Le jeudi 28 octobre 2004 à 12:34 -0400, Peter Jones a écrit :
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.
That's not a loss.
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".
what is the loss ? If the package is signed you can install it with --
nosig or without --nosig.
If the package is not signed you should use --nosig and definitely don't
trust any mirrors at any moment.
So, what is the loss ?
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.
This is a _real_ big loss.
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
But i can't still see the loss.
-- sign the
metadata on the repo, and then compare the packages to that, instead.
????
"createrepo --addsign ...." is better than "rpm --addsign *.rpm" ?
Why ?
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.
???? You mean I should not trust the right package ?
--
Peter