On Fri, 2004-10-29 at 11:06 -0600, Rodolfo J. Paiz wrote:
> That being said, let me take your points one by one:
>
> 1. Replace something that worked well for years. What was the
> mechanism previously that let me verify that the updated kernel RPM on
> Mirror X was a bit-identical copy of the one actually published by Red
> Hat? I know how to verify ISO's but know of nothing that verifies a
> package was not tampered with after being placed on a mirror.
This is an old snapshot of Rawhide but serves well nonetheless:
nils@gibraltar:/misc/scratch/rawhide/i386/Fedora/RPMS> rpm -K rpmdb-fedora-1.91-0.20040325.i386.rpm bash-2.05b-38.i386.rpm
rpmdb-fedora-1.91-0.20040325.i386.rpm: sha1 md5 OK
bash-2.05b-38.i386.rpm: (sha1) dsa sha1 md5 gpg OK
See? I can verify that the bash package is signed with one of the keys I
have in the keyring. Granted that I can't see (here) which key it was
signed with and we have no way where I can say how much I want to trust
a key in terms of RPM -- I admit that RPM's notion of keys and trust is
a little black and white, but it's better than nothing.
> 2. Puts a burden on people who know. Why? If a repo's metadata is
> signed, isn't that just one more check up2date and yum can perform to
Sometimes up2date or yum aren't available (maybe because you botched
your python installation) or you have only the packages on a USB stick
an you have no net or a very slow network connection (where you wouldn't
want to download the entire metadata which is MBs only to verify a 16K
package) or whatever.
> improve authentication of a package? Isn't that automatic? And can't
> someone also get it by hand if they choose? Besides, since you can
> always get the package *without* checking the metadata if you so choose
> with a simple "wget", what burden is put on these people?
I meant that you can get the package but you can't check its integrity
without using yum or up2date which isn't always feasible. Today I can
check that an individual package originates from the Red Hat build
system, I don't want to lose this ability.
> 3. Doesn't stop people from doing things they shouldn't do. No
> kidding... as I understood it, the idea of signing metadata had no
> "control" purposes in mind whatsoever. It was merely intended to be a
> way to know that the bits stored on server "A" were the same as those
> issued by the RHI buildsystem. How is this relevant?
Exactly this purpose is currently being fulfilled in 95% (some random
number) of the packages by themselves being signed. Again my case is not
contra repo metadata signing but pro individual package signing.
> 4. Doesn't exist already. So what's your point? Tell me that it's a
> bad idea and explain why. But "doesn't exist yet" is a bloody silly
> argument.
My point was that RPM package signing exists now and I haven't seen a
convincing argument in this entire discussion why this would be a bad
thing. Not even on Rawhide packages. So I have my gripes with replacing
individually signed packages with something that isn't there yet but
still doesn't offer me the functionality I want. Especially when we can
have both.
> Seems to the unwashed masses here that signing repo metadata provides
> one benefit (knowing package A on server A is bit-identical to package A
> on server B) and has no real cost other than the addition of a new
> feature (which is even optional, since no one *has* to use it) to
> package managers like yum and up2date.
>
> I see no downside. Since you do, can you provide more detail on what and
> why?
I see no downside in repo metadata signing either, it's a good thing
actually. But it is not an argument on why packages shouldn't be signed
individually.
Nils
--
Nils Philippsen / Red Hat / nphilipp@xxxxxxxxxx
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011