sysupdate: Support alternative signature methods

[DemiMarie]

Component

No response

Is your feature request related to a problem? Please describe

systemd-sysupdate currently uses GnuPG for signature verification of downloaded files. This is annoying because GnuPG has extra attack surface that isn’t needed here. Metadata can and should be provided included in the signed hashes file.

Describe the solution you'd like

Support for ed25519 signatures.

Describe alternatives you've considered

None

The systemd version you checked that didn't have the feature you are asking for

No response

[poettering]

yeah, sounds great. has been on the todo list for a while. either something with pkcs7 or maybe something compatible with openbsd signify would be great.

Patches welcome!

[DemiMarie]

I don’t think I will be able to get around to this anytime soon, unfortunately.

PKCS#7 is roughly as bad as OpenPGP in terms of parsing requirements. It happens that systemd-sysupdate needs to parse untrusted ASN.1 for HTTPS downloads to work, but ideally the download would happen in a sandbox, whereas the signature check must be outside of that sandbox. Also, I would like to see systemd-sysupdate eventually use rustls’s OpenSSL compatibility layer.

OpenSSH signatures (as generated by ssh-keygen -Y) would be another option. They do require nontrivial parsing, but the format is much simpler than ASN.1 or OpenPGP, and OpenSSH is known for its high code quality.

Another consideration is that images should be verified before being decompressed. Since images can be very large, this requires being able to verify them incrementally. signify(1) supports this by having a list of hashes (hex encoded, newline separated, and signed with ed25519) as a comment in the gzip header. If one can assume that a 1MiB chunk can fit in memory and that binary SHA512/SHA-3/Blake2b hashes are used, this means that a 64GiB compressed image takes 2¹⁶ chunks, or 2MiB of hashes. More complex schemes are possible, but a system needing 64GiB OS images to be downloaded yet not having 2MiB of free RAM does not seem realistic to me ¹, and less code means less attack surface.

Footnotes

1. There may be other applications where tebibyte-sized images are worth supporting. I just don’t think this is one of those applications. ↩