Re: tag2upload service architecture and risk assessment - draft v2
Ian Jackson writes ("Re: tag2upload service architecture and risk assessment - draft v2"):
> [stuff]
Argh. A bunch of people helped me refine this but I sent an early
draft by mistake. I guess it's too late to hope people will read only
the better version, but here it is anyway.
If you haven't read the first one yet, please prefer this one.
Sorry,
Ian.
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, so 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 seemed 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 rather than a set of concerns, as you put
it, Bastian has some hard design demands. I didn't mean to cause
offence; I was trying to focus on the exact nature of the problems
these requirements are intended to solve.
>From my reading of the thread, it seems that 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 [1], the conversion occurs on a DSA-managed machine
using fully controlled software, with a copious audit trail.
This contrasts starkly with currently leading approaches for git-based
packaging: currently .dscs are produced from git data by uncontrolled
git-buildpackage runes run on uploader's own systems (not even in a
clean environment, usually). So my proposal is far superior to 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 (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 find 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.
[1]
See upthread for more, but the key reference is this
https://people.debian.org/~iwj/tag2upload/2019-08-20/
--
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.
Reply to: