Should Fedora rpms be signed?

[Nils Philippsen]

On Fri, 2004-10-29 at 12:45 -0600, Rodolfo J. Paiz wrote:
> On Fri, 2004-10-29 at 19:37 +0200, Nils Philippsen wrote:
> > 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.
> > 
> 
> Sigh... backing up a few steps for historical clarification:
> 
> Matías argued that, because *some* Rawhide packages are not signed, one
> does not have for those packages *any* ability to see that what is on a
> mirror is in fact exactly what came out of the Red Hat buildsystem. He
> argued pro signing of all Rawhide packages.

I'm with Matías here.

> Others argued that this has either no value or negative value. A debate
> ensued as to whether passwordless keys would be better than nothing or
> worse than nothing.

I wasn't pro password-less keys, but pro some kind of automatic signing
of all packages or to be more precise pro signing of all packages that
get pushed (which implies automatic signing as they're pushed
automatically). This doesn't imply leaving the keys unguarded or
password-less because our build system also isn't unrestricted, i.e. not
everyone can build packages which means that not everyone can get
something signed with that key. When I build a package in the build
system, the one signing the package later will trust me that I didn't do
something nasty with it, so the result is practically the same whether
signing happens manually or automated, only that in the latter case no
package is forgotten. Especially since the people who operate the build
system are the same that do the signing ;-).

> Someone suggested that, for those Rawhide packages which were not
> signed, one possible way to get that benefit of knowing that package XYZ
> on Server A is bit-identical to the one on the main Rawhide server was
> to sign the repo metadata. It was suggested that this would provide an
> additional benefit to the rest of the world, at no real downside.

Still someone or something would have to sign at the time of pushing,
whether this means signing packages or repo metadata and whether this is
done manually or automatically is largely irrelevant IMO.

> I really liked the idea and said basically that if this has good benefit
> and no real downside, then how do we get it done?

OK, sorry for getting you wrong there.

> You came on scene and started arguing that it was a Bad Thing which
> would destroy the world as we know it. ;-) We now realize that you are
> not "contra repo signing" but rather "pro package signing".

I was getting misunderstood as well as some other people -- now that we
can agree on this, how do we move on?

> So welcome to the club. I am also pro package signing, but some Rawhide
> packages are not signed and at least repo signing helps provide some
> benefit, and I like that benefit. Matías is vehemently pro signing
> *every* package, and some people have responded that they either don't
> want to sign all Rawhide packages, or perhaps even don't want to sign
> any Rawhide packages. I'll leave exact interpretations to you when you
> read through the archived thread.

As outlined above, the process of signing repo metadata and the process
of signing individual packages isn't that much different in that it
needs someone or -thing to do the signing. I think signing repo metadata
is good to augment the signing of packages in that someone certifies a
specific set of packages, which is a benefit if you e.g. think of some
bad guy trying to inject a (signed) iptables package into a mirror
repository that by whatever problem wouldn't work together with the
kernel already in there.

> Now... the whole point of this thread is now to:
> 
>  1. Argue that all packages should be signed, even all Rawhide. There
> appear to be strong feelings either way.

I think it can be done without sacrificing any of the security we
already have. Probably we should be thinking about using very short-
lived keys for that, along with teaching RPM how to respect EOL dates
for these keys as well as signed keys so that we can e.g. change the
Rawhide key every few days, having it (manually) signed with a "master"
key and have this key in a well defined place where tools and/or users
could grab it once a new one is out and being sure that by SSL-
certificate and GPG signing that this is the real key.

On the other hand the argument that we should use the presence of a (Red
Hat) signature as a measure of quality is rather moot in my eyes as I
have had a number of my packages out there with great difference in
quality and all of them signed, even with a non-Rawhide key ;-). We have
to teach the people who think about the signature being a sign of
quality instead of origin about its real meaning, we shouldn't conform
to their ill views.

>  2. In context, it also appeared that repo signing could also be
> implemented as an *additional* measure that would provide some good
> benefits. I have not seen any arguments against that other than yours.
>
> What do you think of those two thoughts?

Mine wasn't an argument against repo metadata signing -- some people
(too lazy to check who ;-) sounded to me like they would want to replace
package signing with repo metadata signing.

Have a nice Sunday,
Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"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