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.
Thanks for your work on git-buildpackage!
--dkg
signature.asc
Description: OpenPGP digital signature
