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
Attachment:
pgpBXj7KjTvay.pgp
Description: PGP signature