4 Commits
Author SHA1 Message Date
David Benjamin 17b60f1f5a Update releasing docs slightly
Change-Id: I0c60698f5277c500fad1c85b212565adca39e3c8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/81207
Commit-Queue: Lily Chen <chlily@google.com>
Reviewed-by: Lily Chen <chlily@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
2025-08-12 19:02:29 -07:00
Bob Beck bf1fe798d0 add some details to releaseing.md
Change-Id: I4367cb284c0f26b6f0eea07ae8e76ca84df080fe
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/72527
Reviewed-by: David Benjamin <davidben@google.com>
Auto-Submit: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
2024-10-25 18:37:59 +00:00
David Benjamin 3dee41147a Note that the tag won't mirror to GitHub immediately
Doing this now and it seems to actually take a bit, which is a bit
annoying.

Change-Id: I85ef8da5054dd6ba6f75768586d48761df9a831b
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/71687
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
2024-10-02 19:46:58 +00:00
David Benjamin fb61601c55 Write custom tooling for publishing to BCR
I had hoped to use Publish to BCR, but there are a few issues with it.

First, a security issue: Publish to BCR requires granting a third-party
app write access to the GitHub repository, even though it only reads
from the repository, which requires no special privileges to read a
repository: https://github.com/bazel-contrib/publish-to-bcr/issues/157

Second, merely cutting a release is not sufficient to satisfy
https://blog.bazel.build/2023/02/15/github-archive-checksum.html
One needs to manually upload a release tarball that GitHub then stores
explicitly. (Perhaps someone should define a deterministic tarball
creation process for git revisions and end this silliness.) Since that
tarball is added by an individual developer, it seems poor that nothing
checks it against the git repository.

The BCR repository itself has some tooling for making a release. It
works by interactively asking questions (not automatable), but then
saves an undocumented JSON file with the answers. I've written a script
that generates the JSON file we need from a git tag. These JSON files
need to reference file paths, so they cannot be made standalone. (See
https://github.com/bazelbuild/bazel-central-registry/issues/2781)
Instead, the script drops everything into a temporary directory.

Since BCR's limitations force us to do a lot of custom processing
anyway, I made the script check that:

1. The release tarball matches the archive tarball, which are stable
   enough in practice. This allows anyone to perform an easy
   (still GitHub-dependent) check that they match, unless GitHub
   changes the hash.

2. The tarball's contents match the git tag in the local repository, so
   we verify GitHub against the developer's workstation.

The script then prints a command to run in a local fork of the
bazel-central-registry repository to make a PR. Alas, even downloading
the tarball from GitHub takes a few seconds, so I had a bit of fun with
the script output.

Change-Id: I2a748309f63848ff097ee3c3e93e11751ef65cd7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/71307
Reviewed-by: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
2024-09-16 19:13:38 +00:00