On Thu, 2004-10-28 at 14:34 +0200, nodata wrote:
> Yes, but that's not really the point.
> The point is that the RPMs are not signed.
>
> It's not really important how it came to be noticed that the RPMs were not
> signed (i.e. the announcement about the recent scam)
>
> It's not really relevant either than RPMs can verify themselves.
> The whole point of my post was that there is no way to verify a rawhide
> RPM originated from Red Hat.
>
> True, signing them would devalue the signing key, but NOT signing them
> devalues the RPMs even more because they cannot be automatically verified
> using a package manager.
The question is still one of gains versus losses. I personally think we
gain more by _not_ signing them. If we automatically sign them, we make
it more convenient for people who don't want to use --nosig or whatnot
on rawhide packages.
That's not a win. In fact, it's a big loss. If the packages are
automatically signed during the build process, the only thing the
signature means is "it showed up in the queue of things to be signed".
But if you see a signed package, the impression you get is that it is in
some way "trusted". Of course, it isn't trusted. It's just got a
signature that says "don't make the user type --nosig".
If you _really_ want a way around that, change the update tools so you
can mark a repo as being allowed to have unsigned packages.
If the problem you're trying to avoid is corruption or injection attacks
on a repo, signing the packages still isn't the right answer -- sign the
metadata on the repo, and then compare the packages to that, instead.
Then there's no misplaced trust on the package, as you'd get by signing
it, but there is verification that it is the right package.
--
Peter