- arti#448 and arti!607 highlight an issue with upgrading `rsa`: namely,
the `x25519-dalek` version previously used has a hard dependency on
`zeroize` 1.3, which creates a dependency conflict.
- However, `x25519-dalek` version `2.0.0-pre.1` relaxes this dependency.
Reviewing the changelogs, it doesn't look like that version is
substantially different from the current one at all, so it should be
safe to use despite the "prerelease" tag.
- The new `x25519-dalek` version also bumps `rand_core`, which means we
don't have to use the RNG compat wrapper in `tor-llcrypto` as much.
closes arti#448
This commitid is the current head of my MR branch
https://github.com/colin-kiegel/rust-derive-builder/pull/253https://github.com/ijackson/rust-derive-builder/tree/field-builder
Using the commitid prevents surprises if that branch is updated.
We will require this newer version of derive_builder. The version
will need to be bumped again later, assuming the upstream MR is merged
and upstream do a release containing the needed changes.
We will need the new version of not only `derive_builder_core` (the
main macro implementation) but also`derive_builder` for a new error
type.
The new version of derive_builder requires a newer darling.
Ooops. Upstream MR here:
https://github.com/colin-kiegel/rust-derive-builder/pull/242
For now, upgrade darling. When there's a new upstream derive_builder,
we can use it and drop this.
The *earlier* versions of these crates pull in *dependencies* that
violate our MSRV policy by requiring a *later* version of Rust.
Empirically, env_logger 0.5.4 would be enough, but practice here seems
to be to just say "cargo update".
Previously this code was in .gitlab-ci.yml, but for the purposes of
testing my fix for #275, it turned out to be much better to have it
in a script of its own.
Also, we now need to update our "quote" second-order dependency,
since otherwise our minimal first-order dependencies won't build
correctly.