Scott Kitterman writes ("Re: tag2upload service architecture and risk
assessment - draft v2"):
> I sometimes use who-uploads from devscripts when I want to find out who
> actually did an upload. In theory, it could be re-written to support
> whatever.
As I mention in my other mail, that's the last entry in my table,
about existing things which look at the .dsc signature getting it
wrong. And yes this would need to be fixed.
> I also check that the signature validates when I download a package
> from the archive. I like the fact that this signature connects to a
> developer key in the keyring.
You presumably don't really notice when it doesn't so connect ?
I guess you (like everyone else) have your tools set to carry on
regardless in that case, because otherwise you will run into failures
(and I don't know what a sensible recovery strategy would be) ?
> That said, I'm not the one who suggested losing this would be a
> problem in the previous thread, so I can't say what they were
> thinking. I just don't think the threat assessment is a serious
> response to what people were suggesting. It would be a mistake to
> assume silence is concurrence.
Do you think my risk assessment is "not a serious response" because I
have missed lots of other things too ? Presumably you don't think
this it is wrong to try to understand what the actual fears are that
motivate the comments.
Maybe I communicated poorly the link between the mailing list mails
and my risk assessment. Do you feel I should have dealt with the
mailing list thread by taking each comment and making a little
subthread ? I could go back and do that of course. I'm not sure it
would be very welcome.
(I'm really not happy to have something I spent some care on, and
which I tried to do with integrity, described as "not a serious
response".)
> I may be wrong, but I think Ian's made up his mind what he wants to do, so
> there's not a lot of point in convincing him otherwise.
Well, it's fair to say that I am reasonably convinced that something
roughly of this shape should be deployed. We need the convenience and
integrity benefits of officially using and publishing the git format
which most of us are unofficially using and unofficially consider
primary.
For the reasons which were explored in Vaumarcus and resulted in the
current design, I think something like my proposal is the only
realistic approach. If you need additional evidence that this is the
case, consider that no other approach has got anywhere beyond mailing
list handwaving - and we have wanted to solve this problem for at
least half a decade.
But that's not to say that I'm not willing to make changes. The draft
that was posted here was already changed significantly from a version
which was reviewed privately by an independent member of a
security-related Debian core team. That private review resulted in
significant changes, notably the addition of privsep. (As a result,
that privsep is the substantial part which is not yet implemented.)
The review of my public v1 draft resulted in my proposals for
facilitating double checks by dak, and general improvements to
traceability.
Ian.
--
Ian Jackson <ijack...@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.
