Sign release artifacts

[marmarek]

Currently release assets (like https://github.com/Nitrokey/pynitrokey/releases/download/v0.4.44/nitropy-v0.4.44-x64-linux-binary.tar.gz) are not signed. It seems the only way currently to get authenticated release is to clone git repository, verify signed tag and go from there, but it isn't very convenient for end users.
So, can you please sign releases, for example with a detached signature?
That's still not as convenient as proper distribution package (#494 for example), but still an improvement.

[UndeadDevel]

It's been almost a year since it was promised to add signatures for the release artifacts, so I'd like to bump this; or has there been added a different way to reliably verify the integrity of the nitropy binary?

[robin-nitrokey]

I would recommend to install pynitrokey from source or build the binary yourself if you want to have a verifiable build. In my opinion, this is even better than having signed binaries in the release artifacts.

The release binaries are built in the GitHub CI, so realistically they would need to be signed by the CI server. This means you could only verify the release against a GitHub CI key and would have to trust multiple parties: a) GitHub to handle the secret key responsibly, b) GitHub Actions to build the binary correctly, c) PyPI to provide the correct dependencies (and their maintainers), and of course d) us to trigger the release correctly.

If you build from source, you can directly verify our signature on the tag or commit. All releases are signed with one of these keys that are all stored on hardware devices. (This is for example used for the Arch package.) So by building from source, you can ignore parties a) and b).

[UndeadDevel]

It's not just me and people like me who could commit the extra effort of building the package themselves. Remember that QubesOS has expanded its YubiKey module to also work with NK3 for access control; this is even reflected in the Qubes documentation. So the affected users are all QubesOS users, who also use an NK3 for access control; that will inevitably include users who don't have the skills or time to build the binary themselves.

The QubesOS team explicitly warns against using PyPI (so e.g. pipx install ...) for anything important, and for good reason (e.g. the vast majority of malicious code contributions is hosted on PyPI or NPM and their integrity verification is less than optimal to say the least, e.g. in the case of PyPI it is completely absent unless the publisher uploads a detached signature, which the user then has to manually download and verify, but Nitrokey doesn't upload such a signature for its pynitrokey releases there; the Nitrokey team also doesn't use the Github Actions supported Trusted Publishing on PyPi, either, but the gravest concern is, of course, lacking integrity verification when using pipx install...).

The fix for this, apart from packaging with Debian, Fedora, etc., which is a non-trivial effort on Nitrokey's part, is actually very simple: upload a detached signature to the GitHub release pages, which takes just a few seconds, if automated. Given that new pynitrokey versions are released about once per month (over the past year) it seems like a very low cost. That way users could simply download the binary and signature from the GitHub releases page, verify it locally, and push the binary into their PATH, which is certainly a whole lot simpler than figuring out how to build or use the source code directly while also being a whole lot more secure than pipx install pynitrokey (which is roughly the equivalent, security-wise, of downloading the binary from the GitHub releases page without verifying it).