Re: tag2upload service architecture and risk assessment - draft v2

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Sam Hartman writes ("Re: tag2upload service architecture and risk assessment - draft v2"):
> I do think it would be valuable to confirm whether we're at an impasse.
> It sounds like Ian may think that resolving your concerns would be a
> no-go

I'm definitely trying to have a constructive discussion about the best
design, what the risks are of various approaches, etc.

Indeed I have been trying to resolve people's concerns.  The concerns
were almost all about archive integrity, and I have tried to analyse
the actual risks, and where appropriate propose control measures for
those risks.

My intent was not to ignore Bastian's requirements but instead tease
out the risks that they were aimed at, and make constructive
evaluations of those.  It thought it was reasonably clear what risks
Bastian was concerned with, but I had hoped Bastian would help me out
where I had misunderstood.

Unfortunately it seems that Bastian doesn't have "concerns" as you put
it.  He seems to have hard design demands.  He appears to be offended
that instead of accepting what he sees as non-negotiable requirements,
I have attempted to explain why I disagree with them.


>From my reading of the thread, I think there are two disputed design
demands, which are related.

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

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

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

Furthermore, there is nearly no benefit in redoing this mapping.  In
my design proposal, the conversion occurs on a DSA-managed machine
using fully controlled software, with a copious audit trail.  This is
far superior to the current situation, where .dscs are produced by
uncontrolled git-buildpackage runes run on uploader's own systems (not
even in a clean environment, usually).  So my proposed design is much
better than the status quo.

In principle it would be possible to satisfy this demand.  The
tag2upload service could ship the git data to the archive, bundled
with the .changes (as a git bundle perhaps).  The archive would then
re-run the source package generation (perhaps using the reproduction
script that my proposal already includes), and compare the results.

So this is negotiable, although this seems to me like a silly
direction to be going.  And it would likely involve a long delay to
deployment if the extra dak rebuild machinery were to be regarded as a
blocker.


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

Again, I have analysed the SHA-1 risk in my risk assessment.  So here
too I have explained why I don't think this is an appropriate
requirement to place on the tag2upload service.  We have already
accepted the SHA-1 risk; the mitigations we have are (including the
code in git which deals with at least the known collision attack) are
tolerably sufficient.

The tag2upload proposal doesn't make it worse; in some ways it is
slightly better because git object data comes from a central source
(salsa) rather than the maintainer's machine.

I think this demand cannot be met by anything I would call a "tag to
upload" system.  The tag data would have to contain some kind of file
manifest.  The tag would not be constructable by normal tooling, but
only by a special program.  It would not be simply a git tag.


> and that you think that his design is a no-go.
> Confirming whether that's true would actually be valuable.
> I think the ball is probably in Ian's court on that issue.

I was hoping for constructive engagement with the substance of the
arguments I am making.  I found it difficult to see where to go from
Bastian's most recent message, in which he seemed to me to say he had
been laying down non-negotiable demands and was offended that I
disagreed.


> I also think it would be very interesting to get Joerg's personal
> opinion on designs in this space because it sounds like he's thought
> about it for a while.

I would definitely welcome wider engagement with the substance of the
risks, the design tradeoffs, etc.


>  One of the factors we as a project will consider is whether other
> implementations emerge or whether Ian is the only one who will
> choose to implement in this space.

I would like to point out that tag2upload is by no means all my own
work.

The original design approach (from Vaumarcus) for a Debian git
transition was a joint effort (mostly with Joey), and there are other
contributors to src:dgit (Sean has been invaluable and of course wrote
git-debpush).

Also much of the heavy lifting in tag2upload is not done by src:dgit
itself.  In particular, much of the git patch queue manipulation is
done using tools from src:git-buildpackage.


Thanks,
Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.