auto importing rpm gpg public keys from keyserver

[Andrea Arcangeli]

On Thu, Jun 15, 2006 at 02:45:06PM -0400, Jeff Johnson wrote:
> 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.

Not sure what's the problem. My current pop-up gui fetches a random key,
and it tells the user it must check the fingerprint before answering yes.

If the userid data and the fingerprint of the key (both shown in the
popup window) are both correct, it's secure enough to trust the key. The
key will be injected into rpm keyring and then it's up to RPM to check
the signature of the payload, and not just that the keyid of the
public-key matches the keyid of the rpm package. I assume rpm does the
right thing here (if it's slower like you said in previous email, rpm
must be checking the signature for real and not just comparing the keyid).

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

YAST2 in suse 10.0 and all previous always did signature checking too,
but yet smart didn't by default, what's the difference?

We can't fix all package managers in the world, we're in smart list,
otherwise you should also plan how to fix zen/rug in 10.1 that had more
serious problems than the signature checking.

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

In the ideal world, it can't be in rpm business to set the policy
because the same mechanism should work for deb too. Infact in the ideal
world you could use rpm and deb in the same system trasparently.

> 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 ;-)

So is rpm already exploitable or not? I hope not. But if not, how do you
know that gpg is less probable to be buggy in the signature checking
code than rpm? I don't really see a big risk difference in invoking gpg
or rpm first on maliciously altered data: the only important thing would
be to do this first invocation as user nobody to handle obviously
corrupt packages that may segfaults. I would use a new ts after fork
and change of uid for that check, but it will be slower since it'll have
to parse the header and check the singature multiple times.