string_view was implicitly convertible to std::string, but
std::string_view is only explicitly convertible. This makes the
`operator std::string` explicit to be more compatible, and re-adds a
bunch of explicit string casts to the code where needed.
(This also fixes the build if changing the standard to c++17)
Renames the cmake Catch2 test target to "catch" (instead of "check") and
adds a "rungtest" for gtest (because the "gtest" target is already taken
by the gtest library itself), and then repurposes the "check" target to
run both test suite binaries.
Also updates the top-level Makefile to do the same thing, except that
there the gtest target is just "gtest" instead of "rungtest".
Adds a TrimWhiteSpace instead of using abseil's.
Adds Catch2 tests for it, and also converts the existing str tests to
catch (which look much, much nicer than the gtest ones).
- util::Mutex is now a std::shared_timed_mutex, which is capable of
exclusive and shared locks.
- util::Lock is still present as a std::lock_guard<util::Mutex>.
- the locking annotations are preserved, but updated to the latest
supported by clang rather than using abseil's older/deprecated ones.
- ACQUIRE_LOCK macro is gone since we don't pass mutexes by pointer into
locks anymore (WTF abseil).
- ReleasableLock is gone. Instead there are now some llarp::util helper
methods to obtain unique and/or shared locks:
- `auto lock = util::unique_lock(mutex);` gets an RAII-but-also
unlockable object (std::unique_lock<T>, with T inferred from
`mutex`).
- `auto lock = util::shared_lock(mutex);` gets an RAII shared (i.e.
"reader") lock of the mutex.
- `auto lock = util::unique_locks(mutex1, mutex2, mutex3);` can be
used to atomically lock multiple mutexes at once (returning a
tuple of the locks).
This are templated on the mutex which makes them a bit more flexible
than using a concrete type: they can be used for any type of lockable
mutex, not only util::Mutex. (Some of the code here uses them for
getting locks around a std::mutex). Until C++17, using the RAII types
is painfully verbose:
```C++
// pre-C++17 - needing to figure out the mutex type here is annoying:
std::unique_lock<util::Mutex> lock(mutex);
// pre-C++17 and even more verbose (but at least the type isn't needed):
std::unique_lock<decltype(mutex)> lock(mutex);
// our compromise:
auto lock = util::unique_lock(mutex);
// C++17:
std::unique_lock lock(mutex);
```
All of these functions will also warn (under gcc or clang) if you
discard the return value. You can also do fancy things like
`auto l = util::unique_lock(mutex, std::adopt_lock)` (which lets a
lock take over an already-locked mutex).
- metrics code is gone, which also removes a big pile of code that was
only used by metrics:
- llarp::util::Scheduler
- llarp:🧵:TimerQueue
- llarp::util::Stopwatch
Step 1 of removing abseil from lokinet.
For the most part this is a drop-in replacement, but there are also a
few changes here to the JSONRPC layer that were needed to work around
current gcc 10 dev snapshot:
- JSONRPC returns a json now instead of an optional<json>. It doesn't
make any sense to have a json rpc call that just closes the connection
with returning anything. Invoked functions can return a null (default
constructed) result now if they don't have anything to return (such a
null value won't be added as "result").
gtest ~renamed INSTANTIATE_TEST_CASE_P to INSTANTIATE_TEST_SUITE_P and
added a "backwards compatibility" shim, but the shim fails at compile
time if you pass in an empty fourth argument.
This makes PrivateKey store both the key followed by the hash. For
PrivateKeys based on SecretKeys this just means the second half of the
SHA-512 of the seed, and makes a PrivateKey constructed from a SecretKey
give an identical signature to signing directly with sodium.
For derived keys we use a ShortHash of the root key's signing hash
concatenated with the publicly known hash value, so that our derived key
signing hash will be different from the root signing hash and also
different for different derivation parameters.
This also changed one of the asserts in crypto_noop, but upon closer
inspection the copying of the secret key into the signature seems really
wrong, so just changed them to fill with 0s.
The reason things weren't working here is because libsodium does
something completely unintuitive and called the seed the "secret key"
when it isn't, it's the seed.
This adds a new PrivateKey class (alongside the existing SecretKey and
PubKey) that holds just a private key value but no seed -- which we need
to do because there is no way we can get a seed after calculating a
derived keypair.
With these changes, we now generate exactly the same keys and subkeys as
Tor (and a new test case uses values generated in Tor to verify this).
This is incomplete -- the subkey signing code is still not implemented;
it has to be adapted to create a signature from a PrivateKey rather than
a SecretKey which will probably requiring working around/reimplementing
some of what libsodium does for creating a signature since it expects
"secret keys" i.e. the seed.
Jeff Becker
Stephen Shelton
Jason Rhinelander
Thomas Winget