- Copy
https://pkg.go.dev/github.com/letsencrypt/pebble/v2/cmd/pebble-challtestsrv
to `test/chall-test-srv`
- Rename pebble-challtestsrv to chall-test-srv, consistent with other
test server naming in Boulder
- Replace Dockerfile go install with Makefile compilation of
`chall-test-srv`
- Run chall-test-srv from `./bin/chall-test-srv`
- Bump `github.com/letsencrypt/challtestsrv` from `v1.2.1` to `v1.3.2`
in go.mod
- Update boulder-ci GitHub workflow to use `go1.24.1_2025-04-02`
Part of #7963
Add a new boulder service, email-exporter, which uses the Pardot API
client added in #8016 and the email.Exporter gRPC service added in
#8017.
Add pardot-test-srv, a test-only service for mocking communication with
Salesforce OAuth and Pardot APIs in non-production environments. Since
Salesforce does not provide Pardot functionality in developer sandboxes,
pardot-test-srv must run in all non-production environments (e.g.,
sre-development and staging).
Integrate the email-exporter service with the WFE and modify
WFE.NewAccount and WFE.UpdateAccount to submit valid email contacts.
Ensure integration tests verify that contacts eventually reach
pardot-test-srv.
Update configuration where necessary to:
- Build pardot-test-srv as a standalone binary.
- Bring up pardot-test-srv and cmd/email-exporter for integration
testing.
- Integrate WFE with cmd/email-exporter when running test/config-next.
Closes#7966
Feedback from SRE was to just go straight to the new packaging.
Also, fix the Architecture field of the .deb to be amd64 (Debian
requires this specific value), and check that we are building on x86_64
OR amd64.
We recently started getting these errors in CI:
```
ERROR: Error installing fpm:
The last version of rchardet (~> 1.8) to support your Ruby & RubyGems was 1.8.0. Try installing it with `gem install rchardet -v 1.8.0` and then running the current command again
rchardet requires Ruby version >= 3.0.0. The current ruby version is 2.7.0.0.
```
Installing specific versions of dependencies fixes it.
Boulder switched from multiple binaries to one by having symlinks for
the old binaries, but we invoke boulder via subcommands now. This drops
support for running via symlinks in Boulder, and drops them from the
build process.
This does explicitly list out the four binaries in the makefile, which I
think explicitly listing them is fine given that we rarely add them.
This also avoids needing to duplicate mentioning the special ct-test-srv
in the deb/tar rules. We could probably just look at what's in `bin/`
after `go install ./...`, but I didn't want to get too into makefile
changes.
We haven't used the symlinked versions of commands for a while, and can
drop them from builds.
This also drops the .rpm builds, which we also haven't used in a long
time.
Adds a nameid tool to the boulder tools directory for SRE use. The
existing local and github CI framework correctly catches build failures
of this directory.
Examples of usage:
```
$ go run ./tools/nameid/nameid.go test/certs/webpki/int-ecdsa-c.cert.pem test/certs/webpki/int-rsa-a.cert.pem
test/certs/webpki/int-ecdsa-c.cert.pem: 56560759852043581
test/certs/webpki/int-rsa-a.cert.pem: 29947985078257530
$ go run ./tools/nameid/nameid.go -s test/certs/webpki/int-ecdsa-c.cert.pem test/certs/webpki/int-rsa-a.cert.pem
56560759852043581
29947985078257530
```
Fixes https://github.com/letsencrypt/boulder/issues/7469
The code path is now adequately tested in CI with try-release.yml. This
means it will no longer be automatically tested locally with `./t.sh`,
but it can be manually tested locally with `./tools/make-assets.sh`.
Also, to ensure CI has similar coverage to the old make-artifacts phase,
change make-deb.sh to make-assets.sh, and have it make all of rpm, deb,
and tar.
Change release.yml so it uploads the .tar.gz as well as the .deb.
Create a GitHub Actions workflow that creates a PR to update
the publicsuffix-go dependency. This workflow runs monthly,
or whenever we choose to trigger it manually.
Fixes#5796
Add a new code path to the ctpolicy package which enforces Chrome's new
CT Policy, which requires that SCTs come from logs run by two different
operators, rather than one Google and one non-Google log. To achieve
this, invert the "race" logic: rather than assuming we always have two
groups, and racing the logs within each group against each other, we now
race the various groups against each other, and pick just one arbitrary
log from each group to attempt submission to.
Ensure that the new code path does the right thing by adding a new zlint
which checks that the two SCTs embedded in a certificate come from logs
run by different operators. To support this lint, which needs to have a
canonical mapping from logs to their operators, import the Chrome CT Log
List JSON Schema and autogenerate Go structs from it so that we can
parse a real CT Log List. Also add flags to all services which run these
lints (the CA and cert-checker) to let them load a CT Log List from disk
and provide it to the lint.
Finally, since we now have the ability to load a CT Log List file
anyway, use this capability to simplify configuration of the RA. Rather
than listing all of the details for each log we're willing to submit to,
simply list the names (technically, Descriptions) of each log, and look
up the rest of the details from the log list file.
To support this change, SRE will need to deploy log list files (the real
Chrome log list for prod, and a custom log list for staging) and then
update the configuration of the RA, CA, and cert-checker. Once that
transition is complete, the deletion TODOs left behind by this change
will be able to be completed, removing the old RA configuration and old
ctpolicy race logic.
Part of #5938
Generate .deb packages for all currently configured Go versions
(usually the current and upcoming versions that we use in prod), rather
than just the one default version. Also ensure that the uploaded
artifacts have 8-character short hashes in their names.
Unfortunately this does require updating Go versions in one additional
place (the release.yml file), since we are no longer parsing it out of the
docker-compose.yml. This is unavoidable without hacks that I consider
to be even uglier than the repetition.
Fixes#6075Fixes#6084
This allows us to narrow permissions by only granting write privileges
to the upload portion of the job (which doesn't run any code from our
repo). It also allows us to verify that the release build works on every
commit, while only generating releases on actual release tags.
Go releases are PGP-signed with a key from
https://www.google.com/linuxrepositories/. We can improve our confidence
in the provenance of our Go binaries by verifying that signature. This
adds a script that encapsulates the public key, the fetch, and the
verification, outputting go.tar.gz once it's verified.
So far this only adds to the release workflow in CI. It needs a little
more thought about how to organize boulder-tools so it can consume
fetch-and-verify-go.sh (which is in a different directory and therefore
not part of the input to `docker build`).
Jacob Hoffman-Andrews
Samantha Frank
Matthew McPherrin
Phil Porada
Aaron Gable