Scott Kitterman writes ("Re: tag2upload service architecture and risk
assessment - draft v2"):
> 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.
I'm sorry you feel like that. But thanks for at least reading it.
> 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.
I think I must have read those comments as being solely from the point
of the archive. This is perhaps because I think it is very difficult
to do any kind of post-hoc verification of .dsc signatures: to make
sense of whether a signature is appropriate, you need reliable
information about who was a DD or DM (for each package) at what time.
So I focused on the need for the *archive* to verify things.
So you are right that this point is not captured in my risk
assessment. As I said in the mail at the top of this thread:
| I may well have missed something. Please let me
| know if you think there is anything which is not covered.
Note that verifying .dsc signatures is not an end in itself; it is a
means to some end. The question for me then is what end. There were
some useful answers in this thread.
If I were to add this to the risk table, it would probably look like
this:
Risk
It might be no longer possible to for third parties to usefully
verify the .dsc signature, and thus verify the archive operation and
see who was responsible for the upload.
Degree to which accepted in existing arrangements
Verifying the archive operation is already difficult because .dsc
signatures are valid in the context of an uploader's status as DD/DM
at the time: signature verification may involve using old keyrings,
expired keys, etc.
Control measures and mitigations
Information about the uploader's key identity is included in the
.dsc. The uploader's original signed git tag is permanently
archived (by Debian on a designated server).
Analysis; notably, additional risk?
When the uploader used tag2upload, verification of original
uploaders' signatures will involve obtaining and verifying the
signed git tags; this is additional inconvenience for an
already-unreliable and rarely-done activity.
Would that make sense ? Do you disagree with this characterisation or
analysis of the issue you are raising ?
The question of simply knowing who did the upload (eg, you mentioned
who-uploads from devscripts) is much easier and is more or less dealt
with already under this existing entry:
Communications (eg emails and tracking web pages) which currently go
to (or for the attention of) the signing uploader might go to the
wrong place.
(last entry in the table). Maybe I need to broaden the wording here,
maybe adding "or which refer to" ?
> > 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 don't think that can really properly cover the issue you mention
above, about .dsc verification.
> I expect technical concerns don't weigh heavily when
> you're on a moral crusade.
Maybe you could assume good faith ? For example you could assume that
I had missed something, as I said I might have done, rather than
implying that I am deliberately missing things out and then shouting
at me. :-(.
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.
