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>
5 files changed
tree: 28da666ef958f6c60b2a3453ec22636a46e9e3d6
  1. .bcr/
  2. .github/
  3. cmake/
  4. crypto/
  5. decrepit/
  6. docs/
  7. fuzz/
  8. gen/
  9. include/
  10. pki/
  11. rust/
  12. ssl/
  13. third_party/
  14. tool/
  15. util/
  16. .bazelignore
  17. .bazelrc
  18. .clang-format
  19. .gitignore
  20. API-CONVENTIONS.md
  21. BREAKING-CHANGES.md
  22. BUILD.bazel
  23. build.json
  24. BUILDING.md
  25. CMakeLists.txt
  26. codereview.settings
  27. CONTRIBUTING.md
  28. FUZZING.md
  29. go.mod
  30. go.sum
  31. INCORPORATING.md
  32. LICENSE
  33. MODULE.bazel
  34. MODULE.bazel.lock
  35. PORTING.md
  36. PrivacyInfo.xcprivacy
  37. README.md
  38. SANDBOXING.md
  39. STYLE.md
README.md

BoringSSL

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: