auto importing rpm gpg public keys from keyserver

[Jeff Johnson]

On Jun 15, 2006, at 1:09 PM, Andrea Arcangeli wrote:

>
>
> However we still have to mangle (i.e. split) the string to get to the
> key number right?
>

Yes. IMHO, string splitting is easier than API/ABI method changes if,  
say, 64 (or 32) bit keyid's are chosen.
With strings, rpmlib gives you 64 bit keyid's and you can choose 32  
bit if you wish.

(aside)
The user id in a gpg pubkey is bound by a signature, which rpm does  
not check.

So it would be quite easy to concoct a gpg pubkey cert with a  
misleading userid with the
current implementation of OpenPGP in rpm.

That's not true for the pubkey parameters themselves, from which the  
fingerprint digest is derived.

However, your pop-up GUI now takes previously <shrug> userid data and  
presents
to end-user as a basis for a "trust" decision.

>> You can find example usage in yum if not in smart already.
>>
>> This is a series of nested tests for existence of 4 possible  
>> signatures.
>>
>> There are two types of plaintext: header-only and header+payload.
>>
>> There were different tags used for pgp (essentially RSA) and gpg
>> (essentially DSA) historically.
>
> It seems it worked if I got the above result.
>

I wouldn't bother checking header+payload signatures, they should  
have been ripped
out of rpm several, years ago. The issue is certain vendors -- IBM,  
Sun, HP (and formerly SuSE -) --
that insist (and insisted ;-) on using rpm-3.0.x with header+payload  
signatures forevermore.

A header-only signature secures the metadata from a package, all that  
depsolvers need, and
a header-only signature that verifies payload file digests should be  
adequately secure as long as
the digests are verified while files are being installed.

>
>> The flags to disable signature checking are per-transaction, the
>> method is ts.setVSFlags.
>
> Yes, I noticed.
>
>> All the flags are disablers, so
>>     ts.setVSFlags(-1)
>> disables all signature and digests checking by rpm.
>
> To avoid executing rpm with popen, we need to only temporarily disable
> the signature checking, that's easy, problem is that I couldn't  
> find how
> to re-enable it. However creating a new temporary rpm.ts()  
> workarounded
> it. With a new temporary rpm.ts() I can disable signatures checking  
> so I
> can read the header and now using your sprintf() I can get to the key.
>
>> Note carefully the chicken <-> egg problem of reading the header in
>> order to identify the pubkey you wish to import.
>
> Creating a new ts seems to work, however if I could just re-enable
> signature checking after reading the header, I could avoid to create a
> new ts.
>

Yes, create a new transaction, set VSFlags as appropriate.

The real issue is that signature checking policy needs to be set  
outside of
applications. Say smart chooses to verify signatures, yum does not, and
both are used to install software on the same box.

The policy of whether to verify signatures or not needs to be per- 
system, not
per-application, at least in some ideal world.


>> Some security problems, like a buffer overflow reading a package
>> header leading to a setuid shell, will occur before you are able to
>> import the pubkey. In those cases, your scheme using gpg to import
>> pubkeys  is no security at all.
>
> And how disabling signature checking would help to make things more
> secure? If the signature check is off and the package is malicious  
> they
> won't even need to hope the NX bit is disabled in the pte to get  
> istant
> root.
>
> Also note, if you think this is a serious concern it's very  
> possible to
> do all signature checking and gpg key fetching as user nobody, so it's
> totally fixable even if you think the signature checking is so flakey
> and nearly unfixable in reasonable time (infact with my way of forking
> off a new rpm I could simply do su - nobody -c 'rpm ...' and catch the
> output, it would be a two liner to make 100% secure as long as the
> kernel isn't buggy too, and the point is that it wouldn't give you
> istant root).

Yes, there's a number of alternatives to address the design deficiencies
in rpm signatures.

The simplest answer is to sign *.rpm files with onepass signatures  
using gpg
and whatever functionality one wants.

I like that answer because I don't have to change 1 line of rpm code ;-)

73 de Jeff