Questions below ...

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

1) PEM encoding is what gpg refers to as "armored"? Or are you chasing
X.509 certificate signing (which has been on my todo list for years,  
I don't
know of any application other than gnutls that handles both OpenPGP
and X.509 certs).

2) If "cleartext" signing is what gpg refers to as "one-pass"  
signatures,
there's a slew of added complexity because of the need to handle
embedded compression within the one-pass signature.

Support for "one-pass" signatures is unlikely to happen _TODAY_, but
definitely needs to happen, *.rpm signatures are way too Baroque for  
hysterical
reasons. A one-pass signature is what should have been implemented  
long ago, but
my manglers overruled my preference at the time.

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

Largely straightforward logic even if the side effects of the chosen
API are perhaps easier to implement with some flags instead.

> 2. the "gnupg(<datafile>)[ = <fingerprint>]" implementation
>    should be changed to gnupg(<datafile>[,<sigfile>])[ =
>    [<pubkeyfile>:]<fingerprint>]" and implemented via a call to
>    rpmCheckPgpSignatureOnFile().
>

Why change? Adding another name space is trivial ...

There are also syntax issues with ',' (and other embedded white space),
and ':' tricking the data through the existing parseSpec()  
implementation.

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

Are you trying for signature verification of some/all package files  
through Lua
serialization into an arbitrary tag? Adding an explcit per-file tag  
to carry a
variable length signature (rather than a constant sized digest) could  
be done
by parsing a binary blob of per-file concatenated OpenPGP signature pkts
with a check that #files == #pkts and some representation for missing/ 
unspecified
signatures.

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

Glad to hear working for you. ;-) There is still much to be done, sigh.

73 de Jeff