On Fri, Dec 28, 2007, Jeff Johnson wrote:
> On Dec 28, 2007, at 9:48 AM, Ralf S. Engelschall wrote:
>
>> RPM AFAIK contains PGP signature verification code which seems to
>> be able to even handle the PEM/Base64 variants. So, I'm wondering
>> whether it would be even possible to implement the "gnupg(<path>) [=
>> <fingerprint>]" *WITHOUT* an external gpg(1).
>>
>> The background for this is that especially with the latest GnuPG 2.x
>> the dependencies to install gpg(1) increased dramatically. This means
>> that in a self-contained environment like OpenPKG one would be able to
>> check "gnupg(...)" dependencies only after one has built about a dozen
>> packages -- this renders "gnupg(...)" mostly useless for us in practice.
>>
>> But all which I'm seeking for is to be able quickly (no external program
>> forks) and self-contained (no external dependencies) to check the PGP
>> signature on a file. So, as RPM already ships with BeeCrypt based PGP
>> verification functionalit, would be *EASILY* possible to use this
>> already existing functionality?
>
> Yep. The gnupg(...) probe dependency was proof-of-concept for stronger
> than digest fetched content verification. Invoking gpg was the easy
> hack for an idea that noone "gets" yet.
>
> Most of the existing code in rpm is heavily tricked up to handle header and
> payload
> items used in *.rpm without temporary files or external helpers.
>
> Verifying the signature on a single file is rather easy, starts with
> getting the digest
> on the plaintext, parsing the signature, etc etc.
>
> Do you want such functionality under gnupg() in rpm-5.0? Signature
> verification is relatively risk free, the mathematics insures that you
> either win or lose unambiguously, no memory leaks or other implementation
> details to fuss about.
Well, I have to admit that also all my "official" requirements on RPM
5.0 are now already fully satisfied, this particular item is still on
my personal "hidden agenda" ;-) I really have to be able to verify the PGP
signature on a text-file (either in mixed text/signature mode or with
a separate signature file doesn't matter here very much) directly from
within RPM and without requiring any slow external stuff.
So, yes, what would be really good is if we still could hack up today
the following:
1. a function
int rpmCheckPgpSignatureOnFile(
const char *filename_data,
const char *filename_signature,
const char *signer_pubkey_filename,
const char *signer_pubkey_fingerprint
);
where "filename_data" is the filesystem path to the file containing
either just the data itself or (of "filename_signature" is NULL) also
the signature ("cleartext signing" mode). If "filename_signature" is
not NULL, it contains the detached signature -- usually either in
binary or PEM format.
If "signer_pubkey_filename" is not NULL, only this (PEM encoded)
public key is used for verification. Else RPM consults the RPMDB for
the existing ("rpm --import") public keys.
If "signer_pubkey_fingerprint" is NULL, it is fine if
any key (either the "signer_pubkey_filename" or any from
RPMDB) matched. If "signer_pubkey_fingerprint" is not NULL,
it is required that the matching key has exactly this
fingerprint. "signer_pubkey_fingerprint" is a hex-sequence like
"4E23E878D41A0A88EDFCFA5A6E744ACBA9C09E30".
2. the "gnupg(<datafile>)[ = <fingerprint>]" implementation
should be changed to gnupg(<datafile>[,<sigfile>])[ =
[<pubkeyfile>:]<fingerprint>]" and implemented via a call to
rpmCheckPgpSignatureOnFile().
The availability of the functionality in the dedicated function I would
like to see as I would like to use the functionality later also from
other places in RPM (think about a a macro "%{gnupg:...}" and a Lua
function rpm.gnupg(), etc).
Jeff, if you could help me and implement the first cut for such a
functionality today, you are really my hero. I'm helping out in testing
and and fixing any introduced bugs, of course.
> OTOH, it is 12/28/2007 ;-)
Well, really still enough time to make RPM 5 an ultimate packaging
solution... ;-) Yeah, sorry that I come such late with those requests,
but they were just triggered now that I have RPM 5 finally fully flying
in a real packaging environment. OTOH, now that I have it flying, I'm
the first time really sure that RPM 5 is really working just fine in
practice -- and not just in a simple lab environment...
Ralf S. Engelschall
rse@engelschall.com
www.engelschall.com
Received on Fri Dec 28 16:34:12 2007