Previously, this function would return an error in case the provided digest is not of 32 bytes long. As per our [spec](https://github.com/libp2p/specs/blob/master/peer-ids/peer-ids.md#secp256k1), we hash _all_ messages with SHA256 before signing, thus this error can never happen in practice.
This brings us one step closer to an infallible `Keypair::sign` which is now only fallible due to RSA signing. If we manage to fix that as well, constructors like `noise::Config::new` will become infallible.
Pull-Request: #3850.
`Keypair` and `Publickey` are rendered opaque:
- `Keypair` is replaced by a private `KeyPairInner` enum that is encapsulated inside the `Keypair` `pub struct`
- `Publickey` is replaced by a private `PublickeyInner` enum that is encapsulated inside the `Publickey` `pub struct`
Resolves#3860.
Pull-Request: #3866.
Implement encoding to/decoding from DER-encoded secret key document for `ecdsa::SecretKey`.
Implement encoding to/decoding from protobuf format for ECDSA keys.
Bump dependency `p256` from 0.12 to 0.13.
Bump dependency `sec1` from 0.3.0 to 0.7
Related: #3681.
Pull-Request: #3863.
Previously, we would specify the version and path of our workspace dependencies in each of our crates. This is error prone as https://github.com/libp2p/rust-libp2p/pull/3658#discussion_r1153278072 for example shows. Problems like these happened in the past too.
There is no need for us to ever depend on a earlier version than the most current one in our crates. It thus makes sense that we manage this version in a single place.
Cargo supports a feature called "workspace inheritance" which allows us to share a dependency declaration across a workspace and inherit it with `{ workspace = true }`.
We do this for all our workspace dependencies and for the MSRV.
Resolves#3787.
Pull-Request: #3715.
Some of the feature-flags weren't set correctly and thus produced warnings for unused code. We can fix this by using absolute paths instead of imports and allow `dead_code` for the error constructor. It might be possible to write a correct `cfg` for this as well but I think it will be very verbose, hence I didn't bother.
Pull-Request: #3859.
The `unreachable_pub` lint makes us aware of uses of `pub` that are not actually reachable from the crate root. This is considered good because it means reading a `pub` somewhere means it is actually public API. Some of our crates are quite large and keeping their entire API surface in your head is difficult.
We should strive for most items being `pub(crate)`. This lint helps us enforce that.
Pull-Request: #3735.
This patch removes the `version 0.2.0` for deprecations as libp2p-identity is only at `0.1.1` and this can be confusing to the reader.
It also adds `impl From<ed25519::PublicKey> for PublicKey` (et al.) so that `PublicKey::from(ed25519::PublicKey)` works.
Fixes https://github.com/libp2p/rust-libp2p/issues/3802.
Pull-Request: #3805.
This PR renames some method names that don't follow Rust naming conventions or behave differently from what the name suggests:
- Enforce "try" prefix on all methods that return `Result`.
- Enforce "encode" method name for methods that return encoded bytes.
- Enforce "to_bytes" method name for methods that return raw bytes.
- Enforce "decode" method name for methods that convert encoded key.
- Enforce "from_bytes" method name for methods that convert raw bytes.
Pull-Request: #3775.
All we need from the multihash is for it to be a data structure that we pass around. We only ever use the identity "hasher" and the sha256 hasher. Those are easily implemented without depending the (fairly heavy) machinery in `multihash`.
Unfortunately, this patch by itself does not yet lighten our dependency tree because `multiaddr` activates those features unconditionally. I opened a companion PR for this: https://github.com/multiformats/rust-multiaddr/pull/77.
https://github.com/multiformats/rust-multiaddr/pull/77 is another breaking change and we are trying to delay those at the moment. However, it will (hopefully) land eventually which should then be much easier to implement.
Fixes#3276.
Pull-Request: #3514.
