Keeping it to X25519/Ed25519 for now, but arguably we could pick "raw"
options for most of our keys. The problem is just when there's a couple
different options. (ECPrivateKey or just the serialized scalar for EC
keys, compressed vs uncompressed points.)
Bug: 42290364
Change-Id: I1e1a0a3fa971f27a962946301091ebe11bac2725
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/81667
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
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>
Define a workspace in rust/ so that bssl-sys and bssl-crypto crates can
be built and tested at once from the rust/ directory:
cd rust
cargo build --workspace
cargo test --workspace
(The --workspace arg is optional since this is a virtual manifest; the
default is the whole workspace.)
Change-Id: I88fb738a96837ce19b53fdaeabe91491fa0240fd
Bug: 42290446
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/80527
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Auto-Submit: Lily Chen <chlily@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>
These algorithms depend on `new_uninit`, which was only made stable with
Rust 1.82. To allow consumers to catch up, this change gates
ML-{KEM,DSA} support in `bssl-crypto` behind a (non-default) feature.
Change-Id: I6ffe60560a4dc0f802564c56498f6a0a073d94da
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/75027
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Auto-Submit: Adam Langley <agl@google.com>
This reverts commit d678fbfb48.
The original change broke Chromium:
```
error[E0725]: the feature `new_uninit` is not in the list of allowed features
--> ../../third_party/boringssl/src/rust/bssl-crypto/src/lib.rs:28:12
|
28 | #![feature(new_uninit)]
| ^^^^^^^^^^
```
Change-Id: I6732a720a5705cfe7b0219b5d9d02a911af0f89a
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/74987
Auto-Submit: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@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>
since this gets a slice both by using get_mut
with unwrap, and just directly getting a reference
to a slice, make them both use get and unwrap
and fix both clippy warnings.
Change-Id: I5a7870a342ae7dd9d41fbae1afbb70cc44df98c0
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/72588
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Bob Beck <bbe@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>
This CL moves some methods that exist in every hashing algorithm
implementation to the `Algorithm` trait; namely, `new`, `update`,
and `digest`. This allows for clients to instantiate the hashing
algorithms, and to call `update` and `digest` on objects that
have this trait. It allows a generic representation of an algorithm
that can be used.
In order to avoid users of concrete instance of `Algorithm` to have
to import `Algorithm` and every time they want to
use the functions implemented, these functions are also included in
the inherent implementation of each algorithm (as it was originally
set up, except that now the methods call the equivalent method in the
Algorithm implementation'
This CL also adds the block size as a const field in the `Algorithm`
trait.
Note: this specifically supports the hashing algorithm use in the
style of what is done in AOSP's
`packages/modules/Virtualization/libs/apkverify`, which was previously
using the rust openssl `Hasher` to instantiate algorithms specified
by their `MessageDigest`.
Redoing Ic47691ee2a4303923519b246de7d9724da90f60d which has since
been reverted.
Change-Id: Ib7c02e79952491d814bb49a1ff8f23271b716414
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69387
Commit-Queue: Ellen Arteca <emarteca@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@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 reverts the following commits:
e1a860c374a11277e18725cf1bb965
There were a couple nuisances caused by this change, stemming from a
Rust language deficiency. If you move a method from a type to a trait,
this is a backwards-incompatible change that is visible to the caller.
That is, Rust does not allow introducing abstractions in a
backwars-compatible way!
This meant you had to import Algorithm to use a hash. This made updating
downstream code hard, but at least par for the course with Rust. It
seems Rust just isn't a language where API stability and library
evolution are possible.
However, even after we pay the transition costs, downstream code needed
to import WithOutputLength. This is too much of an implementation detail
to leak into the public API, so revert it for now. We'll need to find
some way to do this that keeps the public API reasonable.
Change-Id: I82d00b47a77fe77b5893b1e9b15faef727ef9866
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/69227
Reviewed-by: Bob Beck <bbe@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
This CL moves some methods that exist in every hashing algorithm
implementation to the `Algorithm` trait; namely, `new`, `update`,
and `digest`. This allows for clients to instantiate the hashing
algorithms, and to call `update` and `digest` on objects that
have this trait. It allows a generic representation of an algorithm
that can be used.
This CL also adds the block size as a const field in the `Algorithm`
trait.
Note: this specifically supports the hashing algorithm use in the
style of what is done in AOSP's
`packages/modules/Virtualization/libs/apkverify`, which was previously
using the rust openssl `Hasher` to instantiate algorithms specified
by their `MessageDigest`.
Change-Id: Ic47691ee2a4303923519b246de7d9724da90f60d
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/68748
Commit-Queue: Ellen Arteca <emarteca@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@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>
David Benjamin