A command line tool for interacting with Nitrokey devices (GitHub mirror) https://git.ireas.org/mirrors/nitrocli/atom?h=v0.1.1 2017-08-17T13:20:36Z 2017-08-17T13:20:36Z Daniel Mueller deso@posteo.net 2017-08-17T13:20:36Z urn:sha1:ea4ea0e5fced2780c569b2e420e56f47f62adca8 2017-08-17T12:46:06Z Daniel Mueller deso@posteo.net 2017-08-17T12:46:06Z urn:sha1:57c002a84bf14f9ca964c541714c1874dfc2ca69 In the past the Nitrokey Storage device reported wrong CRC values for certain commands, e.g., the closing of an encrypted volume. This problem was tracked by issue 32: Nitrokey/nitrokey-storage-firmware#32 Firmware version 0.47 includes a fix for the problem. With this change we remove the workaround for the incorrect CRC from nitrocli. By doing so, we require the Nitrokey Storage to be running firmware 0.47 or higher to be properly usable. 2017-08-17T11:39:56Z Daniel Mueller deso@posteo.net 2017-08-17T11:39:56Z urn:sha1:8d4a7d0ec9c3a82c7546482875be80827e2be57a The nitrokey-storage-firmware package defines an array of four byte values to hold information about the firmware version. libnitrokey uses a similar definition but overlays it with some more semantically meaningful information by putting it into a union: union { uint8_t VersionInfo_au8[4]; struct { uint8_t __unused; uint8_t major; uint8_t __unused2; uint8_t minor; } versionInfo; }; In order to derive the firmware version representation for nitrocli we used the same major/minor version definition as libnitrokey. This definition, however, is wrong or at least not in line with how the firmware is versioned officially. This change reworks the way we interpret the version information reported by the Nitrokey Storage device. Like the firmware, we treat the first byte as the major version and the second one as the minor version. The remaining two bytes seem to represent the build number and an internal version according to usage of those fields in nitrokey-storage-firmware but we ignore both to keep the reported string similar to that of the nitrokey-app. 2017-05-29T22:48:40Z Daniel Mueller deso@posteo.net 2017-05-29T22:48:40Z urn:sha1:ac29709a644682c61a5a28d2a23f8887174fcc31 Although the version information for all the local dependencies can be inferred from various locations, cargo requires an explicit mentioning of the version of each dependency for the 'package' command to be successful. This change adds explicit versions. 2017-05-29T21:07:12Z Daniel Mueller deso@posteo.net 2017-05-29T21:07:12Z urn:sha1:684c4574c09a6f2cc5a208e4505e9306602b4abc The 'libc' create got a couple of updates. This change imports the new code and bumps the version to use. Import subrepo libc/:libc at 7db3fd570dfb41a38fb17116e93679307178103a 2017-05-29T20:58:05Z Daniel Mueller deso@posteo.net 2017-05-29T20:58:05Z urn:sha1:436915453f7474117234aa0cedab6f97b3b3575f The 'gcc' create got a couple of updates. This change imports the new code and bumps the version to use. Import subrepo gcc/:gcc at 6b41873be3172415efcadbff1187a3ff42428943 2017-04-10T04:24:38Z Daniel Mueller deso@posteo.net 2017-04-10T04:24:38Z urn:sha1:5744889d0d3a9c033913bdce499064a4760a1249 When closing the encrypted volume we could potentially cause the volume to be in an inconsistent state if writes to it were cached by the operating system. To mitigate this case this patch causes an invocation to the sync(2) system call to flush outstanding writes to disk. 2017-04-10T03:53:54Z Daniel Mueller deso@posteo.net 2017-04-10T03:53:54Z urn:sha1:3ce72e0ce1a0442786bc2600a7f276ae1994d90e Until now we treated any response but "ok" and "idle" to the encrypted volume opening command as an error and reported it. However, the opening process is a potentially long running and it is very likely that the nitrokey reports a couple of "busy" messages. This change implements the logic to wait until the nitrokey either reports an error or a successful open. 2017-04-10T03:32:31Z Daniel Mueller deso@posteo.net 2017-04-10T03:32:31Z urn:sha1:1e4a359f42e081851b98a12511ffe24968bfc6da We currently unconditionally use gpg-agent to enter the PIN to use when opening the encrypted volume. The agent has the advantage of caching the password for us so that subsequent invocations against the same cache entry can be served without user interaction. For various reasons, however, it can be desirable to have the ability to remove this entry from the cache. This change introduces a new command 'clear' that achieves precisely this task. 2017-04-10T03:21:39Z Daniel Mueller deso@posteo.net 2017-04-10T03:21:39Z urn:sha1:a23c692dc38fe95b1a584663166fd3c9ed251326 When a wrong password is entered when attempting to open the encrypted volume the nitrokey will report that in the form of an error. In such a case we should retry the operation after asking the user for the corrected password. This change implements this logic. Note that because we use gpg-agent for the PIN inquiry and because it caches passwords by default we must make sure to clear the cache before retrying.