On Dec 29, 2007, at 11:09 AM, Ralf S. Engelschall wrote:

> On Sat, Dec 29, 2007, Jeff Johnson wrote:
>
>> [...]
>> 1) The rpmCheckPgpSignature() routine exists.
>
> Great!
>
>> 2) detached signatures, PEM encoded, for both DSA/RSA using NSS, are
>> functional.
>
> Fine. Is this NSS-only now? What about BeeCrypt? In OpenPKG we cannot
> use NSS (because it is not as easily portable and stand-alone as
> BeeCrypt) and hence for RPM have just BeeCrypt (or even OpenSSL)
> available.
>

I've added --bc and --nss, checking both implementations. Note
the quick hack assuming sizeof(int) == sizeof(void *) in tpgp.c
option table before testing portably.

>> 3) binary, instead of PEM, encoding needs an appropriate pgpArmor  
>> return
>> [...]
>> With the return code, binary encoding is likely functional.
>
> Doesn't matter for me. I can easily enforce the use of PEM only in my
> all of my use cases.
>

binary encoding is now functional.

(aside) The expectations on rpm -- particularly for signature
checking -- are impossible to satisfy imho. People with nothing
better to do are fuzzing *.rpm's and feeding rpm random crapola
and complaining when rpm doesn't Get It Right. There _WILL_ be
complaints because I changed pgpReadPkts() to handle additional
functionality.

And now there is an a priori, trackable,  "I told you so."  message to
trump the dweeb's. *shrug*

>> 4) the plaintext needs to be split out for clear signed documents,
>> pgpReadPkts likely
>> extracts the armored signature already.
>
> Yes, would be nice to have, too. But for plain checking
> the signature this is still not required, of course.
>

Working on it, likely in the next hour or so.

>> 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.
>
> Ok, this is no problem as our OpenPKG keys are both in the RPMDB and
> on the filesystem. So we can easily stick to the functionality which
> directly loads the key from the filesystem.
>

OK.

>> [...]
>> Do you really need key fingerprint checking?
>
> Yes, indeed. Sorry, but this is really essential and also the reason
> why I added fingerprint checking for gnupg() yesterday. One could
> "rpm --import" arbitrary pubkeys or even overwrite the pubkey on the
> filesystem, so it is actually *essential* to not just check whether
> a pubkey matched, but also to check the fingerprint of this signing
> pubkey to make sure something was signed by the *right* key.
>

Whoa!

The issue is whether a full 160 bits of SHA1 "key fingerprint" or  
just the least
significant 64 bits of "key id" need to be compared.

Adding additional complexity to compare the full fingerprint to avoid
possible collisions in a 64bit space is what is being discussed, not
whether any random pubkey will do.


>> [...]
>> 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.
>
> Well, _here_ we minimally just need the possibility to check the
> fingerprint of the matched pubkey. No tag fiddling or whatever else
> currently needed. But the raw fingerprint check is really essential
> IMHO.
>

See above.

>> Personally, I don't see much added value in explicitly handling
>> fingerprint's other than completely pedantically correct  
>> implementation.
>
> It prevents one to accept _any_ matching pubkey while one often really
> wants to accept just a _particular_ matching pubkey. Think about for
> instance our OpenPKG security advisories: they are PGP signed by
> a particular OpenPKG GmbH key, not just by any key from a OpenPKG
> developer. If one wants to check the integrity one has to not just  
> check
> whether it was signed by _someone_ but signed by the particular  
> OpenPKG
> GmbH key.
>

See above.

>> I'll also wire up the pgp(...) name space this morning, that's really
>> really easy.
>
> I just cannot wait to testdrive this. I'm partly excited to have
> this functionalities in place. Especially the rpmCheckPgpSignature()
> function. Hopefully you get it working with BeeCrypt or OpenSSL  
> instead
> of NSS, too...

Note that I have a "private agenda" for on-the-fly signature checking  
as well.

Hint: Swallowing tripwire config parsing and rebasing the data store  
on an rpmdb will
need on-the-fly /var/lib/rpm/Packages signing.

73 de Jeff