| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
Now that all vendored dependencies have been removed, this change moves
the program's source code from the nitrocli/ directory into the root of
the repository.
|
|
|
|
|
|
|
|
|
| |
This change updates the minimum required version of Rust to 1.35.0. The
motivation for doing so is at least two fold. First, next we want to
bump the nitrokey crate to version 0.4.0 and it requires Rust 1.34.0 as
a minimum. Second, and perhaps more importantly, though, in 1.34.0 a
clippy lint regressed, breaking our pipeline. That is the reason why we
are going to 1.35.0 instead.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change updates the version of the nitrokey crate that we use to
0.4.0-alpha.3. This version is the supposedly last pre-release before
0.4.0, with no further major anticipated changes.
In order to integrate with this new version we have to adjust the way we
connect to a Nitrokey device by funneling those connection requests
through a global manager object. The rationale behind that step being
that the underlying libnitrokey actually cannot handle access of
multiple devices at the same time, and so the manager object is used to
prevent accidental wrong concurrent usage.
Because a device object now effectively keeps a reference to the
manager, we need to provide an additional lifetime to that and derived
objects.
Lastly, the use of a manager is also the reason why the tests had to be
adjusted to no longer accept device objects in their signatures, but
only the respective model for which to invoke the test. That is required
because, as elaborated earlier on, having a device object implies having
taken a reference to a manager (in that case owned by nitrokey-test),
and that reference clashes with the nitrocli code itself attempting to
take the manager. We side step this problem by merely accepting a Model
object, which can be passed around independently of the manager itself,
meaning that nitrokey-test does not need to hold such a reference while
the test is run.
Import subrepo nitrokey/:nitrokey at f150d59410eefdec2ae69b2422906a3d1d88aa07
Import subrepo nitrokey-sys/:nitrokey-sys at 8695e2c762807e033a86c8d03974b686d20cdd72
Import subrepo lazy-static/:lazy-static at b4b2b16aaa79dd7548e288455a0dbe4065bf4e1a
|
|
|
|
|
|
|
|
|
|
| |
This change updates the dependency to nitrokey to version 0.4.0-alpha.2.
In addition to minor interface changes for the get_*_firmware_version
and get_*_retry_count functions, several functions that change the
device state now require a mutable handle to the nitrokey. Hence, this
patch a number of function signatures to accept mutable device objects.
Import subrepo nitrokey/:nitrokey at 34efcfadf1436102e42144f710edabaa2c4b55cd
|
|
|
|
|
|
| |
Since version 0.4.0, nitrokey provides the default admin and user PIN as
constants. This patch removes the constants from nitrocli and uses
nitrokey's constant instead.
|
|
|
|
|
|
|
|
| |
With nitrokey-test up to version 0.2.0 we required a work around to make
device tests work across different modules.
With this patch we bump the consumed version of the crate to 0.2.1, as
part which the underlying problem got fixed. Hence, with this change we
remove this hack as it is no longer needed.
|
|
|
|
|
|
|
|
|
|
|
| |
This is patch marks the first step in the process of updating the
nitrokey dependency to version 0.4. In particular, it integrates with
the first alpha version.
The main change on the nitrocli side accompanying the version bump is
that the nitrokey::CommandError got replaced by a more general
nitrokey::Error which includes the former variant.
Import subrepo nitrokey/:nitrokey at d433189caefe6bd6c88da7fbb1d6e9304353eb83
|
|
|
|
|
|
|
|
|
|
| |
The library ultimately taking care of communicating with the Nitrokey
device, libnitrokey, unconditionally expects hexadecimal strings
supplied as part of the configuration of an OTP slot to have an even
number of bytes.
Users should not be aware of this detail and so with this change we take
care of padding the supplied string with a leading zero to make such a
configuration go through without an error.
|
|
|
|
|
|
|
|
|
|
|
| |
Subcommands of the encrypted and unencrypted commands were found to have
a wrong help text displayed. The reason for that behavior was that the
subargs were are constructing as part of the argument parsing process
were missing the command being requested and instead containing only the
subcommand.
This change fixes this deficiency. It also adds a test ensuring that the
"Usage" string displayed in the help text of each command and subcommand
contains the proper arguments.
|
|
|
|
|
|
|
| |
This change adds support for changing the read-write mode of the
unencrypted volume. To do so, we introduce a new top-level command,
unencrypted, with a new subcommand, set, that accepts the new mode of
the volume.
|
|
|
|
|
|
|
|
| |
This change is the last step in the process of restructuring the storage
command. In particular, now that functionality pertaining hidden volumes
has been moved out into a dedicated top-level command, it renames said
command to encrypted, because dealing with the encrypted volume is the
only functionality it provides.
|
|
|
|
|
|
| |
This patch marks the next step in the process of restructuring the
storage command. Specifically, it promotes the storage hidden subcommand
to a top-level command, hidden.
|
|
|
|
|
|
|
|
| |
In an attempt to rework the structure of the storage command to better
accommodate future requirements for allowing to change the read-write
state of the unencrypted volume (as well as potentially the encrypted
one), this change removes the storage status subcommand and merges its
output into the storage command.
|
|
|
|
|
|
|
|
|
|
| |
When a PIN is changed using the pin set command, the last action is to
confirm the operation with the previously used PIN. This step will cause
this PIN, which is now stale and no longer valid, to be cached, which in
turn can cause follow up command using the same PIN type to use this
wrong cached entry for authentication.
To fix this problem, this change explicitly clear the PIN entry from the
cache after the PIN has been changed.
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far we have cached secrets in gpg-agent(1) whenever that made sense
to do (i.e., for the two PINs in most contexts but not for passwords).
While there is reason to believe that such caching is desired by the
majority of users, not everybody has a use for it.
To give users an opportunity to opt out of such caching, this change
introduces a new environment variable, NITROCLI_NO_CACHE, that, when
present in the environment, instructs the program to bypass the cache
for all operations that require a secret and to instead inquire such
secrets each time they are needed.
|
|
|
|
|
| |
This change adds a test case for the -V/--version option to the suite of
tests.
|
|
|
|
|
|
|
|
| |
The factory reset only clears the slot status. The slot content is
overwritten with random data. Therefore accessing a PWS slot after a
factory reset returns garbage data. We fixed this by always querying
the status before accessing the PWS. This patch adds a corresponding
test case.
|
| |
|
|
|
|
|
|
|
|
|
| |
This change adds tests for the lock command. For the Nitrokey Pro we
cannot test too much because the only side-effect is that the password
safe is closed and it will be opened automatically again by virtue of
our non-interactive testing methodology.
For Storage devices we verify that the encrypted volume is closed, which
is a documented side-effect.
|
|
|
|
|
|
|
| |
This change adds a test for the creation, opening, and closing of a
hidden subvolume. In order to support that in a non-interactive fashion,
we introduce and honor the NITROCLI_PASSWORD environment variable, that
prevents an interactive password query.
|
|
|
|
|
|
|
|
| |
This change adds two tests for the storage command. The first one
verifies that a proper error message is emitted if a storage command is
attempted on a Pro device. The second one checks the output of the
status subcommand and expected changes to it when opening or closing the
encrypted volume.
|
|
|
|
|
| |
This change adds a set of tests for the pws command. Covered are all
subcommands with the most commonly used parameter combinations.
|
|
|
|
|
|
| |
This change adds a set of tests for the config get and set commands. We
cover chosen valid parameter combinations and verify that they work as
expected as well as an invalid one.
|
|
|
|
|
|
|
| |
This change adds a set of tests for the otp command. We cover some
variants of the status, set, get, and clear. Testing all the possible
combinations is out of scope and so only a more or less arbitrary subset
of arguments was chosen.
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far we have taken all nitrokey::CommandError objects and put them in
formatted form into the Error::Error variant. What we really should do,
though, is to preserve the original error, with the additional context
provided by the caller, and report that up the stack directly. Doing so
has at least the benefit that we are able to check for expected errors
without hard coding the textual representation as maintained by the
nitrokey create.
This change refactors the code accordingly and adds two tests for such
expected error codes.
|
|
|
|
|
|
|
| |
Now that we have the infrastructure for non-interactive PIN supply in
place, we can add tests for commands that require the entry of a PIN.
To that end, this change adds tests for the pin set as well as pin
unblock commands.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to run tests fully non-interactively we need to avoid the need
for using the GPG agent's PIN entry and caching mechanism. To accomplish
that, we first need an alternate way to supply the PINs to use to the
program.
This change offers such a way by extending the execution context with
two fields representing the PINs that are populated by corresponding
environment variables, NITROCLI_ADMIN_PIN & NITROCLI_USER_PIN, if set.
While only two PINs are required right now, because the program allows
for the changing of each of the PINs, we also add two fields
representing new PINs. These latter two fields are populated by the
NITROCLI_NEW_ADMIN_PIN and NITROCLI_NEW_USER_PIN environment variables.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the future we will need to perform a sequence of invocations of the
program for testing purposes, with each having a slightly different
execution context. Such a scheme does not map very well to the existing
design where we essentially just have a function invocation to run the
program. We would either have functions that produce a different
execution context or pass in the data to modify.
Neither of these approaches is appealing and so this change reworks the
code slightly. With it, we now can create a Nitrocli object, which
contains the data that diverges from the default execution context. This
data will eventually be modifiable by callers.
|
|
|
|
|
|
|
|
| |
For testing purposes it is beneficial to be able to check for expected
errors with the least amount of boiler plate code possible. This change
attempts to be a first step into this direction. It introduces a
test-only trait that can be used to directly unwrap a specific error
from a Result<T, crate::error::Error>.
|
|
This change introduces the first set of integration-style test for the
application. Those tests may or may not connect to an actual Nitrokey
device (depending on what they test). We use the nitrokey-test crate's
test attribute macro to automatically dispatch tests to connected
devices or skip them if a required device is not present. It also
provides the means for automatically serializing tests.
|