On Thu, 2004-10-28 at 12:34 -0400, Peter Jones wrote:
> 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.
If we don't sign packages we make it basically impossible for people to
check where a specific package comes from. There is nothing else that a
signature on a package says.
> 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".
That's a misinterpretation of the signature on the package. We shouldn't
sign or not sign packages based on how people could misconceive what
such a signature means. We should sign packages so people can verify
that these packages are actually from us and haven't been tampered with
in the meantime.
I mean, I have the privilege of sucking the packages directly from the
build system so I can be fairly sure that these packages are the real
ones (besides getting them first haha!). If I wouldn't have this access,
I would be either forced to use certain tools that could cope with
signed repository metadata or download directly from
download.fedora.redhat.com. Both alternatives aren't very appealing to
me.
> 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.
I still don't see how signing a package makes it more trustworthy than
signing the repo metadata. Signing a package gives me some amount of
trust in its origin, not its quality or whatever.
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