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.