| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
| |
Upon creation of a release on Github, the platform publishes the source
code. It is good practice to sign this source code, but it obviously
should be verified first. The procedure is not quite as trivial as it
should be and tedious to do manually.
To aid the process, this change adds a Makefile recipe that contains the
core logic and guides the user through the steps that are necessary.
|
| |
|
|
|
|
|
|
|
|
| |
A while ago we removed all device specific tests from the project as
part of the move to using the nitrokey crate. While adding additional
tests is a work in progress, the intention is to have them run solely by
issuing 'cargo test'.
In any case, this change removes the 'test' target from the Makefile as
it is no longer needed, because all tests can run concurrently just
fine.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change adds a new target to the Makefile that can be used for
generating a PDF version of the man page. It also checks in the
generated file and links to it from the README.
We have also experimented with creation of an HTML version, but at least
the groff generated file is not very visually pleasing and also cannot
be linked to directly from Github. Github wants to prevent hosting of
web pages directly like this in repositories and instead promote their
Github Pages solution for that purpose. To that end they deliver content
with a Content-Type representing plain text which causes HTML to not be
rendered. PDF content, however, is rendered in-line and looks reasonable
at that.
|
|
|
By just sending a command to the nitrokey alone we have no idea of what
actually happened on the side of the nitrokey. A command could simply be
invalid in the current context or the stick could be busy or in a
failure state.
In order to determine the success of an operation, this change adds the
logic to retrieve the response from the nitrokey as well.
|
