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.
Attachment:
signature.asc
Description: This is a digitally signed message part