[Rpm-maint] [rpm-software-management/rpm] RPMv6 proposal: Detached signatures (#1482)

Demi Marie Obenour notifications at github.com
Sun Jan 10 06:07:21 UTC 2021


For RPMv6, we can replace the signature header with detached signatures.  To quote [my comment on another issue]:

> I am strongly in favor of detached signatures, for multiple reasons:
> 
> * Detached signatures can be verified without having to parse the RPM _at all_.  This dramatically reduces the attack surface ― only the PGP signature parser and the crypto code remains.
> * Detached signatures can be verified without the involvement of RPM.  This means that one can use whatever signature format they desire, rather than being limited to what RPM supports.  For instance, someone could use OpenBSD’s signify (or its compatible replacement minisign) instead.
> * Detached signatures mean that supporting multiple signatures is trivial.
> * Detached signatures can be created without using RPM, which reduces the attack surface of the signing system.
> * Detached signatures work for any file whatsoever, not just RPMs.  This means that a signing and verification pipeline can use the same code for all files, rather than having to special-case specific kinds of files.  If there was a generic signed container format, this would also work, but (to my knowledge) no such format exists (yet).
> * Detached signatures get RPM out of the crypto business.  RPM is a package manager.  Let RPM handle what it is good at, and let the cryptographic tools handle what they are good at.

Because of the above properties, detached signatures integrate well with tools like [The Update Framework] (TUF).  TUF handles signature verification itself, and treats packages as opaque blobs.  In such a system, having RPM try to validate signatures is pointless.

[The Update Framework]: https://github.com/theupdateframework/tuf.
[my comment on another issue]: https://github.com/rpm-software-management/rpm/issues/189#issuecomment-757421219

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1482
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20210109/421402c3/attachment.html>


More information about the Rpm-maint mailing list