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

[Justus Winter]

@teythoon 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?

Historically, the OpenPGP spec has mostly concerned itself with syntax, not semantics.  Therefore, implementing OpenPGP securely requires a lot of tribal knowledge.  Reading RFC4880 and implementing something based only on that reading is a recipe for disaster.

Many things are possible.  We have often talked about writing up that tribal knowledge in a separate document, like an annotated version of the RFC.  That takes people with that kind of knowledge a lot of time.  As always, someone needs to do it.

I have seen many horrible half-baked implementations, you know, like the one in RPM.  Sure, you can spend a lot of time improving that, but in the end, you shouldn't even attempt to implement a complex security-relevant protocol, you should use a library.  You don't implement TLS, you don't implement XZ, RSA, EdDSA.  Why would you even think that it is okay to implement 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.

Yeah, that is half-way implemented.  It "only" requires annotating each test with the required operations, then selecting to run just those tests.  But, I'm very skeptical about these point solution implementations.  RPM's is the first verification-only implementation I have encountered.  And, I have plugged it into the test suite and it was informative even though some tests were not applicable.

>     * 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.

The test suite is about semantics of OpenPGP, not about the memory safety of implementations.  I think implementations are better off with compiler-supported fuzzing techniques.  Having said that, Sequoia includes a protocol-aware fuzzer and uses it in its tests.  It could conceivably be adapted to test another implementation.

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

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