[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))

> > * First, there are more certifications that can be used by implementations as binding (self) signatures.  Note the "most" in Section [5.2.1 of RFC4880](https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.1):
> > 
> > > ```
> > >   Most OpenPGP implementations make their "key signatures" as 0x10
> > >   certifications.  Some implementations can issue 0x11-0x13
> > >   certifications, but few differentiate between the types.
> > > ```
> 
> RPM does not implement self-signatures at all. RPM basically implements a subset of `gpgv`.

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

> > * You should really care about subkey binding signatures.  How else would you know that a subkey is eligible to make signatures in the name of the certificate, i.e. whether
> >   
> >   * the subkey is bound to a certificate at the time the signature in question is created, and
> 
> How should RPM determine this? Is it by checking that the signature creation time was after the binding signature creation time? In the presence of multiple binding signatures, is it okay to only use the first one?

No.  You need to consider the newest valid signature (i.e. non-expired, non-revoked, policy likes it, maths checks out) with a creation time prior to the target signature's creation time.

> > * the subkey is marked as signing-capable?
> 
> RPM does not know either of these. I actually consider this to be a security vulnerability, but I do not know if upstream does. In any case there is no point in an embargo since this is already public.

It is a security vulnerability, but upstream disagrees.

(But, contemporary SLES likes MD5 signatures in FIPS mode, so the bar isn't high.)

> > "Care about" here means that the creation time is used calculate the "release" element of the synthetic pubkey rpm package. There's nothing else rpm does with the creation time of pubkey signatures.
> 
> In this case RPM should use a completely separate field for this. The actual time is important for the reasons @teythoon mentioned.

See, this is the problem.  You point out a problem with their OpenPGP implementation, and get told why it isn't a problem for RPM, or why it is okay in this case, or why you just haven't looked at it from their perspective enough.

I have cared for the most widely used OpenPGP implementation.  Then, I wrote a new implementation from scratch that the creator of the protocol calls the most advanced implementation out there.  I have written the most comprehensive OpenPGP test suite ever created that found countless bugs across multiple implementations.

Take my advice or leave it.  I don't have time to argue why RPM is so special that it doesn't need to do what everyone else absolutely needs to do.

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

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