On Dec 28, 2007, at 10:33 AM, Ralf S. Engelschall wrote:

>
> 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".
>

OK, here's what exists now:

1) The rpmCheckPgpSignature() routine exists.

2) detached signatures, PEM encoded, for both DSA/RSA using NSS, are  
functional.

3) binary, instead of PEM, encoding needs an appropriate pgpArmor  
return code identifying
pubkey <-> signature packet type in rpmio/rpmpgp.c:1289 pgpReadPkts():

     /* Read unarmored packets. */
     if (pgpIsPkt(b)) {
         ec = 0;         /* XXX FIXME: fish out pkt type from  
unarmored item. */
         goto exit;
     }

With the return code, binary encoding is likely functional.

4) the plaintext needs to be split out for clear signed documents,  
pgpReadPkts likely
extracts the armored signature already.

5) implicit lookup in rpmdb keyring is implemented, but there's  
something
funky going on with RSA key id's, so RSA lookup's are failing because  
the
primary key id is incorrect, not for any implementation reason.

I'll look at clear signed documents and binary encoding next. I'm likely
to punt on RSA key id madness for rpm-5.0 because I'm as likely
to screw something as not without serious regression tests. I will
look at RSA key id issues as soon as possible after rpm-5.0 however.
It's likely a V3 <-> V4 key issue afaict, RSA already has different key
id's for identical keys depending on whether the representation is V3
or V4.

Do you really need key fingerprint checking? I've deliberately avoided
dealing with key fingerprint's so far in rpm, mostly because the added
complexity to avoid key id collisions barely seems worth the effort.

If you really need, the key fingerprint is calculated in (the misnamed)
pgpPubkeyFingerprint() routine, but the 160bit SHA1 fingerprint is
not returned. There's a butt load of other todo item's, like creating
a header extension and tag for indexing key's by fingerprint as
well as key id that need doing if you want key fingerprints.

Personally, I don't see much added value in explicitly handling
fingerprint's other than completely pedantically correct implementation.

I'll also wire up the pgp(...) name space this morning, that's really  
really easy.

73 de Jeff