Re: tag2upload service architecture and risk assessment - draft v2

[Ian Jackson]

Holger Levsen writes ("Re: tag2upload service architecture and risk assessment 
- draft v2"):
> On Wed, Aug 28, 2019 at 05:07:00PM +0100, Ian Jackson wrote:
> > In my proposal the source package is reproducible (in the
> > "reproducible builds" sense) from the uploader's signed git tag.  
>  
> i'm confused. 'reproducible builds' is about creating bit by bit
> identical binaries from a given source.
> 
> if you are talking about re-creating bit by bit identical source
> packages, that's fine, but nothing within the scope of reproducible
> builds.

Sorry for the confusion.  When I wrote

  reproducible (in the "reproducible builds" sense)

I wasn't saying that this is somehow part of, or within the scope of,
the reproducible builds project.  I was just clarifying what the word
"reproducible" meant in my sentence: I am using the word
"reproducible" the same way that the reproducible builds project uses
it - ie I am borrowing that definition of reproducible.  (That's what
"X (in the Y sense)" means.)

I was indeed clarifying that I do mean bit-by-bit identical.  In this
case, bit-by-bit identical dsc (apart from the signature of course),
from (i) git tag (ii) _source.buildinfo containing tools versions etc.

> also, as a side note, we have tried to reproduce bit by bit identical
> source packages, failed and moved on. it didnt seem trival when we
> tried.

I remember some of those discussions.  I'm pretty sure it's possible
in my context, although there are as you say some difficulties with it
in the wider reproducible builds context.

I hope that helps.

Thanks,
Ian.

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

Re: tag2upload service architecture and risk assessment - draft v2

[Holger Levsen]

On Wed, Aug 28, 2019 at 05:07:00PM +0100, Ian Jackson wrote:
> In my proposal the source package is reproducible (in the
> "reproducible builds" sense) from the uploader's signed git tag.  
 
i'm confused. 'reproducible builds' is about creating bit by bit
identical binaries from a given source.

if you are talking about re-creating bit by bit identical source
packages, that's fine, but nothing within the scope of reproducible
builds.

also, as a side note, we have tried to reproduce bit by bit identical
source packages, failed and moved on. it didnt seem trival when we
tried.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: tag2upload service architecture and risk assessment - draft v2

[Ian Jackson]

Joerg Jaspert writes ("Re: tag2upload service architecture and risk assessment 
- draft v2"):
> First off: I, for personal reasons, am a bit detached right now with
> anything Debian (though that should change soon). For that reason, I
> haven't read most of the mail threads, though i skimmed over this
> one a bit.

Hi.  Thanks for your attention.

> I currently do not have too deep a thought on how good their
> implementation is. Just one thing I've seen picked at multiple times,
> and in different places: The current implementation appears to move away
> the final integrity check linking an upload to a person away from the
> archive software to some other.

I don't think that's really true, although I can see why you might
think it from reading the thead.  I will try to explain.

> Thats a no-go.
> 
> Note: I do not say it must be "a dsc" "a git commit" or "a something"
> that is used for this check. That is an implementation detail. But the
> final check/link of an upload with a maintainer(s key) has to be "in"
> the archive. Systems before it can *additionally* do any number of them,
> but the final one is in dak.

In my proposal, as soon as dak supports it, each upload from the
tag2upload service would include a copy of the original uploader's
signed git tag object.

This would allow dak to verify the identity of the original uploader,
and the uploader's intended source package, version, suite, and
distribution; and see that they intended to use the tag2upload
service.  All of that is covered by the original uploader's signature
on the git tag object and can be checked very simply without further
data.  Based on what's been said in the thread I imagine that dak
would want to check all of these things.

The difficulty is that it is complicated to verify the *contents* of
the source package.  (It wasn't clear to me, from your mail, whether
that is something you think is critical for dak to do.)

It would be *possible* for dak to verify the contents, since the .dscs
generated by the tag2upload service are reproducible.  But it's not
easy.

Firstly, it depends on additional data: the referenced git objects
have to be obtained.  (There is at least a designated place to get
them, so finding them is not a problem.)

Secondly, it is a complicated process, because it is reproducing the
complicated mapping between maintainer git branches (which may be in a
variety of forms - see my git packaging practices survey [1]) and
uploaded .dscs (which must be in a standard form).

So to do that reproduction dak would have to effectively have another
instance of the tag2upload infrastructure within it.  Overall I don't
think this would make sense, even though it's possible.

I hope that clarifies things.

Thanks,
Ian.

[1] https://wiki.debian.org/GitPackagingSurvey
  Not all of these are supported by tag2upload yet, but the most
  common ones are.  The biggest one which is missing is the monorepos.
  They present additional difficulties because the maintainer tag name
  must include the package name, so can't conform to standard gbp or
  DEP-14 practice.

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

Re: tag2upload service architecture and risk assessment - draft v2

[Raphael Hertzog]

Hi,

I reviewed the whole thread and the point of friction is the requirement
to sign the .dsc file to make sure that the source package matches what
the maintainer intended to upload. Ian doesn't want the maintainer to have
to deal with the .dsc and the ftpmasters wants to have a signature within
the archive to verify that the code that we build is the code that the
maintainer wanted to ship.

I have a proposal to get out of this impasse.

1/ When the maintainer generates the git tag, he will sign the tag
   but he will also sign the output of "git ls-tree -r HEAD"
   and that signature is stored in the tag long description.

   This signature will be the basis of the trust that ftpmaster are
   looking for.

2/ tag2upload constructs a .dsc that embeds a new field where the
   output of "git ls-tree -r HEAD" is provided (let's call it "Content")
   and a second field with the signature of the maintainer (let's call
   it "Content-Signature"). tag2upload signs the .dsc as a whole with
   its own key.

3/ "dpkg-source -x" is modified to remove any file that does not appear
   in the "Content" field. It could warn about missing files too (and maybe
   silently ignore for a few common files that are usually not part of the
   "make dist"). It could also verify the checksums and complain if they
   don't match.

4/ dak is modified to also verify the signature in "Content-Signature"

5/ profit, everybody should be happy.


Comments are welcome, obviously.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: tag2upload service architecture and risk assessment - draft v2

[Joerg Jaspert]

On 15508 March 1977, Sam Hartman wrote:

First off: I, for personal reasons, am a bit detached right now with
anything Debian (though that should change soon). For that reason, I
haven't read most of the mail threads, though i skimmed over this one a
bit.


Scott> Your proposal completely changes the notion of what our
Scott> package archive is while, IMO, pretending to be something
Scott> else.



During the DPL campaign, a number of people, including Joerg, made
statements that I interpreted as explicitly wanting to make this change.
That is, they wanted to move our authoritative source format to Git,
possibly even getting rid of dscs in the medium future.


Yes.


Now we all get to think about it and decide how their implementation
experience influences whether we think it is a good idea.


I currently do not have too deep a thought on how good their
implementation is. Just one thing I've seen picked at multiple times,
and in different places: The current implementation appears to move away
the final integrity check linking an upload to a person away from the
archive software to some other.

Thats a no-go.

Note: I do not say it must be "a dsc" "a git commit" or "a something"
that is used for this check. That is an implementation detail. But the
final check/link of an upload with a maintainer(s key) has to be "in"
the archive. Systems before it can *additionally* do any number of them,
but the final one is in dak.


At least in my mind, this is all predicated on believing that moving
away from today's dscs toward git as authoritative source is actually a
good idea.
If you don't believe that, then you're never going to like this proposal
at all.
I guess you could decide you want tag2upload somehow even though you
don't want that transition.
I personally don't see how you get there unless you buy into the idea of
moving toward git as source.
Also, I want to make it clear that the DPL campaign didn't establish a
project direction.  It established enough interest that the idea was
worth exploring.
I'm not saying that because people brought this up in the campaign,
we've somehow decided to make a change.
I'm also not saying that this is somehow a DPL issue because it happened
in the DPL campaign.


I do like (as I stated in the past too) to move to something more git
like. I still want to keep the link between upload and maintainer in the
archive. I am sure that is achievable somehow. It may require one more
roundtrip with the maintainer for a signature.

Also, note that entirely relying on git for stuff introduces us back to
sha1, something the archive got rid of. Going backwards doesn't seem to
be a good idea?!

--
bye, Joerg

Re: tag2upload service architecture and risk assessment - draft v2

[Russ Allbery]

Bastian Blank  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 (r...@debian.org)   

Re: tag2upload service architecture and risk assessment - draft v2

[Ian Jackson]

Russ Allbery writes ("Re: tag2upload service architecture and risk assessment - 
draft v2"):
> For who-uploads, I think you just need a trusted metadata store somewhere,
> and recovering this from the PGP signatures on *.dsc files is not a great
> trusted metadata store (among other things, it's tedious and complicated
> to search).

Also, my proposal includes the original uploader information in
additional .dsc fields.  So wouldn't be hard to teach existing
machineries (which look at the .dsc signer) to use the new
information, and there is no actual need for a new database anywhere.

> The cryptographic binding becomes important if we for some reason don't
> trust archive upload records maintained by DAK, and I'm not sure of a use
> case for that.

In my proposal the source package is reproducible (in the
"reproducible builds" sense) from the uploader's signed git tag.  That
is admittedly less convenient to verify than the just checking the
.dsc signature.

Ian.

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

Re: tag2upload service architecture and risk assessment - draft v2

[Russ Allbery]

Tobias Frost  writes:

> Not sure if I understood this correctly, but the MIA team (via echolon?)
> uses the information to tell us if there is an upload from a prossible
> MIA person. (IOW the person is still active.)
> I also use who-uploads occasionally to see if a sponsor knows about
> where-abouts of some possible MIA persons.

One of the things I'm trying to understand is if the cryptographic
signature part is important, or if metadata about who uploaded a package
last without a cryptographic binding to the *.dsc file would solve the
same use case.

For who-uploads, I think you just need a trusted metadata store somewhere,
and recovering this from the PGP signatures on *.dsc files is not a great
trusted metadata store (among other things, it's tedious and complicated
to search).

The cryptographic binding becomes important if we for some reason don't
trust archive upload records maintained by DAK, and I'm not sure of a use
case for that.

-- 
Russ Allbery (r...@debian.org)   

Re: tag2upload service architecture and risk assessment - draft v2

[Bastian Blank]

PS: Please stop sending my copies of e-mails, I explicitely ask not to
by specifying Mail-Followup-To.

Hi Ian

On Wed, Aug 28, 2019 at 12:10:44PM +0100, Ian Jackson wrote:
> 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.

I have no idea what you are talking about.  We have keyrings, we have
other information.  If the .dsc is signed by a person, you can verify
it.

> With
> my proposal it indeed becomes more complicated.

Then make it less complicated?

> But I have to ask:
> Is the uploader signature on the .dsc really the thing we want to
> trace the .dsc back to ?  Usually nowadays the uploader .dsc signature
> is made on the output of some git-buildpackage rune (or automatically,
> by that rune).

Yes.  So he certifies that he wants to upload exactly this version of
the code, not something else.  And that is exactly what we are talking
about: do we have exactly the same source as intended by the uploader.

> Typically the human uploader doesn't intend to release some particular
> .dsc; that's an output artefact.  The uploader intends to release some
> git commit.

No, he wants to release a particular version of the code.  Git is just a
transport medium.

> So the .dsc should be traceable to that git commit.  Currently it is
> not.  With my proposal the .dsc is traceable to the git history,
> including the uploader's signed tag.

Well, providing this information just needs another field in the .dsc,
not overall changes in the process.

Bastian

-- 
There are always alternatives.
-- Spock, "The Galileo Seven", stardate 2822.3

Re: tag2upload service architecture and risk assessment - draft v2

[Bastian Blank]

Hi Sam

On Wed, Aug 28, 2019 at 09:42:56AM -0400, Sam Hartman wrote:
> During the DPL campaign, a number of people, including Joerg, made
> statements that I interpreted as explicitly wanting to make this change.
> That is, they wanted to move our authoritative source format to Git,
> possibly even getting rid of dscs in the medium future.

Maybe they should step up then and we can start discussing the larger
goal.  Because in the end they all need to solve the same problems.

We have to decide what guarantees the Debian archive should provide in
terms of verifyability.  This is however independent from the question
if there is Git involved or not.  And after both npm[1] and rubygems[2]
managed to provide trojaned binaries, it's more pressing then ever.

> At least in my mind, this is all predicated on believing that moving
> away from today's dscs toward git as authoritative source is actually a
> good idea.

What do you mean by "authoritative source"?  buildds should now download
a git repo, checkout the given sha1 and build it?  This means we can now
use gitlab-ci to build it, yeah!

However we often need to ship immutable source for license reasons,
sometimes even near the binaries.  So in some cases we can't refer to an
external Git repository.  How do you suggest we would handle them?

Currently the archive certifies the included source by signing the
Release file.  By retrieving the tar and verifying the checksum you can
be sure you've got the exact source that was included.  Do you know what
you have to do to actually get the same with Git?

> If you don't believe that, then you're never going to like this proposal
> at all.

I even provided the outline of a counterproposal providing almost the
same flexibility, but without sacrifice the current guarantees we have:
converting the git repo reproducibly into immutable source that we can
ship similar to what it is like now.  It just needs a special formatted
and signed tag (plus some source format changes to get rid of
pristine-tar).

> I guess you could decide you want tag2upload somehow even though you
> don't want that transition.

This thread is about _how_ it can be done, not if.

Bastian

[1]: https://github.com/dominictarr/event-stream/issues/116
[2]: https://github.com/rest-client/rest-client/issues/713
-- 
Superior ability breeds superior ambition.
-- Spock, "Space Seed", stardate 3141.9

Re: tag2upload service architecture and risk assessment - draft v2

[Ian Jackson]

Sam Hartman writes ("Re: tag2upload service architecture and risk assessment - 
draft v2"):
> I'm sure that Ian and Sean had been thinking about this before the
> DPL campaign.  But I think in a very real sense, they took that
> discussion and tried to show us what it might look like.

This is much much older than the DPL campaign.

tag2upload is the next stage in the git plan that was developed on the
famous piece of cardboard in Vaumarcus in 2013.  That plan's basic
design principle is *bidirectionally* gatewaying between dscs and git.

> That is, they wanted to move our authoritative source format to Git,
> possibly even getting rid of dscs in the medium future.

I want to be 100% clear that although I think dscs are largely
obsolete, I have no intention of trying to get rid of them any time
soon.  Certainly not in the medium term.  Maybe not in the long term
either.

There are a lot of unresolved issues with getting rid of dscs
completely.  See the recent LFS discussion here on -devel for just one
small example.  There will be packages and uploads where the .dsc is
primary for a very long time, perhaps forever.

Additionally, the social stress of trying to abolish dscs would be far
too severe.  So let's avoid talk of getting rid of dscs.

My goal is to make it possible for git users, and dsc users, to each
have a good user experience and to collaborate with each other.

Part of that is for git users not to have to worry about or think
about dscs.  With the appropriate technology, the worrying about dscs
can be done by computers.  git users can spend their brainpower on
commits and code and packaging.

So tag2upload is an important next step for improving the user
experience of git users, and thus lowering friction in Debian.

The DPL campaign discussions made it look like the time might be
right.  I had lots and lots of positive conversations in Curitiba.
Generally people were super keen and ready with encouragement,
detailed critical review, etc., according to their nature.  My current
proposal includes the results of those conversations.

Ian.

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

Re: tag2upload service architecture and risk assessment - draft v2

[Scott Kitterman]

On August 28, 2019 1:42:56 PM UTC, Sam Hartman  wrote:
>> "Scott" == Scott Kitterman  writes:
>
>Scott> Today the authoritative repository for what's in Debian is
>Scott> the package archive.  My read is you want to change it so
>Scott> that the package archive is an implementation detail hanging
>Scott> off of a set of git repositories and I am not at all
>Scott> comfortable with this concept.
>
>Scott> Your proposal completely changes the notion of what our
>Scott> package archive is while, IMO, pretending to be something
>Scott> else.
>
>Actually, I think that this is so basic to the proposal that it may be
>understated but is obvious and is not being hidden.
>
>During the DPL campaign, a number of people, including Joerg, made
>statements that I interpreted as explicitly wanting to make this
>change.
>That is, they wanted to move our authoritative source format to Git,
>possibly even getting rid of dscs in the medium future.
>
>I'm sure that Ian and Sean had been thinking about this before the DPL
>campaign.
>But I think in a very real sense, they took that discussion and   tried
>to show us what it might look like.
>
>Now we all get to think about it and decide how their implementation
>experience influences whether we think it is a good idea.
>
>At least in my mind, this is all predicated on believing that moving
>away from today's dscs toward git as authoritative source is actually a
>good idea.
>If you don't believe that, then you're never going to like this
>proposal
>at all.
>
>
>I guess you could decide you want tag2upload somehow even though you
>don't want that transition.
>I personally don't see how you get there unless you buy into the idea
>of
>moving toward git as source.
>Also, I want to make it clear that the DPL campaign didn't establish a
>project direction.  It established enough interest that the idea was
>worth exploring.
>I'm not saying that because people brought this up in the campaign,
>we've somehow decided to make a change.
>I'm also not saying that this is somehow a DPL issue because it
>happened
>in the DPL campaign.
>
>As I just mentioned on IRC, I'm spending more time replying to these
>messages than makes sense for the DPL to do.  (My replies are personal
>to the extent that's a thing, but because I'm the DPL any reply I make
>here inherently takes time away from other things.) I think someday the
>DPL might need to get involved in helping make decisions in this space.
>I think that's months or longer away.  So, I'm trying to disengage, but
>doing a terrible job of it.  I guess in part because I see people
>talking past each other.

Okay.  If that's the goal, then let's discuss what that would look like and if 
it's a good idea rather than focusing on implementation details of getting the 
camel's nose inside the tent [1].

Scott K

[1] https://en.m.wikipedia.org/wiki/Camel's_nose

Re: tag2upload service architecture and risk assessment - draft v2

[Ian Jackson]

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 mak

Re: tag2upload service architecture and risk assessment - draft v2

[Sam Hartman]

> "Scott" == Scott Kitterman  writes:

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

Scott> Your proposal completely changes the notion of what our
Scott> package archive is while, IMO, pretending to be something
Scott> else.

Actually, I think that this is so basic to the proposal that it may be
understated but is obvious and is not being hidden.

During the DPL campaign, a number of people, including Joerg, made
statements that I interpreted as explicitly wanting to make this change.
That is, they wanted to move our authoritative source format to Git,
possibly even getting rid of dscs in the medium future.

I'm sure that Ian and Sean had been thinking about this before the DPL
campaign.
But I think in a very real sense, they took that discussion and   tried
to show us what it might look like.

Now we all get to think about it and decide how their implementation
experience influences whether we think it is a good idea.

At least in my mind, this is all predicated on believing that moving
away from today's dscs toward git as authoritative source is actually a
good idea.
If you don't believe that, then you're never going to like this proposal
at all.


I guess you could decide you want tag2upload somehow even though you
don't want that transition.
I personally don't see how you get there unless you buy into the idea of
moving toward git as source.
Also, I want to make it clear that the DPL campaign didn't establish a
project direction.  It established enough interest that the idea was
worth exploring.
I'm not saying that because people brought this up in the campaign,
we've somehow decided to make a change.
I'm also not saying that this is somehow a DPL issue because it happened
in the DPL campaign.

As I just mentioned on IRC, I'm spending more time replying to these
messages than makes sense for the DPL to do.  (My replies are personal
to the extent that's a thing, but because I'm the DPL any reply I make
here inherently takes time away from other things.) I think someday the
DPL might need to get involved in helping make decisions in this space.
I think that's months or longer away.  So, I'm trying to disengage, but
doing a terrible job of it.  I guess in part because I see people
talking past each other.

Re: tag2upload service architecture and risk assessment - draft v2

[Gard Spreemann]

Scott Kitterman  writes:

> Several time people have said they feel it's important to be able to verify
> from contents of the archive.

Hi all,

Please forgive my ignorance if this is stupid, or if it's already been
discussed and I overlooked it. I'm not posing this as a suggestion, but
rather as a way for me to help myself understand the technical aspects
of this very interesting debate better.

Why could there not be specified new (complementary, not superseding!)
formats of .dsc and .changes files wherein those files are not expected
to be signed themselves, but instead are expected to refer to signed git
tags? When ftp-master sees this particular format, it could perform a
shallow git clone of the required tag, verify it, and consider that as
the source of the package. That source object in the archives is then
verifiably from the signer, and requires no intermediate service (apart
from the current problems of people changing keys etc.).

Obviously I'm missing something here, and I feel I'd learn something
interesting if someone could explain.

Thanks, and sorry for the potential small distraction from the
conversation.


 -- Gard

Re: tag2upload service architecture and risk assessment - draft v2

[Scott Kitterman]

On Wednesday, August 28, 2019 7:10:44 AM EDT Ian Jackson wrote:
> Bastian Blank writes ("Re: tag2upload service architecture and risk 
assessment - draft v2"):
> > 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.
> > 
> > Right now the team delegated to keep the archive running and safe is not
> > willing to drop the ability to verify the contents independently.
> 
> 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.
> 
> But I have to ask:
> 
> Is the uploader signature on the .dsc really the thing we want to
> trace the .dsc back to ?  Usually nowadays the uploader .dsc signature
> is made on the output of some git-buildpackage rune (or automatically,
> by that rune).
> 
> Typically the human uploader doesn't intend to release some particular
> .dsc; that's an output artefact.  The uploader intends to release some
> git commit.
> 
> So the .dsc should be traceable to that git commit.  Currently it is
> not.  With my proposal the .dsc is traceable to the git history,
> including the uploader's signed tag.
> 
> Ian.

This is an example of where I struggle with 'assume good faith'.

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

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.

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.

Your proposal completely changes the notion of what our package archive is 
while, IMO, pretending to be something else.

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 think I don't have a lot more to contribute on the topic.

Scott K

Re: tag2upload service architecture and risk assessment - draft v2

[Ian Jackson]

Bastian Blank writes ("Re: tag2upload service architecture and risk assessment 
- draft v2"):
> 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.
> 
> Right now the team delegated to keep the archive running and safe is not
> willing to drop the ability to verify the contents independently.

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.

But I have to ask:

Is the uploader signature on the .dsc really the thing we want to
trace the .dsc back to ?  Usually nowadays the uploader .dsc signature
is made on the output of some git-buildpackage rune (or automatically,
by that rune).

Typically the human uploader doesn't intend to release some particular
.dsc; that's an output artefact.  The uploader intends to release some
git commit.

So the .dsc should be traceable to that git commit.  Currently it is
not.  With my proposal the .dsc is traceable to the git history,
including the uploader's signed tag.

Ian.

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

Re: tag2upload service architecture and risk assessment - draft v2

[Holger Levsen]

On Wed, Aug 28, 2019 at 04:02:32PM +0500, Andrey Rahmatullin wrote:
> On Wed, Aug 28, 2019 at 12:09:41AM -0400, Scott Kitterman wrote:
> > 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.
> I think this doesn't work for e.g. old packages whose last uploader is
> already retired or changed the key.

it does, though nobody said it was easy.

src:debian-keyring is available on snapshot.d.o, so it's possible.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: tag2upload service architecture and risk assessment - draft v2

[Andrey Rahmatullin]

On Wed, Aug 28, 2019 at 12:09:41AM -0400, Scott Kitterman wrote:
> 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.
I think this doesn't work for e.g. old packages whose last uploader is
already retired or changed the key.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: tag2upload service architecture and risk assessment - draft v2

[Ian Jackson]

Sam Hartman writes ("Re: tag2upload service architecture and risk assessment - 
draft v2"):
> Ian Jackson  writes:
> > 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.
> 
> It's nontrivial in your design.

It is true that there are other possible approaches.
Key benefits of the present proposal are:

1. The uploader can continue to use their existing best practice git
   repository layout, their existing git workflow, and so on.  So no
   disruption or degradation of maintainer experience.

2. The Debian ftp archive continues to publish a .dsc like those from
   current best practice approaches.  So no disruption or degradation
   to the experience of downstreams of the archive.

3. tag2upload publishes the git history in accordance with current
   best practices (ie, maintainer view on salsa and dgit view on dgit
   git server).  So no disruption or degradation to the experience of
   current git users.

4. The uploader does not need to work with, or transfer or keep, any
   tarballs (unless this is needed because of upstream practices). [+]

5. The instruction to upload is a plain signed git tag pointing at
   the commit to be released. [*]

1-3 are "no degradation compared to existing approaches".

4-5 are "this is an ordinary git operation, not a bodge where we
 transport other data embedded in git objects".

That the conversion to a .dsc is nontrivial seems to follow directly
from the above objectives.  It arises because existing conversions of
maintainer's git commits to source packages are already complex.

Oh, and of course:

0. It exists.

Ian.

[+] Publishing pristine upstream tarballs would obviously involve
working with tarballs at least some of the time.  It is feasible with
my approach but not yet implemented.

[*] Obviously there has to be some extra information in the tag, such
as instructions about which distro and suite to upload to.  But by a
"plain" git tag we mean that any such information is short and flat
and straightforward, so it could be generated by hand, or by a variety
of tools, etc.

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

Re: tag2upload service architecture and risk assessment - draft v2

[Ian Jackson]

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

Re: tag2upload service architecture and risk assessment - draft v2

[Ian Jackson]

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

Re: tag2upload service architecture and risk assessment - draft v2

[Bastian Blank]

On Tue, Aug 27, 2019 at 05:04:06PM -0700, Russ Allbery wrote:
> Scott Kitterman  writes:
> > 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.
> Does anyone do this?  Does it work today?

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.

> I'm dubious that you would be able to successfully verify all of the
> archive from *.dsc signatures now.  Maybe you would be able to verify the
> pieces that are the most important to you, though?

Still, even if the success rate it not a 100%, do we want to actively
abolish this possibility and reduce it to ~0%?

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

Right now the team delegated to keep the archive running and safe is not
willing to drop the ability to verify the contents independently.

Regards,
Bastian

-- 
Yes, it is written.  Good shall always destroy evil.
-- Sirah the Yang, "The Omega Glory", stardate unknown

Re: tag2upload service architecture and risk assessment - draft v2

[Tobias Frost]

On Tue, Aug 27, 2019 at 05:04:06PM -0700, Russ Allbery wrote:
> Scott Kitterman  writes:
> 
> > 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.
> 
> Does anyone do this?  Does it work today?
> 
> I'm dubious that you would be able to successfully verify all of the
> archive from *.dsc signatures now.  Maybe you would be able to verify the
> pieces that are the most important to you, though?
> 
> 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.

Not sure if I understood this correctly, but the MIA team (via echolon?)
uses the information to tell us if there is an upload from a prossible
MIA person. (IOW the person is still active.)
I also use who-uploads occasionally to see if a sponsor knows about
where-abouts of some possible MIA persons.

> -- 
> Russ Allbery (r...@debian.org)   
> 

Re: tag2upload service architecture and risk assessment - draft v2

[Scott Kitterman]

On Tuesday, August 27, 2019 8:04:06 PM EDT Russ Allbery wrote:
> Scott Kitterman  writes:
> > 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.
> 
> Does anyone do this?  Does it work today?
> 
> I'm dubious that you would be able to successfully verify all of the
> archive from *.dsc signatures now.  Maybe you would be able to verify the
> pieces that are the most important to you, though?
> 
> 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.

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.

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.

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.

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.

Scott K

Re: tag2upload service architecture and risk assessment - draft v2

[Russ Allbery]

Scott Kitterman  writes:

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

Does anyone do this?  Does it work today?

I'm dubious that you would be able to successfully verify all of the
archive from *.dsc signatures now.  Maybe you would be able to verify the
pieces that are the most important to you, though?

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.

-- 
Russ Allbery (r...@debian.org)   

Re: tag2upload service architecture and risk assessment - draft v2

[Scott Kitterman]

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 difficu

Re: tag2upload service architecture and risk assessment - draft v2

[Sam Hartman]

> "Ian" == Ian Jackson  writes:

Ian> From my reading of the thread, it seems that there are two
Ian> disputed design demands, which are related.

Ian> The most basic demand is that the archive should be able to
Ian> verify the whole contents of the .dsc, given data signed by the
Ian> user.

Ian> The risk assessment explains why I don't think this is an
Ian> appropriate requirement, but I will go through it again:

Ian> The mapping from git tag to .dsc is nontrivial.  git tag to
Ian> .dsc construction (or verification) is complex and offers a
Ian> large attack surface to the incoming source code.  It ought not
Ian> to be done near a powerful key such as the dak master archive
Ian> signing key.

It's nontrivial in your design.  It sounds like in Ansger's approach
where effectively all the data you need for the dsc is included in the
tag, it would be a lot more trivial.  Obviously that design fails to
give you some things you value.  But it seems to me at least that if you
are willing to do significantly more work on the tagger's computer you
can make tag to dsc verification a lot simpler.

Also, I think the question of whether third-parties should be able to
verify that a dsc was properly generated without going back to a git tag
is interesting.

Ian> The second demand (or the second aspect) is that all of this
Ian> verification, by the archive, should be doable without relying
Ian> on the git SHA-1 object system.


If we get down to a point where this is a major issue, I'm happy to step
in as someone who has a lot of protocol security design experience and
reach out to other Internet security experts for their review.  I could
explain why I think relying on Git's integrity mechanisms for verifying
the authenticity of objects stored in Git (which is exactly what you are
doing) is a reasonable thing to do from a security standpoint.  My
answer will look a lot like Russ's answer.

I understand why SHA-1 looks worrying, and I was initially worried.  I'd
need to do a bit more review before I'd feel comfortable doing a write
up on this, but I think Russ's analysis is looking fairly good from
where I sit now.

Re: tag2upload service architecture and risk assessment - draft v2

[Ian Jackson]

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

Re: tag2upload service architecture and risk assessment - draft v2

[Ian Jackson]

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, and 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 thought it was 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 Bastian doesn't have "concerns" as you put
it.  He seems to have hard design demands.  He appears to be offended
that instead of accepting what he sees as non-negotiable requirements,
I have attempted to explain why I disagree with them.


>From my reading of the thread, I think 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, the conversion occurs on a DSA-managed machine
using fully controlled software, with a copious audit trail.  This is
far superior to the current situation, where .dscs are produced by
uncontrolled git-buildpackage runes run on uploader's own systems (not
even in a clean environment, usually).  So my proposed design is much
better than 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 are (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 found 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 m

Re: tag2upload service architecture and risk assessment - draft v2

[Holger Levsen]

Dear Bastian,

On Tue, Aug 27, 2019 at 02:41:28PM +0200, Bastian Blank wrote:
> No, you just did a medium break.  Mail is not web, don't do that.  You
> need to at least list the differences.
[...] 
> Sorry, but I don't see how we can go forward, while you seem to be
> either unable to understand what we want to tell you or just decided to
> ignore it.  I don't think it makes sense to continue this discussion
> without a mediator.

the hostility in your mail makes me very sad and want to go away. I believe 
this is your intention :-(


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: tag2upload service architecture and risk assessment - draft v2

[Sam Hartman]

> "Bastian" == Bastian Blank  writes:


Bastian> Please describe the design changes you added to address our
Bastian> concerns.  The risk assessment still lists things we
Bastian> described as no-go.

Bastian> Sorry, but I don't see how we can go forward, while you
Bastian> seem to be either unable to understand what we want to tell
Bastian> you or just decided to ignore it.  I don't think it makes
Bastian> sense to continue this discussion without a mediator.

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 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 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'd really like to find ways to get more experience with tag2upload-like
things.
I've proposed my ideas for running experiments  with the technology in
limited fassions to Ian.
Sadly none of my ideas were all that helpful so far.

Also, if Ansgar is going to implement his solution it would be valuable
to get experience with that.  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.

Ultimately, if we are at an impasse, and we've reached the point where
it's time to make a decision, I do think there is a way forward.  We can
delegate a specific decision (probably something like deciding an
initial policy for archive integrity) to a group of developers.  We'd
want to include members of ftpmaster, people who want something like
tag2upload, and some respected neutral parties to balance things out.
Yes, such a delegation would have power that overlapped with ftpmaster.
That's clearly constitutionally fine, but I also think in a limited
circumstance like a specific decision it is both appropriate and a
reasonable way to break a logjam.

Right now, I think it's too early to do something like that.


signature.asc
Description: PGP signature

Re: tag2upload service architecture and risk assessment - draft v2

[Bastian Blank]

On Tue, Aug 20, 2019 at 06:32:30PM +0100, Ian Jackson wrote:
> Thanks for all the comments on the draft service architecture I posted
> in late July. [1]  I have made a v2, incorporating the various helpful
> suggestions, and the information from the thread.

No, you just did a medium break.  Mail is not web, don't do that.  You
need to at least list the differences.

> Some respondents raised archive integrity concerns.  It seemed best to
> address those more formally, and in a more structured way, than as a
> mailing list subthreads.  Accordingly, v2 of my proposal has a formal
> risk assessment, in a format loosely borrowed from health and safety
> management.

Please describe the design changes you added to address our concerns.
The risk assessment still lists things we described as no-go.

Sorry, but I don't see how we can go forward, while you seem to be
either unable to understand what we want to tell you or just decided to
ignore it.  I don't think it makes sense to continue this discussion
without a mediator.

Regards,
Bastian

-- 
Those who hate and fight must stop themselves -- otherwise it is not stopped.
-- Spock, "Day of the Dove", stardate unknown

Re: tag2upload service architecture and risk assessment - draft v2

[Ian Jackson]

Ian Jackson writes ("tag2upload service architecture and risk assessment - 
draft v2"):
> Thanks for all the comments on the draft service architecture I posted
> in late July. [1]  I have made a v2, incorporating the various helpful
> suggestions, and the information from the thread.

It has been a week.  I'm not sure whether that means people haven't
looked at the linked documents (I guess there might be some tl;dr
going on).

It would be good to get a review of the risk analysis in particular,
hence this ping.  I'd appreciate public follow-ups.

Anyway, I'll leave it at least another week.  If anyone wants more
time than that to properly review my proposal, please let me know when
you expect to be able to respond.

If no-one has any comments, then I intend to use this set of documents
as basis for asking for a formal go-ahead before I do a lot of
implementation work (privsep code etc.)

Thanks,
Ian.

> Some respondents raised archive integrity concerns.  It seemed best to
> address those more formally, and in a more structured way, than as a
> mailing list subthreads.  Accordingly, v2 of my proposal has a formal
> risk assessment, in a format loosely borrowed from health and safety
> management.
> 
> I think I have captured in the risk assessment all the risks mentioned
> in the thread, but I may well have missed something.  Please let me
> know if you think there is anything which is not covered.  Also please
> let me know if any of my analysis seems wrong.
> 
> Please find an introduction, and detailed documentation, here:
>   https://people.debian.org/~iwj/tag2upload/2019-08-20/
> 
> Thanks,
> Ian.
> 
> [1] This message and the subsequent thread:
>   https://lists.debian.org/debian-devel/2019/07/msg00501.html

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

tag2upload service architecture and risk assessment - draft v2

[Ian Jackson]

Thanks for all the comments on the draft service architecture I posted
in late July. [1]  I have made a v2, incorporating the various helpful
suggestions, and the information from the thread.

Some respondents raised archive integrity concerns.  It seemed best to
address those more formally, and in a more structured way, than as a
mailing list subthreads.  Accordingly, v2 of my proposal has a formal
risk assessment, in a format loosely borrowed from health and safety
management.

I think I have captured in the risk assessment all the risks mentioned
in the thread, but I may well have missed something.  Please let me
know if you think there is anything which is not covered.  Also please
let me know if any of my analysis seems wrong.

Please find an introduction, and detailed documentation, here:
  https://people.debian.org/~iwj/tag2upload/2019-08-20/

Thanks,
Ian.

[1] This message and the subsequent thread:
  https://lists.debian.org/debian-devel/2019/07/msg00501.html

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