Implemented a generic Aead trait and struct against the EVP_AEAD
API's, which can be used to provide bindings to all of the AEAD's
provided by boringssl. Starting with AES_GCM_SIV, but will expand
to more AEAD's.
Change-Id: I7d4113f3d49ff40de3ccb76424f9a25d25797e82
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/59965
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: 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>
This probably needs a few iterations, but fix the stuff I noticed on a
first pass:
- I don't think it's useful to say this is the BoringSSL implementation
of something. That's all implicit from this crate anyway.
- Rust seems to prefer "Returns ..." rather than "Return ..."
- Algorithm names like "hkdf" or "hmac" should be written "HKDF" or
"HMAC" when referring to the algorithms. Also BoringSSL is styled
"BoringSSL" rather than "boringssl".
- Given Rust overall doesn't try to handle allocation failure, let's
just write that we don't believe in allocation failure once in the
README rather than marking which functions do and don't panic.
Change-Id: I48501717dd0b063a2fa4106c4c140d76a7ef69a9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60546
Reviewed-by: Nabil Wadih <nwadih@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@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>
If another project includes us as a subproject, as gRPC does,
CMAKE_SOURCE_DIR points to the top-level source directory, not ours.
PROJECT_SOURCE_DIR points to ours. Likewise, CMAKE_BINARY_DIR will
point to the top-level one.
gRPC doesn't consume this CMake build, but in preparation for
eventually unifying the two CMake builds, replace CMAKE_SOURCE_DIR and
CMAKE_BINARY_DIR with a combination of CMAKE_CURRENT_{SOURCE,BINARY}_DIR
and PROJECT_SOURCE_DIR.
There's one more CMAKE_SOURCE_DIR which controls some default install
directory. I've left that one alone for now as I'm not sure what to do
with it. Probably the answer is to, like in gRPC, disable the install
target by default when we're not the top-level source directory.
Bug: 542
Change-Id: Iea26bbef8a4637671fd0e7476101512e871e7e18
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57686
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
bindgen, by default, will bind every random symbol in the libc, which is
clearly unreasonable. Now that --allowlist-file exists, we can switch to
doing what it should have done from the beginning.
This produces a pretty large diff in the bindgen output, but it's all to
exclude miscellaneous bits of libc.
Change-Id: I9a35fda10ff6f1b82449919f9fcc2ea86ad5b802
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/57325
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Alex Gaynor <alex.gaynor@gmail.com>
Reviewed-by: Bob Beck <bbe@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
It's unclear to me whether doing it target-by-target is an improvement
in crypto/fipsmodule, but this otherwise does seem a bit tidier. This
aligns with CMake's documentation and "modern CMake" which prefers this
pattern.
Change-Id: I36c81842bff8b36eeaaf5dd3e0695fb45f3376c9
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56585
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
Without this, it was using the headers from /usr/include, and on my
machine it failed with the following:
```
$ cmake .. -DRUST_BINDINGS=$(gcc -dumpmachine) && make
/boringssl/rust/rust_wrapper.c: In function
‘ERR_GET_FUNC_RUST’:
/usr/local/google/home/yukl/boringssl/rust/rust_wrapper.c:27:10: error:
implicit declaration of function ‘ERR_GET_FUNC’; did you mean
‘ERR_GET_LIB’? [-Werror=implicit-function-declaration]
27 | return ERR_GET_FUNC(packed_error);
| ^~~~~~~~~~~~
| ERR_GET_LIB
```
Change-Id: Ia34830c939f32a8807e1c8be03d962c21dfc1635
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/55932
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Matthew Maurer <mmaurer@google.com>
Reviewed-by: Adam Langley <agl@google.com>
The C11 change has survived for three months now. Let's start freely
using static_assert. In C files, we need to include <assert.h> because
it is a macro. In C++ files, it is a keyword and we can just use it. (In
MSVC C, it is actually also a keyword as in C++, but close enough.)
I moved one assert from ssl3.h to ssl_lib.cc. We haven't yet required
C11 in our public headers, just our internal files.
Change-Id: Ic59978be43b699f2c997858179a9691606784ea5
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/53665
Auto-Submit: David Benjamin <davidben@google.com>
Commit-Queue: Bob Beck <bbe@google.com>
Reviewed-by: Bob Beck <bbe@google.com>
When a rust crate uses the boringssl rust bindings like:
```Cargo.toml
[dependencies]
bssl-sys = { path = "./third_party/boringssl/build/rust" }
```
The working directory of `build.rs` is set to the the crate's
working directory so "." and ".." aren't relative to the bindings'
directory. Use CARGO_MANIFEST_DIR to specify link search paths.
Change-Id: Ieb49f4ab479f47390388dc5ace70561f593dc238
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/51645
Reviewed-by: David Drysdale <drysdale@google.com>
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
This is designed to be the minimal infrastructure required to support
using BoringSSL in the Rust ecosystem without fear of ABI drift. Bindgen
is used to generate Rust bindings in lockstep with the rest of the
build. `rust-openssl` can consume these generated bindings with minimal
changes.
Change-Id: I1dacd36a4131e22a930ebb01da00407e8465ad7e
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/49645
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
Maurice Lam