Signed packages = _secure_ authentication of origin and not a policy (was: Should Fedora rpms be signed?)

Axel Thimm Axel.Thimm at ATrpms.net
Fri Nov 5 10:16:48 UTC 2004


On Fri, Nov 05, 2004 at 10:58:37AM +0100, Arjan van de Ven wrote:
> On Fri, 2004-11-05 at 10:50 +0100, Axel Thimm wrote:
> > On Fri, Nov 05, 2004 at 12:34:32AM -0600, Satish Balay wrote:
> > > On Thu, 4 Nov 2004, Peter Jones wrote:
> > > > My model is that the signature is more than just a gpg signature.
> > > > Conceptually, it's a signature on a certificate with data that
> > > > specifies exactly which ways the package may be trusted.  One
> > > > could actually implement it that way, which I think we should, but
> > > > it's some significant effort.
> > 
> > A signature is a signature, nothing more. You are talking about
> > policies, which are orthogonal to signing. Red Hat has policies,
> > ATrpms has policies, every repo has one, and they may partly
> > overlap. But you cannot (should not) deduce a policy from a signature.
> > 
> > The only thing IMHO a signature should be doing is to ensure the
> > package origin is from the key-holder of the package, nothing more. It
> > is a security, not policy entity.
> 
> Well policy and security somewhat interact. The value you give the the
> signature depends on the policy. Most extreme example: if I put my
> secret key on a public webpage, there is no value in signing anything
> with it at all.
> 
> Of course nobody sane is going to do that, so it's clear that there is
> some value in signing. And I can even see even the point of having
> multiple signatures:
> * The buildsystem that builds the rpm signs for having build the package
> * The person doing QA signs the package for having passed the required
> checks
> * The release manager (eg RH or you or Dag) signs for publishing the
> package (whether it is automated or not that's besides the point)
> * The mirror signs the package as a "pass through" 
> 
> that way you even create an authentication trail.... And you can decide
> which to trust for what.

I thought rpm signing allowed only one signature, otherwise strange
things happen, or not? Don't remember whether that was an rpm bug that
could be fixed w/o breaking backwards compatibility, but I remember it
had some implication which is why it wasn't fixed and instead signing
keys had to be adjusted.

Otherwise I agree with the general workflow, but probably mirrors
should not be signing at all - each package would appear different on
each mirror (and a courier doesn't sign a document either ;) -, and
the end user does not care who did internal QA (the release managers
do though).

The end user should see simple one-key signing to keep his logistics
low. Perhaps the above model should be done by signature replacement
(QA replaces build-system signature with its own, release manager
replaces QA signature).

Anyway the thread's recommendation to disallow signing because signing
would imply certain policies would be very wrong.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/test/attachments/20041105/94ce1de2/attachment.bin 


More information about the test mailing list