commit | fb61601c5583583140a3b500f8ec9df4829675cf | [log] [tgz] |
---|---|---|
author | David Benjamin <davidben@google.com> | Sat Sep 14 23:36:08 2024 -0400 |
committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Mon Sep 16 19:13:38 2024 +0000 |
tree | 28da666ef958f6c60b2a3453ec22636a46e9e3d6 | |
parent | ea0f16439301e278110f94e723f50774f8bc2904 [diff] |
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>
BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.
Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.
Programs ship their own copies of BoringSSL when they use it and we update everything as needed when deciding to make API changes. This allows us to mostly avoid compromises in the name of compatibility. It works for us, but it may not work for you.
BoringSSL arose because Google used OpenSSL for many years in various ways and, over time, built up a large number of patches that were maintained while tracking upstream OpenSSL. As Google's product portfolio became more complex, more copies of OpenSSL sprung up and the effort involved in maintaining all these patches in multiple places was growing steadily.
Currently BoringSSL is the SSL library in Chrome/Chromium, Android (but it's not part of the NDK) and a number of other apps/programs.
Project links:
To file a security issue, use the Chromium process and mention in the report this is for BoringSSL. You can ignore the parts of the process that are specific to Chromium/Chrome.
There are other files in this directory which might be helpful: