On Thu, Mar 31, 2016 at 02:39:41PM -0000, Ralf Senderek wrote: > Zbigniew Jędrzejewski-Szmek wrote: > > I don't buy that reasoning. You sign stuff to prevent silent > > modification (because of malice or corruption), and not to track > > changes, we have better mechanisms for that. > > Signing is much more than an integrity proof for which hash values would > suffice.The fact that some upstream sign their code (in particular when > the code is security critical) means that they're willing to take > responsifility for > the code in the form "they signed it off". It is sometimes very easy to ruin > a secure system by modifying it (with a patch or some code in the spec file > doesn't matter). That's why I thought it might make sense for the packager > to take responsibility for his modifications by signing them.
Packagers already take responsibility for their modifications by committing under their name. We have a mechanism of secure transmission of dist-git changes (using ssh), so we don't need GPG signatures to trust what we download from dist-git. We could go a step further, and require gpg signatures for commits to dist-git. This could serve as an additional verification step that maintainer credentials have not been compromised. But that's another discussion, and I'm not sure that gpg signatures would be the best way. Maybe two factor auth for dist-git would be better. We already have that in place, and we could talk about making it mandatory, at least for some important packages. That subject is orthogonal to current discussion though. > The changelog don't really reflect the modifications in enough detail. Yes, changelogs are a terse overview. Use 'git log -p' for the details. But the signature doesn't reflect the modifications at all (apart from a hash of the final version), so I don't see the relevance. Zbyszek -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
