Re: tag2upload service architecture and risk assessment - draft v2
On Tuesday, August 27, 2019 1:19:14 PM EDT Ian Jackson wrote:
> 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/
I haven't gone back and re-read the previous thread, but I did look at the
risk assessment and I don't find it a serious response to concerns people
raised.
As an example, I recall concerns about there not being an uploader signature
on the source anymore, so we would lose the ability to verify from the archive
who was responsible for the upload.
To the extent I can find it in the risk assessment at all, I suspect you called
it:
> Data needed to understand where the .dscs came from might later, become
> unavailable.
and you describe it as a feature. I really don't know how to respond. I
expect technical concerns don't weigh heavily when you're on a moral crusade.
Scott K
Reply to: