Allow building rpm without OpenPGP support #2984
Conversation
|
As per the commit message, the intent is to follow-up this with a patch to split the rpmpgp_legacy directory off the rpm main repo entirely, at which point #2414 is achieved while letting others to maintain the code if they so wish. That split is not done here because it'd make any tweaks to the first patch horribly painful. |
INSTALL
Outdated
| The source for the file utility + library is available from | ||
| ftp://ftp.astron.com/pub/file/ | ||
|
|
||
| You will need a cryptographic library to support digests and |
There was a problem hiding this comment.
Perhaps: s/cryptographic library/OpenPGP implementation/
There was a problem hiding this comment.
It gets tricky here because now those two are separated in some of the options. What a crazy tangle 😄 But yeah the language here needs some more love. I also realized the "Use of rpm-sequoia..." paragraph looks odd where it is now - I just moved it a bit earlier without other changes but that doesn't quite cut it.
It's also surprisingly hard to write meaningful docs for the internal parser part when you know it'll be shortly removed.
|
All good points, thanks for the review! As for |
|
This will also need some further tweaks to skip the relevant tests. |
For bootstrapping purposes, having rpm depend on Rust is painful, but directing people to unmaintained crypto code as an alternative is hair-raising. As a middle ground, let rpm be built without OpenPGP support at all, which at least gives you a functional rpm and rpm-build even if you can't sign or verify signatures. Achieving this is a moderately complex dance which can't meaningfully be split into multiple commits because everything is interconnected: Add a new WITH_SEQUOIA option to control use of Sequoia, on by default. When Sequoia is disabled, default to a newly added dummy PGP implementation instead which just returns error on everything. And finally, if the older WITH_INTERNAL_OPENPGP is enabled, use the old PGP implementation. As the intent is to cut out rpmpgp_legacy to a separate repository, sanity requires that we also split the openssl/libgcrypt code at the digest/signature fault line. It's not ideal, but the alternative of having unused crypto code on which an external component depends on is just not sustainable. This way, the signature side of things is quite neatly cut off with the PGP stuff. The diff looks big but there are no code/functional changes in the libgcrypt/openssl split.
|
Lints added, a couple of simple tests added, a whole lot tests skipped when dummy pgp used. |
|
Okay, best to just get this out of the way... |
|
You really should use Sequoia for digesting. It makes no sense to use openssl/libgcrypt in rpm and something else in sequoia. If it's not already exposed, can you please add expose digesting functionality in Sequoia? |
|
The sole reason for this exercise is to be able to build rpm without rpm-sequoia. |
|
Why wouldn't it make sense? Sequoia needs to do digesting anyway to verify the signatures, it might as well expose the functionality. Securitywise it is bad design if two implementations are used. |
|
Oh, I guess I wasn't clear: sure rpm-sequoia supports and exports all the digest functionality rpm needs. What I mean is that it does NOT support using libgcrypt/openssl from rpm side to do that. libgcrypt/openssl digest support in rpm is only for the case where rpm-sequoia is not available. |
|
Ah, I missed that. Then please ignore me ;-) |
|
I know the split is somewhat painful this way, but it was the least painful (or only) way I could see to accomplish this within reasonable time/effort. |
4 participants
For bootstrapping purposes, having rpm depend on Rust is painful, but directing people to unmaintained crypto code as an alternative is hair-raising. As a middle ground, let rpm be built without OpenPGP support at all, which at least gives you a functional rpm and rpm-build even if you can't sign or verify signatures.
Achieving this is a moderately complex dance which can't meaningfully be split into multiple commits because everything is interconnected:
Add a new WITH_SEQUOIA option to control use of Sequoia, on by default. When Sequoia is disabled, default to a newly added dummy PGP implementation instead which just returns error on everything. And finally, if the older WITH_INTERNAL_OPENPGP is enabled, use the old PGP implementation.
As the intent is to cut out rpmpgp_legacy to a separate repository, sanity requires that we also split the openssl/libgcrypt code at the digest/signature fault line. It's not ideal, but the alternative of having unused crypto code on which an external component depends on is just not sustainable. This way, the signature side of things is quite neatly cut off with the PGP stuff. The diff looks big but there are no code/functional changes in the libgcrypt/openssl split.