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.