search

Nitrokey / nitrokey-start-firmware

A mirror of Gnuk's 1.0.x and 1.2.x branches.
56 stars 15 forks source link

Use gnuk as submodule for easier upgrade #69

Open dvzrv opened 2 years ago

dvzrv commented 2 years ago

Hi! After #67 is stalling for a bit I have been looking at potentially helping to upgrade this repository to use gnuk > 1.2.15 (e.g. current 1.2.19).

I came to the conclusion that the use of the gnuk upstream is unfortunately very intransparent and an upgrade path is not documented. Furthermore, modified files (and firmware blobs(?!)) from nitrokey's upstream are entangled with the gnuk upstream code in this repository.

For outside contributors this is very hard to grasp and to propose or implement changes (e.g. some changes should actually be applied to upstream gnuk, not to this repository!). In the current setup it is also very hard to understand what are the changes applied by nitrokey and which are relevant for the firmware.

To improve the current situation I propose using gnuk as a submodule of this repository. This way gnuk can be pinned down to a specific commit. Changes to gnuk internals are directly upstreamed and if that is not possible, scripts can be duplicated and modified in this repository as to not use the gnuk internals. Additionally, I believe the resulting firmware files can be built in a reproducible way and these build artifacts should therefore not exist in the source code repository (git is really bad at tracking binary data) but be moved to a long-lived storage and/ or attached to releases of this repository.

So far my suggestions. I don't know if I am making some really naive assumptions about your workflows here (sorry in advance :laughing: ), but those are the conclusions I came to when looking at the code base and trying to understand where even to start to help update gnuk.

szszszsz commented 2 years ago

Hi! Thank you for your interest on that! Yes, this got a bit entangled. Major points:

  1. The hardware board Nitrokey Start uses is added to the upstream, so in any case you can always build GNUK and flash it to the Nitrokey Start. I have not tested the update compatibility between these two, but I would expect it working, except for maybe LEDs;
  2. The "multiple identities" feature was not upstreamed, as this was highly experimental: we have taken all the left space to use it for the user data, leaving nothing for the new firmware. It works quite good in practice, and hopefully we can get push it out now. Ideally all our changes would be upstreamed;
  3. Yes, prebuilt binaries are stored in the repository due to the historical reasons, and perhaps will be moved to releases at some point;
  4. So far we have merged GNUK updates by release tags, and this worked quite well. You should be able to see differences using plain git diff command between the respective release tags from the both repositories, but I understand this might not be satisfying solution.

In general the idea is to follow GNUK development closely, as long as it's feature list is not changing much. Recent releases remove the RSA support, on which our customers still rely, hence updating directly to the latest is not that easy without wide confusion. I will be happy to respond in case you have more questions/suggestions. Perhaps we could make some kind of "contributors introduction" document from our discussions.