We are now several layers deep in working around problems in this
language.
Rust's bindgen cannot even bind headers that reference <stdio.h> without
tripping a Rust warning due to
https://github.com/rust-lang/rust-bindgen/issues/2807
As a result we need to manually suppress the warning. However, that
warning is not available until newer Rusts, so trying to suppress the
warning causes a different warning in older Rusts.
https://boringssl-review.googlesource.com/c/boringssl/+/80707 attempted
to work around this Rust bug by using cfg_version, but that broke the
Chromium build because it is not part of Stable Rust. Stable Rust has
not yet caught up to C89 in having some way to condition code on
version.
Instead, suppress the future lint by just suppresing unknown lints. Also
add some comments so we remember where all this nonsense came from.
This unbreaks the Chromium roll.
Change-Id: I47dcedadae5695b2edab05dfbc08a9cd8cfafdc1
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/80747
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The `unnecessary_transmutes` lint was added in Rust 1.88 and will warn
when used unconditionally with prior Rust releases. This can break the
build when downstream users treat warnings as errors (even if they
shouldn't). Enabling this lint on Rust versions that supports it avoids
triggering any new warnings or errors.
Test: build bssl-sys with Rust 1.87 and 1.88; verify lack of warnings
Change-Id: Id038e359a763dc608cd389a90829dc035d9232d3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/80707
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
The bindgen output contains unnecessary transmutes, which produce
compiler warnings by default. They are not actionable, so suppress these
warnings to reduce noise.
All 5 of the unnecessary transmute warnings come from bindgen's handling
of bitfields in the FILE struct. Bindgen uses transmute for bitfields
even when it could instead use a cast_(un)signed, or transmutes an
integer type to itself; this is a known issue [1].
[1] https://github.com/rust-lang/rust-bindgen/issues/2807
Change-Id: I402873725ce83c0aef699339a74982a808edd713
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/80467
Auto-Submit: Lily Chen <chlily@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Historically, sha.h included both SHA-1 and SHA-2 functions. But SHA-1
functions mostly shouldn't be used now, and it's useful to be able to
audit at the level of header names in some contexts.
Therefore move SHA-2 things into a new sha2.h. In order not to break
everything, sha.h now includes sha2.h so no changes are needed in
existing callers.
Change-Id: I68d5e991f58a1c74ca377ba017caaff356acc870
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/80327
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
CMake expects you to provide your link lines in the right order for
platforms without rescanning linkers. When they're not in the right,
it'll preserve your order but duplicate transitive dependencies. That
is, if:
A -> C B
B -> C
The final link line will be:
A C B C
Wheras if A wrote B C then there would be no duplication. Newer macOS
toolchains (which do not need the duplication) seem to warn on duplicate
libraries, which is how I noticed this.
That said, this is not actually sufficient to avoid duplication and thus
the warning. Consider:
A -> B D
B -> C D
CMake always lists direct dependencies before transitive ones, so the
result will be:
A B D C D
decrepit_test triggers this because decrepit_test does not directly
depend on ssl but decrepit does. It's a bit awkward to have to list it
again, but adding it avoids this issue.
Newer CMakes (3.31) now know that:
1. macOS rescans dependencies so the dependencies don't have to be in
order.
2. macOS has this warning so it should dedup things.
However, even updating to 3.31 isn't sufficient because CMake keys all
behavior changes on cmake_minimum_required. I didn't set the target
policy version because I figure testing it at 3.16's behavior is
probably useful for the sake of keeping 3.16 hopefully working.
Change-Id: Ibb006eefbbb23f1899ef91277465d31fa8202d2e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/77747
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
We use the standard Apache 2.0 file header, described in "APPENDIX: How
to apply the Apache License to your work."
This was primarily automated by running:
git ls-tree -r --name-only HEAD | xargs go run ./util/relicense.go
See go/boringssl-relicensing-triage for the results of triaging the
output of the tool.
As part of this, switch from taking fiat-crypto under MIT license to
Apache 2.0. (It is licensed under MIT OR Apache-2.0 OR BSD-1-Clause.)
The copyright_summary tool can also be used to confirm we didn't
accidentally drop any copyright lines:
# Run before the CL
git grep -l Copyright | xargs go run ./util/copyright_summary.go -out /tmp/old.json
# Run after the CL
git grep -l Copyright | xargs go run ./util/copyright_summary.go -compare /tmp/old.json
Bug: 364634028
Change-Id: I17c50e761e9d077a1f92e25969e50ed35e320c59
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75852
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Following the guidance in
https://opensource.google/documentation/reference/releasing/authors,
start maintaining an AUTHORS file.
Update all existing Google copyright lines to 'The BoringSSL Authors'
per the document. This CL also changes the styling to match the new
guidance: removed the '(c)' and the comma.
All other existing copyright lines are left unmodified. Going forward,
our preference will be that new contributions to BoringSSL use 'The
BoringSSL Authors', optionally adding to the AUTHORS file if the
contributor desires.
To avoid being presumptuous, this CL does *not* proactively list every
past contributor in the BoringSSL half of the AUTHORS file. Past
contributors are welcome to send us a patch to be added, or request that
we add you. (Listed or not, the commit log continues to be a more
accurate record, and any existing non-Google copyright lines were left
unmodified.)
The OpenSSL half of the AUTHORS file is seeded with the contents of the
current OpenSSL AUTHORS file, as of writing. The current contents in the
latest revision of the 1.1.1 branch
(b372b1f76450acdfed1e2301a39810146e28b02c) and master
(d992e8729ee38b082482dc010e090bb20d1c7bd5) are identical, just formatted
in text vs Markdown.
Note when reviewing: CONTRIBUTING.md and AUTHORS contain non-mechanical
changes.
Bug: 364634028
Change-Id: I319d0ee63ec021ad85e248e8e3304b9cf9566681
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74149
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Otherwise we get a bunch of warnings:
> unexpected cfg condition name: bindgen_rs_file
While I'm here, drop the authors field. It's no longer accurate as we've
significantly reworked this from Android's original contribution. We
could list the current maintainers, but that's redundant with the git
repo, and bssl-crypto omits it, so let's just omit it.
Change-Id: Ia1b60f1dfa4f4626b5fe2562f35a14ea0ce3aef5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/72627
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
This avoids the need for a custom environment variable in Cargo or GN
builds, including under the soong build. Then Chromium will also be able
to generate bindgen into the OUT_DIR for a sys crate via its GN rules,
as boringssl is the only crate we can find which relies on a custom
environment variable in its sys crate library's include statement.
The idea to copy from a pre-generated location comes from libsqlite3-sys
https://github.com/rusqlite/rusqlite/blob/master/libsqlite3-sys/build.rs
Bazel does not support the OUT_DIR system that is used by Cargo and
every bindgen-based crate that we could find (that didn't write to the
source dir directly). So we keep a cfg around that Bazel rules can
pass when building the bssl-sys crate.
Bug: b/373864033
Change-Id: If8a8aa8a1d8a00ead2e9935a5319bcac2aa09d1f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/72487
Reviewed-by: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Now that we don't depend on external CRYPTO_library_init calls or the
static initializer to initialize CPU capabilities, we can drop a ton of
code.
This makes CRYPTO_library_init, and all its wrappers, into no-ops and
drops the (non-FIPS) static initializer. I've added an internal
OPENSSL_init_cpuid function for the places where the library actually
needs to initialize the CPU vector.
Note this slightly changes the default, previously
static-initializer-full build: previously, CRYPTO_library_init was a
no-op and we relied on the static initializer. Now we uniformly use
CRYPTO_once. This should be an atomic read in the steady state and
essentially free. We can restore the static initializer by default if
this ends up being a problem, but having only one mode is more
straightforward. This also avoids problems if an application calls into
BoringSSL during its own static initializer. Static initializers are not
coherently ordered.
Update-Note: The BORINGSSL_NO_STATIC_INITIALIZER build option and
CRYPTO_library_init are now unnecessary. Once updating past this
revision, those options can now be cleaned up from downstream projects.
Fixed: 40644931
Change-Id: Idc2e6ea7a73d6352e0360fd886c46d88dba3568c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69508
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This CL adds a re-export for `CBS_init` and
`CBS_len`, since these are declared as `OPENSSL_INLINE` and are
thus unavailable currently since inline support is not yet merged.
It also changes the existing wrappers for inline functions
to re-exports too.
Note: this is required to land the boringssl update in AOSP.
Test: m checkbuild
Change-Id: Ic6e2927d7a79b788a4ed0380cf27b3557b6f6f64
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68327
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Matthew Maurer <mmaurer@google.com>
Commit-Queue: Ellen Arteca <emarteca@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Android are currently using a sed line to replace our include! to a
module import. As those don't quite behave the same, and we don't want
to carry patches (even as sed lines) downstream like this, we need to
find a convention that works for everyone.
Most of the Rust world uses environment variables to communicate between
the build system and source. However, rather than principled convention,
where each target was passed in a separate environment variable, Rust
picked an inflexible convention of setting an OUT_DIR variable, and then
hardcoding everything else relative to it. It simply assumes the build
placed everything in that directory.
This is problematic for more complex build systems, which would now take
on I/O costs to copy files around into where Rust wants. It's also less
convenient for the build file author. So, instead we went with an
environment variable that carries the entire path. This has worked out,
except that Android's build tool, Soong, cannot express this! It has no
way to specify that some build product's path should be passed in via
some environment variable.
Soong does, however, have some (less preferred, less efficient) way to
emulate the OUT_DIR behavior, by copying files around until it's in the
place that the Rust convention expects. So introduce that option too,
gated on cfg(soong).
Update-Note: When this rolls into Android, remove the sed logic from
Android.bp and instead set up the OUT_DIR cargo emulation.
Bug: b:291253039
Change-Id: Id0afe9259f15f041c953dc5ad945cb9eda24ffc7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68048
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
As with all FFI libraries, the Rust conventions around safety don't
really work well. There's a ton of noise from bindgen needing to
conservatively mark everything unsafe, obscuring true safety sharp edges
like Rust's FFI-incompatible empty slice representation.
Change-Id: I2199e61b4900a01e3610772063765c5bb0cb493c
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66287
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Due to https://github.com/rust-lang/rust-bindgen/issues/923, bindgen
does not evaluate constants correctly. This means arithemetic is done
with the wrong type, and more importantly the output has the wrong type.
Ultimately, this is a bug in bindgen, but as that's remains unfixed,
we'll have to work around it.
rust-openssl's bindgen mode works around this by using the build.rs
bindgen driver and registering a callback to fix the type. This won't
work for some of our consumers, which require a hermetic and
reproducible builds. Instead, apply bssl-sys's workaround at the lib.rs
level. This removes a divergence between bssl-sys and rust-openssl's
bindgen mode.
Fixing these types does not mean we recommending using all of these
constants! Many of the options here are ill-defined or produce even more
ambiguous output than most. XN_FLAG_COMPAT is especially fun because it
change the calling convention! The only option anyone should use is
XN_FLAG_RFC2253, as that's at least a well-defined output.
Fixed: 636
Change-Id: Id34b4a46e0cfd6dcb275477d9bb915bda66c787d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/66228
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This removes the need to hand-write rust_wrapper.c, because bindgen can
generate it for us. bindgen 0.65 or later is needed. Earlier versions of
this were buggy.
I've also removed the claim that bssl-sys is somehow a solution for
version skew. That was the original thinking from Android, but it hasn't
worked out. The version skew solution is simply "use bindgen, don't
handwrite bindings".
Android are quite behind their originaly July timeline for adding the
build half of this mechanism, but as this is now in the way of other
work, we're going to proceed with using this now. There is now a
unsupported_inline_wrappers cfg that Android can set to use the old
mechanism.
Update-Note: Rust support now requires your build correctly handle
--wrap-static-fns. On Android, you will need to enable the
unsupported_inline_wrappers cfg option until b/290347127 is fixed.
Chromium doesn't actually use any of the inline functions yet, so we can
handle --wrap-static-fns asynchronously, but I have a CL ready to enable
that.
Fixed: 596
Change-Id: I51fd1108a8c17a06f1bdd9171ebf352cea871723
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58985
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Given all the previous changes, the version should be bumped. Also
the license was wrong: new code in BoringSSL is ISC licensed and
the license at the top of the Rust files is the ISC license.
Change-Id: If8a5baa5b631145f85ec85b430dbfe8ffd2044bf
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/65181
Reviewed-by: Bob Beck <bbe@google.com>
Due to b/290792019 and b/290785937, we need them to actually exist at
the original symbols. For all of Rust's language-level safety benefits,
the ecosystem seems determined to undo it with patterns that are even
less safe than C.
This is not great and the bugs need to be fixed, but do this for now to
unblock the Android update.
Change-Id: Ia883336879779f652e7320cecdd5ca843996f6a3
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/61525
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Instead, just have it look for the files it needs via a
BORINGSSL_BUILD_DIR environment variable. This avoids hardcoding
"../../build" anywhere that cannot be easily overriden by the user.
Although this puts logic in a build.rs file, which is problematic for
repositories with more coherent build stories like Android or Chromium,
those are already driving the bindgen and link process themselves,
without calling CMake. I.e. this file should already only be used for
standalone development and testing and not directly impact them. (Though
we'd like to keep it vaguely analogous to better predict without a
change will impact downstream folks.)
For now, I've kept bindgen generated from CMake, mostly in anticipation
of using the inline functions feature. Building the synthesized C file
from CMake seems less of a headache than Cargo. Additionally, calling
bindgen from the command-line is closer to how those consumers will do
it, so this forces us to stick to bindgen invocations that can be
expressed via command-line arguments. (E.g. the mess that is regexes and
escaping.)
As part of this, I've removed the messy "find the first matching wrapper
file" behavior in build.rs. Instead, it knows the expected TARGET and
just finds the file with matching name. This means we'll be stricter
about matching the two. (Otherwise there's no point in naming it by
target name anyway.)
Fixed: 598
Change-Id: I07fa74f7e5f5f008d6f0ceec648a2378df7d317a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59105
Reviewed-by: Matthew Maurer <mmaurer@google.com>
Reviewed-by: Nabil Wadih <nwadih@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
The allowlist is just a regex, which means bindgen leaves it to the
user to resolve Windows vs POSIX filepath differences. We need to
support both / and \. It's unclear why only some headers are broken, but
it's probably something to do with whether the header is included
directly or indirectly.
Unfortunately, in doing so, we run into a mess of escaping issues, so
the regex is more permissing than ideal.
Bug: 595
Change-Id: I8b785aeaaeff162d9eb2aced89928f9602445903
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58967
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
David Benjamin