| commit | 3a138e43694c381cbd3d35f3237afed5724a67e8 | [log] [tgz] |
|---|---|---|
| author | David Benjamin <davidben@google.com> | Thu Aug 29 13:41:37 2024 -0400 |
| committer | Boringssl LUCI CQ <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com> | Thu Aug 29 18:33:42 2024 +0000 |
| tree | 8f1aef18c4e5ca0d58024fa03a95ed441cecf748 | |
| parent | d2638490679527185fe9817e24eca316acc93d96 [diff] |
Rename bcm.c fragments to foo.c.inc Having the files named .c but included causes a ton of problems with build systems. Many of our build systems care about three categories of files: - public headers, available to downstream targets - source files, each of which is compiled as a compilation unit - internal headers, not available to downstream targets There is usually a check, in Bazel called layering_check that enforces source files only include headers that are declared somewhere appropriate. The bcm.c fragments, under this classification, are internal headers. However, in both GN and Bazel, internal headers and sources both go in the source list. They are distinguished only by file extension. When FIPS fragments have a .c file extension, they are misinterpreted as source files, and many things break. Rename them. Either .h and .inc would be sufficient. Because we had to disable Bazel's parse_headers feature, there is no difference (AFAICT) in their handling. Also, these files actually pass the parse_headers feature, even though they don't have an include guard. Still, the tech of the style guide suggests that .inc is probably the better file extension. https://google.github.io/styleguide/cppguide.html#Self_contained_Headers I used .c.inc rather than plain .inc so that we can easily rename them back to .c when we solve https://crbug.com/362530616. Note that, as .inc is not as common of a file extension, people working on BoringSSL may need to reconfigure their editors to map .inc to C/C++. Update-Note: Some downstream builds have been working around this by building the fragments individually and excluding bcm.c. This change will break those workarounds but also remove the need for it. It should now be consistently possible to build BoringSSL without modifying the file list. Bug: 362664827 Change-Id: I933115c37843317a066e24a1092728c9afce35f5 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/70689 Reviewed-by: Bob Beck <bbe@google.com> Commit-Queue: Bob Beck <bbe@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: