mirror of
https://github.com/kidfromjupiter/nearby.git
synced 2026-09-16 15:36:12 -04:00
Anay Wadhera
f26d25ed01
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
67 lines
1.9 KiB
C++
67 lines
1.9 KiB
C++
// Copyright 2022 Google LLC
|
|
//
|
|
// Licensed under the Apache License, Version 2.0 (the "License");
|
|
// you may not use this file except in compliance with the License.
|
|
// You may obtain a copy of the License at
|
|
//
|
|
// https://www.apache.org/licenses/LICENSE-2.0
|
|
//
|
|
// Unless required by applicable law or agreed to in writing, software
|
|
// distributed under the License is distributed on an "AS IS" BASIS,
|
|
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
// See the License for the specific language governing permissions and
|
|
// limitations under the License.
|
|
|
|
#ifndef THIRD_PARTY_NEARBY_FASTPAIR_COMMON_ACCOUNT_KEY_H_
|
|
#define THIRD_PARTY_NEARBY_FASTPAIR_COMMON_ACCOUNT_KEY_H_
|
|
|
|
#include <ostream>
|
|
#include <string>
|
|
#include <vector>
|
|
|
|
#include "absl/strings/escaping.h"
|
|
#include "absl/strings/string_view.h"
|
|
#include "fastpair/common/constant.h"
|
|
#include "internal/platform/crypto.h"
|
|
|
|
namespace nearby {
|
|
namespace fastpair {
|
|
|
|
class AccountKey {
|
|
public:
|
|
AccountKey() = default;
|
|
explicit AccountKey(absl::string_view bytes) : bytes_(bytes) {}
|
|
explicit AccountKey(const std::vector<uint8_t> bytes) {
|
|
bytes_ = std::string(bytes.begin(), bytes.end());
|
|
}
|
|
|
|
static AccountKey CreateRandomKey() {
|
|
std::string key(kAccountKeySize, 0);
|
|
RandBytes(key.data(), kAccountKeySize);
|
|
return AccountKey(key);
|
|
}
|
|
|
|
absl::string_view GetAsBytes() const { return bytes_; }
|
|
|
|
bool Ok() const { return bytes_.size() == kAccountKeySize; }
|
|
|
|
explicit operator bool() const { return Ok(); }
|
|
|
|
private:
|
|
std::string bytes_;
|
|
};
|
|
|
|
inline std::ostream& operator<<(std::ostream& stream, const AccountKey& key) {
|
|
stream << "AccountKey(" << absl::BytesToHexString(key.GetAsBytes()) << ")";
|
|
return stream;
|
|
}
|
|
|
|
inline bool operator==(const AccountKey& a, const AccountKey& b) {
|
|
return a.GetAsBytes() == b.GetAsBytes();
|
|
}
|
|
|
|
} // namespace fastpair
|
|
} // namespace nearby
|
|
|
|
#endif // THIRD_PARTY_NEARBY_FASTPAIR_COMMON_ACCOUNT_KEY_H_
|