PKCS#8 support

[tarcieri]

NOTE: depends on #222 and #223 which need to be merged first.

Adds optional integration with ed25519::pkcs8 with support for decoding/encoding Keypair from/to PKCS#8-encoded documents.

TODO: support for decoding/encoding PublicKey from/to SPKI documents. Added, good to go!

[tarcieri]

This is feature-complete now but still needs docs

[tarcieri]

This should hopefully be good to go now.

pkcs8 has an MSRV of 1.57, so I bumped to that unilaterally for now.

[rozbb]

Looks great! Left some small comments

[tarcieri]

Had to rebase so I guess I can go ahead and squash

[tarcieri]

@rozbb this is green again

[tarcieri]

Re: 5eab15d, IMO having extern crate anywhere than the toplevel lib.rs is a bit weird since it's a crate global linking directive.

I swear there used to be a warning/lint for it but perhaps I'm mistaken

[tarcieri]

Ran rustfmt over it and the only problems were with the newly-added PKCS#8 code, so this is also rustfmt clean.

@rozbb ready for re-review

[rozbb]

Left minor comments. Also since dalek-cryptography/curve25519-dalek#470 merged, this line needs to be changed to use Scalar::ZERO:

ed25519-dalek/tests/ed25519.rs

Line 159 in 1a6f50a

while s_candidate == Scalar::zero() {

EDIT: Fixed

[pinkforest]

@rozbb - Fixed current tests failing here in #239

[rozbb]

I thought I was going crazy. I have pages and pages of errors when testing locally. Thankfully this shows up in the CI.

Probably something related to the warning:

warning: Patch `ed25519 v2.0.0-pre.1 (https://github.com/RustCrypto/signatures.git#fd78bf79)`
    was not used in the crate graph.
Check that the patched package version and available features are compatible
with the dependency requirements. If the patch has a different version from
what is locked in the Cargo.lock file, run `cargo update` to use the new
version. This may also occur with an optional dependency that is not enabled.

[pinkforest]

I can confirm that most of the build errors go away by bumping to .1 as I've .pathc'd

EDIT: Also curve25519-dalek [dependency] needs to be patched to .pre.3 - updated .patch: #224 (comment)

Just leaves one batch related error after:

error[E0432]: unresolved import `rand::thread_rng`
  --> src/batch.rs:28:5
   |
28 | use rand::thread_rng;
   |     ^^^^^^^^^^^^^^^^ no `thread_rng` in the root

Which is fixed in

• Fix batch build #220

[pinkforest]

Also @rozbb the curve25519-dalek [dependencies] has to be .patched as well to pre.3 so:

diff --git a/Cargo.toml b/Cargo.toml
index f87f430..971328e 100644
--- a/Cargo.toml
+++ b/Cargo.toml
@@ -24,8 +24,8 @@ rustdoc-args = ["--cfg", "docsrs"]
 features = ["nightly", "batch", "pkcs8"]
 
 [dependencies]
-curve25519-dalek = { version = "=4.0.0-pre.2", default-features = false, features = ["digest", "rand_core"] }
-ed25519 = { version = "=2.0.0-pre.0", default-features = false }
+curve25519-dalek = { version = "=4.0.0-pre.3", default-features = false, features = ["digest", "rand_core"] }
+ed25519 = { version = "=2.0.0-pre.1", default-features = false }
 merlin = { version = "3", default-features = false, optional = true }
 rand = { version = "0.8", default-features = false, optional = true }
 rand_core = { version = "0.6", default-features = false, optional = true }

Problem with [patch.crates-io] here was that it needs to match the .patched manifest version exactly. if the patch target e.g. git branch Cargo.toml does not match the asked depdendency - it will give out that warning and does nothing leading to that error - unless intended as eventual "patch kill switch"

In this case release/4.0 curve25519-dalek and ed25519 repo branch Cargo.toml's got updated and then it didn't match the asked version and rendered .patch void that was asking pre.0 for ed25519 and pre.2 for curve25519.

This is why it is also best to avoid cargo publish anything with [patch.crates-io] that mutable target git ref without locking to immutable branch / commit ref. Usually it's best to just override dependency to directly target a git instead if this is required as .patch only gives a warning (sometimes this is feasible but rarely) instead of error.

[tarcieri]

@pinkforest [patch.crates-io] works just fine if Cargo.lock is checked in, which stores the upstream git SHA1 hash that was used at the time, and won't update it unless cargo update [-p <package>] was used explicitly.

I think the advice not to check in Cargo.lock for libraries is a bit dated now that dependabot exists, and without it builds aren't reproducible or bisectable.

[rozbb]

nightly doesn't exist anymore, but we can get that in another PR