Re: tag2upload service architecture and risk assessment - draft v2

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Scott Kitterman writes ("Re: tag2upload service architecture and risk assessment - draft v2"):
> This is an example of where I struggle with 'assume good faith'.

I'm sorry.  I really am trying.

Although I have found it difficult at times, I think our conversation
here is valuable.  You have made some very cogent points.

I don't want to leave concerns unaddressed.  Nor do I want people to
feel their concerns are unaddressed.  I think you are helping.

> Several time people have said they feel it's important to be able to
> verify from contents of the archive.  Your response seems to me a
> consistent 'meh, not important'.

That's not my own attitude and I don't want to come across that way.

When I wrote, in the mail you are replying to:

  These kind of considerations are why in my proposal the .dscs are
  reproducible from the uploader-signed git tags.

  Tracing the archive contents back to uploader signatures is already
  complicated because of the difficulty of understanding what an
  appropriate maintainer signing key is for any particular .dsc.  With
  my proposal it indeed becomes more complicated.

I was trying to acknowledge those desires and explain how my proposal
tries to satisfy them.  I was also trying to acknowledge that indeed
there is a downside here: tracing the published source contents back
to the uploader's signature does become more complicated.

On the other hand I think it is only fair for me to point out that
this is very much a minority activity, and that any such activity
conducted right now will experience verification failures and/or need
fallback to old keyrings, so it's already complicated and unreliable.

I don't know how to make those points without sounding like "meh, not
important" as you put it.  I've said that these desires are important
enough that I'm planning put work in to support them - for example, by
arranging for .dscs to be reproducible (and for that to be tested).
That's not a trivial amount of effort.

And, somewhat separately: Yes, quite a few people in this subthread
(and elsewhere) have talked about needing the uploader identity.
Obviously that has to be widely available and easy to get hold of.
Most (admittedly not all) of those people didn't seem to have a need
for verification independent from the archive: so that's an easier
case, and their needs are met by the tag signer info which I propose
to include in the .dsc.

Does that all make some kind of sense ?

> My view of this seems to come from the opposite perspective of yours.  A git 
> commit is a reference to a set of code at a given time.  What the uploader 
> intends to release is not "some git commit".  It's code.  The fact that it's 
> in git or not is a minor implementation detail.

You are right that the uploader intends to release code.
I obviously didn't express myself clearly.

The question I was trying to pose is this: when the uploader decides
to make a release, what do they have in mind as their idea of
*what code* they wish to release ?

Nowadays with most existing git workflows, what the uploader has in
mind for "what code am I going to release" is "the tip of my master
branch".  Not "my working tree as it is now" (since no-one releases
without committing, and if the working tree contains untracked files,
they mean to release only what is committed).  And not "this .dsc"
(because the .dsc doesn't even exist at that point - it is generated
after the user instructs their computer to make the release).

So I am contending that, at least for gitish users with gitish
workflows, when the user says to themselves "let us ship this", by
"this" they are thinking "my git HEAD" or "my git master" or some
such.  This is one reason why the existing Debian git tooling all
makes appropriate signed git tag(s).

If I am right about the uploader intent - and I think for most
uploaders nowadays I am - tracing a .dsc back to some signed statement
of the uploader's intent means tracing back to the uploader's git tag,
not just to a signed .dsc.

So while I acknowledge people's desire to trace the .dsc back to the
original uploader, I'm trying to point out that for maay purposes
that's not really sufficient.

> Today the authoritative repository for what's in Debian is the
> package archive.  My read is you want to change it so that the
> package archive is an implementation detail hanging off of a set of
> git repositories and I am not at all comfortable with this concept.

Unfortunately, the archive is already no longer fully authoritative.
People using gitish workflows already treat it as an output format.
Now you may say that people shouldn't do that, but I think it is now a
majority practice within Debian.

One of the things I am trying to do here is make sure that the archive
and the published git actually correspond.

My approach is to try to make it convenient to verifiably and
reproducible and reliably publish the same thing to both the
maintainer's git view (which the maintainer regards as primary) and
the public archives (which the rest of the project, and downstreams,
regard as primary).

> Your proposal completely changes the notion of what our package
> archive is

I can see that that is one way to look at it.  As I say above, I think
that this change is already well under way, in an uncontrolled and
fashion.  But, yes, my proposal could be seen as formalising it.

> while, IMO, pretending to be something else.

I certainly don't want to pretend anything that isn't true.  Where
would be the best place for me to deal with this more explicitly ?

Maybe in my intro web page or as a paragraph in the risk assessment
document ?

> I don't necessarily assume bad faith, but it feels like you are so
> convinced of the righteousness of your approach that you are having
> trouble taking concerns seriously.

I have spoken to a lot of people who all very much want to upload to
Debian just by signing and pushing a git tag (and, implicitly, without
messing about with tarballs etc.).  Being able to do that would take
away large amounts of friction from many people's workflows.
That's one reason why I think this is important.

I have thought about these matters a lot and it is true that I am by
now convinced that this cannot be achieved other than with something
roughly like my approach.  And I don't think it can be achieved
without raising the same concerns as we see here.

> I think I don't have a lot more to contribute on the topic.

I would appreciate it if you would help me further with your frank
criticism.

Thanks,
Ian.

-- 
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.