By default, clippy doesn't suggest changes if it would break the public API. Whilst a sensible default, it makes us miss certain opportunities to follow conventions correctly. When a new lint is added, we can always temporarily allow it and make a change in the next breaking release but I think it is better to be aware of the lint than having it automatically silenced.
Pull-Request: #4653.
Starting with nightly-2023-09-10, the `[lints]` section in `Cargo.toml` files is stable. Together with workspace inheritance, this can be used to declare all lints we want to enforce in a single place.
Resolves: #4484.
Pull-Request: #4575.
`libp2p-identity` gets a special treatment in our workspace because it is the only crate that is a dependency of crates _outside_ the workspace, in particular `multiaddr`. We however also depend on `multiaddr` again in the workspace. As a result, we need to use `[patch.crates-io]` to replace the `libp2p-identity` version across the entire dependency tree. This however doesn't work well with `cargo semver-checks` as it doesn't copy over `[patch]` sections into its workspace where it does the docs building.
To fix the semver checks error, we need to release a new version of `libp2p-identity`.
Pull-Request: #4583.
Previously, only the clippy job was denying warnings. We have many other CI jobs that compile our library in all sorts of configurations. All of them should be free of warnings.
Pull-Request: #4384.
From the lint documentation:
> If both `PartialOrd` and `Ord` are implemented, they must agree. This is commonly done by wrapping the result of `cmp` in `Some` for `partial_cmp`. Not doing this may silently introduce an error upon refactoring.
Pull-Request: #4379.
Some restricted environments lack proper random source, and `getrandom` crate
fails to compile. However, random sources is needed only for random key
generation which is not always required.
This change introduces `rand` feature flag that is gate to all the
functionality that requires `rand` crate.
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.
