We require Python >= 3.6 and corresponding
We intend to support Linux, Windows and macOS. Other platforms aren't supported by the FIDO2 library we rely on.
To get started, run
pip3 install solo-python, this installs both the
solo library and the
For development, we suggest you run
make init instead, which
soloas symlink using our packaging tool
flit, including all runtime dependencies listed in
One way to ensure the virtual environment is active is to use direnv.
For help, run
solo --help after installation. The tool has a hierarchy of commands and subcommands.
solo ls # lists all Solo keys connected to your machine solo version # outputs version of installed `solo` library and tool solo key wink # blinks the LED solo key verify # checks whether your Solo is genuine solo key rng hexbytes # outputs some random hex bytes generated on your key solo key version # outputs the version of the firmware on your key
Upon release of signed firmware updates in solokeys/solo, to update the firmware on your Solo to the latest version:
solotool if necessary via
pip3 install --upgrade solo-python
solo key update
For possibly helpful additional information, see https://github.com/solokeys/solo/issues/113.
solotool.py has been refactored into a library with associated CLI tool called
It is still work in progress, example usage:
import solo client = solo.client.find() client.wink() random_bytes = client.get_rng(32) print(random_bytes.hex())
Comprehensive documentation coming, for now these are the main components
solo.client: connect to Solo Hacker and Solo Secure keys in firmware or bootloader mode
solo.dfu: connect to Solo Hacker in dfu mode (disabled on Solo Secure keys)
solo.cli: implementation of the
solocommand line interface
By abuse of the
hmac-secret extension, we can generate static challenge responses,
which are scoped to a credential. A use case might be e.g. unlocking a LUKS-encrypted drive.
DANGER The generated reponses depend on both the key and the credential. There is no way to extract or backup from the physical key, so if you intend to use the "response" as a static password, make sure to store it somewhere separately, e.g. on paper.
DANGER Also, if you generate a new credential with the same
(host, user_id) pair, it will likely
overwrite the old credential, and you lose the capability to generate the original responses
DANGER This functionality has not been sufficiently debugged, please generate GitHub issues if you detect anything.
There are two steps:
solo key make-credential, storing the (hex-encoded) generated
credential_idfor the next step.
solo key challenge-response <credential_id> <challenge>.
Licensed under either of
at your option.
Any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.
We keep a CHANGELOG.
solo/VERSIONfile as appropriate
CHANGELOG.md(no need to repeat commit messages, but point out major changes in such a way that a user of the library has an easy entrypoint to follow development)
make fixto ensure code consistency
make buildto double check
make publish(assumes a
~/.pypircfile with entry
make tagto tag the release and push it