Re: tag2upload service architecture and risk assessment - draft v2
Bastian Blank <waldi@debian.org> writes:
> On Tue, Aug 27, 2019 at 05:04:06PM -0700, Russ Allbery wrote:
>> I think this requirement is a bit incomplete, in that I don't
>> understand the use case that would lead you to want to do this. It's
>> more of a description of an implementation strategy than a use case,
>> which makes it hard to find other ways of accomplishing the same use
>> case.
> We don't want to be forced to trust ftp-master. We have reproducible
> builds to verify the content of binary packages. We have the user
> signatures to verify source packages. Of course none of this are
> foolproof or will work all the time.
I get that part. What I'm trying to understand is why. What is the
underlying goal that you feel you are accomplishing by being able to
independently cryptographically verify the uploader of a *.dsc file? When
would we do that independent verification, and why would we do it?
I think this bit from earlier in your message may be the answer:
> Yes, I did in the past complete security archive checks against
> signatures, both on the advisories when they still contained checksums,
> and the dsc signatures.
So you're using this as a audit and detection strategy to discover whether
someone managed to compromise ftp-master in the past without us detecting
it?
The reason why I'm trying to get at the use case is that we're paying a
fairly high technical cost in order to publish cryptographic signatures on
the *.dsc file made by the maintainer. As long as this is a requirement,
we're blocked from a large number of possible designs that would treat the
Git repository as more of a first-class citizen in our development
process. This isn't just Ian's tag2upload proposal, but also many other
potentially useful designs. Consider, for instance, being able to do
automated source NMUs for archive-wide minor source problems the way that
we can do binary NMUs to trigger rebuilds. Or suppose that I want a
Debian package to be *truly* team-maintained so that any Debian Developer
can merge PRs and then, if automated tests pass, the resulting package is
automatically uploaded to the archive.
I understand that each of these ideas is in itself controversial, and many
of them we may never want to do for other reasons, and I'm not saying
anyone is going to work on doing these things tomorrow. But I want to dig
in a bit on why published cryptographic signatures on the *.dsc files by
DDs are so important to you, since I think it blocks an entire branch of
solution space.
Therefore, looking more deeply at what problem you're trying to solve
(independently verifying the signatures isn't itself the problem, it's an
implementation strategy for solving some as-yet-unstated problem) is
useful because it lets us see whether there's another possible way to
solve the same problem or if this really is the best approach (with, to be
clear, a bias towards the existing approach because we've already
implemented it).
> Right now the team delegated to keep the archive running and safe is not
> willing to drop the ability to verify the contents independently.
What I'm hoping for is an open design discussion where everyone is
prepared to have their minds changed. I'm also trying to tease apart the
reasons *beneath* the invariants that you're trying to maintain. In any
system that's been around for a long time, there are some long-term
invariants that turn out to not be as useful as people think they are, and
are worth thinking about dropping to allow more design flexibility. I'm
not saying that this is definitely one of those, but I think it's worth
discussing.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: