Why aren't rawhide packages signed?

[marko]

I know the rawhide packages aren't signed (usually), I'm just wondering why. Is there a security risk in giving out some key to a large number of people? I'd think it wouldn't take too look to actually sign the file?

[nirik]

Because in order to do so some human would have to sit there and do it each day for all the packages produced that day. ;)

There is work going on to allow the buildsystem to automagically sign rawhide packages as they are built, but this is not yet in place.

[Demz]

i think yum is sposed to do it, they have or are taking that ability out of RPM an putting it into yum instead, ( correct me if im wrong ) so yum should be able to sign the packages instead

[nirik]

I'm not sure what you are asking there. ;)

rpm can sign and check signatures of packages.
yum can use rpm to check package signatures, it has no ability to sign them.

I was talking about koji (the fedora build system). It's been proposed that it will sign all packages it builds with a 'this was built by the fedora build system' and that would be used to check rawhide packages.

Currently there is no easy way to sign all the rawhide packages, so they are not signed.

[Demz]

http://rpm.org/roadmap

eliminate gpg-pubkey's from rpmdb im sure thats the one im refering to in my above post so yum will do it instead

[RahulSundaram]

Hi,

Yum already does that. The roadmap is referring to a different thing and it solves a different problem. There are blog posts explaining the details. Feel free to look them up

[Demz]

thanks for clearing that up Rahul i wasnt sure

[Don3]

Sorry if this is off-topic/late, but about message #4: I have just downloaded kernel-2.6.30.5-28.rc2.fc11.i586.rpm and related files from http://kojipkgs.fedoraproject.org/packages/kernel/2.6.30.5/28.rc2.fc11 ... initially from the "i586" and "noarch" sub-dirs ... When I tried to install them yum/rpm complained:

Package kernel-2.6.30.5-28.rc2.fc11.i586.rpm is not signed

Now that I've seen the discussion above, that no longer surprises me... But then I noticed that there is another tree under .../data/signed/d22e77f2 (and d22e77f2 matches one of the public keys I have). So I downloaded the corresponding files from there, but yum still complains that the package is not signed.

Anyone know what the purpose of the "signed" tree might be?

- Don