On Wed, Mar 27, 2013 at 01:55:47PM -0400, Daniel Kahn Gillmor wrote: > Hi Guido-- > > Thanks for your prompt and thoughtful response, i appreciate it! > > git-buildpackage helps me a lot because it encodes standard workflow > decisions and operations so i don't have to think about them. without > this fix, i have to work around git-buildpackage and do more things > manually. > > On 03/26/2013 06:47 PM, Guido Günther wrote: > > > We had a complained that this is already too much information (juat > > cp.version was deemed enough). > > Who made this complaint? Is it public? > > When i make cryptographic signatures, i consider it important that those > signatures can be successfully interpreted in a context-independent > manner. That is, if the same signature was presented in a new place, it > should not change its interpretation. The data being signed needs to > contain its own context explicitly and unambiguously. For example, i > would not sign an e-mail if the entire body was: "Yes, I think this is a > good idea." because the message could be trivially replayed in some > other e-mail conversation to imply my agreement with an idea that i > might not actually agree to. > > It is critically important that any tool that makes automated signatures > on my behalf respects the same context-independence constraint. > > > Given that he has commit access to that repo. > > There are lots of ways that an attacker can gain access to a repo > without having legitimate commit privileges. Some git repositories are > accessed in the clear (e.g. via git:// or http://), so anyone in control > of the network could spoof the repo; An attacker could compromise > another developer's account; and so on. > > The point of having signed tags is that *it doesn't matter* who has > access to the repo. The entire communications infrastructure could fall > apart or leak like a sieve and you could still verify whether the tag > was made by one of a list of trusted individuals, and what they intended > by the tag. > > > Assuming you don't check that the commit you build can reach the > > debian branch head. > > The debian branch head can be moved to any commit in the repo by someone > with control over the repo. > > I agree that it's possible that some automated systems will have an > fingers-crossed boostrap phase and then only accept fast-forward merges > before attempting a rebuild, but not all of them work that way, and > given that we have cryptographic authentication possible, we shouldn't > have to cross our fingers during the bootstrap phase or require > fast-forward merges anyway. > > > I'm not convinced that this helps an automated build system. Isn't this > > just a hint (that can be enforced by a commit hook). It certainly eases > > the detection that the commit belongs to the package. > > It doesn't ease the detection -- it makes that detection possible. > Without it, there is no way to cryptographically guarantee that the tag > you're looking at was intended for the project you expect. > > > But if we're > > really after security here we should also document a proper setup for > > automated builds, otherwise the fix isn't useful as is. What workflow is > > on your mind? > > I agree that it would be good to have some best-practices documentation > for folks who have automated build farms. I don't believe that this fix > should wait on that documentation. The fix enables the documentation to > be written, not the other way around. > > I'm not trying to claim that this bug makes the signed tags completely > worthless; any human who actually examines a repository and is willing > to think about it would see that a transplanted signed tag is pretty > fishy. But (a) i want signed tags to be usable by machines which are > much worse at detecting "fishiness", and (b) not all humans think this > stuff through.
Convinced and pushed. Thanks for your patch! -- Guido > > Thanks for your work on git-buildpackage! > > --dkg >
signature.asc
Description: Digital signature
