Drop subkey support from the internal OpenPGP parser #2281
Conversation
|
@nwalfield and @DemiMarie if you have time to check this over I'd appreciate, not that we're in any hurry with this. |
pmatilai
force-pushed
the
nosubkey
branch
2 times, most recently
from
8ea3dd3 to
954a11e
Compare
The world of OpenPGP subkeys is scarily complicated and we're failing at it in too many ways to count. People who need the complexity of a full implementation can use the Sequoia backend, meanwhile this tames the internal parser back to something we may be able to support. Update tests accordingly - as a nice side-effect this makes the internal parser behave the same as Sequoia for these cases. Fixes: rpm-software-management#2278
|
This cannot be dropped, subkeys are used by a number of prominent users (including AlmaLinux). Dropping this will make it difficult for various build environments to use RPM to verify signatures. |
|
Those who want subkeys get to use something else than the internal PGP parser. That is the point here. |
|
In other words: the choice is not whether to keep subkey support in the internal parser or not. The choice is whether to keep the internal parser at all, and significantly reducing the complexity is the only way to keep it around for now. |
|
Closing temporarily, this needs a little more thought but also just to document the situation that we have zero pending PR's in the queue 😆 ) |
The world of OpenPGP subkeys is scarily complicated and we're failing at it in too many ways to count. People who need the complexity of a full implementation can use the Sequoia backend, meanwhile this tames the internal parser back to something we may be able to support.
Update tests accordingly - as a nice side-effect this makes the internal parser behave the same as Sequoia for these cases.
Fixes: #2278