Going 1.0

[d-e-s-o]

I am cautiously confident that the code is moving towards a state where we can say it won't change in completely unexpected ways anymore (our experience with argparse is overall positive so we are unlikely to change that; nitrokey-rs is obviously there to stay; we have our testing story flushed out). As such, perhaps it is time to roughly sketch out what we see as requirements for a 1.0 release candidate.

The two big items I see are:

• tests for all the existing commands
• extension support needs to be ironed out and implemented fully

I don't think we need to have support for all the features that nitrokey-app or libnitrokey provides. However, I would like to see the following:

• hidden volume support
• everything that is necessary for the initial setup of a Nitrokey device as it is shipped from Berlin
  • I count into that the ability to upgrade the firmware of storage devices (I don't think we need to support the entire workflow, but putting the device into upgrade mode should likely be included)
  • make the unencrypted volume writable
  • (I am probably missing something)

We should also have at least considered the remaining features a Nitrokey supports, and have confidence that they will somehow fit into the existing command scheme or can be implemented as extensions in a sensible way.

It would be nice to only depend on 1.0 crates ourselves, but that is obviously out of our control to a large extent. However, nitrokey-rs is still a bit in flux and I would definitely wait until @robinkrahl has not planned any more incompatible changes.

If anybody has any thoughts/additions, I'd be happy to hear them.

[d-e-s-o]

There is one more thing I have been thinking about on and off, and that is error reporting. We do a reasonable job in general, but what may be considered missing is more context. For example, when looking up an extension we may get an io::Error and all it says is "file not found". Without context (and there is little aside from the command being invoked [which may be enough in the example but not in general]), this error may or may not be helpful.

I believe that crates such as error-chain (and I believe fault at some point, but I can't find off hand), provide some more useful context in a generic way. We may want to consider evaluating those to up our game.

[d-e-s-o]

There is also custom_error that I just came across. But ultimately we may just stick to what we have. If we ensure a little more context for all errors that don't already have it (most nitrokey reported errors do by virtue of the get_error function) we should be good. And that can probably be enforced statically at compile time.