The compiler complained that `words` is never read in situations where
it is passed to the assembly code as a `Key`, relying on `Key` being
`#[repr(transparent)]`.
We've been moving away from using `repr(transparent)` for these kinds of types. Do
that here to solve this problem and also to continue that general trend. Use
`words_less_safe()` instead of directly accessing `words` to reduce the amount of
conditional logic.
Don't try to share logic between sealing and opening, so that we can clarify
the assumptions and simplify the implementation.
This will enable future improvements to the internal AEAD API.
Avoid trying to have common logic inside the `aead()` function in favor
of having specialized control flow within each of `seal()` and `open()`.
This will enable future improvements to the internal AEAD API.
macos-11.0 is pre-production. Use macos-latest instead, to (I hope)
make macOS jobs more likely to succeed. (Presently, they frequently
fail with no logs.)
Upgrade to Xcode 12.4 in hopes that this will make things work.
Inline the implementation of the old `open_within_` function into
`LessSafeKey::open_within`. Rename the inner `open_within` function to
`open_within_`.
Implement `UnboundKey`, `OpeningKey`, and `SealingKey` in terms of
`LessSafeKey`. Ultimately those key types are restrictoins on the
interface of `LessSafeKey`. It wasn't done this way previously because
we had the idea that code that uses `BoundKey` shouldn't ever touch
`LessSafeKey`. That sounded nice in theory, but the unintended result
was that we introduced code duplication and otherwise made things harder
to understand. Continuing on the previous path would have seen us
duplicate `LessSafeKey` as `KeyInner` or something similar.
Now each bound key opening/sealing function is implemented in terms of
the same-named function in `LessSafeKey`.
Replace the old `LessSafeKey::new()` with an implementation of
`From<UnboundKey>`.
This is a very very basic sanity check on k generation, but it helps
make sure we haven't *completely* disconnected the RNG.
Change-Id: If7ae5dd6be3d0866962cd966b8c1ed1cdedffb50
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45865
Reviewed-by: Adam Langley <agl@google.com>
Trusty requires its own trusted app to implement the ACVP modulewrapper
functionality for validation. Separate the frontend from the generic
functions that implement each algorithm.
Change-Id: I86802b66c627ce4f5b5ddd54555a386e8e993eed
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45604
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: Adam Langley <agl@google.com>
Make sure the recent changes to the builders all work.
Change-Id: I0eca1b7732da29a14325673deeb031c8863b45b8
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45724
Reviewed-by: David Benjamin <davidben@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
These are ultimately just the upstream tarballs, but it's one less
ad-hoc script to maintain.
Change-Id: Ia93a7a9d4944d482e4e4137587998790e8e59294
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45784
Commit-Queue: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>
Newer versions of CMake have some fix for default libraries on
Windows/ARM64. (Not sure exactly what version, but the latest CMake does
seem to work.)
While trying to update the others, it turns out my workstation no longer
makes CMake builds compatible with the builders. It's also tedious that
updating CMake requires making builds myself. Fortunately, Chrome infra
is maintains some packages of third-party software in CIPD.
However, they don't make Windows CMake builds (filed
https://crbug.com/1180257 to request them), and they're stuck on 3.13.x
(blocked on https://crbug.com/1176531).
So, this CL switches to CIPD for Mac/Linux, with the latest version they
have available. It sticks with the old method (uploading copies of
upstream's packages) for Windows and grabs the latest version. When both
of the bugs above are fixed, hopefully things will be more uniform.
Change-Id: I710091fc60594165738a893b2be73cdcef54dfe2
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/45764
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>
