Michael Schroeder <m...@suse.de> writes:

> On 10/21/21 18:12, Justus Winter wrote:
>> First, I think replacing RPM's point solution with a general purpose
>> implementation will improve correctness.  Robust signature verification
>> requires canonicalization of the issuing certificate, which is tricky
>> [0], [1], [2].
> Wait, those links don't say why canonicalization is required. What's
> the attack vector? Do you have other pointers?

Canonicalization is required before a certificate can be safely used for
any operation.  OpenPGP certificates are compound structures made out of
packets bound together by signatures.  Canonicalization requires several
steps, among them re-ordering out-of-place packets, deduplicating
packets, checking signatures (and embedded signatures for signing
subkeys), reasoning about signature and key lifetimes, and revocations.

>> Further, RPM shouldn't be burdened with maintaining
>> their own point solution, which will require constant maintenance to
>> keep up with evolving standards and algorithms.
> I somewhat agree except that PGP moves really really slowly. It takes
> ages till some new algorithm goes in. See EdDSA as an example.

That unfortunately is true.  Or rather, it was.  OpenPGP's development
picked up speed, we recently formed a design team that is creating a
proposal for the next RFC, and have produced a new draft just last week:


Relevant changes for RPM include: New key packet types, new hash
algorithms, EdDSA over Ed448, new fingerprint format, maybe new
signature packet types.

I expect the working group to produce a new revision of OpenPGP later
this year or early next year.

>> Second, Rust has been criticized for being not too portable [3].  While
>> there is some truth to that, at least today, there is ongoing work to
>> add a GCC backend to the Rust compiler [4], and to write a Rust frontend
>> for GCC [5].
> But doesn't that mean that we need to wait till this work is done?

Well, we can carefully structure the work so that RPM can keep the
current implementation while adding support for a Sequoia-based one.  So
RPM can keep using its current implementation in environments where Rust
is too much of a burden as a build dependency.  At the same time, adding
a proper abstraction layer will likely benefit the code base, and we can
improve the current implementation by comparing what it computes with
what Sequoia computes.


Attachment: signature.asc
Description: PGP signature

Rpm-maint mailing list

Reply via email to