[Rpm-maint] [rpm-software-management/rpm] Phasing out obsolete crypto in rpm (#1292)

[Neal Gompa (ニール・ゴンパ)]

> > Besides the currently obsolete things, new things need to be built with the mindset that all crypto _will_ become obsolete over time, and avoid putting it into new places where it only gets in our way eventually.
> 
> I suggest avoiding algorithm agility as much as possible. It is great in theory, but in practice, it leads to a bunch of extra complexity, which in turn causes exploitable vulnerabilities. The current header parsing code is already _far_ too complex.
> 
> Instead, choose _one_ ― and only one ― set of algorithms. Drop support for all the others. And change the file version number when an algorithm change is needed. That’s what signify, age, WireGuard, and most other new cryptographic protocols do.

This would be a pretty bad idea for any archive format. That would mean we'd be making incompatible revisions of RPM very frequently, which would cause a whole host of problems as things move forward. Algorithm agility is the _only_ reason that new algorithms are easily adopted _at all_. If you decide to make algorithm selection part of the protocol/file format itself, you wind up with a different trap: the inability to upgrade. I think we can all agree that is a much worse outcome.

Your examples are also sufficiently immature that there is no way that any of them have seen the consequences of those choices. WireGuard itself was only mainlined fairly recently, and has no current plan for dealing with the inevitable issue of cross-version (thus incompatible) client and server mixes existing in production. As for signify and age, any project from OpenBSD winds up being problematic because longevity, compatibility, and accessibility are not virtues held by the OpenBSD project.

It is important to recognize that security enhancements need to be balanced with usability and accessibility, otherwise nobody will use either for long. RPM has also been around for 25 years, and until _very_ recently, all RPMs produced in that timeframe were still accessible by the latest version of RPM.

-- 
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/1292#issuecomment-751311495
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20201225/8c3d83b1/attachment.html>