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
- Both implementations implement `AdvertisementDecoder` interface and provide the
concrete implementation for AdvertisementDecoderImpl
- cleanup missing includes as complained about by clang-tidy
PiperOrigin-RevId: 621187625
- Removes banned_data_types_, PUBLIC identity advertisements will never have
any corresponding credentials anyways, so decryption will always be skipped
and this is now guarenteed by asserts in UpdatePublicCredentials
- Filtering adv based on identity is moved into advertisement Filter which
already contains the requested identity info from scan_request
- LegacyPresenceScanFilter is no longer used by AdvertisementDecoder since
this is not being used anywhere at the moment
- Cleanup miscellaneous clang-tidy lints about missing or unused includes
PiperOrigin-RevId: 620086399
- this decouples filtering logic from advertisement decoding logic
in preparation for introducing a Rust backed impl of
AdvertisementDecoder
- this change is only a refactor and does not change functionality
in any way
PiperOrigin-RevId: 618978564
Expose APIs to fetch local credentials from the CredentialManager, which will be used to fetch a local credential to be used for authentication in follow up CL's. See go/cros-nearby-presence-np-nc-authentication for details.
PiperOrigin-RevId: 601781066
Nearby Presence scanning sessions may be very long. We need a way to notify the scanner that new credentials were added during scanning.
`SubscribeForPublicCredentials()` allows us to subscribe for such updates.
PiperOrigin-RevId: 502699345
1. Update the API to accept the credentials on input instead of credential manager.
2. Update the test with values using the LDT encryption.
These changes allow us to have a more asynchronous implementaion.
When broadcasting we can:
1. Fetch the private credentials asynchronously.
2. Create the advertisement and start broadcasting when the credentials have been fetched.
When scanning we can:
1. Fetch public credentials asynchronously.
2. Start scanning for advertisements.
3. Update the decoder when new credentials are fetched.
PiperOrigin-RevId: 493998041
Ivo Ristovski List