diff --git a/CHANGELOG-parent.md b/CHANGELOG-parent.md deleted file mode 100644 index 12233201..00000000 --- a/CHANGELOG-parent.md +++ /dev/null @@ -1,160 +0,0 @@ -# Changelog -All notable changes to this project will be documented in this file. - -The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), -and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). - -## [Unreleased] - -## [0.0.18] - 2019-10-29 -### Added -### Changed -- When signing, signatures were incorrectly annotated with `2.3.0` version. updated to `2.5.3`. - -## [0.0.17] - 2019-10-28 -### Added -### Changed -- remove `--hacker` and `--secure` options when auto-updating. -- pull `firmware-*.json` instead of choosing between hacker and secure - -## [0.0.16] - 2019-10-28 -### Added -- option to specify attestation certificate with attestation key -- mergehex operation adds in attestation certificate -- mergehex operation adds in lock status with `--lock` flag - -### Changed -- attestation key requires associate attestation cert -- sign operation adds 2 signatures for 2 different versions of solo bootloader -- solo version attempts to uses HID version command to additionally see lock status of key. - -## [0.0.15] - 2019-08-30 -### Added -- `solo.hmac_secret.make_credential` method -- separate `solo key make-credential` CLI target - -### Changed -- remove credential generation from `solo.hmac_secret.simple_secret` -- demand `credential_id` in `solo key challenge-response` - -## [0.0.14] - 2019-08-30 -### Added -- challenge-response via `hmac-secret` - -## [0.0.13] - 2019-08-19 -### Changed -- implement passing PIN to `solo key verify` - -## [0.0.12] - 2019-08-08 -### Changed -- update fido2 to 0.7.0 - -## [0.0.11] - 2019-05-27 -### Changed -- adjust to and pin fido2 0.6.0 dependency (@conorpp) -- only warn if run as sudo - -## [0.0.10] - 2019-03-18 -### Added -- solo client improvements -- experimental interface to feed kernel entropy from key: -`sudo ALLOW_ROOT= /path/to/solo key rng feedkernel` - -## [0.0.9] - 2019-03-18 -### Added -- enforce `solo` command does not run as root - -## [0.0.8] - 2019-03-18 -### Added -- `solo key probe` interface -### Changed -- fixes to set options bytes to leave DFU mode - -## [0.0.7] - 2019-03-08 -### Changed -- Exit properly on boot to bootloader failure -- `--alpha` flag for `update` - -## [0.0.6] - 2019-02-27 -### Changed -- Fix bootloader-version command (@Thor77) -- Reboot to bootloader in `program` if necessary -### Added -- yes flag for `update` - -## [0.0.6a3] - 2019-02-20 -### Changed -- Typo - -## [0.0.6a2] - 2019-02-20 -### Added -- Monkey-patch to communicate via UDP with software key -- Flag `--udp` to use it for certain `solo key` commands - -## [0.0.6a1] - 2019-02-19 -### Added -- Serial number support - -## [0.0.5] - 2019-02-18 -### Changed -- Initial feedback from https://github.com/solokeys/solo/issues/113 - -## [0.0.4] - 2019-02-18 -### Changed -- Enforce passing exactly one of `--hacker|--secure` in `solo key update` - -## [0.0.3] - 2019-02-18 -### Changed -- Bugfix in `solo.dfu` -- Minor improvements - -## [0.0.2] - 2019-02-18 -### Changed -- Fix broken `solo program dfu` command -- Remove `solotool` script installation -- Add Python version classifiers - -## [0.0.1] - 2019-02-17 -### Added -- Implement `solo key update [--hacker]` - -## [0.0.1a8] - 2019-02-17 -### Added -- Forgot to add some files in last release -- Add client/dfu find\_all methods -- Add `solo ls` command - -## [0.0.1a7] - 2019-02-16 -### Added -- More implementation of `solo program aux` (mode changes) -- Implement `solo program bootloader`. -- More comments - -## [0.0.1a6] - 2019-02-16 -### Changed -- Implements part of `solo program dfu` and `solo program aux` -- Adds Conor's change allowing to pass in raw devices to DFU+SoloClient - -## [0.0.1a5] - 2019-02-16 -### Changed -- Unwrap genkey from CLI to operations - -## [0.0.1a4] - 2019-02-16 -### Added -- Everything moved out of solotool, except programming chunk - -## [0.0.1a3] - 2019-02-16 -### Added -- Start redo of CLI using click - -## [0.0.1a2] - 2019-02-15 -### Changed -- Bugfixes related to refactor - -## [0.0.1a1] - 2019-02-15 -### Changed -- Start to split out commands, helpers and client - -## [0.0.1a0] - 2019-02-15 -### Added -- Initial import of `solotool.py` script from [solo](https://github.com/solokeys/solo) diff --git a/README-parent.md b/README-parent.md deleted file mode 100644 index 80cf8a26..00000000 --- a/README-parent.md +++ /dev/null @@ -1,129 +0,0 @@ -![](https://img.shields.io/pypi/l/solo-python.svg?style=flat) ![](https://img.shields.io/pypi/pyversions/solo-python.svg?style=flat) ![](https://img.shields.io/pypi/v/solo-python.svg) ![](https://img.shields.io/pypi/wheel/solo-python.svg?style=flat) - -# Python tool and library for SoloKeys - -## Getting Started -We require Python >= 3.6 and corresponding `pip3` command. - -We intend to support Linux, Windows and macOS. Other platforms aren't supported by the [FIDO2 library](https://github.com/Yubico/python-fido2) we rely on. - -To get started, run `pip3 install solo-python`, this installs both the `solo` library and the `solo` interface. - -Possible issues: - -- on Linux, ensure you have suitable udev rules in place: -- on Windows, optionally install a libusb backend: - -For development, we suggest you run `make init` instead, which - -- sets up a virtual environment -- installs development requirements such as `black` -- installs `solo` as symlink using our packaging tool `flit`, including all runtime dependencies listed in [`pyproject.toml`](pyproject.toml) - -One way to ensure the virtual environment is active is to use [direnv](https://direnv.net/). - -## Solo Tool -For help, run `solo --help` after installation. The tool has a hierarchy of commands and subcommands. - -Example: - -```bash -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 -``` - -## Firmware Update - -Upon release of signed firmware updates in [solokeys/solo](https://github.com/solokeys/solo), -to update the firmware on your Solo Secure ("regular" version) to the latest version: - -- update your `solo` tool if necessary via `pip3 install --upgrade solo-python` -- plug in your key, keeping the button pressed until the LED flashes yellow -- run `solo key update --secure` - -To update an (unmodified) Solo Hacker, instead run `solo key update --hacker`. - -For possibly helpful additional information, see . - -## Library Usage - -The previous `solotool.py` has been refactored into a library with associated CLI tool called `solo`. - -It is still work in progress, example usage: - -```python -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 `solo` command line interface - -## Challenge-Response - -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 -too. - -**DANGER** This functionality has not been sufficiently debugged, please generate GitHub issues -if you detect anything. - -There are two steps: - -1. Generate a credential. This can be done with `solo key make-credential`, storing the - (hex-encoded) generated `credential_id` for the next step. -2. Pick a challenge, and generate the associated response. This can be done with - `solo key challenge-response `. - -## License - -Licensed under either of - -- Apache License, Version 2.0 ([LICENSE-APACHE](LICENSE-APACHE) or - http://www.apache.org/licenses/LICENSE-2.0) -- MIT license ([LICENSE-MIT](LICENSE-MIT) or http://opensource.org/licenses/MIT) - -at your option. - -## Contributing - -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. - -Code is to be formatted and linted according to [Black](https://black.readthedocs.io/) and our [Flake8](http://flake8.pycqa.org/en/latest/) [configuration](.flake8) -Run `make check` to test compliance, run `make fix` to apply some automatic fixes. - -We keep a [CHANGELOG](CHANGELOG.md). - -## Releasing - -For maintainers: - -- adjust `solo/VERSION` file as appropriate -- add entry or entries to `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) -- run `make check` and/or `make fix` to ensure code consistency -- run `make build` to double check -- run `make publish` (assumes a `~/.pypirc` file with entry `[pypi]`), or `flit publish` manually -- run `make tag` to tag the release and push it -