There are a few places where library functions can panic, when an input is an unexpected length. For example, when KeyPair signature is incorrect length:

fn main() {
    let kp = nkeys::KeyPair::new_user();
    kp.verify(&[], &[]);
}

This panics, it does not return an error.

If the signature is always meant to be 64 bytes long, and you can't do anything useful with something that isn't 64 bytes long, I'd just take a &[u8; 64] and expect the caller to do the conversion. That would be a breaking change, but it means the copy_from_slice can never fail.

This just happened in the last few days:

$ cargo build
    Updating crates.io index
   Compiling typenum v1.11.2
   Compiling libc v0.2.67
   Compiling getrandom v0.1.14
   Compiling cfg-if v0.1.10
   Compiling byteorder v1.3.4
   Compiling zeroize v1.1.0
   Compiling cc v1.0.50
   Compiling byte-tools v0.3.1
   Compiling ppv-lite86 v0.2.6
   Compiling opaque-debug v0.2.3
   Compiling subtle v2.2.2
   Compiling fake-simd v0.1.2
   Compiling log v0.4.8
   Compiling data-encoding v2.2.0
   Compiling subtle-encoding v0.4.1
   Compiling block-padding v0.1.5
   Compiling clear_on_drop v0.2.3
   Compiling generic-array v0.12.3
   Compiling rand_core v0.5.1
   Compiling rand_chacha v0.2.2
   Compiling digest v0.8.1
   Compiling block-buffer v0.7.3
   Compiling signature v1.0.0-pre.5
   Compiling curve25519-dalek v2.0.0
   Compiling sha2 v0.8.1
   Compiling ed25519 v1.0.0-pre.3
   Compiling rand v0.7.3
   Compiling signatory v0.16.0
   Compiling ed25519-dalek v1.0.0-pre.3
   Compiling signatory-dalek v0.16.0
   Compiling nkeys v0.0.8 (/home/kit/wrk/src/github.com/encabulators/nkeys)
error[E0599]: no method named `as_slice` found for type `ed25519::Signature` in the current scope
   --> src/lib.rs:210:20
    |
210 |             Ok(sig.as_slice().to_vec())
    |                    ^^^^^^^^ method not found in `ed25519::Signature`

warning: unused import: `Signature`
  --> src/lib.rs:45:28
   |
45 | use signatory::signature::{Signature, Signer, Verifier};
   |                            ^^^^^^^^^
   |
   = note: `#[warn(unused_imports)]` on by default

error: aborting due to previous error

For more information about this error, try `rustc --explain E0599`.
error: could not compile `nkeys`.

To learn more, run the command again with --verbose.

See here: https://github.com/MystenLabs/ed25519-unsafe-libs

    = Announcement: https://github.com/MystenLabs/ed25519-unsafe-libs
    = Solution: Upgrade to >=2 (try `cargo update -p ed25519-dalek`)
    = ed25519-dalek v1.0.1
      └── nkeys v0.3.1
          ├── async-nats v0.31.0
          │   └── vector v0.32.0
          └── vector v0.32.0 (*)

It looks like nkeys is affected by https://rustsec.org/advisories/RUSTSEC-2022-0093.html . To resolve it needs to use 2.0.0+ of ed25519-dalek.

The current version is 0.0.12 which according to Specifying Dependencies:

The version 0.0.x is not considered compatible with any other version.

This appears to be causing an issue when installing wash-cli because the transitive dependencies for crates like wascap get updated containing potentially new versions of nkeys, but the direct nkeys dependency will stay the same causing errors like this later as new versions get published:

error[E0308]: mismatched types
   --> src/claims.rs:367:34
    |
367 |     println!("{}", claims.encode(&issuer)?);
    |                                  ^^^^^^^ expected struct `wascap::prelude::KeyPair`, found struct `nkeys::KeyPair`
    |
    = note: expected reference `&wascap::prelude::KeyPair`
               found reference `&nkeys::KeyPair`
    = note: perhaps two different versions of crate `nkeys` are being used?

I believe this can be alleviated by incrementing the nkeys version to 0.1.0 so that any compatible versions for direct and transitive dependencies will get updated if possible at the same time, avoiding the mismatched types problem.

I think the issue is pretty self-explanatory, but to elaborate:

It's been a while since GitHub made main the default branch name, for some very good reasons, and since then they've made the functionality available directly on GitHub, so this repository should just go ahead and rename 🙂

So I ran into this when playing around trying to sign a .wasm file using wash but the issue orignates from this crate.

Basically this happens if your account.nk/module.nk files ends with a linebreak when passing them to wash sign. In the context of this crate that means the source arg to KeyPair::from_seed ends with a line break making it the wrong length.

It turns out that the Errors Display impl recurses infinitely.

Reproduce:

echo MODULE_SEED > module.nk
echo MODULE_SEED > account.nk
wash claims sign build/contract.wasm --http_server --cap "new:hostcap" --subject account.nk --issuer module.nk --name test_actor

And forgive me if I am completley failing above, still learning, and the issue still remains 😄

The infinite recursion and stackoverflow seems to occur in the err! macro.

It seems the only call to the 3 argument variant of the macro is in KeyPair::from_seed.

Looks like nkeys depends on ed25519_dalek::Signature::BYTE_SIZE which isn't actually guaranteed by the ed25519-dalek = { version = "1.0.1", default-features = false, features = ["u64_backend"] } dependency in Cargo.toml. ed25519_dalek::Signature is a re-exported ed25519::Signature, and ed25519's Cargo.toml in turns only depends on ed25519 = { version = "1", default-features = false }.

ed25519 commit 5286a9768217b6ca0911f25991558a0bb97bedcd added Signature::BYTE_SIZE. Looks like the next release tag was v1.3.0.

I suppose nkeys should directly depend on ed25519 = "1.3".

I'll send a PR shortly.

$ cargo check
...success..
$ cargo update -p ed25519
$ cargo check
...
    Checking nkeys v0.3.0 (/Users/slamb/git/crates/nkeys)
error[E0599]: no associated item named `BYTE_SIZE` found for struct `ed25519_dalek::Signature` in the current scope
   --> src/lib.rs:257:58
    |
257 |         let mut fixedsig = [0; ed25519_dalek::Signature::BYTE_SIZE];
    |                                                          ^^^^^^^^^ associated item not found in `Signature`

error[E0599]: no function or associated item named `from_bytes` found for struct `ed25519_dalek::Signature` in the current scope
   --> src/lib.rs:259:47
    |
259 |         let insig = ed25519_dalek::Signature::from_bytes(&fixedsig)?;
    |                                               ^^^^^^^^^^ function or associated item not found in `Signature`
    |
    = help: items from traits can only be used if the trait is in scope
help: the following trait is implemented but not in scope; perhaps add a `use` for it:
    |
48  + use signatory::signature::Signature;
    |
help: there is a method with a similar name
    |
259 |         let insig = ed25519_dalek::Signature::to_bytes(&fixedsig)?;
    |                                               ~~~~~~~~

For more information about this error, try `rustc --explain E0599`.
error: could not compile `nkeys` (lib) due to 2 previous errors
...