solokeys / solo2-cli Goto Github PK
View Code? Open in Web Editor NEWSolo 2 library and CLI in Rust
Home Page: https://docs.rs/solo2
License: Apache License 2.0
Solo 2 library and CLI in Rust
Home Page: https://docs.rs/solo2
License: Apache License 2.0
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.
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.
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?
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 :
It's the same issue as solokeys/solo1#74 ? message appears also if the key have been correctly registered using chrome
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.
I notice that app fido wink
doesn't work. There's no change in the light.
cli 0.1.1, firmware 1:20200101.9
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.
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.
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 ?
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 :-)
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
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>
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
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-0ubuntu120.04.1, cargo 0.58.0-0ubuntu120.04.1, gcc 9.3.0
I'd be happy to provide more info, pls feel free to ask.
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.
> solo2 list
Solo 2 *** (PCSC only, firmware 1:20200101.9)
As per the title, please add a version info resource and sign the binary.
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.
The (new) "Allow accessories to connect" dialog on MacOS Ventura (13):
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?
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>
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.
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)
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.
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.
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
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 for
pcsc-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
`
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.
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 --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
$ 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>
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"
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.
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.
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.
curl https://sh.rustup.rs -sSf | sh
)sudo apt-get install libudev-dev libpcsclist-dev
) NB: they should be added to the readmecargo install solo2
)sudo apt-get install pcscd
)etc/udev/rules.d
and reboot or reload rules (sudo udevadm control --reload-rules && sudo udevadm trigger
)sudo service start pcscd && sudo service pcscd status
)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
$ solo2 ls
$ solo2 app admin uuid
Error: Empty list of smartcards
Any suggestions?
Thanks in advance for your help.
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.
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
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.
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
➜ ~ 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.
nvm
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.
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
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.
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?
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.
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
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?
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
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.
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.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.