solokeys / solo2-cli Goto Github PK

View Code? Open in Web Editor NEW

169.0 169.0 29.0 319 KB

Solo 2 library and CLI in Rust

Home Page: https://docs.rs/solo2

License: Apache License 2.0

Makefile 0.60% Rust 95.31% Shell 4.09%

solo2-cli's People

Contributors

Stargazers

Watchers

solo2-cli's Issues

fail to compile from repo

Tried to compile solo2 from the repo in order to get rid of the need to have a smartcard in my reader (which is built into ma laptop). But build fails.

Here's what I did:

git clone https://github.com/solokeys/solo2-cli.git solo2
cd solo2/
cargo build

Build runs fine for quite a while, but finally fails with this error message:

   Compiling solo2 v0.1.2 (/home/user/temp/solo2)
   Compiling serde_yaml v0.8.23
   Compiling serde-big-array v0.3.2
   Compiling toml v0.5.8
   Compiling ureq v2.4.0
error: there is no argument named `uuid`
   --> src/bin/solo2/main.rs:336:61
    |
336 |                     let url = format!("https://s2pki.net/s2/{uuid}/x255.txt");
    |                                                             ^^^^^^

error: could not compile `solo2` due to previous error

LinuxMint 20.3 (underlying Ubuntu 20.04) running here, rustc 1.57.0+dfsg1+llvm-0ubuntu1~~20.04.1, cargo 0.58.0-0ubuntu1~~20.04.1, gcc 9.3.0

I'd be happy to provide more info, pls feel free to ask.

Sending fatal alert BadCertificate

When doing a "solo2 update" I get a

Downloading latest release from https://github.com/solokeys/solo2/
 WARN  rustls::conn > Sending fatal alert BadCertificate
Error: https://api.github.com/repos/solokeys/solo2/releases/latest: Connection Failed: tls connection init failed: invalid peer certificate contents: invalid peer certificate: UnknownIssuer

Any solution ?

Thank you for your help

Cannot detect Solo2

➜  ~ uname -r
5.15.2-arch1-1
➜  ~ lsusb | grep -i solo
Bus 003 Device 003: ID 0483:a2ca STMicroelectronics Solo 4.1.5
Bus 001 Device 005: ID 1209:beee Generic Solo 2 Security Key
➜  ~ solo ls
:: Solos
207D329B304B: SoloKeys Solo 4.1.5
➜  ~ solo2 -V
solo2 0.0.6
➜  ~ solo2 ls
<nothing>
➜  ~ solo2 app admin uuid
Error: Could not find any Solo 2 devices connected.

`solo2 app admin uuid` causes panic

RUST_BACKTRACE=full solo2 app admin uuid
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: TryFromSliceError(())', /home/kusma/.cargo/registry/src/github.com-1ecc6299db9ec823/solo2-0.1.1/src/apps/admin.rs:48:55
stack backtrace:
   0:     0x562dc1e1521c - std::backtrace_rs::backtrace::libunwind::trace::h09f7e4e089375279
                               at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:     0x562dc1e1521c - std::backtrace_rs::backtrace::trace_unsynchronized::h1ec96f1c7087094e
                               at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x562dc1e1521c - std::sys_common::backtrace::_print_fmt::h317b71fc9a5cf964
                               at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/sys_common/backtrace.rs:67:5
   3:     0x562dc1e1521c - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::he3555b48e7dfe7f0
                               at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/sys_common/backtrace.rs:46:22
   4:     0x562dc1e37b9c - core::fmt::write::h513b07ca38f4fb1b
                               at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/core/src/fmt/mod.rs:1149:17
   5:     0x562dc1e0e3e5 - std::io::Write::write_fmt::haf8c932b52111354
                               at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/io/mod.rs:1697:15
   6:     0x562dc1e16db0 - std::sys_common::backtrace::_print::h195c38364780a303
                               at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/sys_common/backtrace.rs:49:5
   7:     0x562dc1e16db0 - std::sys_common::backtrace::print::hc09dfdea923b6730
                               at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/sys_common/backtrace.rs:36:9
   8:     0x562dc1e16db0 - std::panicking::default_hook::{{closure}}::hb2e38ec0d91046a3
                               at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:211:50
   9:     0x562dc1e16965 - std::panicking::default_hook::h60284635b0ad54a8
                               at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:228:9
  10:     0x562dc1e17464 - std::panicking::rust_panic_with_hook::ha677a669fb275654
                               at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:606:17
  11:     0x562dc1e16f40 - std::panicking::begin_panic_handler::{{closure}}::h976246fb95d93c31
                               at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:502:13
  12:     0x562dc1e156c4 - std::sys_common::backtrace::__rust_end_short_backtrace::h38077ee5b7b9f99a
                               at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/sys_common/backtrace.rs:139:18
  13:     0x562dc1e16ea9 - rust_begin_unwind
                               at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:498:5
  14:     0x562dc1b98751 - core::panicking::panic_fmt::h35f3a62252ba0fd2
                               at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/core/src/panicking.rs:107:14
  15:     0x562dc1b98843 - core::result::unwrap_failed::hb53671404b9e33c2
                               at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/core/src/result.rs:1613:5
  16:     0x562dc1bd2d82 - solo2::apps::admin::App::uuid::h88a43cfcaf252619
  17:     0x562dc1baf029 - solo2::try_main::h3da5c40298bb04ab
  18:     0x562dc1baa842 - solo2::main::h2f53ebae3c6c1ed6
  19:     0x562dc1bb1b93 - std::sys_common::backtrace::__rust_begin_short_backtrace::h58295e1b40801fda
  20:     0x562dc1bb17c9 - std::rt::lang_start::{{closure}}::hf17fe86fa20fa28f
  21:     0x562dc1e14eab - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h7e688d7cdfeb7e00
                               at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/core/src/ops/function.rs:259:13
  22:     0x562dc1e14eab - std::panicking::try::do_call::h4be824d2350b44c9
                               at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:406:40
  23:     0x562dc1e14eab - std::panicking::try::h0a6fc7affbe5088d
                               at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:370:19
  24:     0x562dc1e14eab - std::panic::catch_unwind::h22c320f732ec805e
                               at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panic.rs:133:14
  25:     0x562dc1e14eab - std::rt::lang_start_internal::{{closure}}::hd38309c108fe679d
                               at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/rt.rs:128:48
  26:     0x562dc1e14eab - std::panicking::try::do_call::h8fcaf501f097a28e
                               at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:406:40
  27:     0x562dc1e14eab - std::panicking::try::h20e906825f98acc1
                               at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:370:19
  28:     0x562dc1e14eab - std::panic::catch_unwind::h8c5234dc632124ef
                               at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panic.rs:133:14
  29:     0x562dc1e14eab - std::rt::lang_start_internal::hc4dd8cd3ec4518c2
                               at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/rt.rs:128:20
  30:     0x562dc1bb17b2 - main
  31:     0x7feb646b17ed - __libc_start_main
                               at ./csu/../csu/libc-start.c:332:16
  32:     0x562dc1b98efa - _start
  33:                0x0 - <unknown>

fail to compile (dependencies?)

command $ cargo install solo2
results in

....... Compiling num-bigint-dig v0.7.0 Compiling uriparse v0.6.4 error: failed to run custom build command forpcsc-sys v1.2.0`

Caused by:
process didn't exit successfully: /tmp/cargo-installSSHJ9R/release/build/pcsc-sys-88cd1d3ac0c201e1/build-script-build (exit status: 101)
--- stdout
cargo:rerun-if-env-changed=LIBPCSCLITE_NO_PKG_CONFIG
cargo:rerun-if-env-changed=PKG_CONFIG_x86_64-unknown-linux-gnu
cargo:rerun-if-env-changed=PKG_CONFIG_x86_64_unknown_linux_gnu
cargo:rerun-if-env-changed=HOST_PKG_CONFIG
cargo:rerun-if-env-changed=PKG_CONFIG
cargo:rerun-if-env-changed=LIBPCSCLITE_STATIC
cargo:rerun-if-env-changed=LIBPCSCLITE_DYNAMIC
cargo:rerun-if-env-changed=PKG_CONFIG_ALL_STATIC
cargo:rerun-if-env-changed=PKG_CONFIG_ALL_DYNAMIC
cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64-unknown-linux-gnu
cargo:rerun-if-env-changed=PKG_CONFIG_PATH_x86_64_unknown_linux_gnu
cargo:rerun-if-env-changed=HOST_PKG_CONFIG_PATH
cargo:rerun-if-env-changed=PKG_CONFIG_PATH
cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64-unknown-linux-gnu
cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR_x86_64_unknown_linux_gnu
cargo:rerun-if-env-changed=HOST_PKG_CONFIG_LIBDIR
cargo:rerun-if-env-changed=PKG_CONFIG_LIBDIR
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64-unknown-linux-gnu
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR_x86_64_unknown_linux_gnu
cargo:rerun-if-env-changed=HOST_PKG_CONFIG_SYSROOT_DIR
cargo:rerun-if-env-changed=PKG_CONFIG_SYSROOT_DIR

--- stderr
thread 'main' panicked at 'Could not find a PCSC library.
For the target OS linux, I tried to use pkg-config to find libpcsclite.
Do you have pkg-config and libpcsclite configured for this target?: "pkg-config" "--libs" "--cflags" "libpcsclite" "libpcsclite >= 1" did not exit successfully: exit status: 1
error: could not find system library 'libpcsclite' required by the 'pcsc-sys' crate

--- stderr
Package libpcsclite was not found in the pkg-config search path.
Perhaps you should add the directory containing libpcsclite.pc' to the PKG_CONFIG_PATH environment variable No package 'libpcsclite' found Package libpcsclite was not found in the pkg-config search path. Perhaps you should add the directory containing libpcsclite.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libpcsclite' found
', /home/tcc/.cargo/registry/src/github.com-1ecc6299db9ec823/pcsc-sys-1.2.0/build.rs:30:22
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...
error: failed to compile solo2 v0.1.1, intermediate artifacts can be found at /tmp/cargo-installSSHJ9R
`

solo2 should blink when there's a pending firmware update to confirm

Hi,

I have both devices plugged in, one needs an update. I'm not sure which of them I need to tap right now to confirm the pending update. I feel like it would be appropriate for the device to blink when it's waiting for this confirmation, similar to how Yubikeys blink when they're waiting for touch confirmation.

Please tag and release 0.1.2

According to the changelog version 0.1.2 was released on 2022-01-07 but you didn't tag nor upload to crates.io - could you please do so?

BTW: I plan to work on packaging solo2-cli for Debian next week :-)

Duo HOTP key rejected

I tried to add a HOTP key (for Duo), but it was rejected with Error: invalid length at 48. The secret is 51 characters base32. (From the --help example I assume it should be given as base32, and it would be good if the help said.) It works with oathtool, for instance.

cargo install fails to build

Trying to issue cargo install as suggested by the README on Debian Sid results in the following errors:

error[E0658]: panicking in constant functions is unstable
   --> /home/kusma/.cargo/registry/src/github.com-1ecc6299db9ec823/solo2-0.1.1/src/transport/ctap.rs:114:9
    |
114 |         assert!(vendor_code >= 0x40);
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: see issue #51999 <https://github.com/rust-lang/rust/issues/51999> for more information
    = note: this error originates in the macro `assert` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0658]: panicking in constant functions is unstable
   --> /home/kusma/.cargo/registry/src/github.com-1ecc6299db9ec823/solo2-0.1.1/src/transport/ctap.rs:115:9
    |
115 |         assert!(vendor_code <= 0x7F);
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: see issue #51999 <https://github.com/rust-lang/rust/issues/51999> for more information
    = note: this error originates in the macro `assert` (in Nightly builds, run with -Z macro-backtrace for more info)

For more information about this error, try `rustc --explain E0658`.
error: could not compile `solo2` due to 2 previous errors
warning: build failed, waiting for other jobs to finish...
error: failed to compile `solo2 v0.1.1`, intermediate artifacts can be found at `/tmp/cargo-install7vAcTe`

Caused by:
  build failed

I'm no rust-expert, but it seems like a too new language feature was used.

Just unable to get this to work (macOS Monterey)

Where to start? I'm trying to install this to test out my new Solo V2 keys, but I have not been able to get it to work.

I appreciate this is still in development, but it would be great if the installation instructions could be updated for a fresh install as it seems that things aren't fully explained to relatively inexperienced people (like myself I guess).

After some initial problems, I had to install Rust by running (as outlined here):

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Then I managed to get solo2 to install by running:

cargo install solo2

However, when I run the following command:

solo2 app admin uuid

I get:

Error: Empty list of smartcards

Revisiting the README file, it mentions something about Solo 2 is supported by Ludovic Rousseau's CCID driver, but there has not been a release. The included Info.plist works.

Ok, so what does that actually mean to somebody who isn't very familiar with all this? I've tried to install Ludovic Rousseau's CCID driver by running:

wget https://ccid.apdu.fr/files/ccid-1.4.34.tar.bz2
tar xzvf ccid-1.4.34.tar.bz2
cd ccid-1.4.34.tar.bz2
./configure
make
make install

As outlined here, I've also tried:

./MacOSX/configure
make
sudo make install

But the first command (./MacOSX/configure) results in:

/usr/local/Cellar/libusb/1.0.24/lib/libusb-1.0.0.dylib	/usr/local/Cellar/libusb/1.0.24/lib/libusb-1.0.dylib
*****************************
Dynamic library libusb found in /usr/local/Cellar/libusb/1.0.24/lib
*****************************
Rename it to force a static link

I have tried removing libusb (brew uninstall --ignore-dependencies libusb --force) and trying again, which seems to progress further, but then results in:

configure: error: libusb.h not found, install libusb or use ./configure LIBUSB_CFLAGS=...

I have no idea what that means or what else to do on that so that runs into other problems and the rabbit hole deepens... Should I be doing something with the included Info.plist and if so, what and where?

In an ideal world, it would be great if the installation instructions were looked at again from a fresh installation point of view, so that any dependencies are detailed as it seems something isn't quite right here and I do not know what else to do to get this to work.

I'm running this on macOS Monterey (version 12.0.1) with cargo version 1.56.0 and solo2 version 0.1.0.

"solo2 app oath" does not work correctly

Software version

$ solo2 --version
solo2 0.1.1

$ solo2 app admin version
1:20200101.9

$ hostnamectl
Operating System: Pop!_OS 21.10                   
Kernel: Linux 5.16.11-76051611-generic
Architecture: x86-64

Steps to reproduce

$ export SECRET=$(head -c 32 /dev/urandom|base32 -w0)

$ solo2 app oath register example ${SECRET}
example

$ solo2 app oath totp example
Error: p1/p2 parameters not supported on this transport

$ solo2 app oath list
thread 'main' panicked at 'explicit panic', /home/davideriva/.cargo/registry/src/github.com-1ecc6299db9ec823/solo2-0.1.1/src/transport/ctap.rs:90:18
stack backtrace:
   0:     0x55e23515803c - std::backtrace_rs::backtrace::libunwind::trace::h91c465e73bf6c785
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:     0x55e23515803c - std::backtrace_rs::backtrace::trace_unsynchronized::hae9da36f5d58b5f3
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x55e23515803c - std::sys_common::backtrace::_print_fmt::h7f499fa126a7effb
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/sys_common/backtrace.rs:67:5
   3:     0x55e23515803c - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h3e2b509ce2ce6007
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/sys_common/backtrace.rs:46:22
   4:     0x55e23517d1ec - core::fmt::write::h753c7571fa063ecb
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/core/src/fmt/mod.rs:1168:17
   5:     0x55e235150d93 - std::io::Write::write_fmt::h2815c0519c99ba09
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/io/mod.rs:1660:15
   6:     0x55e23515a8e2 - std::sys_common::backtrace::_print::h64941a6fc8b0ed9b
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/sys_common/backtrace.rs:49:5
   7:     0x55e23515a8e2 - std::sys_common::backtrace::print::hcf25e43e1a9b0766
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/sys_common/backtrace.rs:36:9
   8:     0x55e23515a8e2 - std::panicking::default_hook::{{closure}}::h78d3e6cf97fc623d
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/panicking.rs:211:50
   9:     0x55e23515a4c5 - std::panicking::default_hook::hda898f8d3ad1a5ae
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/panicking.rs:228:9
  10:     0x55e23515af33 - std::panicking::rust_panic_with_hook::h1a5ea2d6c23051aa
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/panicking.rs:606:17
  11:     0x55e23515ac22 - std::panicking::begin_panic_handler::{{closure}}::h07f549390938b73f
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/panicking.rs:500:13
  12:     0x55e2351584e4 - std::sys_common::backtrace::__rust_end_short_backtrace::h5ec3758a92cfb00d
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/sys_common/backtrace.rs:139:18
  13:     0x55e23515a989 - rust_begin_unwind
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/panicking.rs:498:5
  14:     0x55e234eee561 - core::panicking::panic_fmt::h3a79a6a99affe1d5
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/core/src/panicking.rs:116:14
  15:     0x55e234eee4ad - core::panicking::panic::h97167cd315d19cd4
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/core/src/panicking.rs:48:5
  16:     0x55e234f3966b - <solo2::device::ctap::Device as solo2::transport::Transport>::call::h0cab9461d19d9864
  17:     0x55e234f1fde3 - <solo2::device::Solo2 as solo2::transport::Transport>::call::h1b4f3b7f26a22f66
  18:     0x55e234f0c984 - solo2::transport::Transport::instruct::h03a3301f5235c3a8
  19:     0x55e234f296df - solo2::apps::oath::App::list::h2ee6a571c175cb1a
  20:     0x55e234f01435 - solo2::try_main::hf2939f35317c5c42
  21:     0x55e234efe4c2 - solo2::main::hfd9fc59f365b416f
  22:     0x55e234f08353 - std::sys_common::backtrace::__rust_begin_short_backtrace::hd039ae7e42400795
  23:     0x55e234f04389 - std::rt::lang_start::{{closure}}::h6c17aedab7191aa6
  24:     0x55e2351576f0 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h443f738a8e9f947a
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/core/src/ops/function.rs:259:13
  25:     0x55e2351576f0 - std::panicking::try::do_call::h1e21ba261ba489ec
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/panicking.rs:406:40
  26:     0x55e2351576f0 - std::panicking::try::h6afd48af8b6c96ac
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/panicking.rs:370:19
  27:     0x55e2351576f0 - std::panic::catch_unwind::h85dd95e0bab7fb60
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/panic.rs:133:14
  28:     0x55e2351576f0 - std::rt::lang_start_internal::{{closure}}::h038455e697c8b03e
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/rt.rs:128:48
  29:     0x55e2351576f0 - std::panicking::try::do_call::h6b0ad65979f3077a
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/panicking.rs:406:40
  30:     0x55e2351576f0 - std::panicking::try::h010108d314169ac6
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/panicking.rs:370:19
  31:     0x55e2351576f0 - std::panic::catch_unwind::hff397f912b1535c2
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/panic.rs:133:14
  32:     0x55e2351576f0 - std::rt::lang_start_internal::h52e73755f77c7dd9
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/rt.rs:128:20
  33:     0x55e234f03e62 - main
  34:     0x7fb96f92ffd0 - <unknown>
  35:     0x7fb96f93007d - __libc_start_main
  36:     0x55e234eeecd5 - _start
  37:                0x0 - <unknown>

SoloKey not turning back on after update

I updated al my solokeys to the latest firmware (few weeks ago that was) but one of them is stuck in boot loader, and won't turn back

The screenshot is after trying it a few times in communication with solokeys

It does not return to the prompt and the LED is not turned back on.

3 solokeys updated without a hitch, but this one is not working anymore. Anyone have an idea how to get it working again?

I use it as a backup key which is normally in my safe at home for when I loose my primary key.

Solo2 Key OATH HOTP unable to register with Secrets from Keepass

Hello. I am trying to secure my keepass database with OATH HOTP.

So in keepass it lets me generate a random 128-Bit Secret Key or an 256-Bit Secret Key.
Since the example from the CLI is 128-Bit i went with that, but for some reason i am unable to get the CLI to accept the generated Key.

I am always getting Error: invalid symbol at 4 etc. number always changing when generating a new Secret Key.
Since i haven't found to let the CLI generate the Secret, i am a bit lost and the error is not really helpful what is wrong with the key.
I tried to delete and replace the symbols at the mentioned locations but only got to Error: invalid symbol at 0

And no matter what i change the first number/letter to, it stays at location 0.

Any idea or solution how this is supposed to work?

btw. using the example secret like this:
solo2-v0.1.1-x86_64-pc-windows-msvc.exe app oath register -c 20 -k hotp -d 8 keepass JBSWY3DPEHPK3PXPJBSWY3DPEHPK3PXP
it works, but i don't want to use a secret everybody knows.

solo2 update not working on Ubuntu

Hello, I've just tried to update firmware on one of the SoloKey2 I just received.
I get prompted to tap to confirm, the led on the key goes off bit then I get a tiemout error:

❯ solo2 update
Downloading latest release from https://github.com/solokeys/solo2/
Fetched firmware version 1:20200101.9 (1.0.9)
Tap button on key to confirm, or replug to abort...
Error: User prompt to confirm maintenance timed out!
❯ solo2 -V
solo2 0.2.0

I installed solo2 with cargo install.
I was able to update the SoloKey2 on Mac with no issues.

48 character TOPT "To long"

on websites that for example could be amazon, the totp secret is 52 characters long. however when registering them in solo2-cli it states thew folowing:
solo2 app oath -a register Amazon "52 character long TOPT code"
Error: invalid length at 48.

cargo install solo2 fails to compile

I'm trying to install solo2 with cargo install solo2, but it fails to compile with:

error[E0599]: no variant or associated item named `PKCKS11` found for enum `uriparse::Scheme` in the current scope
   --> /Users/angel/.cargo/registry/src/github.com-1ecc6299db9ec823/pkcs11-uri-0.1.2/src/lib.rs:209:52
    |
209 |         if uri.scheme() != Some(&uriparse::Scheme::PKCKS11) {
    |                                                    ^^^^^^^
    |                                                    |
    |                                                    variant or associated item not found in `uriparse::Scheme<'_>`
    |                                                    help: there is a variant with a similar name: `PKCS11`

For more information about this error, try `rustc --explain E0599`.
error: could not compile `pkcs11-uri` due to previous error

Seems to be due to a typo in https://github.com/nickray/pkcs11-uri/ so I've opened a PR there nickray/pkcs11-uri#1.

The typo's root cause might be another dependency, namely https://github.com/sgodwincs/uriparse-rs/ which had the typo at one point, but it was corrected in sgodwincs/uriparse-rs#19 by @nickray and merged later. Might be that a uriparse version update in https://github.com/solokeys/solo2-cli repo triggered this.

I see @nickray is a contributor to both solo2 and pkcs11-uri, so they might be able to do a new release of pkcs11-uri with the fix and update the solo2 dependencies.

Rust version tested with:

% rustc -V -v
rustc 1.59.0 (9d1b2106e 2022-02-23)
binary: rustc
commit-hash: 9d1b2106e23b1abd32fce1f17267604a5102f57a
commit-date: 2022-02-23
host: aarch64-apple-darwin
release: 1.59.0
LLVM version: 13.0.0

Homebrew Support

Hi,

I need some help for packaging solo2-cli in homebrew.
Homebrew build packages by its own ci and test this packages.
So I match the empty response of solo2 ls. This command run sometimes into a timeout. (takes to lang)
May someone has an idea.

Homebrew/homebrew-core#112877

Solokey 2 NFC

Hi, I emailed support and was told to create an issue here for visibility. When using NFC on solokey 2 with Android, after 2FA, it always redirects the web page to solokeys.com. Is there a way to disable this behaviour? Thanks

Windows binary not signed and missing version info resource

As per the title, please add a version info resource and sign the binary.

Cannot use some app commands

I'm attempting to use the solo2 app ndef data and solo2 app oath list commands, and I get an explicit panic. When I added some debug statements, it appears that the cli is attempting to send vendor code 0xA4 for ndef data and 0xA1 for oath list, both of which are outside the expected range for vendor codes.

I checked the CTAP spec and it says that the range is actually 0x40 to 0xBF, so I expanded the expected range on the solo cli source to match that. When I attempt to run those commands it now hangs after sending the packet over CTAP.

I found those hex values in the apps' sources, so I would expect this to work unless there is another check earlier on in the firmware that is dropping instructions beyond the vendor code range.

Are these commands expected to work on the latest released firmware and CLI?

I can provide detailed trace level logs and backtraces if requested.

Building with provided PKGBUILD fails in Arch with LTO

When trying to build this package with LTO enabled, it fails at the linking stage.

The default in Arch is disabled as far as I can tell, however I'd like to ask to add an explicit options=('!lto') to the PKGBUILDS so that this package still builds on systems with that setting enabled.

thread 'main' panicked at 'success: HidApi(IncompleteSendError { sent: 60, all: 36 })' in bootloader mode in Windows 10

When trying to update on Windows 10, the key appears to be put into (or there are attempts to put it into) bootloader mode, but no commands seem to work on it afterwards - this results in thread 'main' panicked at 'success: HidApi(IncompleteSendError { sent: 60, all: 36 })' error on update and with other bootloader commands (bootloader ls, bootloader reboot). Full logs with SOLO2_LOG=debug and RUST_BACKTRACE=full (redacted some number since I'm not sure if they aren't supposed to be kept private):

 INFO  solo2 > solo2 CLI startup
 INFO  solo2::smartcard > connecting with reader: `SoloKeys CCID/ICCD Interface 0`
 DEBUG solo2::smartcard > >> [redacted]
 DEBUG solo2::smartcard > RECV 2 bytes
 DEBUG solo2::smartcard > << [redacted]
 DEBUG solo2::smartcard > >> [redacted]
 DEBUG solo2::smartcard > RECV 18 bytes
 DEBUG solo2::smartcard > << [redacted]
 INFO  solo2::smartcard > ...connected
 DEBUG solo2::smartcard > Reader has a card.
 INFO  solo2::smartcard > connecting with reader: `Windows Hello for Business 1`
 DEBUG solo2::smartcard > >> [redacted]
 DEBUG solo2::smartcard > RECV 2 bytes
 DEBUG solo2::smartcard > << [redacted]
 INFO  solo2::smartcard > ...connected
 DEBUG solo2::smartcard > Reader has a card.
Downloading latest release from https://github.com/solokeys/solo2/
 DEBUG reqwest::connect > starting new connection: https://api.github.com/
 DEBUG reqwest::async_impl::client > response '200 OK' for https://api.github.com/repos/solokeys/solo2/releases/latest
Downloading firmware v1.0.6...
 INFO  solo2::update               > found solo2 firmare in release
 DEBUG reqwest::connect            > starting new connection: https://github.com/
 DEBUG reqwest::async_impl::client > redirecting 'https://github.com/solokeys/solo2/releases/download/1.0.6/solo2-firmware-1.0.6.sb2' to 'https://objects.githubusercontent.com/github-production-release-asset-2e65be/234604146/5b57af48-017e-4c3f-82df-77de0e78bbcb?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20211103%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20211103T172234Z&X-Amz-Expires=300&X-Amz-Signature=1ad971124eaf1a5a4c491ecc499818c11b1f345893132abbdb0b35d9ce91c4d6&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=234604146&response-content-disposition=attachment%3B%20filename%3Dsolo2-firmware-1.0.6.sb2&response-content-type=application%2Foctet-stream'
 DEBUG reqwest::connect            > starting new connection: https://objects.githubusercontent.com/
 DEBUG reqwest::async_impl::client > response '200 OK' for https://objects.githubusercontent.com/github-production-release-asset-2e65be/234604146/5b57af48-017e-4c3f-82df-77de0e78bbcb?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20211103%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20211103T172234Z&X-Amz-Expires=300&X-Amz-Signature=1ad971124eaf1a5a4c491ecc499818c11b1f345893132abbdb0b35d9ce91c4d6&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=234604146&response-content-disposition=attachment%3B%20filename%3Dsolo2-firmware-1.0.6.sb2&response-content-type=application%2Foctet-stream
 INFO  solo2::update               > found solo2 firmare hash in release
 DEBUG reqwest::async_impl::client > redirecting 'https://github.com/solokeys/solo2/releases/download/1.0.6/solo2-firmware-1.0.6.sha2' to 'https://objects.githubusercontent.com/github-production-release-asset-2e65be/234604146/aaec22f8-9514-4b5e-b831-5957d12a9aa4?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=[redacted]3%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20211103T172236Z&X-Amz-Expires=300&X-Amz-Signature=323ad9614e94db42fff1d967548f67d04d6762027a93ac7aece7cd2f75a95863&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=234604146&response-content-disposition=attachment%3B%20filename%3Dsolo2-firmware-1.0.6.sha2&response-content-type=application%2Foctet-stream'
 DEBUG reqwest::async_impl::client > response '200 OK' for https://objects.githubusercontent.com/github-production-release-asset-2e65be/234604146/aaec22f8-9514-4b5e-b831-5957d12a9aa4?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=[redacted]%2F20211103%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20211103T172236Z&X-Amz-Expires=300&X-Amz-Signature=323ad9614e94db42fff1d967548f67d04d6762027a93ac7aece7cd2f75a95863&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=234604146&response-content-disposition=attachment%3B%20filename%3Dsolo2-firmware-1.0.6.sha2&response-content-type=application%2Foctet-stream
Verified hash.
Multiple devices connected.
Enter 0-1 to select:
0 - "SoloKeys CCID/ICCD Interface 0" UUID: [redacted]
Selection (0-9): 0
 INFO  solo2::apps                 > selecting app: A00000084700000001
 DEBUG solo2::smartcard            > >> [redacted]
 DEBUG solo2::smartcard            > RECV 2 bytes
 DEBUG solo2::smartcard            > << 9000
 DEBUG solo2::smartcard            > >> [redacted]
 DEBUG solo2::smartcard            > RECV 6 bytes
 DEBUG solo2::smartcard            > << [redacted]
 INFO  solo2::update               > current device version major: 1
 INFO  solo2::update               > new sb2 firmware version: Version { major: 1, minor: 0, patch: 6 }
Tap button on key...
 DEBUG solo2::smartcard            > >> [redacted]
Waiting for key to enter bootloader mode...
 INFO  solo2::update               > attempt 0
 INFO  solo2::update               > attempt 1
 INFO  solo2::update               > attempt 2
thread 'main' panicked at 'success: HidApi(IncompleteSendError { sent: 60, all: 36 })', C:\Users\oplik0\.cargo\registry\src\github.com-1ecc6299db9ec823\lpc55-0.1.0-alpha.7\src\bootloader\protocol.rs:110:76
stack backtrace:
   0:     0x7ff74339754f - <unknown>
   1:     0x7ff7433aed0a - <unknown>
   2:     0x7ff743391058 - <unknown>
   3:     0x7ff743399cd6 - <unknown>
   4:     0x7ff7433997bc - <unknown>
   5:     0x7ff74339a335 - <unknown>
   6:     0x7ff743399f1b - <unknown>
   7:     0x7ff743397e87 - <unknown>
   8:     0x7ff743399e79 - <unknown>
   9:     0x7ff7433c4bd0 - hid_write
  10:     0x7ff7433c4ce3 - hid_write
  11:     0x7ff7432a0cc8 - <unknown>
  12:     0x7ff74329f61b - <unknown>
  13:     0x7ff74329e18b - <unknown>
  14:     0x7ff74329ef00 - <unknown>
  15:     0x7ff74329d370 - <unknown>
  16:     0x7ff74329d114 - <unknown>
  17:     0x7ff7431158af - <unknown>
  18:     0x7ff7430e050f - <unknown>
  19:     0x7ff7430e5427 - <unknown>
  20:     0x7ff7430e7277 - <unknown>
  21:     0x7ff7430dcb59 - <unknown>
  22:     0x7ff7430dcd75 - <unknown>
  23:     0x7ff7430f55ca - <unknown>
  24:     0x7ff7430dd531 - <unknown>
  25:     0x7ff7430d9be6 - <unknown>
  26:     0x7ff7430f2efc - <unknown>
  27:     0x7ff743396e97 - <unknown>
  28:     0x7ff7430dd6a7 - <unknown>
  29:     0x7ff7433b6db4 - hid_write
  30:     0x7ffbb8757034 - BaseThreadInitThunk
  31:     0x7ffbb9f82651 - RtlUserThreadStart

Subsequent runs produce basically the same output just without the device selection step.

Edit: this appears to be a general bootloader issue in Windows, not just with updates. Putting the key into bootloader mode manually (be it via solo app admin boot-to-bootrom or holding all keys for 5 seconds when inserting) bootloader commands emit the same thread 'main' panicked at 'success: HidApi(IncompleteSendError { sent: 60, all: 36 })' error

Solo v2 reset

Hello,

I forgot what pin I created in Windows 10 for 1 solokey v2 and decided to reset it. I did it via oath reset on Win10, no errors returned - Win10 still says that "too many wrong PIN entered, contact IT administrator". I did reset on Mac M1 and it did not help as well. Next was an attempt to format solo on Mac, but it returns error:

./solo2-v0.2.0-x86_64-apple-darwin app provision reformat-filesystem
thread 'main' panicked at 'explicit panic', src/transport/ctap.rs:90:18
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

How to fully reset the key?

no wink

I notice that app fido wink doesn't work. There's no change in the light.
cli 0.1.1, firmware 1:20200101.9

Update fails after confirming and entering bootloader mode

Trying to update a new Solo2 to the latest firmware for the key-length bug fix, windows 10 x64 pro, and I get this:

Warning: This is is major update and it could risk breaking any current credentials on your key.
Check latest release notes here to double check: https://github.com/solokeys/solo2/releases
If you haven't used your key for anything yet, you can ignore this.

✔ Continue? · yes
Continuing
Tap button on key...
Waiting for key to enter bootloader mode...
thread 'main' panicked at 'success: HidApi(IncompleteSendError { sent: 60, all: 36 })', C:\Users\runneradmin\.cargo\registry\src\github.com-1ecc6299db9ec823\lpc55-0.1.0-alpha.7\src\bootloader\protocol.rs:110:76
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

It did put it into bootloader mode, and the driver did end up getting installed and the light goes off, but it doesn't actually update it. If I run the update again while it's already in bootloader, I still get the same panic.

I'm using the 0.0.6 release binary for the tool.

(It does work on Linux with the tool installed with cargo install solo2 after updating that config file for ccid)

Update crates.io package

Bump the crates.io package version to 0.1.1.

Reason:
I'm aware that you can install packages via git (cargo install --git https://github.com/solokeys/solo2-cli), however this has the disadvantage that those packages are not tracked via cargo-update etc., so it's pretty easy to end up with an outdated/broken version without noticing it.

Question about the current usability

Some questions from a beginner's perspective:
How has the development progressed so far? Maybe a brief look at the roadmap.
How is the current functionality compared to the solo1?
e.g. still possible to reset the stick?

...thank you

Solo Key USB A + NFC Issue "USB device was not recognized"

Hi,

i have a issue with an Solo Key USB A + NFC of the first recent order.

One of the Solo Tabs was only recognized by Windows when it was plugged in for the first time.
After plugging in the following error message comes up: "USB device was not recognized".

device manager:
This device has stopped because it was reporting errors. (code 43)
A request for the USB device descriptor failed.

The error also appears on another Windows/Linux device.
The second Solo Key USB A + NFC of the order works fine.

The LED of the defective stick does not light up after plugging it in.
If the stick is pressed continuously while plugging it in, the LED flickers red and green continuous.

Use semver for end-user version display

CalVer is not something most people expect, it doesn't match the GitHub releases and it doesn't actually work as it returns 1:20200101.8 for 1.0.8 released on 2021-11-11 (which is the date 0 in lpc55 calver from my quick check).

See this discussion for an example of confusion: solokeys/kickstarter2021#31

It's not clear at all that this version is actually 1.0.8 from GitHub.

lpc55-host also implements to_semver, so it should be a simple replacement.

2 keys: 1 can be updated, the other not

I have an issue I can't understand:
I was given 2 solokeys and I was told I have to update them before use.
I followed the instructions and it works perfectly on the first key.

For the second key, I can see 1 blue bink only and then:

20:20200101.0 is under 2:20220822.0, isn't it ?

MacBook-3:SoloUpdates2 PJ$ solo2 update --verbose
Downloading latest release from https://github.com/solokeys/solo2/
Fetched firmware version 2:20220822.0 (2.964.0)
 INFO  solo2::transport > using CTAP as minimal transport
 INFO  solo2::transport > using CTAP as minimal transport
 INFO  solo2::device    > device fw version: 20:20200101.0
 INFO  solo2::device    > new fw version: 2:20220822.0
Firmware version on device higher than firmware version used.
This would be rejected by the device.
Error: Firmware rollback attempt

Can you explain me the issue.

When I plug the both keys:

MacBook-3:SoloUpdates2 PJ$ solo2 ls
Solo 2 1949AECA1525A256A384748B4189736D (CTAP only, firmware 2:20220822.0, locked)
Solo 2 FEB84FD1CFABCF59AD7F5C2BDBD8FEA9 (CTAP only, firmware 20:20200101.0)
MacBook-3:SoloUpdates2 PJ$

The first line is the key which was updated succesfully. Why is there this locked ?

Registering TOTP Causes CLI To Crash

I registered a TOTP secret and ever since the OAUTH and NDEF apps no longer work correctly.
Also not able to reset the device.

solo2 app oath register test_user INR6PHIAIQTCQMZMQAL3P2SE

Attached is the backtrace when I run solo2 app oath list
solo2.txt

Solo V2 not working with all websites

I just received my SoloKey V2 and tried to register it everywhere where I already use my SoloKey V1. Unfortunately some platforms seem to have problems with the V2 (Firmware 20200101.9). For example Amazon AWS or GitLab does not recognize the key. With the V1 everything is working as expected.

Is this an already known issue?

"solo2 app oath" does not work correctly

Software version

$ solo2 --version
solo2 0.1.1

$ solo2 app admin version
1:20200101.9

$ hostnamectl
Operating System: Pop!_OS 21.10                   
Kernel: Linux 5.16.11-76051611-generic
Architecture: x86-64

Steps to reproduce

$ export SECRET=$(head -c 32 /dev/urandom|base32 -w0)

$ solo2 app oath register example ${SECRET}
example

$ solo2 app oath totp example
Error: p1/p2 parameters not supported on this transport

$ solo2 app oath list
thread 'main' panicked at 'explicit panic', /home/davideriva/.cargo/registry/src/github.com-1ecc6299db9ec823/solo2-0.1.1/src/transport/ctap.rs:90:18
stack backtrace:
   0:     0x55e23515803c - std::backtrace_rs::backtrace::libunwind::trace::h91c465e73bf6c785
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:     0x55e23515803c - std::backtrace_rs::backtrace::trace_unsynchronized::hae9da36f5d58b5f3
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x55e23515803c - std::sys_common::backtrace::_print_fmt::h7f499fa126a7effb
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/sys_common/backtrace.rs:67:5
   3:     0x55e23515803c - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h3e2b509ce2ce6007
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/sys_common/backtrace.rs:46:22
   4:     0x55e23517d1ec - core::fmt::write::h753c7571fa063ecb
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/core/src/fmt/mod.rs:1168:17
   5:     0x55e235150d93 - std::io::Write::write_fmt::h2815c0519c99ba09
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/io/mod.rs:1660:15
   6:     0x55e23515a8e2 - std::sys_common::backtrace::_print::h64941a6fc8b0ed9b
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/sys_common/backtrace.rs:49:5
   7:     0x55e23515a8e2 - std::sys_common::backtrace::print::hcf25e43e1a9b0766
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/sys_common/backtrace.rs:36:9
   8:     0x55e23515a8e2 - std::panicking::default_hook::{{closure}}::h78d3e6cf97fc623d
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/panicking.rs:211:50
   9:     0x55e23515a4c5 - std::panicking::default_hook::hda898f8d3ad1a5ae
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/panicking.rs:228:9
  10:     0x55e23515af33 - std::panicking::rust_panic_with_hook::h1a5ea2d6c23051aa
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/panicking.rs:606:17
  11:     0x55e23515ac22 - std::panicking::begin_panic_handler::{{closure}}::h07f549390938b73f
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/panicking.rs:500:13
  12:     0x55e2351584e4 - std::sys_common::backtrace::__rust_end_short_backtrace::h5ec3758a92cfb00d
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/sys_common/backtrace.rs:139:18
  13:     0x55e23515a989 - rust_begin_unwind
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/panicking.rs:498:5
  14:     0x55e234eee561 - core::panicking::panic_fmt::h3a79a6a99affe1d5
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/core/src/panicking.rs:116:14
  15:     0x55e234eee4ad - core::panicking::panic::h97167cd315d19cd4
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/core/src/panicking.rs:48:5
  16:     0x55e234f3966b - <solo2::device::ctap::Device as solo2::transport::Transport>::call::h0cab9461d19d9864
  17:     0x55e234f1fde3 - <solo2::device::Solo2 as solo2::transport::Transport>::call::h1b4f3b7f26a22f66
  18:     0x55e234f0c984 - solo2::transport::Transport::instruct::h03a3301f5235c3a8
  19:     0x55e234f296df - solo2::apps::oath::App::list::h2ee6a571c175cb1a
  20:     0x55e234f01435 - solo2::try_main::hf2939f35317c5c42
  21:     0x55e234efe4c2 - solo2::main::hfd9fc59f365b416f
  22:     0x55e234f08353 - std::sys_common::backtrace::__rust_begin_short_backtrace::hd039ae7e42400795
  23:     0x55e234f04389 - std::rt::lang_start::{{closure}}::h6c17aedab7191aa6
  24:     0x55e2351576f0 - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h443f738a8e9f947a
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/core/src/ops/function.rs:259:13
  25:     0x55e2351576f0 - std::panicking::try::do_call::h1e21ba261ba489ec
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/panicking.rs:406:40
  26:     0x55e2351576f0 - std::panicking::try::h6afd48af8b6c96ac
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/panicking.rs:370:19
  27:     0x55e2351576f0 - std::panic::catch_unwind::h85dd95e0bab7fb60
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/panic.rs:133:14
  28:     0x55e2351576f0 - std::rt::lang_start_internal::{{closure}}::h038455e697c8b03e
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/rt.rs:128:48
  29:     0x55e2351576f0 - std::panicking::try::do_call::h6b0ad65979f3077a
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/panicking.rs:406:40
  30:     0x55e2351576f0 - std::panicking::try::h010108d314169ac6
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/panicking.rs:370:19
  31:     0x55e2351576f0 - std::panic::catch_unwind::hff397f912b1535c2
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/panic.rs:133:14
  32:     0x55e2351576f0 - std::rt::lang_start_internal::h52e73755f77c7dd9
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/rt.rs:128:20
  33:     0x55e234f03e62 - main
  34:     0x7fb96f92ffd0 - <unknown>
  35:     0x7fb96f93007d - __libc_start_main
  36:     0x55e234eeecd5 - _start
  37:                0x0 - <unknown>

update fails

I've just tried "solo2 update" before reporting anything else (from firmware 1:20200101.8) with the cli v0.1.1 on Debian 11, with no luck. When I tap (more like prod) at the prompt, the key goes dead and needs to be unplugged. The kernel log has multiple disconnect messages. I don't know if it's necessary, but I had reloaded udev with the given rules; I don't know when they are actually needed, but probably the readme here should at least mention installing them. Anyway, I see this before it dies:

$ SOLO2_LOG=info solo2 update
Downloading latest release from https://github.com/solokeys/solo2/
Fetched firmware version 1:20200101.9
 INFO  solo2::transport > using CTAP as minimal transport
 INFO  solo2::device    > device fw version: 1:20200101.8
 INFO  solo2::device    > new fw version: 1:20200101.9
Tap button on key to confirm, or replug to abort...
 INFO  solo2::transport > using CTAP as minimal transport

The prompt says "replug to abort", but the command just hangs pending ^C. Also it says "tap the button", but there isn't anything most people would call a button, and it's not clear whether that means any of the edges or a specific one.

Solokey v2: not working with google on firefox (ubuntu)

Hello ,

I'm trying to authenticate with my solo v2 (USB) to google.

Everything works fine on chrome, but in firefox I got this message:

There was a problem
Try using your security key again or try another way to verify it’s you

versions :

ubuntu 20.04
firefox 99.0
solo firmware 1:20200101.9

It's the same issue as solokeys/solo1#74 ? message appears also if the key have been correctly registered using chrome

FIDO2 not recognized on Win10

I get met Solo2 USB-C keys (4) now. But I'm not able to use them, because in none of the browsers they are recognized. The key is not in the list of available hardware.

What is needed to make them run also on Windows? A complete absence of documentation is really frustrating.

On Chromebook it works.

Windows

Edition: Windows 10 Pro
Version: 21H2
Build: 19044.1706

Browsers

Edge Version 101.0.1210.53
Brave Version 1.39.111 Chromium: 102.0.5005.61

Key

> solo2 list
Solo 2 *** (PCSC only, firmware 1:20200101.9)

Solokey v2 not working in Windows

Solokey v2 normal version1:20200101.8 and 1:20200101.7 is not working in Windows 10.
if plugged in windows will recordnize the solokey and install the device.

when trying to register the key to a web site, i used a test website with different web browser. windows show form to touch key right now.
and solokey led change light a little bit. but nothing happens if i touch the device.

with ios and nfc using it on the test website it is working like expected.

with solokey v2 hacker version 1:20200101.8 if plugged in windows will recordnize the solokey and install the device.
when trying to register the key to a web site, i used a test website with different web browser. windows show form to touch key right now.
and solokey led change light to another color. if i touch the device now solokey registration on that test website is successfull.
i can use it same way to loggin to the test website.

example commands crash

I tried these with 0.1.1 on Debian 11

$ solo2 app admin uuid
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: TryFromSliceError(())', src/apps/admin.rs:48:55
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
$ solo2 app ndef capabilities
thread 'main' panicked at 'explicit panic', src/transport/ctap.rs:90:18
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Reflashing from bootloader mode without hardware

I have a Solo 2 Hacker edition, as I was thinking of playing around with it, but I'm not in love with the possibility of functionally permanently bricking it (because the special cable is currently twice the price of the Solo).

Will/can there be a special way for the Solo to boot to the bootloader so I can reflash the firmware if it panics? Can I connect some pin to ground during boot, for example? Or is this impossible from the hardware and I'd better not play around too much?

Solo v2 enters into a constant "getting ready" "touch device" loop on Windows 11

This is not a CLI problem but, we can't file bugs in the firmware repository, and the previous bug (#35) was closed because "it wasn't CLI related". If you don't want us to report firmware bugs, explicitly say so.

Firmware version: 2:20220822.0 (2.964.0)

I'm trying to add SoloKey as a FIDO2 device to a web site using Microsoft Edge (Chromium) on Windows 11. The Windows Hello prompt constantly switches between "Getting ready" and "Touch device" states. If I can catch it during "touch device" it works fine, but it's an accessibility nightmare.

This doesn't happen with YubiKeys.

solo2 app fido init and sudo2 app fido wink commands also give Error: CTAP Unavailable error.

[Feature request] Package binary also for arm darwin M1/M2 chips

I can see in packages three different packages for darwin, linux and windows, all x86_64

It would be great to be able to use this CLI natively also on arm chips like the M1/M2 ones.

nvm

Update fails

Trying to update:

guillaume@thinkpad ~> solo2 update                                                                                                                                                                                                               ~
Downloading latest release from https://github.com/solokeys/solo2/
Fetched firmware version 1:20200101.8
Tap button on key to confirm, or replug to abort...
thread 'main' panicked at 'success: AbortDataPhase', /home/guillaume/.cargo/registry/src/github.com-1ecc6299db9ec823/lpc55-0.1.0-alpha.8/src/bootloader/protocol.rs:110:76
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

after:

guillaume@thinkpad ~ [101]> solo2 ls                                                                                                                                                                                                             ~
LPC 55 9AE924EB79ECC45DA66A0841426A083A

Key is completely unresponsive.

solo2 bootloader reboot

is not working.

EDIT: Running solo2 update once again while the key is unresponsive in bootloader mode then restored it to a functional state.

Solo key seem dead after received

I've been redirected here after a mail i sent to [email protected]
I've just received my Solo v2 hacker (USBC) ordered from the Kickstarter campaign a while back.

Immediately after received it, I tried it as I would normally use it.

It worked well for registering, login on Windows and mac. When I tried using NFC on my phone, it failed (something saying the transaction was unexpectedly finished). When I retried, nothing happens, the key seems dead.
When I put it back in the Windows PC, it complains now about being able to retrieve the USB descriptors from the device.

One thing that is worth being added:
When I plugged the key in my PC or Mac, for the first time, the LEDs lighten up.
When I plugged the key in the PC after the NFC test (when i have problems with the USB descriptors) the leds did light up at all ?

Any ideas on what could have happened ?
Could it be a manufacturing issue ?
Should the key be replaced, if yes, how do I proceed ?

Any help would be great, thank you.

Solo2 key not recognized under Ubuntu/Debian

Hello everybody,
Thanks for making this project reality!

That said, I cannot get my solo2 key to be detected by solo2-cli.
(Also the key works to register and authenticate on website by "squeezing", yet the LED never blinks to indicate confirmation is required.)

I tried both on Ubuntu 20.04.3 and Debian 11.

Steps to reproduce:

Get a fresh Debian 11 install
Either:

Download the binary from release 0.1.0 OR
Install through cargo
- Install cargo (curl https://sh.rustup.rs -sSf | sh)
- Install dependencies (sudo apt-get install libudev-dev libpcsclist-dev) NB: they should be added to the readme
- Install solo2-cli (cargo install solo2)

Install PCSC daemon (sudo apt-get install pcscd)
Copy 70-solo2.rules under etc/udev/rules.d and reboot or reload rules (sudo udevadm control --reload-rules && sudo udevadm trigger)
Ensure PCSC daemon is running (sudo service start pcscd && sudo service pcscd status)
Connect Solo2 key and check dmesg

[ 2782.699240] usb 2-2: new full-speed USB device number 6 using ohci-pci
[ 2783.228068] usb 2-2: New USB device found, idVendor=1209, idProduct=beee, bcdDevice= 1.00
[ 2783.228076] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2783.228081] usb 2-2: Product: Solo 2 Security Key
[ 2783.228084] usb 2-2: Manufacturer: SoloKeys
[ 2783.228087] usb 2-2: SerialNumber: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
[ 2783.255162] hid-generic 0003:1209:BEEE.0005: hiddev0,hidraw1: USB HID v1.11 Device [SoloKeys Solo 2 Security Key] on usb-0000:00:06.0-2/input1
[ 2783.255413] cdc_acm 2-2:1.2: ttyACM0: USB ACM device

Run (as root or current user)

$ solo2 ls


$ solo2 app admin uuid
Error: Empty list of smartcards

Any suggestions?
Thanks in advance for your help.

MacOS - "Allow accessories to connect" dialog disapears to fast

The (new) "Allow accessories to connect" dialog on MacOS Ventura (13):

(example for other device)

When I insert me Solo Key V2 this diealog only appear for a few milliseconds and the device is connected but not matched and registered:

ioreg -p IOUSB | grep Solo
  | +-o Solo 2 Security Key@01100000  <class IOUSBHostDevice, id 0x10000cd26, !registered, !matched, active, busy 0, retain 13>

If I disable accessories security (autom. allow when unlocked), the token is connected correctly and works as expected:

ioreg -p IOUSB | grep Solo
| +-o Solo 2 Security Key@01100000  <class IOUSBHostDevice, id 0x10000cd46, registered, matched, active, busy 0 (52 ms), retain 45>

This doesn't happen with other USB device on this machine (unfortunately I don't have another macOS 13 device here to cross check this).

Anyone has the same problem? May that have to do with some timeout behaviour of the token?

New key, cannot list or update

Just received my solo2, thought I'd check if there was an update before using it. Can't seem to even get it recognized by the solo2 program.

➜  ~ solo2 update          
Downloading latest release from https://github.com/solokeys/solo2/
Fetched firmware version 1:20200101.9
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: The operation requires a Smart Card, but no Smart Card is currently in the device', /home/bendem/.cargo/registry/src/github.com-1ecc6299db9ec823/solo2-0.1.1/src/device/pcsc.rs:98:50
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Environment information:

➜  ~ cat /etc/fedora-release
Fedora release 34 (Thirty Four)
➜  ~ rustc --version             
rustc 1.59.0 (9d1b2106e 2022-02-23)
➜  ~ dnf list --installed pcsc-lite systemd
Installed Packages
pcsc-lite.x86_64                     1.9.1-1.fc34                      @anaconda
systemd.x86_64                       248.10-1.fc34                     @updates
➜  ~ cat /etc/udev/rules.d/70-solo2.rules 
# NXP LPC55 ROM bootloader (unmodified)
SUBSYSTEM=="hidraw", ATTRS{idVendor}=="1fc9", ATTRS{idProduct}=="0021", TAG+="uaccess"
# NXP LPC55 ROM bootloader (with Solo 2 VID:PID)
SUBSYSTEM=="hidraw", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="b000", TAG+="uaccess"
# Solo 2
SUBSYSTEM=="tty", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="beee", TAG+="uaccess"
# Solo 2
SUBSYSTEM=="usb", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="beee", TAG+="uaccess"

solo2.exe - The smart card cannot be accessed because of other connections outstanding

Hi!

I updated my Solo2 and tried just a basic solo2.exe ls:

PS C:\Users\colem> solo2
solo2 0.1.1
SoloKeys Developers
solo2 is the go-to tool to interact with a Solo 2 security key

USAGE:
    solo2.exe [OPTIONS] <SUBCOMMAND>

OPTIONS:
    -h, --help       Print help information
    -V, --version    Print version information

TRANSPORT:
        --ctap    Prefer CTAP transport
        --pcsc    Prefer PCSC transport

SELECTION:
    -u, --uuid <UUID>    Specify UUID of a Solo 2 device

SUBCOMMANDS:
    app           Interact with on-device applications
    bootloader    Interact with bootloader
    help          Print this message or the help of the given subcommand(s)
    list          List all available devices [aliases: ls]
    pki           PKI-related
    update        Update to latest firmware published by SoloKeys. Warns on Major updates

PS C:\Users\colem> solo2 ls
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: The smart card cannot be accessed because of other connections outstanding', src\device\pcsc.rs:98:50
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Firmware update fails due to timeout

I tried updating five regular Solo2 keys with the cli tool today. I managed to update three of them, but the other two keep failing due to a timeout:

[michael@toolbox ~]$ /var/home/michael/.cargo/bin/solo2 update
Downloading latest release from https://github.com/solokeys/solo2/
Fetched firmware version 2:20220822.0 (2.964.0)
LPC55 Bootloader detected. The LED should be off.
Writing new firmware...
thread 'main' panicked at 'success: HidApi(HidApiError { message: "Connection timed out" })', /var/home/michael/.cargo/registry/src/github.com-1ecc6299db9ec823/lpc55-0.1.2/src/bootloader.rs:296:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

What happens is that the progress bar for the firmware update first starts advancing, but at some point it freezes and shortly afterwards I get the error message above. The same issue happened with at least one of the three keys that I successfully updated, but simply replugging it into the laptop and running the update again solved the issue. I don't understand why it doesn't work for the last two keys.

Note in README.md about old 1.4.35 CCID driver no longer valid

Since MacOS Ventura (13) the CCID driver version 15.0.0 is used which supports Solo 2 Security Key.

See https://ludovicrousseau.blogspot.com/2022/11/macos-ventura-and-smart-cards-status.html for more details.

So this information could be updated/removed, at least for MacOS 13:

Solo 2 is supported by Ludovic Rousseau's CCID driver since release 1.4.35 (July 25, 2021).
Unfortunately, Debian and macOS have not updated yet.

The included Info.plist works.

If someone could check this for Debian, it might help others to update this outdated information.

solokeys / solo2-cli Goto Github PK

solo2-cli's People

Contributors

Stargazers

Watchers

Forkers

solo2-cli's Issues

Software version

Steps to reproduce

Windows

Browsers

Key

Steps to reproduce:

Recommend Projects

Recommend Topics

Recommend Org