Re: Summary of the current state of the tag2upload discussion

[Soren Stoutner]

Russ,

I just wanted to say that I have appreciated all of the time and effort you 
have put into this discussion, and particularly appreciate your explanation of 
why some security efforts fail and which aspects of security humans are good at 
compared to which aspects machines are good at.

On Tuesday, June 25, 2024 12:03:24 PM MST Russ Allbery wrote:
> The basic problem (and this may sound flippant but it isn't) is that DDs
> are humans and humans are so bad at the type of validation that you would
> want them to perform that there is essentially no chance that this will
> happen systematically and effectively.
> 
> People, when trying to solve a security problem, will tend towards a
> fairly straightforward approach at first: figure out where the attack
> happened, figure out how to detect the attack, and then add a new process
> to check for that attack.  When another attack is found, add another
> process to detect that attack.  And so forth.
> 
> This is a very natural approach, and in some cases it can work, but in the
> general case what you get is airport security.  It has precisely that
> model: planes were hijacked with weapons or blown up with bombs, and
> therefore we check every passenger's luggage for weapons or bombs.  Each
> time we find a new weapon, we add a new check.  In this case, we have gone
> far, far beyond anything that Debian would have the resources to do: we
> hire an army of people whose entire job is to do these checks, we give
> them a bunch of expensive equipment, and we regularly test them to see how
> well they do at performing this screening.
> 
> In independent tests of TSA screening (the US airport security agency),
> that screening misses 80-95% of weapons or bombs.
> 
> This is a very common cautionary tale in the security community, and it's
> not because the agency is incompetent, or at least any more incompetent
> than any group of fallible humans told to do a boring job over and over
> again will be.  This is not a TSA problem, it's a human being problem.
> 
> The assumption on which this security approach is based is not as true as
> people want it to be.  You cannot simply tell people to check something
> and expect them to find problems if those problems are extremely rare and
> 99% of the time they will find nothing.  The human brain is literally
> hostile to this activity.  It is not optimized for it and will not do it
> reliably.  To get the accuracy as high as airport security achieves
> already requires training, testing, and a whole lot of assistance from
> technology that doesn't get bored or inattentive, and it still fails more
> often than not.
> 
> You have probably run into a similar version of this problem if you have
> proofread something that you have written.  If you are like most people
> (there are some people who are an exception to this), you will miss
> obvious, glaring errors that someone else will see immediately because you
> know what you intended to write and therefore that's what you see.  With a
> great deal of concentration and techniques to override your brain's normal
> behavior, such as reading all the sentences in reverse order, you can
> improve your accuracy rate, but you will still regularly miss errors.
> 
> Security is even worse because it's adversarial.  You're not attempting to
> spot static bugs that are sitting there waiting to be detected.  You are
> trying to defeat an intelligent, creative, adaptive enemy who watches what
> you do and adjusts their attack approach to focus on your weak spots.  And
> in the case of computer security, *unlike* airport security, catching the
> attacker once doesn't let you arrest them and prevent them from ever
> attacking you again.  The attacker can just try again, and again, and
> again until they succeed.
> 
> This doesn't mean that spot checks are useless.  Doing an occasional
> manual check can catch unanticipated problems and snare a lot of
> attackers, and it's part of a good overall security strategy.  But this
> approach isn't *reliable* and shouldn't be the front line of the strategy.
> 
> This problem is one of the reasons why there is so much emphasis in
> computer security at looking at the whole system, including the humans
> involved, and anticipating how the humans will fail.  Humans are
> vulnerable to boredom, to inattentiveness, to alert fatigue, to seeing
> what they expect to see, to laziness and haste, to emotional manipulation,
> and any number of other factors that interfere with them following
> processes.  The security design has to account for this.
> 
> Some processes are worse than others.  Processes that require a human to
> check something for errors that will not be present 99% of the time, and
> where it is overwhelmingly likely that no one will ever know if the human
> did the check properly or not, is nearly a worst-case scenario.  The check
> just won't happen reliably, no matter the intentions of everyone involved.
> People will skip it "just 

Re: General Resolution to deploy tag2upload

[Tiago Bortoletto Vaz]

Hi,

> Two comments, one more emotional and one more analytical:
> 
> * Part of my gut feeling is that the call for a GR might be a bit
>   premature, as I have the feeling that especially Gannef is not
>   opposed to t2u in general but is trying to work out how it might
>   work; and I really appreciate this positive attitude!

This is how I feel as well. I'm doing my best to follow the discussion since
its beginning, so far having no major concerns about t2u implementation itself,
but disliking the way this suddenly became, apparently, the most urgent thing
in the project.

> * On the other hand, I have the impression, based on my own
>   experiences with the FTP team, that this can go on for another 5
>   years or longer, as the FTP team usually avoids taking any formal
>   decisions; and this (meta level now) comes from the fact the no
>   delegated or ad-hoc team in Debian (except the TC) has any
>   bylaws/procedures for taking a decision, so it's easier to just not
>   decide.
> 
> Not sure what my conclusion might be; maybe something like "Wait for
> 4 more weeks for an official statement of the FTP team, and failing
> that, call for a GR."

I agree with the above. Not certain about 2, 4, 12 weeks... But such a
direction would definitely reduce the potential for a disruption in an
important part of Debian, at the (small?) cost of a possible implementation
delay that wouldn't result in any important damage here, in my view.

Bests,

--
Tiago

Re: General Resolution to deploy tag2upload

[Russ Allbery]

Sean Whitton  writes:

> =
> BEGIN FORMAL RESOLUTION TEXT

> tag2upload allows DDs and DMs to upload simply by using the
> git-debpush(1) script to push a signed git tag.

> 1. tag2upload, in the form designed and implemented by Sean Whitton and
>Ian Jackson, and design reviewed by Jonathan McDowell and Russ
>Allbery, should be deployed to official Debian infrastructure.

> 2. Under Constitution §4.1(3), we overrule the ftpmaster delegate's
>decision: the Debian Archive should be configured to accept and trust
>uploads from the tag2upload service.

> 3. Future changes to tag2upload should follow normal Debian processes.

> 4. Nothing in this resolution should be taken as requiring maintainers
>to use any particular git or salsa workflows.

> END FORMAL RESOLUTION TEXT
> =

Seconded.

The timing of this GR follows the schedule suggested by Joerg in
<87sexbl45e@ganneff.de>.  The discussion is not getting anywhere, and
I don't see any evidence that it's going to get anywhere.  We're still
stuck on the same question that we were stuck on in 2019.

I could say a lot about process, and I expect there are a lot of process
arguments to come, but, to be frank, I am exhausted.  I am exhausted with
the burden of process being entirely on the side of people who just want
to deploy their work.  I am exhausted with trying to eke small progress
out of discussions being conducted in obvious bad faith.  There were so
many opportunities here for someone to say, "You have done a bunch of hard
work on this, I don't understand the problem you're trying to solve
clearly enough, and I have clearly misunderstood how much it matters to
you.  Give us a couple of weeks to review the design in detail and put
together a list of questions so that you can explain the things we don't
understand, and then we will try to understand the answers and give you a
clear yes or no decision."  And yet this never happened.

The GR is the only decision-making process that the project has that
produces a clear answer in a well-defined time frame.  If we don't like
that fact, that is something that is on those of us who are project
delegates to address.  In the meantime, if people want to penalize project
members for trying to get a clear decision in the well-defined way that
the project constitution says that they can, well, obviously I can't stop
you.  But please don't lose sight of how frustrating and draining it is to
be told you have to keep discussing something with no end or progress in
sight.

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


signature.asc
Description: PGP signature

Re: General Resolution to deploy tag2upload

[Pierre-Elliott Bécue]

I'd like to submit a ballot option.

Not really happy with the current text though. The idea is simple : I
have been convinced, reading the previous discussion, that no formal
opinion from ftpmaster has been provided.

I'm not sure that it was asked explicitly, and I think that before
having a GR to force a tool down their throats, we should simply require
a formal statement from ftpmaster as delegates on the matter.

I also saw valid points that are too easily ignored by Sean and Ian
regarding their implementation, probably due to them not being eager to
change something that works.

I really think this GR is counter-productive in its current state. To be
clear, I'd vote for the default option above any ballot option trying to
force ftpaster (and then DSA) to push a tool that has not received a
formal review from ftpmaster, except if ftpaster decides to ignore the
assessment request thrown th them (in which case at some point I'd view
this as a decision - silent, but still).

That being said, I do feel that ftpmaster failed multiple times to reply
to requests from other DDs regarding rejects et al. I'd like to see this
change.

LBNL, I would expect tag2upload to work only if both a tag and the
commit it points to are signed. I also view the requirement to have a
proper DSC embedded some way is a sane one (as I consider it a sane idea
to build something before uploading it).

I'm happy to get counter-proposals regarding this option.

=
BALLOT OPTION BEGIN

tag2upload allows DDs and DMs to upload simply by using the git-debpush
script to push a signed git tag.

1. tag2upload should be deployed to official Debian infrastructure.

2. ftpmaster is expected to provide a formal opinion regarding the
   current implementation of tag2upload and the proposal from Sean
   Whitton and Ian Jackson to add it as a trusted source for the Debian
   Archive. Should ftpmaster consider that tag2upload can't be added as
   a trusted source for the Debian Archive as it is, ftpmaster is
   expected to provide a reasonable way forward.

3. Should ftpmaster fail to provide a proper and formal reply by
   September the 30th 2024, then under Constitution §4.1(3), the
   ftpmaster delegate decision would be overruled and become: the Debian
   Archive should be configured to accept and trust uploads from the
   tag2upload service.

BALLOT OPTION END
=

-- 
PEB


signature.asc
Description: PGP signature

Re: General Resolution to deploy tag2upload

[gregor herrmann]

On Thu, 27 Jun 2024 16:21:47 +0200, Joerg Jaspert wrote:

> On 17273 March 1977, Aigars Mahinovs wrote:
> > Refusing to make a decision is a decision.
> We haven't refused to make one.
> We haven't been asked for one, even.

> > There is no point in service building a
> > Debian source package where there is a hard requirement that the Debian
> > source package must be a part of the inputs provided to the system.
> We already said that we will do it in a way, that it can be done with
> *minimal* things necessary on client side.

Two comments, one more emotional and one more analytical:

* Part of my gut feeling is that the call for a GR might be a bit
  premature, as I have the feeling that especially Gannef is not
  opposed to t2u in general but is trying to work out how it might
  work; and I really appreciate this positive attitude!

* On the other hand, I have the impression, based on my own
  experiences with the FTP team, that this can go on for another 5
  years or longer, as the FTP team usually avoids taking any formal
  decisions; and this (meta level now) comes from the fact the no
  delegated or ad-hoc team in Debian (except the TC) has any
  bylaws/procedures for taking a decision, so it's easier to just not
  decide.

Not sure what my conclusion might be; maybe something like "Wait for
4 more weeks for an official statement of the FTP team, and failing
that, call for a GR."


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Re: Any reference of ftpmaster does not want to accept tag2upload (Was: [RFC] General Resolution to deploy tag2upload)

[Sam Hartman]

> "Andreas" == Andreas Tille  writes:

Andreas> I would really love to see some mails / logs of discussion
Andreas> between tag2upload developers and ftpmaster team.  Is there
Andreas> any chance that we could bring the involved parties in one
Andreas> (virtual) room and discuss the thing directly?  I'd love to
Andreas> serve as moderator in this room (with my DPL hat on).

There's a fair bit of that in the lea...@debian.org archive. I'll
forward you the early discussions.

Seconding the General Resolution to Deploy Tag2upload: supporting the idea that a GR is an appropriate process in this instance

[Sam Hartman]

> "Sean" == Sean Whitton  writes:

Sean> = BEGIN FORMAL RESOLUTION TEXT

Sean> tag2upload allows DDs and DMs to upload simply by using the
Sean> git-debpush(1) script to push a signed git tag.

Sean> 1. tag2upload, in the form designed and implemented by Sean
Sean> Whitton and Ian Jackson, and design reviewed by Jonathan
Sean> McDowell and Russ Allbery, should be deployed to official
Sean> Debian infrastructure.

Sean> 2. Under Constitution §4.1(3), we overrule the ftpmaster
Sean> delegate's decision: the Debian Archive should be configured
Sean> to accept and trust uploads from the tag2upload service.

Sean> 3. Future changes to tag2upload should follow normal Debian
Sean> processes.

Sean> 4. Nothing in this resolution should be taken as requiring
Sean> maintainers to use any particular git or salsa workflows.

Sean> END FORMAL RESOLUTION TEXT =


Seconded.
I realize  I asked you to wait, but Russ's message
8734oytl8l@hope.eyrie.org has convinced me I was wrong.

In addition, I would like to respond to those who claim that a GR is
inappropriate, or that ftpmaster should be given more time.

Back in 2019, you and Ian approached ftpmaster asking for tag2upload
support. There was an extensive debian-devel thread, and there was a fair
bit of private discussion.

At that time, I was DPL. You followed a reasonable process. You tried
to understand their requirements. It became clear to you and to me [1]
as a neutral party that your design was not going to be able to meet
their requirements.

[1]:  I did support the idea of replacing Debian source packages with
git in my DPL platform. Amusingly that was in response to a proposal
Joerg made. I was not a specific proponent of either tag2upload or
ftpmaster's concerns. I did support exploring tag2upload as a promising
option.

Ftpmaster did decide. No, perhaps it was not a formally announced
decision. Perhaps it was only a blocking decision of multiple individual
members rather than a team. No one proposed an option for how you could
ask for a formal decision. Other members of ftpmaster could have
indicated how you could ask for a collaborative design. They could have
proposed ways to have collaborative design. They could have, but did not.
They blocked your work.

My take away was that they believed that essential security properties
they cared about were incompatible with your design and there was no way
forward. Even getting requirements out of ftpmaster was difficult. I had
to intervene as DPL and talk about the importance of delegated teams
working with the project as a whole. (It is not the DPL’s job to second
guess a team’s decision, but it is the DPL’s job to prod teams when balls
are getting dropped or when teams aren’t working to resolve cross-team
issues.)

Let’s be honest, personalities were involved. It looked fairly clearly
like there were people on ftpmaster who didn’t want to work with Ian on
this issue. I get that: I’ve been frustrated working with Ian before, and
I know he’s been frustrated with me.

There are solutions to allow things to move forward even when
personality conflicts get in the way.  could have worked with you. They could
have even insisted that if tag2upload was going to move forward, you
needed to get someone else involved to work on the design with them. (You
might not have liked that, but tag2upload has enough support that if
getting another designer involved was what it took to make progress, that
could have happened.)

Instead, there was silence. You worked with ftpmaster. They said no. That’s
fine. There’s nothing wrong with that. These things are always
complicated. It was probably a combination of believing that the
security concerns they had were paramount, insufficient hours in the
day, and emotionally draining discussions. All that is part of life in
Debian. What should not be part of life in Debian is those combinations
blocking work with no recourse to get a broader opinion.

The project needs to be able to balance the decisions of teams
against other competing interests. We delegate responsibility to our
teams to move forward based on the overall needs of the project, not on
the needs and desires of the delegates. Yes, delegates get a lot of
discretion because they are doing the work, because we value being a
do-ocracy, and because volunteer work is fun when we have the flexibility
to do our jobs in a manner that appeals to us.

For Debian to remain vibrant and fun, we need to have ways to resolve
conflicts when one person’s doing crosses ways with another person’s
doing. We need to have ways to ask a broader group when ftpmaster’s
concerns about archive signatures run against your desire to make Debian easier
to contribute to and to provide better traceability of our source
packages.

It turns out we do have ways of addressing that. They include GRs, the
technical committee setting policy (such as policy on archive security
requirements), 

Re: [RFC] General Resolution to deploy tag2upload

[Matthias Urlichs]

On 27.06.24 19:50, Ansgar  wrote:

You missed a very simple part: it wouldn't sign (a hash of) the output
of dgit. So the problem does not exist in the form you imagine.


OK. Sorry if I misunderstood that email then, it's been a busy week, but 
… so what *do* you want t2u to checksum?


--
-- regards
--
-- Matthias Urlichs



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: General Resolution to deploy tag2upload

[Russ Allbery]

Ansgar   writes:
> On Thu, 2024-06-27 at 09:15 -0700, Russ Allbery wrote:

>> *As soon as* you indicated that there was some willingness to move your
>> position, people reinvested substantial effort into trying to have that
>> discussion

> Yes, I remember. For example getting examples from Russ Allbery about
> what would surely not work, but that would work trivially...

It's very unfortunate that you didn't read Ian's message, in which he
confirmed that I was correct originally, my example was valid, and I had
misunderstood what was going on.  The only reason why this *appears* to be
trivial is because I was running dgit locally: in other words, precisely
the thing that would not happen in the tag2upload case.  As soon as I
stopped doing that because I was using tag2upload, my example would have
behaved in the way that I was describing to you.

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

Re: [RFC] General Resolution to deploy tag2upload

[Ansgar ]

Hi Matthias,

On Thu, 2024-06-27 at 13:56 +0200, Matthias Urlichs wrote:
> On 27.06.24 09:50, Ansgar  wrote:
> > leading to having no idea
> > why a checksum as suggested isn't possible (it would work trivially for
> > the counterexamples given...).
> 
> I  assume that "checksum" refers to something 
> likehttps://pkg.go.dev/golang.org/x/mod/sumdb/dirhash#Hash1 which you
> referred to in a message on 06-19.
> 
> Question: How can the tag2upload client, which is not going to run dgit 
> by design, add the hash of dgit's output to the tag it creates?
> 
> Answer: it's impossible to do that. This is the whole point of tag2upload.

You missed a very simple part: it wouldn't sign (a hash of) the output
of dgit. So the problem does not exist in the form you imagine.

> Please enlighten me if I have missed something here.

You are welcome. Bye.

Ansgar

Re: General Resolution to deploy tag2upload

[Ansgar ]

Hi Russ,

On Thu, 2024-06-27 at 09:15 -0700, Russ Allbery wrote:
> *As soon as* you indicated that there was some willingness to move your
> position, people reinvested substantial effort into trying to have that
> discussion

Yes, I remember. For example getting examples from Russ Allbery about
what would surely not work, but that would work trivially... That's
kind of energy draining and removes motivation to continue to read the
thread. (Yes, that is the reason why I haven't read further mails yet
(as Sean should know). Well done to now use that against me!)

Ansgar

Re: General Resolution to deploy tag2upload

[Russ Allbery]

Joerg Jaspert  writes:
> On 17273 March 1977, Aigars Mahinovs wrote:

>> Refusing to make a decision is a decision.

> We haven't refused to make one.
> We haven't been asked for one, even.

Don't you think this is getting kind of absurd?  I flatly don't believe
that you actually believe that.  There is literally no way that you could
think, after all of this discussion, that you haven't been asked for a
decision or what that decision is about.

*As soon as* you indicated that there was some willingness to move your
position, people reinvested substantial effort into trying to have that
discussion, including multiple replies and attempted discussion with
Ansgar despite his quite open hostility earlier in this discussion.  You
said at that time, and I am quoting from your message in
<87sexbl45e@ganneff.de>:

| I would ask you to wait a bit more before continuing with a GR (in the
| term of days, not months), at least some time, but do whatever you feel.

That was ten days ago.  Sean did exactly what you asked.

When that conversation stopped, entirely on the FTP master side, people
waited and then Sean you to provide some indication of whether you were
still considering the options.  There wasn't a response.

This process is utterly exhausting.  You are asking people to prolong it
even further.  You have to give them *something* that justifies doing that
if you expect them to agree, at least a message saying that there's a lot
of material to digest and providing some rough timeline.  You can't ask
people to wait days but not weeks for a GR, stop responding to them, and
then get angry at them for doing what you asked and moving forward when
you didn't reply further.  Or, well, you *can*, but it doesn't seem
justified to me.

I know people are reluctant to go to a GR for these types of decisions,
but at some point there *has to be an end*.  Otherwise, it's just a form
of decision by attrition: exhaust people until they no longer care whether
their request is approved or not, or possibly about Debian at all.

If you think there's something more to discuss that would help you change
your mind, the GR isn't happening tomorrow.  But there has to be an end in
sight.  Doing things in Debian cannot be an endless series of procedural
hoops, beyond which is simply more procedural hoops.

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

Re: General Resolution to deploy tag2upload

[Matthias Urlichs]

On 27.06.24 16:21, Joerg Jaspert wrote:

We haven't refused to make one.
We haven't been asked for one, even. 


Given that Ansgar still more-or-less insists on his checksum approach, 
which AFAICT cannot work for many dgit workflows, there's really no 
point in asking in the first place IMHO.


Also, Russ did update his security review. One of you could have reacted 
with either "OK, thanks that's good enough, what do you need from us for 
the next steps?" *or* "sorry but that doesn't convince us, because 
«reason»" (or possibly "hmm, OK, we (= the ftpmasters) are going to 
figure out a consensus position on this, give us a week please") without 
being asked explicitly.


Yes, there's a fair amount of communications breakdown here, obviously, 
but I don't think it's as one-sided as you imply here.


--
-- regards
--
-- Matthias Urlichs



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: General Resolution to deploy tag2upload

[Sam Hartman]

> "Sean" == Sean Whitton  writes:

Sean> Hello everyone, I seek seconds for the General Resolution at
Sean> the end of this e-mail.  The preceding sections are an
Sean> introductory explanation and rationale.

Sean> We have reviewed the discussion we've already had and prepared
Sean> an FAQ, linked below.

I think you are about a week too early to ask for seconds on this.
I do think the discussion threads are winding down, and  I do think this
should come to a vote soon.
But I really do think you have misjudged by about a week.
I also think that week will significantly affect the perceived cost of
this  vote on the project.



signature.asc
Description: PGP signature

Re: General Resolution to deploy tag2upload

[Joerg Jaspert]

On 17273 March 1977, Aigars Mahinovs wrote:

Refusing to make a decision is a decision.


We haven't refused to make one.
We haven't been asked for one, even.

If this was the same kind of discussion that happened five years ago, 
I can

see why it was not continued. There is no point in service building a
Debian source package where there is a hard requirement that the 
Debian

source package must be a part of the inputs provided to the system.


We already said that we will do it in a way, that it can be done with
*minimal* things necessary on client side.

--
bye, Joerg

Re: [RFC] General Resolution to deploy tag2upload

[Matthias Urlichs]

On 27.06.24 09:50, Ansgar  wrote:

leading to having no idea
why a checksum as suggested isn't possible (it would work trivially for
the counterexamples given...).


I  assume that "checksum" refers to something 
likehttps://pkg.go.dev/golang.org/x/mod/sumdb/dirhash#Hash1 which you 
referred to in a message on 06-19.


Question: How can the tag2upload client, which is not going to run dgit 
by design, add the hash of dgit's output to the tag it creates?


Answer: it's impossible to do that. This is the whole point of tag2upload.

Please enlighten me if I have missed something here.

--
-- regards
--
-- Matthias Urlichs



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: General Resolution to deploy tag2upload

[Aníbal Monsalve Salazar]

On Thu, 2024-06-27 15:15:42 +0800, Sean Whitton wrote:
> =
> BEGIN FORMAL RESOLUTION TEXT
> 
> tag2upload allows DDs and DMs to upload simply by using the
> git-debpush(1) script to push a signed git tag.
> 
> 1. tag2upload, in the form designed and implemented by Sean Whitton and
>Ian Jackson, and design reviewed by Jonathan McDowell and Russ
>Allbery, should be deployed to official Debian infrastructure.
> 
> 2. Under Constitution §4.1(3), we overrule the ftpmaster delegate's
>decision: the Debian Archive should be configured to accept and trust
>uploads from the tag2upload service.
> 
> 3. Future changes to tag2upload should follow normal Debian processes.
> 
> 4. Nothing in this resolution should be taken as requiring maintainers
>to use any particular git or salsa workflows.
> 
> END FORMAL RESOLUTION TEXT
> =

Seconded.


signature.asc
Description: PGP signature

Re: General Resolution to deploy tag2upload

[Scott Kitterman]

On Thursday, June 27, 2024 6:07:33 AM EDT Aigars Mahinovs wrote:
> Refusing to make a decision is a decision. Ansgar has explicitly set a
> requirement for including the checksums of the end result Debian source
> package in the tag. This requirement was not withdrawn or overridden by
> other FTP masters in the public list communications. And all (detailed)
> explanations why this requirement is not appropriate have been ignored.
> Ansgar even explicitly stated that no replies or explanations were read
> (due to lack of time).
> 
> If FTP masters (as a team) override this requirement publicly, then there
> should be no further obstacles to deploying tag2upload. Everything else has
> been already fully discussed.
> 
> If not, then the GR is quite appropriate IMHO.
> 
> If this was the same kind of discussion that happened five years ago, I can
> see why it was not continued. There is no point in service building a
> Debian source package where there is a hard requirement that the Debian
> source package must be a part of the inputs provided to the system.
> 
> On Thu, Jun 27, 2024, 12:30 Joerg Jaspert  wrote:
> > > The ftpmaster team have refused to trust uploads coming from the
> > > tag2upload service.  This GR is to override that decision.
> > 
> > This is wrong, there has *NOT* been such a decision.
> > 
> > > In our design, the git tag contains simple metadata that can be
> > > written
> > > out by hand.  ftpmaster stated a hard requirement that the signed tag
> > > must additionally include a manifest of all files in the .dsc.
> > 
> > And that is wrong too.

I think you are confusing an FTP Master participating in the discussion with a 
decision by the delegates as a team.  As far as I'm aware, no decision has 
been taken.  There are, in fact, discussions still going on within the FTP 
Team (I'm an FTP Assistant, but not a delegated FTP Master) about ways to 
support tag2upload.

I'm unable to find any record of the FTP Masters being asked to accept uploads 
from tag2upload before this GR discussion was started.

It's true that the Debian constitution gives developers the authority via GR 
to make decisions for delegates, so the fact that there's nothing to override 
isn't a strict bar to a GR like this, but it seems like it would be better to 
attempt to do this collaboratively.

It's true that the FTP Masters have not agreed to trust uploads via 
tag2upload, but that's because they were never asked to do so.

Also, before whoever it was that did it the first time sends the Community Team 
after me again, don't bother.  I'm not going to participate further in this 
discussion as it's become quite clear there's no desire for any kind of useful 
collaboration.

Scott K

signature.asc
Description: This is a digitally signed message part.

Re: General Resolution to deploy tag2upload

[Aigars Mahinovs]

Refusing to make a decision is a decision. Ansgar has explicitly set a
requirement for including the checksums of the end result Debian source
package in the tag. This requirement was not withdrawn or overridden by
other FTP masters in the public list communications. And all (detailed)
explanations why this requirement is not appropriate have been ignored.
Ansgar even explicitly stated that no replies or explanations were read
(due to lack of time).

If FTP masters (as a team) override this requirement publicly, then there
should be no further obstacles to deploying tag2upload. Everything else has
been already fully discussed.

If not, then the GR is quite appropriate IMHO.

If this was the same kind of discussion that happened five years ago, I can
see why it was not continued. There is no point in service building a
Debian source package where there is a hard requirement that the Debian
source package must be a part of the inputs provided to the system.

On Thu, Jun 27, 2024, 12:30 Joerg Jaspert  wrote:

>
> > The ftpmaster team have refused to trust uploads coming from the
> > tag2upload service.  This GR is to override that decision.
>
> This is wrong, there has *NOT* been such a decision.
>
>
> > In our design, the git tag contains simple metadata that can be
> > written
> > out by hand.  ftpmaster stated a hard requirement that the signed tag
> > must additionally include a manifest of all files in the .dsc.
>
> And that is wrong too.
>
>
>

Re: General Resolution to deploy tag2upload

[Ian Jackson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sean Whitton writes ("General Resolution to deploy tag2upload"):
> BEGIN FORMAL RESOLUTION TEXT
> 
> tag2upload allows DDs and DMs to upload simply by using the
> git-debpush(1) script to push a signed git tag.
> 
> 1. tag2upload, in the form designed and implemented by Sean Whitton and
>Ian Jackson, and design reviewed by Jonathan McDowell and Russ
>Allbery, should be deployed to official Debian infrastructure.
> 
> 2. Under Constitution §4.1(3), we overrule the ftpmaster delegate's
>decision: the Debian Archive should be configured to accept and trust
>uploads from the tag2upload service.
> 
> 3. Future changes to tag2upload should follow normal Debian processes.
> 
> 4. Nothing in this resolution should be taken as requiring maintainers
>to use any particular git or salsa workflows.
> 
> END FORMAL RESOLUTION TEXT

Seconded.

-BEGIN PGP SIGNATURE-

iQFUBAEBCAA+FiEEVZrkbC1rbTJl58uh4+M5I0i1DTkFAmZ9OU4gHGlqYWNrc29u
QGNoaWFyay5ncmVlbmVuZC5vcmcudWsACgkQ4+M5I0i1DTmRLQf+LDv0LFDYGbLX
q75/ZvmBA5C7v/w4OuoJq14O3RezZqeR19smbX87Ss7VTweTUZ/LK7hl5GjqIq4r
0nx1FMKmbJV/rrdHyjz1KNzCoSn+m/ADAdAW048KsRdQ4nVtedBZvBs6yBwai8vv
BN6q3YzSGfqhkdHZqDttotojwisJlYzI+z/0qLXEwORA/STHrldVVM4NNPgAZSGa
5ers6Id8GTKwWq0IpCBFinW+lGDOtY4B8OY1CaAnBhSC7LygYbzWZkjN2ExNIDer
Oaw5UCOppqzMLfvghQxFIfmjV24n7I1Up3x26AC5r5DvSPmEebLTHLj86r+jXLWI
CEhMkjAxMg==
=gBnj
-END PGP SIGNATURE-
-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Re: General Resolution to deploy tag2upload

[Joerg Jaspert]

On 17273 March 1977, Sean Whitton wrote:


=
NEED FOR A GR



So, why am I proposing a GR?


Because you aren't appearently interested in actual cooperation, but
want to force something down the throat of others, ignoring their
wishes.


The ftpmaster team have refused to trust uploads coming from the
tag2upload service.  This GR is to override that decision.


This is wrong, there has *NOT* been such a decision.

In our design, the git tag contains simple metadata that can be 
written

out by hand.  ftpmaster stated a hard requirement that the signed tag
must additionally include a manifest of all files in the .dsc.


And that is wrong too.


We think that it should be possible to upload packages without any
complex Debian-specific tools, and we want to support as many of our
existing git workflows as we can.
Meeting these goals requires accepting source packages constructed and
uploaded by the tag2upload service.


FTPMaster actually has a very similar wish.

We are concerned that ftpmaster's position is due more to 
conservatism,

leading to an unwillingness to extend trust beyond our existing
processes, no matter how carefully designed and implemented the new
processes may be.


Wrong, again.


Should this GR pass, the tag2upload project will be unstuck, and could
be deployed in a matter of months.  Then the source-only uploads of as
many of us who want it can become just 'git debpush' and done, without
any other workflow changes or learning.


"In a matter of months", but you can't even wait to end the running
discussion first. Where is the hurry?


=
BEGIN FORMAL RESOLUTION TEXT



tag2upload allows DDs and DMs to upload simply by using the
git-debpush(1) script to push a signed git tag.

1. tag2upload, in the form designed and implemented by Sean Whitton 
and

   Ian Jackson, and design reviewed by Jonathan McDowell and Russ
   Allbery, should be deployed to official Debian infrastructure.



2. Under Constitution §4.1(3), we overrule the ftpmaster delegate's
   decision: the Debian Archive should be configured to accept and 
   trust

   uploads from the tag2upload service.


Which decision do you want to overrule? There has not been any.
FTPMaster is talking with you (or trying, but you don't appear to be
open to listen) and trying to get this in, but you are "My way or
nothing" set.
So no, point 2 is not true.

--
bye, Joerg

Re: General Resolution to deploy tag2upload

[Jonathan McDowell]

On Thu, Jun 27, 2024 at 03:15:42PM +0800, Sean Whitton wrote:

> =
> BEGIN FORMAL RESOLUTION TEXT
> 
> tag2upload allows DDs and DMs to upload simply by using the
> git-debpush(1) script to push a signed git tag.
> 
> 1. tag2upload, in the form designed and implemented by Sean Whitton and
>Ian Jackson, and design reviewed by Jonathan McDowell and Russ
>Allbery, should be deployed to official Debian infrastructure.
> 
> 2. Under Constitution §4.1(3), we overrule the ftpmaster delegate's
>decision: the Debian Archive should be configured to accept and trust
>uploads from the tag2upload service.
> 
> 3. Future changes to tag2upload should follow normal Debian processes.
> 
> 4. Nothing in this resolution should be taken as requiring maintainers
>to use any particular git or salsa workflows.
> 
> END FORMAL RESOLUTION TEXT
> =

Seconded.

It's a shame we've come to a GR on this, but I do believe it adds a
significant improvement to the git workflow when working in Debian.

J.

-- 
/-\ |  "Oh, you are awesome when you're
|@/  Debian GNU/Linux Developer |   sarcastic.  Please do carry on
\-  |:-)." -- iwj to rra on Ruby.


signature.asc
Description: PGP signature

Re: General Resolution to deploy tag2upload

[Joerg Jaspert]

On 17273 March 1977, Sean Whitton wrote:


I seek seconds for the General Resolution at the end of this e-mail.
The preceding sections are an introductory explanation and rationale.


So, we are even still discussing things in that other monster thread.
And the second one beside it. FTPMaster has shown that we want it, but
requested some changes. (And is even flexible on them and still up for
finding a way. *WE* are willing, appears you are not.). Where is the
hurry to run a GR now? You waited 5 years without ever bringing this
forward, and now it must be done right now, and can't wait more time? Oh
come on.

All of the things asked got rejected, this appears a "my way only or we 
f*ck

you over with a GR". Helpful. Not.

It's about the worst way to get something into Debian.

I did think better of you, but meh, another disappointment. :(

--
bye, Joerg

Re: General Resolution to deploy tag2upload

[Marc Haber]

On Thu, Jun 27, 2024 at 03:15:42PM +0800, Sean Whitton wrote:
> I seek seconds for the General Resolution at the end of this e-mail.
> The preceding sections are an introductory explanation and rationale.

*NOT* Seconded.

The discussion following the pre-GR has clearly shown that we need to
have further discussion. Going ahead with the GR shows disrespect for
the entirety of the discussion and the suggestions that have been made.
This makes the GR proponents look like "we want it THIS way or not at
all" to me.

That's not the way Debian works. Please consider pulling back for
Debian's sake.

Greetings
Marc

P.S.: Yes, I know how I will vote when this will go ahead

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Re: [RFC] General Resolution to deploy tag2upload

[Ansgar ]

Hi,

On Mon, 2024-06-24 at 16:12 +0800, Sean Whitton wrote:
> Ansgar, Joerg,
> 
> Discussion has died down without a resolution of our impasse, but Ian
> sent a very long message, so perhaps you are working through it.
> 
> Could you let me know if you are still working on further responses,
> and if so, roughly how long you think you need?

As I guess you are aware (given you are on #-ftp-private), I haven't
found time to read recent mails. In particular I haven't had time to
find anything after the discussion with Russ, leading to having no idea
why a checksum as suggested isn't possible (it would work trivially for
the counterexamples given...).

I would still be interested in understanding this and seeing if one
could find a solution (as I guess you are also aware of for the same
reason). Sadly tag2upload developers have refused communication for
several years prior to know, despite recommendations form multiple
parties (including multiple DPLs AFAIU) to do so. Of course we cannot
force developers to do so if they do not want to.

Ansgar

Re: General Resolution to deploy tag2upload

[Didier 'OdyX' Raboud]

Le jeudi, 27 juin 2024, 09.15:42 h CEST Sean Whitton a écrit :
> =
> BEGIN FORMAL RESOLUTION TEXT
> 
> tag2upload allows DDs and DMs to upload simply by using the
> git-debpush(1) script to push a signed git tag.
> 
> 1. tag2upload, in the form designed and implemented by Sean Whitton and
>Ian Jackson, and design reviewed by Jonathan McDowell and Russ
>Allbery, should be deployed to official Debian infrastructure.
> 
> 2. Under Constitution §4.1(3), we overrule the ftpmaster delegate's
>decision: the Debian Archive should be configured to accept and trust
>uploads from the tag2upload service.
> 
> 3. Future changes to tag2upload should follow normal Debian processes.
> 
> 4. Nothing in this resolution should be taken as requiring maintainers
>to use any particular git or salsa workflows.
> 
> END FORMAL RESOLUTION TEXT
> =

Seconded, thanks for the extensive discussion and work towards that goal.

I'm of course worried by the potential disruptions on motivation and morale 
for the FTP team, but I (currently) feel that the potential benefits from a 
working tag2upload are worth at least having that vote.

I wonder if certain amendments would make sense and better the ballot (such as 
weakening the "should be deployed" towards a "ftpmaster are encouraged to 
consider deploying", or so), but I don't have the mental space or bandwidth to 
think of a good one.

-- 
OdyX

signature.asc
Description: This is a digitally signed message part.

General Resolution to deploy tag2upload

[Sean Whitton]

Hello everyone,

I seek seconds for the General Resolution at the end of this e-mail.
The preceding sections are an introductory explanation and rationale.

We have reviewed the discussion we've already had and prepared an FAQ,
linked below.

Thank you for all the input on my previous posting, which has resulted
in a number of changes.

=
INTRODUCTION

The tag2upload system, designed for deployment on official Debian
infrastructure, allows DDs and DMs to make source-only uploads simply by
pushing a signed git tag.  There are two key advantages:

- it will be much quicker & easier for us to do most of our uploads

- it improves the traceability & auditability of our source-only uploads

The system works like this:

1. Maintainer types 'git debpush' to sign and push a suitable git tag.
   The tag includes certain metadata that makes the maintainer's
   intention to upload fully traceable, and unambiguous.

2. A robot on DSA infrastructure automatically, reliably and traceably
   builds the source package, and uploads it to the Debian Archive.

tag2upload will be an additional option for your source-only uploads --
no-one will be required to use it.  For more information on the details
of the system itself, I've included some links below.

The design is complete, and a prototype is fully implemented with a
thorough test suite.
In testing, it has been used to perform real uploads.

As tag2upload is security-sensitive, the design has had careful,
independent security review from Russ Allbery and Jonathan McDowell, who
did not have any part in the original design and implementation.
I note that Jonathan is one of the highly trusted maintainers of our
keyring of human uploaders.

=
NEED FOR A GR

So, why am I proposing a GR?

The ftpmaster team have refused to trust uploads coming from the
tag2upload service.  This GR is to override that decision.

In our design, the git tag contains simple metadata that can be written
out by hand.  ftpmaster stated a hard requirement that the signed tag
must additionally include a manifest of all files in the .dsc.

However, due to several factors, such a file manifest cannot be
generated without the uploader building a source package.
The whole point of tag2upload is to move that process off the
uploader's system, and onto controlled project infrastructure.

We think that it should be possible to upload packages without any
complex Debian-specific tools, and we want to support as many of our
existing git workflows as we can.
Meeting these goals requires accepting source packages constructed and
uploaded by the tag2upload service.

=
CONSERVATISM & TRACEABILITY

We are concerned that ftpmaster's position is due more to conservatism,
leading to an unwillingness to extend trust beyond our existing
processes, no matter how carefully designed and implemented the new
processes may be.

While we want people in Debian in critical paths for archive security to
be relatively conservative, that conservatism can be taken too far, and
we think that is what has happened in this case.

In fact, tag2upload significantly *improves* the traceability of our
source-only uploads.

Currently, source packages are constructed from git with relatively
ad-hoc command line invocations, using whatever tooling the maintainer
has installed on their laptop.
This does not give an adequate level of traceability.

tag2upload will be a massive *improvement* to traceability since it will
restore the formal and traceable link between what most maintainers
actually work with and treat as canonical (git, nowadays), and what
Debian as an institution officially publishes (packages).

=
THE DESIGN & IMPLEMENTATION ARE LATE-STAGE

We wish to be clear that tag2upload can be deployed without *any* code
changes to dak.  It just needs to be given a suitably trusted key,
very similar to how buildds have trusted keys.

There are a few loose ends we want to complete to turn the prototype
into the finished service.  Some design adjustments made in response to
Russ Allbery's security review are still to be implemented, and we will
arrange how the deployment will work in consultation with DSA.

Should this GR pass, the tag2upload project will be unstuck, and could
be deployed in a matter of months.  Then the source-only uploads of as
many of us who want it can become just 'git debpush' and done, without
any other workflow changes or learning.

There do not exist any other designs that are anywhere near complete,
and there are no other implementations, for upload-by-git-tag.

=
WHAT'S NEXT

Initially, we'll complete the implementation and deployment work, in
collaboration with DSA.  When we're ready, we'll advertise for early
adopters, who are happy to put up with teething troubles.

Eventually we expect many people to switch to using tag2upload for all
their source-only uploads, thanks to its convenience.

What comes after that will be up to all of us.
We intend tag2upload to be an incremental change, which 

Re: tag2upload, reproducible .orig and dfsg repacks

[Matthias Urlichs]

On 27.06.24 07:48, Andreas Tille wrote:

I'd prefer if we would not
invent a file that might duplicate the content of the d/copyright
Files-Excluded field - but this seems to be some implementation detail.


You have a point there. We could use "git filter-repo --invert-paths 
--paths-from-file <(extract-excluded- paths d/copyright)" instead.


On the other hand: if the file isn't present anyway, why would we list 
it there in the first place?


Brian:


For example, if an individual file contains a mixture of non-dfsg stuff
and dfsg stuff that is required for building.


These cases would require some more intrusive editing. "git filter-repo" 
does support that: you can use a blob callback to edit individual objects.


Of course we'd have to be a bit more careful to ensure that the callback 
is idempotent and all that, but again I don't see a major problem here, 
other than a somewhat-annoying intermediate step when you pull from 
upstream – but we also need an annoying step when we build the next DFSG 
tarball, so that's no loss. :-P


--
-- mit freundlichen Grüßen
--
-- Matthias Urlichs



OpenPGP_signature.asc
Description: OpenPGP digital signature