On Dec 30, 2007, at 12:25 PM, Ralf S. Engelschall wrote:

> On Sun, Dec 30, 2007, Jeff Johnson wrote:
>
>> On Dec 29, 2007, at 4:45 PM, Jeff Johnson wrote:
>>>
>>> (aside) Hmmm, perhaps enough time before rpm-5.0 to collect some
>>> additional
>>> keyring sources in rpmtsFindPubkey():
>>>     1) drill a FTS file walk through /etc/pki/rpm-gpg
>>>     2) slurp up ~/.gnupg/pubring.gpg
>>> as I suggested privately a couple months back.
>>
>> The fts(3) implementation is a file tree walk lazily initialized on
>> first call to rpmtsFindPubkey() using a path specified by a macro
>> (with usual undef/%{nil} disabling) that does a per-file callback  
>> that
>> attempts rpmReadPkts() which (if a pubkey is successfully read)
>> loads the pubkey(s) into the keyutils cache. Reading a pubkey from
>> a file is already commented out in rpmdb/pkgio.c.
>>
>> Ditto slurping pubring.gpg specified by macro path (with usual  
>> disablers),
>> the only complexity is loop over the possibly multiple pubkey packets
>> returned from pgpReadPkts() in the pgpDig structure before loading  
>> into
>> keyutils cache.
>>
>> For extra credit I'm likely to loop over multiple fts(3) roots and
>> pubring.gpg
>> files.
>>
>> Hmm, actually the above implementations are actually identical,  
>> just loops
>> within
>> loops, not really different. One can walk a single file using fts 
>> (3) too.
>>
>> What say ye? Shall I chase these two issues for rpm-5.0 (or leave for
>> rpm-5.1)?
>
> I'm still busy in checking the signature(...) stuff (it fails for one
> particular PGP key and I still do not understand it, will tell you  
> more
> if I'm unable to debug myself) -- so, CHASE IT FOR RPM 5.0 as I'll not
> be able to roll 5.0b4 before Monday morning as it looks now...
>

OK, todo++. Man you're easy, all that noise abt 2 months of alpha/beta
scared me silly ;-)

Meanwhile, the common DSA failure I've seen is in parsing the MPI.  
For ASN1 compactness
reasons, a paremetr with >8 leading 0 bits needs padding before use.  
See if the r/s DSA
parameters have >8 leading 0 bits using NSS. I'm pretty sure beecrypt  
Gets It Right,
but I've not yet verified the (slightly different) NSS parsing padding.

Easiest hack is to change printing to -1 in pgpPrintPkts() to see the  
goop.

73 de Jeff