Re: tag2upload service architecture and risk assessment - draft v2

[Sam Hartman <hartmans@debian.org>]

>>>>> "Ian" == Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

    Ian> From my reading of the thread, it seems that there are two
    Ian> disputed design demands, which are related.

    Ian> The most basic demand is that the archive should be able to
    Ian> verify the whole contents of the .dsc, given data signed by the
    Ian> user.

    Ian> The risk assessment explains why I don't think this is an
    Ian> appropriate requirement, but I will go through it again:

    Ian> The mapping from git tag to .dsc is nontrivial.  git tag to
    Ian> .dsc construction (or verification) is complex and offers a
    Ian> large attack surface to the incoming source code.  It ought not
    Ian> to be done near a powerful key such as the dak master archive
    Ian> signing key.

It's nontrivial in your design.  It sounds like in Ansger's approach
where effectively all the data you need for the dsc is included in the
tag, it would be a lot more trivial.  Obviously that design fails to
give you some things you value.  But it seems to me at least that if you
are willing to do significantly more work on the tagger's computer you
can make tag to dsc verification a lot simpler.

Also, I think the question of whether third-parties should be able to
verify that a dsc was properly generated without going back to a git tag
is interesting.

    Ian> The second demand (or the second aspect) is that all of this
    Ian> verification, by the archive, should be doable without relying
    Ian> on the git SHA-1 object system.


If we get down to a point where this is a major issue, I'm happy to step
in as someone who has a lot of protocol security design experience and
reach out to other Internet security experts for their review.  I could
explain why I think relying on Git's integrity mechanisms for verifying
the authenticity of objects stored in Git (which is exactly what you are
doing) is a reasonable thing to do from a security standpoint.  My
answer will look a lot like Russ's answer.

I understand why SHA-1 looks worrying, and I was initially worried.  I'd
need to do a bit more review before I'd feel comfortable doing a write
up on this, but I think Russ's analysis is looking fairly good from
where I sit now.