| commit | 581f83dcdbbbe827ca8eda20b85ec869b8be1e99 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Tue Sep 10 19:04:36 2024 -0400 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Fri Sep 13 22:52:17 2024 +0000 |
| tree | d8fba820b195b89c722cea193e6c5256ffac6536 | |
| parent | d9ad235cd8c203db7430c366751f1dddcf450060 [diff] |
Prepare to tag 0.20240913.0 as the first periodic snapshot BoringSSL is a "live at head" project and does not make release branches and thus releases. However, some systems cannot consume git revisions and expect git tags. In Bazel Central Registry's case, the toolchain is suspicious of non-"release" archives of https://github.blog/open-source/git/update-on-the-future-stability-of-source-code-archives-and-hashes/ To accommodate such systems, let's start periodically tagging snapshots as "releases". These versions do not represent any kind of stability or development milestone. BoringSSL does not branch at these releases and will not cherry-pick bugfixes to them. Unless there is a technical constraint to use one of these revisions, projects should simply use the latest revision when updating. Also, so that cutting such revisions is less tedious, probably the simplest is to set MODULE.bazel's version field in HEAD to whatever the last revision was. The process will then be: 1. Bump MODULE.bazel's version 2. Create a git tag 3. Create a GitHub "release" 4. Kick off a BCR update All that mess will ideally be automated, but for now we'll drive that manually. Update INCORPORATING.md to explain these tags, and also to discuss the new pregenerated build files. Versioning scheme is chosen as 0.YYYYMMDD.N so that: - It is deterministic from the date - It begins with zero lest anyone misinterpret these as semver versions - We have a digit at the end to bump when we need to cut two revisions in one day Change-Id: Ie256a5f0f7eaac5928b537c75f82402c934f9fc3 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/71227 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: