| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
This patch release contains a minor change to the Error enum so that
error handling frameworks like anyhow don’t produce redundant error
messages.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch removes the custom implementation of the source method of the
std::error::Error trait for the error::Error type. This means that the
default implementation is used that always returns None. The reason for
this change is that we already print the error message of the source
error in the Display implementation. This leads to a duplicated error
message if both Display and source are checked, for example with
anyhow’s error formatting.
See this thread for more information:
https://lists.sr.ht/~ireas/nitrokey-rs-dev/%3C6e0b4dc8-9059-a113-e98e-b49e52818c75%40posteo.net%3E
|
|
|
|
|
| |
This release changes the Error enum to implement Send, Sync and 'static
for compatibility with error handling crates like anyhow.
|
|
|
|
|
|
|
|
|
|
| |
Since we update rand_os to version 0.2 in commit
6c138eaa850c745b97b7e48a201db0cbaad8e1e0, the random number generation
can no longer fail. Therefore the Error::RandError variant is no longer
needed.
As we did not want to break the public API, we still kept the RandError
variant. This patch removes the RandError variant for good.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, the Error::PoisonError contained the sync::PoisonError that
caused the error. This is problematic as sync::PoisonError does not
implement Send, making it impossible to use the Error enum with the
anyhow crate. At the same time, storing the sync::PoisonError is not
very useful. If a user wants to access the poisoned lock, they can call
the force_take function.
Therefore we remove the sync::PoisonError value from the Error::
PoisonError variant. This also allows us to simplify the
From<sync::PoisonError<…>> and From<sync::TryLockError<…>>
implementations as we no longer need to know the type of the mutex that
caused the error.
For more information, see this thread:
https://lists.sr.ht/~ireas/nitrokey-rs-dev/%3C68ed0f3f-d98f-63bc-04d2-81b6d6cde560%40posteo.net%3E
|
|
|
|
|
|
| |
This release introduces a new struct SerialNumber that represents the
serial number of a Nitrokey device, replacing the strings we used
previously.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In a previous commit, we changed the serial number representation from a
string to an integer. This made it easier to compare serial numbers,
but also introduced new problems:
- Serial numbers should be formatted consistently, for example as
"{:#010x}". It is hard to ensure this for an integer value.
- The format of the serial number may be subject to change. Users
should not rely too much on the u32 representation.
Therefore we introduce a new SerialNumber struct that represents a
serial number. Currently it only stores a u32 value. The following
traits and functions can be used to access its value:
- FromStr for string parsing
- ToString/Display for string formatting
- as_u32 to access the underlying integer value
|
|
|
|
|
|
|
|
|
|
|
|
| |
libnitrokey’s NK_read_config function returns a pointer to an array that
has been allocated using new[]. We would have to delete this pointer
using delete[], but we only have access to free. Therefore this patch
modifies the Device::get_config function to call NK_get_status instead
of NK_read_config.
This also makes the code more safe as we get the data as a struct
instead of an array. It does not add much overhead as NK_read_config
also executes the GET_STATUS command on the Nitrokey device.
|
|\ |
|
| |
| |
| |
| |
| | |
This patch release makes the handling of the randomly generated
temporary passwords more robust.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, we silently cut off temporary passwords that contained a
null byte. With the change to CString, we returned a LibraryError
instead. With this patch, we change to generate_password function to
continue generating passwords until we have a password without a null
byte.
The chance of generating a password with a null byte is ca. 10 % for our
temporary password with 25 characters. Therefore the chance of having
to re-generate the password multiple times is low enough that we don’t
bother with re-generating only the null bytes of the password for the
time being. This should be improved in the future.
|
| |
| |
| |
| |
| |
| |
| | |
This patch changes the generate_password function and the User and Admin
structs to use a CString instead of a Vec<u8> when storing temporary
passwords. This makes sure that the strings that are passed to the C
API are properly null-terminated.
|
| |
| |
| |
| |
| |
| |
| |
| | |
This patch consistently uses u32 integers to store and return the serial
number of a Nitrokey device. This makes it easier to convert and
compare the serial number, as it is a unique representation and as
formatting an integer cannot fail. For more details, see this RFC:
https://lists.sr.ht/~ireas/nitrokey-rs-dev/%3C20200126074816.GA1314%40ireas.org%3E
|
|/
|
|
|
|
| |
To make debugging of unexpected errors easier, this patch adds an
associated String value with a description of the unexpected behavior to
the UnexpectedError variant of the Error enum.
|
|
|
|
|
|
| |
This patch release contains a fix for the serial number formatting in
the list_devices function for Nitrokey Pro devices with firmware
versions older than 0.9.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we assumed that the serial number returned by hidapi
contains the Nitrokey serial number as the least significant bytes. As
disussed here [0], this is not true for Nitrokey Pro devices with
firmware version 0.8 or older: They write the serial number to the most
significant bytes instead.
This patch update the get_hidapi_serial_number function so that
list_devices now returns the correctly formatted and truncated serial
number for all Nitrokey Pro devices. It also makes sure that the serial
number is lowercase to be consistent with libnitrokey’s formatting.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This release adds support for these Nitrokey commands:
For all devices:
- Listing the connected devices and connecting to one of them
(list_devices and Manager::connect_path).
- Querying the status of a Nitrokey device (Device::get_status).
For the Nitrokey Storage:
- Getting the SD card usage (Storage::get_sd_card_usage).
- Getting the status of a background operation
(Storage::get_operation_status).
- Filling the SD card with random data (Storage::fill_sd_card).
With this release, we support all functions provided by libnitrokey –
except those listed as unsupported in the readme file. Therefore we
should be able to release a stable version 1.0.0 soon.
|
|
|
|
|
|
|
|
| |
This patch adds support for libnitrokey’s
NK_fill_SD_card_with_random_data function. It is executed by the
fill_sd_card function of the Storage struct. We also add a new test
case that is set to ignore because it takes between 30 and 60 minutes to
run.
|
|
|
|
|
|
|
| |
This patch adds support for the NK_get_progress_bar_value function: It
adds the OperationStatus enum that stores the return value of this
command and adds the get_operation_status function to the Storage struct
that executes the command.
|
|
|
|
|
|
| |
This patch adds support for the NK_get_SD_usage_data function. It
returns a range of the SD card that has not been accessed during this
power cycle.
|
|
|
|
|
|
|
| |
In the last patch, we added the get_status function to the Device trait.
This patch renames the Storage::get_status function to
get_storage_status to resolve the name clash – though allowed by the
compiler, it is rather confusing for the end user.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support for the GET_STATUS command that returns the
status information common to all Nitrokey devices. It can be accessed
using the Device::get_status function and is stored in a Status struct.
Due to a bug in the Storage firmware [0], the GET_STATUS command returns
wrong firmware versions and serial numbers. Until this is fixed in
libnitrokey [1], we have to manually execute the GET_DEVICE_STATUS
command to fix these values for the Nitrokey Storage.
Also, this leads to a name clash with the existing Storage::get_status
function, which will be renamed in an upcoming patch.
[0] https://github.com/Nitrokey/nitrokey-storage-firmware/issues/96
[1] https://github.com/Nitrokey/libnitrokey/issues/166
|
|
|
|
|
|
| |
This patch adds the connect_path function to the Manager struct that
uses NK_connect_with_path to connect to a Nitrokey device at a given USB
path.
|
|
|
|
|
|
|
| |
This patch adds support for libnitrokey’s NK_list_devices function by
introducing the top-level list_devices function. It returns a vector of
DeviceInfo structs with information about all connected Nitrokey
devices.
|
|
|
|
|
|
|
|
| |
In the next patch, we will add support for the NK_list_devices functions
that returns a list of NK_device_info structs with information about the
connected devices. This patch introduces the DeviceInfo struct that
holds the information returned by NK_list_devices and that can be
created from a NK_device_info struct.
|
|
|
|
|
|
| |
This patch adds the UnsupportedModelError variant to the Error enum:
When parsing the model returned by libnitrokey, we should provide a
meaningful error message for unknown values.
|
|
|
|
|
|
|
| |
After some more research, I decided not to implement some of the methods
provided by libnitrokey. This patch adds them to the list of
unsupported functions in the readme, and removes them from the list of
unimplemented functions in the todo list.
|
|
|
|
|
|
|
|
|
| |
This version contains these major changes:
- Refactoring of the error handling.
- Using mutability to represent changes to the device status.
- Updating the nitrokey-sys/libnitrokey dependency to version 3.5.
- Refactoring the connection management and introducing the Manager
struct.
|
| |
|
|\ |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, we required nitrokey-sys version 3.4, which allows the
upgrade to nitrokey-sys 3.5. Unfortunately, libnitrokey version 3.5,
which is packaged as nitrokey-sys 3.5, introduced breaking changes,
breaking the semantic versioning guarantees and causing compilation
errors if this version is selected.
This patch changes the version specification from 3.4 to ~3.4, i. e. >=
3.4.0, < 3.5.0, to make sure that nitrokey-rs can be compiled without
errors.
|
| |
| |
| |
| |
| |
| | |
This patch splits the rather large device module into the submodules
pro, storage and wrapper. This only changes the internal code structure
and does not affect the public API.
|
| |
| |
| |
| |
| |
| |
| | |
This patch updates the rand_core dependency to version 0.5 and the
rand_os dependency to version 0.2. This causes a change in util.rs:
Instead of constructing an OsRng instance using OsRng::new(), we can
directly instantiate the (now empty) struct.
|
| |
| |
| |
| |
| |
| | |
Previously, we were using a development version of nitrokey-test that
was compatible with nitrokey 0.4. This patch updates nitrokey-test to
version 0.3, which includes the required changes.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The take and take_blocking functions return a PoisonError if the cache
is poisoned, i. e. if a thread panicked while holding the manager. This
is a sensible default behaviour, but for example during testing, one
might want to ignore the poisoned cache. This patch adds the force_take
function that unwraps the PoisonError and returns the cached Manager
even if the cache was poisoned.
|
| |
| |
| |
| |
| |
| |
| |
| | |
To enable applications like nitrokey-test to go back to a manager
instance from a Device instance, we add the into_manager function to the
Device trait. To do that, we have to keep track of the Manager’s
lifetime by adding a lifetime to Device (and then to some other traits
that use Device).
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In the last patches, we ensured that devices can only be obtained using
the Manager struct. But we did not ensure that there is only one device
at a time. This patch adds a mutable reference to the Manager instance
to the Device implementations. The borrow checker makes sure that there
is only one mutable reference at a time.
In this patch, we have to remove the old connect, Pro::connect and
Storage::connect functions as they do no longer compile. (They discard
the MutexGuard which invalidates the reference to the Manager.)
Therefore the tests do no longer compile.
|
| |
| |
| |
| |
| |
| |
| | |
As part of the connection refactoring, this patch moves the connect
methods of the Pro and Storage structs into the Manager struct. To
maintain compatibility with nitrokey-test, the old methods are not
removed but marked as deprecated.
|
| |
| |
| |
| |
| |
| | |
As part of the connection refactoring, this patch moves the
connect_model function to the Manager struct. As the connect_model
function is not used by nitrokey-test, it is removed.
|
| |
| |
| |
| |
| |
| |
| | |
As part of the connection refactoring, we replace the connect function
with the Manager::connect method. To maintain compatibility with
nitrokey-test, the connect function is not removed but marked as
deprecated.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As part of the connection refactoring, we introduce the Manager struct
that deals with connection management. To make sure there can be only
once instance of the manager, we add a global static Mutex that holds
the single Manager instance. We use the struct to ensure that the user
can only connect to one device at a time.
This also changes the Error::PoisonError variant to store the
sync::PoisonError. This allows the user to call into_inner on the
PoisonError to retrieve the MutexGuard and to ignore the error (for
example useful during testing).
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This patch prepares the refactoring of the connection methods by
introducing the Error variants ConcurrentAccessError and PoisonError.
ConcurrentAccessError indicates that the user tried to connect to
obtain a token that is currently locked, and PoisonError indicates that
a lock has been poisoned, i. e. a thread panicked while accessing using
a token.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The new 0.2.1 version of nitrokey-test requires an additional crate,
nitrokey-test-state. This patch updates the nitrokey-test version and
adds the nitrokey-test-state dependency in version 0.1.0. See this
thread [0] for more information.
[0] https://lists.sr.ht/~ireas/nitrokey-rs-dev/%3Ce3e908e5-3f66-7072-9603-8a4de5ac614b%40posteo.net%3E
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As the return type of the NK_get_{major,minor}_firmware_version methods
changed with libnitrokey 3.5, we also have to adapt our
get_firmware_version function in device.rs.
This patch also updates the changelog and the todo list with the changes
caused by the new libnitrokey version.
|
| |
| |
| |
| | |
This reverts commit 0972bbe82623c3d9649b6023d8f50d304aa0cde6.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The current implementation of PasswordSafe stored a normal reference to
the Device. This patch changes the PasswordSafe struct to use a mutable
reference instead. This allows the borrow checker to make sure that
there is only one PasswordSafe instance at a time. While this is
currently not needed, it will become important once we can lock the PWS
on the Nitrokey when dropping the PasswordSafe instance.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In the initial nitrokey-rs implementation, the Admin and the User struct
take the Device by value to make sure that the user cannot initiate a
second authentication while this first is still active (which would
invalidate the temporary password). Now we realized that this is not
necessary – taking a mutable reference has the same effect, but leads to
a much cleaner API.
This patch refactors the Admin and User structs – and all dependent code
– to use a mutable reference instead of a Device value.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, all methods that access a Nitrokey device took a reference
to the device as input. This method changes methods that change the
device state to require a mutable reference instead. In most case,
this is straightforward as the method writes data to the device (for
example write_config or change_user_pin). But there are two edge cases:
- Authenticating with a PIN changes the device state as it may decrease
the PIN retry counter if the authentication fails.
- Generating an HOTP code changes the device state as it increases the
HOTP counter.
|
| |
| |
| |
| |
| |
| | |
To prepare the mutability refactoring, we add a device_mut method to
DeviceWrapper that can be used to obtain a mutable reference to the
wrapped device.
|