mirrors/arti.git/crates/tor-bytes/src/impls.rs, branch arti-v1.8.0

tor-bytes: Make "tor-llcrypto" dependency optional.

2024-10-09T20:02:35Z

This is part of an effort to make arti-rpc-client-core (and future similar tools) able to use our very-low-level crates without depending on things they don't need.

tor-bytes: Add a Reader constructor for use in tests

2024-09-11T13:19:19Z

We could call from_possibly_incomplete_slice in these, but that's confusing and distracting. Here we add this constructor, and document it (in terms of the constructor to come), and change the call sites. No functional change. Doing this now will prevent unwanted changes to test behaviours when we change the behaviour of Readers made by Reader::from_slice.

Change tor_bytes::Readable name to `b` in many places

2024-09-11T12:22:39Z

The codebase uses `r` sometimes and `b` at other times. Making this consistent makes widespread changes easier, and is clearer for humans. I think `b` is better than `r` because `r` might be "return". It is indeed used that way in a couple of places in reader.rs, even. I haven't changed *everywhere*, just Readable impls (where `r` is particularly likely to be "return value") and occurrences in tor-bytes. No functional change.

tor-bytes: avoid write_zeros truncation

2024-03-06T19:52:37Z

Use a saturating add while determining the new length. If it really ends up being usize::MAX, the resize will most likely panic. This is at least a more reliable end of processing than going on with a much smaller vector than expected.

Convert to the latest versions of dalek-cryptography

2023-11-29T15:34:58Z

The main changes that we have to adjust for are as follows: * In x25519-dalek: * `StaticSecret` is now behind a feature. * `StaticSecret::new` is deprecated in favor of `StaticSecret::random_from_rng`. * StaticSecret no longer does its own clamping. * In ed25519-dalek: * `SecretKey` has (in effect) been renamed to `SigningKey`. The name `SecretKey` is now an alias for `[u8; 32]`. * `SigningKey` is effectively a keypair, since it contains a public key as well. * `PublicKey` has been renamed to `VerifyingKey`. * The functions to extract a signing key and verifying key have been renamed as you might expect. * `ExpandedSecretKey` has been moved to `hasmat` and no longer implements `sign`. * `ExpanededSecretKey` now has as its elements a scalar and a hash prefix. * Various functions that took `&[u8]` now take `&[u8; N]`. * We no longer need a wrapper for older versions of rand. There is a single test in tor-keymgr that does not pass. I've marked it as ignore for now, in hopes that @gabi-250 can help me figure it out. This closes #808. There are several changes I want to make before we merge, however. They are marked with TODO DALEK.

Remove direct dependency on generic-array

2023-09-28T14:59:29Z

Instead of tying ourselves to a particular version of the generic-array crate, we now always use the version re-exported by our RustCrypto crates. This lets us avoid the possibility of version mismatch. (Originally I had planned to upgrade to generic-array 1.0, but then I found that we were not actually using it.)

tor-bytes: Remove use of arrayref

2023-05-25T18:48:57Z

Part of #872: Now that const generics are in, we have better ways to express converting slices into array-references.

tor-bytes: impl Readable and Writeable for CtByteArray.

2023-02-28T16:23:44Z

Change tor_bytes::Error::BadMessage to a Cow.

2023-02-09T15:20:31Z

Actually, to avoid making a breaking change, I'm deprecating BadMessage and creating a new InvalidMessage variant that takes a Cow. This way I don't need to track every crate that re-exposes tor_bytes::Error and call this a breaking change in those. Making this change will allow tor_bytes errors to be much more helpful.

Fix some rustdoc errors.

2022-10-13T13:08:46Z

In addition to the usual "You named that method wrong!" errors, we have a new rustdoc error that complains about bogus "HTML tags" that are actually unquoted usage of types like `Result`.