[Rpm-maint] [rpm-software-management/rpm] Require creation time to be unique and hashed (PR #1912)

[Demi Marie Obenour]

@DemiMarie commented on this pull request.



>  	    impl = *p;
-	    if (!(_digp->saved & PGPDIG_SAVED_TIME) &&
-		(sigtype == PGPSIGTYPE_POSITIVE_CERT || sigtype == PGPSIGTYPE_BINARY || sigtype == PGPSIGTYPE_TEXT || sigtype == PGPSIGTYPE_STANDALONE))

> > > `gpgv` canonicalizes certificates. Not doing so is unsafe. Saying RPM implements a subset of that is like saying `/bin/true` implements a subset of `gpgv`.
> > 
> > 
> > Is there a specification for certificate canonicalization anywhere?
> 
> Not that I'm aware, but Paul has a good write-up on how to properly verify signatures: https://blog.jabberhead.tk/2021/04/03/why-signature-verification-in-openpgp-is-hard/

Would it be possible for the specification to include detailed algorithms for verifying a signature, canonicalizing a certificate, determining when a signature is malformed and should be rejected, and other important facets of OpenPGP?

> > Is this test suite open source?
> 
> Of course:
> 
> * https://gitlab.com/sequoia-pgp/openpgp-interoperability-test-suite
> * https://tests.sequoia-pgp.org/

Thanks!  Last I checked there are a few cases where improvements could be made.  You may consider these feature requests, or I can file an issue on GitLab for them.

- Some implementations, by design, only implement a subset of OpenPGP.  For instance, a package manager only needs to implement signature verification, so there is no reason to implement other parts of OpenPGP such as signing, encryption, or decryption.  It would be nice to split the test suite in such a way as to be able to easily exclude tests that simply are not applicable for a given implementation.
- It would be nice to have more tests for very malformed packets and subpackets, such as ones that might be produced by a fuzzer.  This is very important for finding and fixing memory unsafety and other bugs in implementations.  In RPM-Oxide, for instance, I am much less worried about wrongly rejecting a good signature than about wrongly accepting a bad one.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1912#discussion_r811401128
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/pull/1912/review/889064047 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20220221/17384d69/attachment.html>