Adding a check to `IsInvalid()` before accessing `impl_` in
`Blev2Medium::IsExtendedAdvertisementsAvailable()` to prevent a crash when
`impl_` is nullptr (which occurs when BleV2 is disabled).
PiperOrigin-RevId: 635854690
The `RandBytes` functions were being placed in the `crypto` namespace,
which collides with Chromium's namespace of the same name. Within,
`RandBytes` was defined with almost-the-same API. Then in Chromium
builds, the Chromium header would be used instead (though somewhat
inconsistently).
This creates a lot of pain for Chromium development as there's a
third-party repository directly depending on headers from Chromium's
source tree, and is against the third-party policies for that reason.
There are a number of other headers that mirror Chromium and are
swapped out in the Chromium build that will cause similar pain, such as:
```
include "crypto/aead.h"
include "crypto/ec_private_key.h"
include "crypto/hkdf.h"
```
This CL provides a template for how to get rid of these header swaps and
give a platform abstraction in nearby instead.
We provide a platform abstraction in `platform/crypto.h` (really in
`platform/implementation/crypto.h`) which is implemented in
`platform/implementation/shared/crypto.cc`. However that implementation
is removed by `#ifdef` when in the Chromium build.
Then, in the Chromium repo, we will add (separately) an implementation
of the same abstraction in `//third_party/nearby/platform_impl` with GN
rules to include it in the build. It will replace the implementation
from the nearby repo.
Copybara import of the project:
--
6ca8099 by danakj <danakj@chromium.org>:
Provide a platform abstraction for RandBytes instead of swapping headers
The `RandBytes` functions were being placed in the `crypto` namespace,
which collides with Chromium's namespace of the same name. Within,
`RandBytes` was defined with almost-the-same API. Then in Chromium
builds, the Chromium header would be used instead (though somewhat
inconsistently).
This creates a lot of pain for Chromium development as there's a
third-party repository directly depending on headers from Chromium's
source tree, and is against the third-party policies for that reason.
There are a number of other headers that mirror Chromium and are
swapped out in the Chromium build that will cause similar pain, such as:
```
include "crypto/aead.h"
include "crypto/ec_private_key.h"
include "crypto/hkdf.h"
```
This CL provides a template for how to get rid of these header swaps and
give a platform abstraction in nearby instead.
We provide a platform abstraction in `platform/crypto.h` (really in
`platform/implementation/crypto.h`) which is implemented in
`platform/implementation/shared/crypto.cc`. However that implementation
is removed by `#ifdef` when in the Chromium build.
Then, in the Chromium repo, we will add (separately) an implementation
of the same abstraction in `//third_party/nearby/platform_impl` with GN
rules to include it in the build. It will replace the implementation
from the nearby repo.
--
9c2654b by danakj <danakj@chromium.org>:
Remove CryptoSpan, use absl::Span
The header swapping of Chromium crypto libraries is
problematic, but absl::Span will convert to base::span
so there's no need for the typedef even without
removing the header swapping yet.
--
df1135d by danakj <danakj@chromium.org>:
Add missing files
--
ab18a15 by danakj <danakj@chromium.org>:
Remove the random_unittest.cc from Swift build
The file moved, so the Swift package needs its path
updated.
--
2038f78 by danakj <danakj@chromium.org>:
Combine crypto unittests into crypto_test.cc
--
f7ad176 by danakj <danakj@chromium.org>:
Add stdint and stddef includes for uint8_t and size_t
--
9f04590 by danakj <danakj@chromium.org>:
Mark the shared crypto implementation compatable_with non_prod
--
18eeafd by danakj <danakj@chromium.org>:
Add IWYU pragma for crypto implementation
PiperOrigin-RevId: 632150866
Anay Wadhera