| Commit message (Collapse) | Author | Age |
... | |
|
|
|
| |
This change updates the regex-syntax crate to version 0.6.5.
|
|
|
|
| |
This change updates the memchr crate to version 2.1.3.
|
|
|
|
| |
This change updates the proc-macro2 crate to version 0.4.26.
|
|
|
|
| |
This change updates the quote crate to version 0.6.11.
|
|
|
|
| |
This change updates the syn crate to version 0.15.26.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Nitrokey devices do not check whether a PWS slot is programmed
before accessing it (upstream issues [0] [1]). Until this is fixed in
the firmware, we have to manually check the slot status in pws get. This
could have been done in libnitrokey or the nitrokey crate, yet this
would lead to unnecessary commands if we check multiple fields of a slot
at the same time.
[0] https://github.com/Nitrokey/nitrokey-pro-firmware/issues/56
[1] https://github.com/Nitrokey/nitrokey-storage-firmware/issues/81
|
| |
|
|
|
|
|
|
| |
After performing the factory reset, we also build the AES key so that
the device is fully usable. Due to timing issue, we have to add a delay
between the factory reset and building the AES key.
|
|
|
|
|
|
|
|
| |
The -V/--version option prints the nitrocli version to stdout and exits.
In the future, it should also print the used libnitrokey version, but as
the required function is only available with nitrokey 0.3.2 and as the
current interface does not reflect the latest change in version naming,
I skipped that in this patch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change bumps the version of the crate to 0.2.3. The following
notable changes have been made since 0.2.2:
- Added the storage hidden subcommand for working with hidden volumes
- Store cached PINs on a per-device basis to better support multi-device
scenarios
- Further decreased binary size by using system allocator
- Bumped nitrokey dependency to 0.3.4
- Bumped rand dependency to 0.6.4
- Removed rustc_version, semver, and semver-parser dependencies
- Bumped nitrokey-sys dependency to 3.4.3
- Bumped libc dependency to 0.2.47
|
|
|
|
|
|
|
| |
The duplicate_associated_type_bindings lint seems to have been removed
with the Rust 1.32 release.
This change removes the lint from the program to prevent the newly
introduced warning from being emitted.
|
|
|
|
|
|
| |
If nitrokey-app is running, the device it connected to cannot be
detected by other applications. This patch adds this issue to the list
of known problems in the README.
|
|
|
|
|
|
|
| |
The CI scripts and the rustfmt configuration are only needed when
developing. There is no point in distributing them in the package
published on crates.io, so we exclude them from packaging using the
exclude setting in Cargo.toml.
|
|
|
|
|
|
| |
This change updates the libc crate to version 0.2.47.
Import subrepo libc/:libc at ce1dfcbf81bd74662b5cd02a9214818a0bfbbffa
|
|
|
|
|
|
| |
This change updates the nitrokey crate to version 0.3.4.
Import subrepo nitrokey/:nitrokey at 41cdc1f7091a3c442241dbb2379c50dbcc7e9c5f
|
|
|
|
|
|
|
|
|
| |
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 updates the README and the man page with documentation about
hidden volumes in general and the storage hidden subcommand in
particular.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
With this change we implement the storage hidden subcommand. We support
creation, opening, and closing of hidden volumes.
Note that the opening of a hidden volume automatically closes any opened
encrypted volumes and vice versa. To that end, we force file system
level caches to disk even from the storage open and storage hidden open
commands.
|
|
|
|
|
|
|
|
|
| |
This change introduces a new subcommand to the storage command called
'hidden'. This subcommand can be used to interact with hidden volumes.
Right now we support three operations pertaining hidden volumes: create,
open, and close.
This patch merely provides the infrastructure for parsing the commands
and all their arguments, it does not yet implement them fully.
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the required interface for secrets well defined, this change
introduces a second secret type in addition to PINs: passwords. Similar
to a PIN, a password can contain pretty arbitrary characters but
passwords can be retried repeatedly, whereas PINs cause a lockout after
a certain number of failed attempts.
Our first use case for passwords will be for hidden volumes. For those,
we do not want to gpg-agent to cache entries and so a password entry
indicates that it is not to be cached through the previously introduced
mechanism for optional caching.
|
|
|
|
|
|
|
|
| |
Another commonality between a password and a PIN is that they typically
both have a minimum length.
To accommodate for this requirement, this change introduces another
method to the SecretEntry trait that represents the secret's minimum
character length.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, when we enter a secret (i.e., a PIN) through the pinentry
module, this PIN will automatically be cached and not asked from the
user again on subsequent inquiries. However, caching may not always be
desired. For the upcoming support of passwords used in conjunction with
hidden volumes, we do not want any caching because different passwords
can be entered for different volumes and the user's intention is not
clear until a password has actually been entered.
To accommodate this use case, this change modifies the signature of the
SecretEntry trait's cache_id method to return an optional cache ID. If
none is returned, caching of the entered secret is disabled.
|
|
|
|
|
|
|
|
|
| |
We do not know what kind of data future implementers of the SecretEntry
trait may want to return. For all we know these could just be static
strings, in which case the forced conversion into a String by virtue of
the return type is wasteful.
To be more flexible in the future while gaining some consistency, this
change makes all those trait's methods return a Cow object instead.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that we have introduced the notion of a secret abstracting over
whether something is a PIN or a password in terms of terminology, we
need to define what makes a secret in code. From the pinentry module's
perspective, the commonality between the two is that they both can be
entered through a dialog containing a prompt and a description, and they
can be cached.
This change introduces a trait, SecretEntry, that defines methods
representing those properties. Right now only the existing PinEntry
struct implements this trait.
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the past we have worked solely with PINs. PINs in our (or rather, the
Nitrokey's) sense are not necessarily numbers but they can be reasonably
short in length, because they can only be retried a limited number of
times.
In the future, however, we will introduce the notion of a password,
which does not carry such a restriction.
The commonality between the two is that they are secrets and so with
this change we refer to secrets -- rather than PINs -- in places where
both passwords and PINs can conceptually be used.
|
|
|
|
|
|
| |
Various functions in the pinentry module contain an arguably redundant
'_pin' suffix in their name. Examples include inquire_pin and clear_pin.
This change removes this part from their names.
|
|
|
|
|
|
|
|
|
| |
The functionality we have in place for choosing a PIN can arguably be
moved into the pinentry module: it can be considered logic directly
related to working with PINs or secrets and that has no dependencies to
unrelated modules of the program.
This patch moves the choose_pin and check_pin functions into the
pinentry module.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
The previous change to properly format the help text for optional
arguments left one thing out: parameters that are based on an Option as
opposed to an enum. The problem with those is that we cannot simply ask
the value (i.e., the Option) for all the variants of the inner type.
Instead, we have to reference the actual type of the inner enum in order
to retrieve all its possible variants.
|
|
|
|
|
|
|
| |
This change continues the effort of auto-generating more of the help
text content by extending the logic to optional arguments. We make use
of the fmt_enum macro to format the description of the argument with the
available variants (as well as the default, if any) interpolated.
|
|
|
|
|
|
|
|
|
| |
With the ability to fully generate the command enums we use for working
with the argparse crate, we can now take things one step further and
populate the contents of the help string we print for the user that
lists the available commands.
Doing so we also fix a bug where we forgot to mention the "storage
status" command in the help text.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Not too long ago we added a macro to auto generate the command enums and
the required trait implementations from a concise declarative
representation. This change extends this mechanism to the execute method
implementation that some of those enums provide.
When a tuple is specified as the "destination", e.g., here:
> Enum! {ConfigCommand, [
> Get => ("get", config_get),
> Set => ("set", config_set)
> ]}
the second component of this tuple will be interpreted as the function
to invoke when this variant used in the newly generated execute method.
|
|
|
|
|
|
|
|
|
|
|
| |
We have been loosely tracking the resulting size of the stripped release
binary as that is arguably the most relevant metric to optimize for. To
have a better idea of the influence of various changes and their effect
on the binary size, this change adds a script that automates the process
of gathering this metric. E.g.,
$ var/binary-size.py HEAD~3 HEAD --unit kib
> 994
> 970
|
|
|
|
|
|
|
|
|
|
| |
With the update to rand 0.6.4 we no longer require the dependencies to
rustc_version, semver, and semver-parser. Hence, this change removes
them.
Delete subrepo rustc_version/:rustc_version
Delete subrepo semver/:semver
Delete subrepo semver-parser/:semver-parser
|
|
|
|
|
|
|
|
|
|
|
| |
This change updates the nitrokey crate to version 0.3.3. Along with that
change we update rand to 0.6.4 because rand 0.6.1 does not yet contain a
publicly accessible rand_os. Note that we no longer require all
crates in rand's workspace, but only rand_os and rand_core, which is a
significant reduction in the number of lines of code compiled.
Import subrepo nitrokey/:nitrokey at 7cf747d56ddc0b7eeedc3caf36dcc909907a171c
Import subrepo rand/:rand at 4336232dda03323634b10ec72ddf27914aebc3a2
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
This change updates the libc crate to version 0.2.46.
Import subrepo libc/:libc at a9e3cc6c1b529eaffef5b82934d0c47203edebe5
|
|
|
|
|
|
|
|
|
| |
Cargo uses SPDX 2.1 license identifiers. The identifier GPL-3.0+ is
deprecated as of version 2.0rc2 [0]. The current license identifier for GNU
General Public License v3.0 or later is GPL-3.0-or-later [1].
[0] https://spdx.org/licenses/GPL-3.0+.html
[1] https://spdx.org/licenses/GPL-3.0-or-later.html
|
|
|
|
|
| |
This change adds a new section briefly elaborating on the problem of
using the program on macOS and details a possible solution.
|
|
|
|
|
|
| |
This change updates the nitrokey crate to version 0.3.2.
Import subrepo nitrokey/:nitrokey at 6ea73f29daa5db0215663a0a38334b764863671d
|
|
|
|
|
|
| |
This change updates the nitrokey-sys crate to version 3.4.3.
Import subrepo nitrokey-sys/:nitrokey-sys at fe86df47853718983e1f45d6a4289a1d93ace45c
|
|
|
|
|
|
|
|
|
|
|
| |
The nitrokey-sys crate poses a challenge in that upgrading it causes
build errors caused by linking against the system's nitrokey library
from multiple crates, which is not allowed. The exact cause of the
problem is unclear but the suspicion is that a bug in Cargo's replacing
logic is the cause of the issue.
To work around this problem, this change switches to using the [patch]
section for replacing crates with local copies instead of the [replace]
one.
|
|
|
|
|
|
|
|
|
|
| |
With the first usage of the nitrokey crate we have used the dependency's
path attribute to perform the replacement with a local version of the
source code, while most other dependencies are replaced using the
[replace] section.
Because the [replace] section is more flexible (it allows for
replacement of transitive dependencies), this change unifies all
dependencies to use it.
|
|
|
|
|
|
|
|
|
|
|
| |
We exit the program using the process::exit function. This function just
exits the program directly, without any cleanup. That can be a problem
because IO buffers may not be flushed either. For a (typically) line
buffered entity like stdout that may result in data not terminated by a
newline symbol being not displayed properly.
This change explicitly flushes stdout before exiting the process to
alleviate this problem. Note that stderr output is unaffected, because
stderr is not buffered by design.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The application supports multiple devices both plugged in at the same
time as well as when used after the other. However, the GPG cache ID we
use for storing and retrieving the respective PIN is effectively a
constant. This constraint can cause problems when devices have different
PINs, as the PIN of a previously plugged in device may be reused for an
operation on a different one.
To resolve this problem this change adds the respective device's model
and serial number to the cache ID. As each serial number is supposed to
be different, this will ensure that the correct PIN is used for each
device. With this change we also show the model and serial number of the
currently used device in the pinentry dialog.
Note that because we do not store the serial numbers of all previously
plugged in devices, the pin clear command will only clear the PIN for
the currently plugged in device. If a user wants to make sure that a
cached PIN is cleared, the pin clear command should be invoked before
unplugging the device.
|