The naming of our `precertificates` table (now used to store linting
certificates) is definitely confusing, so add some more comments in
various places explaining. See #6807.
Bumps the aws group with 3 updates in the / directory:
[github.com/aws/aws-sdk-go-v2](https://github.com/aws/aws-sdk-go-v2),
[github.com/aws/aws-sdk-go-v2/config](https://github.com/aws/aws-sdk-go-v2)
and
[github.com/aws/aws-sdk-go-v2/service/s3](https://github.com/aws/aws-sdk-go-v2).
Updates `github.com/aws/aws-sdk-go-v2` from 1.31.0 to 1.32.2
Updates `github.com/aws/aws-sdk-go-v2/config` from 1.27.39 to 1.27.43
Updates `github.com/aws/aws-sdk-go-v2/service/s3` from 1.63.3 to 1.65.3
Updates `github.com/aws/smithy-go` from 1.21.0 to 1.22.0
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Creating the list of authzIDs earlier in NewOrderAndAuthzs:
- Saves a `for` loop with duplicated code; we no longer need to range
over two different slices, just one.
- Allows us to create the Order PB later, after more of the data
collection logic, without interrupting it. This makes the order of
operations slightly easier to follow.
- Add `Perspective` and `RIR` fields to the remote-va configuration
- Configure RVA ValidationAuthorityImpl instances with the contents of
the JSON configuration
- Configure VA ValidationAuthorityImpl instances with the constant
`va.PrimaryPerspective`
- Log `Perspective` for non-Primary Perspectives, per the MPIC
requirements in section 5.4.1 (2) vii of the BRs. Also log the RIR for
posterity.
- Introduce `ValidationResult` RPC fields `Perspective` and `Rir`, which
are not currently used but will be required for corroboration in #7616
Fixes https://github.com/letsencrypt/boulder/issues/7613
Part of https://github.com/letsencrypt/boulder/issues/7615
Part of https://github.com/letsencrypt/boulder/issues/7616
Initialize a slice with a capacity of len(nameToString) rather than initializing
the length of this slice.
Signed-off-by: huochexizhan <huochexizhan@outlook.com>
Updates:
- go.opentelemetry.io/contrib/instrumentation (and subpackages) from 0.52.0 to 0.55.0
- go.opentelemetry.io/otel (and subpackages) from 1.27.0 to 1.30.0
Upstream release notes:
https://github.com/open-telemetry/opentelemetry-go-contrib/releases
Also transitively updates a few golang.org/x/ dependencies, and the grpc and protobuf
dependencies.
This config field duplicates functionality that is better provided by
the blockedKeys database table. We should only have one mechanism for
blocking keys, so this one should be removed.
Mark it deprecated as a warning to any downstream consumers of Boulder.
Part of https://github.com/letsencrypt/boulder/issues/7748
The CAB/F Debian weak keys (https://github.com/cabforum/Debian-weak-keys)
repository contains a bunch of DER encoded private keys that we should ensure
are blocked. I hacked up the block-a-key tool to output a base64 encoded SPKI
hash from an arbitrary PEM formatted private key file.
This is our only use of MariaDB's "INSERT ... RETURNING" syntax, which
does not exist in MySQL and Vitess. Add a feature flag which removes our
use of this feature, so that we can easily disable it and then re-enable
it if it turns out to be too much of a performance hit.
Also add a benchmark showing that the serial-insertion approach is
slower, but perhaps not debilitatingly so.
Part of https://github.com/letsencrypt/boulder/issues/7718
Previously, we logged csr.DNSNames along with the precertificate
issuance events, but this was potentially misleading. For instance, if a
CSR contained only a CN and no SANs, this set would be empty.
Instead, log the uniquified, lowercased, sorted SANs that are actually
issued.
Also, emit precert=[] in issuePrecertificateInner, which is consistent
with the field name used when the final certificate is issued.
Note: this definitely underscores why it would be better to log these
things in a more structured way, for instance logging the
`issuance.IssuanceRequest` encoded as JSON, but I wanted to get these
quick fixes out of the way first.
Add a new SerialPrefixHex field to the CA's config, which takes a
two-character hexadecimal string to use as the serial prefix. This
matches the way that the OCSP Responder's acceptable serial prefixes are
configured, and is easier for human operators to configure than raw
integers.
At the same time, change the type of the CA's internal serial prefix
from `int` to `byte`, using the type system to enforce its 8-bit length.
Fixes#7213
This adds custom spans around one of the more important parts of the
issuance stack - actually signing the (pre)certificates. We only have
automatic tracing right now, so this is just a small step towards adding
more customization there.
One specific note: I didn't include the regID in the span attributes,
though it is in the nearby log lines. I think that's something we likely
want to handle holistically (eg, via baggage propagation) rather than
one-off in manual spans like this.
The Boulder WFE accepts incoming connections (from our load balancers)
via either TLS or plain HTTP. When those connections are made over TLS,
it already enforces that the client be using TLS 1.3 or above. When those
connections are made over plain HTTP, the load balancer includes the TLS
version as a header, and Boulder was performing filtering based on that.
Our load balancers are now configured to reject older TLS versions, so we
can remove this check.
Fixes https://github.com/letsencrypt/boulder/issues/7710
The intention here should be to initialize a slice with a capacity of
len(remaining) rather than initializing the length of this slice, so that
the resulting error message doesn't start with empty-string entries.
OpenTelemetry has "semantic conventions" which are versioned
independently of the software package, as it describes the semantics of
the resources being produced. Previously, we'd combined
`resource.Default()` using the `Merge` function with our own resources.
Merge, however, doesn't handle merging resources with different semantic
conventions. This means that every dependabot PR that bumps otel will
break when the `resources.Default` has a new version.
That doesn't seem worth it for the default resources, so just provide
our own resources which have everything we care about. I've added the
PID which we didn't have before but will be interesting. We will lose
the SDK's version, but I don't think that matters.
For more discussion on this topic, see
https://github.com/open-telemetry/opentelemetry-go/issues/3769
Have the release action write the checksums to a file whose name matches
the name of the boulder deb and rpm files whose checksums it contains.
This prevents name-collision errors when we are running multiple Go
versions side-by-side in CI.
To demonstrate this, augment the try-release action to write the
checksums to the same file, print the list of files it would upload, and
print the contents of the checksums file. Also allow the try-release
workflow to be triggered manually.
Clean up how we handle identifiers throughout the Boulder codebase by
- moving the Identifier protobuf message definition from sa.proto to
core.proto;
- adding support for IP identifier to the "identifier" package;
- renaming the "identifier" package's exported names to be clearer; and
- ensuring we use the identifier package's helper functions everywhere
we can.
This will make future work to actually respect identifier types (such as
in Authorization and Order protobuf messages) simpler and easier to
review.
Part of https://github.com/letsencrypt/boulder/issues/7311
When creating an authorization, populate it with all challenges
appropriate for that identifier, regardless of whether those challenge
types are currently "enabled" in the config. This ensures that
authorizations created during a incident for which we can temporarily
disabled a single challenge type can still be validated via that
challenge type after the incident is over.
Also, when finalizing an order, check that the challenge type used to
validation each authorization is not currently disabled. This ensures
that, if we temporarily disable a single challenge due to an incident,
we don't issue any more certificates using authorizations which were
fulfilled using that disabled challenge.
Note that standard rolling deployment of this change is not safe if any
challenges are disabled at the same time, due to the possibility of an
updated RA not filtering a challenge when writing it to the database,
and then a non-updated RA not filtering it when reading from the
database. But if all challenges are enabled then this change is safe for
normal deploy.
Fixes https://github.com/letsencrypt/boulder/issues/5913
Have our gRPC server interceptor check for excessive clock skew between
its own clock and gRPC client clocks. Do this by taking advantage of the
client request timestamp that most clients already supply for the
purpose of measuring cross-service latency. If the included timestamp is
more than 10 minutes from the gRPC server's local time, immediately
error out.
To keep the integration tests -- which heavily rely on clock
manipulation -- working, use build tags to disable this behavior during
integration testing.
Fixes https://github.com/letsencrypt/boulder/issues/7684
Begin testing on go1.23. To facilitate this, also update /x/net,
golangci-lint, staticcheck, and pebble-challtestsrv to versions which
support go1.23. As a result of these updates, also fix a handful of new
lint findings, mostly regarding passing non-static (i.e. potentially
user-controlled) format strings into Sprintf-style functions.
Additionally, delete one VA unittest that was duplicating the checks
performed by a different VA unittest, but with a context timeout bug
that caused it to break when go1.23 subtly changed DialContext behavior.
Have the WFE ask the RA for authorizations, rather than asking the SA
directly. This extra layer of indirection allows us to filter out
challenges which have been disabled, so that clients don't think they
can attempt challenges that we have disabled.
Also shuffle the order of challenges within the authz objects rendered
by the API. We used to have code which does this at authz creation time,
but of course that was completely ineffectual once we stored the
challenges as just a bitmap in the database.
Update the WFE unit tests to mock RA.GetAuthorization instead of
SA.GetAuthorization2. This includes making the mock more accurate, so
that (e.g.) valid authorizations contain valid challenges, and the
challenges have their correct types (e.g. "http-01" instead of just
"http"). Also update the OTel tracing test to account for the new RPC.
Part of https://github.com/letsencrypt/boulder/issues/5913
Jacob Hoffman-Andrews