Re: t2u in the archive

[Scott Kitterman]

On Sunday, June 30, 2024 1:45:15 PM EDT Aigars Mahinovs wrote:
> On Sun, 30 Jun 2024 at 19:28, Russ Allbery  wrote:
> > Aigars Mahinovs  writes:
> > > Correct me if I'm wrong, but I believe the intention is to have two
> > > technically redundant data points saved into the archive:
> > > 
> > > 1) checksums of the contents of the shallow copy git tree in the
> > > maintainer work folder (signed by the maintainer)
> > > 2) contents of the shallow copy git tree in the t2u server work folder
> > > (signed by t2u)
> > 
> > Oh!  Did I misunderstand Joerg's second point entirely?  By "the tag that
> > t2u wants to upload," I assumed that meant the tag the uploader signed or,
> > in other words, the state of the tree *before* t2u started doing its work
> > that has the uploader signature attached.
> 
> I do not see that in either what me or Joerg wrote. And I also don't
> see much sense in that.
> 
> In contrast, having a tarball of the git state *before* t2u starts its
> work would provide a tarball that *can* be verified against the
> checksums from the first file. That will give you a clear data point -
> t2u started its work with the exactly the same workspace as the
> maintainer signed. And will provide a frozen copy of that starting
> workspace in the archive independent of the (more complex) dgit
> service.

It's one at the point the maintainer signed the tag.

Scott K

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

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: Summary of the current state of the tag2upload discussion

[Scott Kitterman]

On June 26, 2024 4:26:03 AM UTC, Simon Richter  wrote:
>Hi,
>
>On 6/26/24 03:42, Aigars Mahinovs wrote:
>
>> Do you actually check that the contents of the source *package* (after all 
>> operations done by dpkg-source and possibly other tools) actually match what 
>> you were looking at before in your source work tree folder?
>
>Yes, although more from a quality control perspective, so I don't do it for 
>minimal changes or simple "declare different target distribution" style 
>backports.
>
>With the 1.0 format, that was a lot easier (zless on the .debian.diff.gz), but 
>with mc that is still doable with 3.0.
>
>I've quite often found problems like accidentally included files, or 
>inconsistencies in the control file because I forgot to apply a change to one 
>package.

Similarly, I debdiff the source package with the previous revision when doing 
stable updates to make sure I'm only including the changes I intend to.  I do 
this sometimes, although far less frequently, for Unstable/Experimental 
uploads.  It's not a guarantee I'll find everything, but it's not nothing 
either.

Scott K

Re: Summary of the current state of the tag2upload discussion

[Scott Kitterman]

On June 25, 2024 9:02:45 AM UTC, Philip Hands  wrote:
>Scott Kitterman  writes:
>
>> Do you have any examples of problems that this would have avoided
>> (xz-utils isn't one - due to the way it's releases are done, it
>> wouldn't be suitable for tag2upload)?
>
>I'm somehow reminded of Ignaz Semmelweis's attempts to improve medical
>hygiene by getting doctors to emulate the local midwives, who scrubbed
>their hands between patients, whereas the doctors generally didn't, and
>would alternate between performing autopsies and attending deliveries.
>
>I'd guess someone may well have pushed back against that, thus:
>
>  Can you to name a single patient who has suffered as a result of
>  existing practice?
>
>If I stretch that metaphor (possibly beyond breaking point), then one
>might think of our developers' laptops as the (potentially infected)
>cadavers, the newly uploaded source packages as the live births, and our
>tooling as the doctors' hands that may carry the infectious material
>from one to the other.
>
>I hope that we've been lucky enough to not actually have any of the
>relevant "infections" in the population of laptops that produce our
>packages, but would it not be wise to make it more difficult for such an
>infection to be silently transmitted?
>
>People state that a compromised machine can as easily commit malicious
>code to git as it could insert it into a source package, but the
>difference is that the malicious commit then needs to be pushed in
>order to work, exposing it to examination.
>
>In our metaphor perhaps the git commit step would equate to requiring
>doctors to touch a new Petri dish before each patient, which would at
>least record what was going on, and might give the opportunity to deal
>with the situation before real harm is done.
>
I don't disagree with any of that, in principle.  I'm not against improvements 
that help address security concerns that we believe are currently only 
theoretical.  I do think that the anti-source package rhetoric in the message I 
was replying to was over the top.

Security is inevitably tied up in trade-offs.  One of the trade-offs for 
tag2upload as currently designed is the loss of any cryptographic connection 
between the person that uploaded the package and the source package in the 
Debian package archive.

I understand that different people will value that differently.  My impression 
is that the message I was responding to was essentially claiming that it's no 
trade-off at all because, due to the massive risk of unknown transformations 
when the source package is built, there's no value to the signature.

I think that's nonsense.

Scott K

Re: Summary of the current state of the tag2upload discussion

[Scott Kitterman]

I understand the theory.  Are we aware of it happening?

Scott K

On June 24, 2024 7:42:25 PM UTC, Aigars Mahinovs  wrote:
>It's pretty simple. Compromise the computer of one developer, the one they
>use for development. Have your code be in one of the tools being called
>during Debian source package build (you don't even need root, just writable
>element in PATH). Now you can inject a malicious payload directly into the
>tarball or debian diff of the target Debian source package. The developer
>will never see it in their code. It will arrive in the archive signed by
>the victim as part of normal delivery. There will be nothing suspicious
>about it unless someone else does a NMU and sees a bigger than expected
>debdiff.
>
>Even if the developer is very security minded and maintains a separate
>air-gapped signing laptop, that doesn't help unless you first actually
>analyse the actual artifact that you are signing.
>
>Maybe it would even possible to trick the developer into to signing an
>upload of a different package (add a binary package with high version to
>their source package?).
>
>With tag2upload there is no obscured source package file to be signed, so
>all content going into the archive must already be visible in the git repo
>being signed and will also be visible in the dgit repo. Any difference to
>the upstream will be quite obvious in either case.
>
>That is the difference between signing something that no human will ever be
>reading and singing the actual source that everyone will be looking at. And
>that is the difference between needing to secure just one service
>(tag2upload) instead of securing a thousand work PCs of all DDs. And we do
>this already for build machines. If one would want to sneak stuff into
>Debian, hacking a buildd would be the best target - you are putting hacked
>binaries into end user machines without leaving traces in source packages
>or repos.
>
>An attack on upstream where a release tarball is different form upstream
>git tree would also be side-stepped by the Debian maintainer simply using
>only the git tree as upstream and completely ignoring the tarballs. It
>would not provide a solution for code hidden in the upstream git itself
>that the maintainer missed.
>
>On Mon, 24 Jun 2024, 22:03 Scott Kitterman,  wrote:
>
>> Do you have any examples of problems that this would have avoided
>> (xz-utils isn't one - due to the way it's releases are done, it wouldn't be
>> suitable for tag2upload)?
>>
>> Scott K
>>
>> On June 24, 2024 6:36:59 PM UTC, Aigars Mahinovs 
>> wrote:
>> >Signing something that you did not write and something that you don't read
>> >is a bad security practice that exposes you to various attacks.
>> >
>> >Just because we have been doing this poor security practice for a long
>> time
>> >does not make it better. Now better methods are possible and we shouldn't
>> >prevent them from being used just because we are used to the weaker
>> >approach.
>> >
>> >On Mon, 24 Jun 2024, 18:34 Scott Kitterman,  wrote:
>> >
>> >>
>> >> None of that changes the fact that it's what they signed.  Historically,
>> >> the project has found that useful and I think it still is.
>>
>>

Re: Summary of the current state of the tag2upload discussion

[Scott Kitterman]

Do you have any examples of problems that this would have avoided (xz-utils 
isn't one - due to the way it's releases are done, it wouldn't be suitable for 
tag2upload)?

Scott K

On June 24, 2024 6:36:59 PM UTC, Aigars Mahinovs  wrote:
>Signing something that you did not write and something that you don't read
>is a bad security practice that exposes you to various attacks.
>
>Just because we have been doing this poor security practice for a long time
>does not make it better. Now better methods are possible and we shouldn't
>prevent them from being used just because we are used to the weaker
>approach.
>
>On Mon, 24 Jun 2024, 18:34 Scott Kitterman,  wrote:
>
>>
>> None of that changes the fact that it's what they signed.  Historically,
>> the project has found that useful and I think it still is.

Re: Summary of the current state of the tag2upload discussion

[Scott Kitterman]

On June 24, 2024 2:48:49 PM UTC, Aigars Mahinovs  wrote:
>On Sun, Jun 23, 2024, 19:17 Scott Kitterman  wrote:
>
>> As an example, I think the fact that I can download any source package in
>> the
>> archive and cryptographically verify who uploaded it and that it's
>> unmodified
>> from what was uploaded is an important property of our current archive
>> structure.  IIRC, you've claimed it's not.  I don't think either of us has
>> a
>> very good understanding of why the other believes that.  I think for both
>> of
>> us it's just too obviously true/not true to be easy to explain.
>>
>
>There are a few problems with that.
>
>1. The source package is not the end state and not what the end user ends
>up using in their system. Users use a binary deb that is .. generated by
>build and signed automatically by build key. You have to trust the build in
>the source to deb translation. Nowadays most builds are reproducible, but
>not all and they were not when buildd keys were introduced. The
>git-to-source conversion is a much simpler process than a build. I have not
>seen any good arguments against applying the same logic here.
>
>2. What is signed is not the same as what the developer has been writing or
>reading. You are putting a lot of weight on this signature of intermediate,
>generated artifacts. Developers basically never verify that contents of the
>tarballs and diffs they are signing actually match the contents of their
>work folder. It would be trivial the create a modified tool in the
>dpkg-source chain that would inject malicious software just into the source
>package files just before they are signed, especially if targeting a
>particular developer.
>
>The tag in git is closest to what the developer inspected and actually can
>sign with confidence. All the downstream from that is a generated artifact
>that may be tampered with and is much harder to manually verify. From this
>perspective relying on debian source package signatures is less secure than
>the proposal with git2upload, but that is what we have historically agreed
>to accept.
>
>There is a bunch of steps between developer uploading the source package to
>the archive and all the way to the end user downloading and installing the
>final package into their system. And we (as Debian) have been diligently
>working towards automating and centrally managing as many of them as
>feasible. All this does is (for some packages) moving the automation state
>one more step closer to the actual source code. Just because this step used
>to be the first does not make it so special as not to be extendable in the
>same way.
>
>And then we can work or reproducible source builds and running two
>conversion servers and comparing results and other security improvements
>(which is a higher bar than what we demand for binary packages that actual
>end users are running).

None of that changes the fact that it's what they signed.  Historically, the 
project has found that useful and I think it still is.

Scott K

Re: Summary of the current state of the tag2upload discussion

[Scott Kitterman]

On Sunday, June 23, 2024 1:55:00 PM EDT Russ Allbery wrote:
> Scott Kitterman  writes:
> > On Sunday, June 23, 2024 11:43:47 AM EDT Russ Allbery wrote:
> >> You are entitled to believe that my analysis is wrong.  You are not
> >> entitled to claim that I didn't do the work that I did, quite publicly
> >> and openly, right here on this mailing list for everyone to see.
> > 
> > This was not intended as a personal attack on you.  I think you've been
> > very diligent in your work and clearly you are trying to be careful to
> > address concerns.  I don't think that's true of everyone involved in
> > this conversation.
> 
> So rather than attacking me, you were insinuating attacks on other people.
> I'm not sure that's any better.
> 
> If you wanted to know why I have been doing most of the discussion rather
> than Sean and Ian, you could just ask.  There is a quite straightforward
> answer:
> 
> 1. I did an independent security review and most of the discussion has
>focused on security and, specifically, on things that I already
>considered in my review.  I therefore have opinions that I thought
>about for weeks before the draft GR was posted, and security is my area
>of professional expertise, so it makes sense for me to address those
>concerns.
> 
> 2. I have a lot of patience for sprawling Debian arguments like this, and
>I get some amount of personal satisfaction out of keeping them
>constructive.  I therefore tend to try to step in and make the
>arguments in a way that I think is the most productive, often before
>someone else can compose a response.  I doubtless do this more than I
>actually need to.
> 
> 3. I'm a self-destructive idealist with poor boundary control who ends up
>thinking about these discussions whether I want to or not, and since
>I'm already waking up in the middle of the night drafting email
>messages in my head, I may as well write them down so that I can go
>back to sleep?  That may be a little harsh on myself.  :)  But I seem
>to allow Debian to destroy my vacations like clockwork every time I
>take one, so why stop now.
> 
> > My impression is that there's still a communication gap between people.
> > I think it's, mostly, in good faith, but it's there.
> 
> Oh, probably, but also there is a limit to how much energy one can
> possibly sink into a discussion, so at some point, if the discussion is
> still stuck, we have to accept that we did the best we could and couldn't
> resolve them and it's time for a GR.  I'm not going to rephrase things
> literally forever until somehow I find the magic phrasing that works and
> gets through the communication gap.  There's only so much that's humanly
> possible.
> 
> > As an example, I think the fact that I can download any source package
> > in the archive and cryptographically verify who uploaded it and that
> > it's unmodified from what was uploaded is an important property of our
> > current archive structure.  IIRC, you've claimed it's not.  I don't
> > think either of us has a very good understanding of why the other
> > believes that.  I think for both of us it's just too obviously true/not
> > true to be easy to explain.
> 
> This is a disagreement.  This is not either of us ignoring each other's
> arguments.  This is us failing to convince each other.  That's not the
> same thing at all.  (And for what it's worth, I don't think it's too
> obviously true to explain.  Quite the contrary, I have written at least
> two comprehensive explanations for exactly why I think this.  But that
> doesn't mean they were convincing to someone else.)
> 
> I rewrote my original message four times to try to avoid implying the
> category into which the FTP team concerns fell.  If I still failed, then I
> sincerely apologize, but I don't think I did.  Here is precisely what I
> 
> said:
> | Blocking people's work beause it's actively dangerous, sure, sometimes
> | we have to do that and it sucks but it may make sense.  But blocking
> | people's work because it didn't solve a larger problem than they wanted
> | to solve, or cared more about backward compatibility than one might
> | wish, or changed a security model in a way that's a little better in
> | places and a little worse than others... that just feels wrong to me.
> | Rude.  Dismissive.  And self-defeating for Debian as a whole.
> 
> There are two options here: actively dangerous, or a bucket of other
> possible objections.  I very carefully did not try to classify people's
> objections into either of those buckets because that wasn't the point.
> 
> This (from an earlier paragraph) was the point:
> | I do 

Re: [RFC] General Resolution to deploy tag2upload

[Scott Kitterman]

On Sunday, June 23, 2024 1:16:38 PM EDT Russ Allbery wrote:
> Scott Kitterman  writes:
> > On Sunday, June 23, 2024 11:48:09 AM EDT Russ Allbery wrote:
> >> As mentioned in the summary, I believe we've found a resolution to this
> >> problem provided that the FTP team is willing to implement the protocol
> >> I described in dak, which Ansgar seemed supportive of.  That allows
> >> them to do both the authentication and authorization check directly on
> >> the Git tag signed by the uploader, which means the trust extended to
> >> tag2upload is then almost precisely equivalent to the trust extended to
> >> a binary buildd:  start from an independently-verified
> >> maintainer-signed thing and produce a build artifact.
> > 
> > I will confess having trouble keeping track of all the back and forth.
> > After that, it was my impression that the press was on to deploy as is.
> 
> So far as I know, no one in this discussion has ever asked for the FTP
> team to deploy tag2upload.  The only hard request of the FTP team is to
> not block uploads made with it.  If the FTP team refuses to do any work
> whatsoever on anything related to tag2upload, it is still possible to
> deploy it (with some assistance from other teams such as DSA, of course).
> 
> There are some very obvious and relatively minor changes to dak that would
> make Debian as a whole more secure and that I would hope the FTP team
> would be willing to make, such as a separate keyring for tag2upload that
> only allows source packages similar to the separate keyring for buildds
> that only allows binary packages.  One of them is to allow tag2upload
> uploads to contain an additional file holding the original signed Git tag,
> and then dak can choose to repeat the authentication and authorization
> checks on that tag, verify that the fields in the *.dsc match the tag,
> etc.  tag2upload can be deployed without those changes, but it would be
> better if those changes were also made.
> 
> If FTP team is willing to incorporate those changes into dak but doesn't
> want to write them, I am sure that we can find volunteers to do so.  That
> volunteer might be me, for example; implementing something practical would
> be a nice break from arguing about things.
> 
> > Regardless, I think the major point is that running on a DSA managed
> > host doesn't necessarily equate to DSA running the service.
> 
> Yes, I think everyone agrees with this and no one expected DSA to run the
> service.  Maybe I'm wrong, in which case someone please correct me.
> Sorting out exactly what "run" means and how labor is divided is something
> that I assumed they would work out with DSA once there was a path forward
> for deploying the service.
> 
> I personally don't know what the standard model for Debian infrastructure
> services is, but I believe Ian has already been through this process with
> the dgit-repos service and knows how it works.
> 
> > I think who is going to run the tag2upload service and if some
> > delegation for doing so is appropriate are both questions that aren't
> > answered by DSA will run the host.
> 
> I believe the answer to who is going to run the tag2upload service is Ian
> and Sean.

Thanks.  I guess I misunderstood the buildd analogy.  I appreciate the 
clarification.

Scott K


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

Re: Summary of the current state of the tag2upload discussion

[Scott Kitterman]

On Sunday, June 23, 2024 11:43:47 AM EDT Russ Allbery wrote:
> Scott Kitterman  writes:
> > I think that can work both ways.  I am old enough to have seen many
> > instances of some new hotness coming along and any objection to it being
> > swept aside because it was clear that the people objecting just didn't
> > understand why the new hotness was so wonderful and why their concerns
> > didn't matter anymore.  My experience has been that when those concerns
> > have been ignored (they usually are), things often don't end well.
> 
> I'm not quite sure how to phrase this (mostly because I want to use much
> stronger language), but I find the belief that what we have just done over
> the past week and a half somehow constitutes ignoring concerns to be
> rather remarkable.
> 
> A whole lot of other people have been involved in this discussion and deep
> in the analysis, but for the moment, I'll just speak for myself here.
> 
> I have, to the absolute best of my ability, taken every concern that
> people have raised very seriously.  I have spelled out exactly where I
> agree with them and where I disagree with them, I have tried to explain in
> great detail precisely why I disagree with the concerns that I disagree
> with, and I posted an entire formal security analysis to that effect.  In
> the places where I was wrong, I have tried to say openly that I was wrong
> and go back and correct the mistaken things that I said.
> 
> Having all of that quite significant work, which has substantially eaten
> into a much-needed vacation and which has literally kept me up nights,
> dismissed as ignoring concerns is
> 
> Well, I guess I don't have words for that.  At least not ones that I want
> to write on this mailing list.
> 
> You are entitled to believe that my analysis is wrong.  You are not
> entitled to claim that I didn't do the work that I did, quite publicly and
> openly, right here on this mailing list for everyone to see.

This was not intended as a personal attack on you.  I think you've been very 
diligent in your work and clearly you are trying to be careful to address 
concerns.  I don't think that's true of everyone involved in this 
conversation.

My impression is that there's still a communication gap between people.  I 
think it's, mostly, in good faith, but it's there.

As an example, I think the fact that I can download any source package in the 
archive and cryptographically verify who uploaded it and that it's unmodified 
from what was uploaded is an important property of our current archive 
structure.  IIRC, you've claimed it's not.  I don't think either of us has a 
very good understanding of why the other believes that.  I think for both of 
us it's just too obviously true/not true to be easy to explain.

Scott K

P.S.  FWIW, the emotional reaction I infer you had when you read my last 
message on this topic is pretty close to the one I had when I read the message 
I was replying to.

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

Re: [RFC] General Resolution to deploy tag2upload

[Scott Kitterman]

On Sunday, June 23, 2024 11:48:09 AM EDT Russ Allbery wrote:
> Scott Kitterman  writes:
> > First, as I understand the position of the FTP Masters involved in this
> > discussion (for clarity, I'm a non-delegated member of the FTP Team
> > (i.e. FTP Assistant)), their view is that determining if an upload is
> > from a person authorized to upload to the Debian archive is a function
> > that is within the scope of their delegated authority and the current
> > tag2upload proposal takes over that function.
> 
> As mentioned in the summary, I believe we've found a resolution to this
> problem provided that the FTP team is willing to implement the protocol I
> described in dak, which Ansgar seemed supportive of.  That allows them to
> do both the authentication and authorization check directly on the Git tag
> signed by the uploader, which means the trust extended to tag2upload is
> then almost precisely equivalent to the trust extended to a binary buildd:
> start from an independently-verified maintainer-signed thing and produce a
> build artifact.

I will confess having trouble keeping track of all the back and forth.  After 
that, it was my impression that the press was on to deploy as is.  

Regardless, I think the major point is that running on a DSA managed host 
doesn't necessarily equate to DSA running the service.  I think who is going 
to run the tag2upload service and if some delegation for doing so is 
appropriate are both questions that aren't answered by DSA will run the host.

Scott K

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

Re: [RFC] General Resolution to deploy tag2upload

[Scott Kitterman]

On Sunday, June 23, 2024 10:57:26 AM EDT Russ Allbery wrote:
> Simon Richter  writes:
> > The difference is the expectation that the delegates will continue to
> > perform this work and therefore need to deal with the long term
> > impact. One-time contributions are welcomed as long as they are a net
> > positive, but not all of them are, and some take up hundreds of hours of
> > volunteer time several years down the line.
> 
> Sure.  I don't think anyone involved has ever intended for tag2upload to
> be a one-time contribution.  It's an ongoing service and the developers
> have been clear that they intend to maintain and further improve it if it
> is deployed.
> 
> > Deploying tag2upload *as a service* is an ongoing commitment, which
> > means creating a new delegation, or altering the scope of an existing
> > one. We need to be explicit which one it is.
> 
> I don't know what the general practice is for Debian project
> infrastructure.  There isn't a separate delegation for the buildds, even
> though I don't believe they're run by the FTP team, and I don't think
> they're entirely covered by the DSA delegation.  tag2upload is essentially
> a source package buildd, so however the buildds are handled might make
> sense, although I realize binary buildds are a bit more complicated since
> it's often different people per architecture.
> 
> In other words, I'm not sure that "ongoing commitment" == "delegation"
> (either new or existing).  I think there are lots of things in Debian that
> are ongoing commitments but not delegations.  But I can also see the
> argument for considering that a bug and wanting a delegation for any new
> ongoing service.

I think that misses some key points, although I mostly agree.

Three thoughts:

First, as I understand the position of the FTP Masters involved in this 
discussion (for clarity, I'm a non-delegated member of the FTP Team (i.e. FTP 
Assistant)), their view is that determining if an upload is from a person 
authorized to upload to the Debian archive is a function that is within the 
scope of their delegated authority and the current tag2upload proposal takes 
over that function.

Second, whatever the current buildd's do, it's downstream of that decision, so 
not involved in the question of if a new upload is authorized or not.  I don't 
think the buildd analogy is particularly helpful here.

Third, even though the host that DAK runs on is DSA managed, DAK is not.  It's 
maintained and developed by the FTP Team and that's an explicit part of the 
FTP Master's delegation.  Assuming tag2upload is integrated into the package 
upload process, I think it is clear it will have to run on a DSA managed host, 
but that's a separate question from who will manage the tag2upload service.

The idea what we would take something that's part of one team's delegated 
responsibility and move it elsewhere for some types of uploads without that 
also being subject to some form of DPL delegation seems wrong.

Scott K


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

Re: Summary of the current state of the tag2upload discussion

[Scott Kitterman]

On Sunday, June 23, 2024 10:46:33 AM EDT Russ Allbery wrote:
> Matthias Urlichs  writes:
> > On 23.06.24 04:45, Russ Allbery wrote:
> >> that just feels wrong to me.  Rude.  Dismissive.  And self-defeating
> >> for Debian as a whole.
> > 
> > 100% agree. Though again: that *feels* rude and dismissive. I'm *not*
> > ascribing *intent* to be rude or dismissive to anybody here, and I'm sure
> > Russ isn't either.
> 
> Yes, thank you, that's an important clarification and I agree.  I do not
> want to speculate about other people's intent, and I think it's very easy
> to get mentally stuck in a corner when new work changes an invariant that
> you believed was important, even if it comes with an argument for why that
> invariant isn't as important as you thought.

I think that can work both ways.  I am old enough to have seen many instances 
of some new hotness coming along and any objection to it being swept aside 
because it was clear that the people objecting just didn't understand why the 
new hotness was so wonderful and why their concerns didn't matter anymore.  My 
experience has been that when those concerns have been ignored (they usually 
are), things often don't end well.

Scott K

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

Re: [RFC] General Resolution to deploy tag2upload

[Scott Kitterman]

On June 21, 2024 6:35:48 PM UTC, Russ Allbery  wrote:
>Scott Kitterman  writes:
>
>> This whole thread is about a draft GR to override a FTP Master decision
>> based on a claim that they had refused to engage with the tag2upload
>> developers for years to explain their concerns or work on resolving
>> them.
>
>> None of that turned out to be accurate.
>
>tag2upload is still being blocked by the FTP team so far as I can tell (I
>don't understand if Joerg's last message changes this), and a GR is still
>the only way to unblock that work that I can see.
>
>It is true that we have now finally had the discussion, with actual
>engagement, that we needed to have.  (And this is exactly why I am so in
>favor of draft GRs for controversial proposals.  That final check is often
>so incredibly useful at uncovering communication problems and getting
>discussions to happen.)
>
>But so far, this has not resolved the problem that one team's work is
>being blocked by a delegate decision with no obvious path forward that
>achieves their goals.  Maybe we will still be able to resolve this: for a
>brief moment, it looked like there was some movement, and then Ansgar
>walked it back.  But I'm still willing to talk about that (and also
>because Joerg asked to keep talking about it for a bit longer).
>
>As things currently stand, though, a GR is still the only path forward.

I don't think that every time an FTP Master makes a statement on a mailing list 
it should be considered a delegate's decision.  I think that's only true if the 
tag2upload developer's view is that only deploying exactly what they have 
developed with no change is the only option.

I would hope that we can be more collaborative than that in Debian.

I get that there's a lot of frustration and impatience, but I think that is 
largely the result of misunderstanding and an absence of communication that was 
not understood to exist.  I think it would be better to reset and actually have 
the conversation that was assumed to have happened before taking the step of a 
GR.

I see broad agreement on the goals of tag2upload (at least to a certain level 
of detail) and I don't think there's any clear evidence that a solution that 
meets those goals while also addressing the FTP Master's concerns isn't 
possible.

Scott K

Re: [RFC] General Resolution to deploy tag2upload

[Scott Kitterman]

On June 21, 2024 4:26:41 PM UTC, Russ Allbery  wrote:
>Ansgar   writes:
>> On Fri, 2024-06-21 at 08:29 -0700, Russ Allbery wrote:
>
>>> Wait, why would I ever want to upload a 3.0 (native) package for a
>>> non-native package with the tooling as it is today in Debian?
>
>> As far as I understand this whole thread is about changing the tooling.
>
>This whole thread is about deploying something that already works with our
>existing tooling and doesn't require boil-the-ocean changes to Debian
>infrastructure or workflows.

This whole thread is about a draft GR to override a FTP Master decision based 
on a claim that they had refused to engage with the tag2upload developers for 
years to explain their concerns or work on resolving them.

None of that turned out to be accurate.

Given that, perhaps debian-vote isn't the best place to do archive design work 
and we should stop and try to actually collaborate on an appropriate solution.

Scott K

Re: [RFC] General Resolution to deploy tag2upload

[Scott Kitterman]

On June 17, 2024 10:56:11 AM UTC, Ian Jackson  
wrote:
>Joerg Jaspert writes ("Re: [RFC] General Resolution to deploy tag2upload"):
>> On 17262 March 1977, Sean Whitton wrote:
>> > I would ask you not to characterise the disagreement we are having as
>> > merely over a technical detail.
>> 
>> You see this as personal? I don't, but if it is not technical, what 
>> else?
>
>I think Sean means it's not a detail.  From our point of view, we're
>talking about a critical property of our design.
>
>> Which behind the scenes? To who did you talk?
>
>Firstly, I want to ask: would it have made any difference if we had
>raised the matter in public again on -devel?
>
>Based on your replies here, it seems that ftpmaster's objections are
>still just as firm now as they have been over the past four years.
>We wouldn't want to keep asking the same question on a list like
>-devel, when we are pretty sure the answer will just be the same; that
>would be rude to both ftpmaster and the rest of Debian.
>
>Anyway, if we're going down this route:
>
>I think we didn't speak to ftpmaster directly about this since 2019.
>
>I don't want to name names in case this turns into a finger-pointing
>exercise, but, over the years, we have spoken to various people, with
>varying levels of formality:
>
> * We made fairly formal appeals to two sitting DPLs.  What we got
>   was, basically, attempts at mediation, or facilitation of
>   discussions.  We didn't see that as helpful, since we saw an
>   irreconcilable gap between our position and ftpmaster's.
>
>   Sean and I were under the impression that the most recent response
>   we got from a sittinug DPL was sent to us after consulting with
>   ftpmaster.
>
> * We have asked for help from two sitting members of the TC, and one
>   former DPL.  I don't think any of those people would have spoken to
>   ftpmaster, but neither did they suggest that we should raise the
>   matter on -devel again.
>
>   One outcome of that was encouragement to give the talk I did at the
>   2023 Cambridge minidebconf.  I explicitly stated that the project
>   was blocked by ftpmaster, but of course I don't expect ftpmaster to
>   have necessarily seen that talk.
>
It seems to me that you are the one that's unwilling to engage in any 
discussion on the topic and as a result, have blocked yourself.

I don't know that there is an irresolvable disconnect between your design goals 
for tag2upload and the FTP Masters' design goals for managing access to the 
Debian archive.  Unfortunately, due to your unwillingness to engage in good 
faith dialogue on the topic, it's likely we'll never know.  If you keep on the 
current path, one of two things is going to happen:

1.  Your GR passes and you get what you want.

2.  Your GR fails and tag2upload is dead.

Personally, I don't like either of those outcomes.

My recommendation is that you step back, give everyone about 6 months to cool 
off and then actually engage with the FTP Team to see if we can do both.

Scott K

Re: Security review of tag2upload

[Scott Kitterman]

On June 17, 2024 5:29:02 AM UTC, Russ Allbery  wrote:
>Scott Kitterman  writes:
>
>> I don't equate responsibility and blame.  If I'm responsible for
>> something and it blows up, then that means I'm responsible to help clean
>> up the mess, regardless of if the thing that went wrong is my fault or
>> not.
>
>How is that type of responsibility not correctly represented by
>tag2upload?  tag2upload is taking responsibility for construction of the
>source package from a Git tree.  If that blows up, it's the responsibility
>of the tag2upload maintainers to help clean up the mess.  The maintainer
>is declaring responsibility for the Git tree that they signed.  If that
>blows up, it's their responsibility to help clean up the mess.
>
I meant it more as a general point about responsibility versus blame in 
response to your point about a culture of blameless post-incident autopsies.

Given the 5 year latency on this discussion, I'm not particularly convinced 
that's true, but I wasn't really trying to tie this into the broader discussion.

Scott K

Re: A thought experiment regarding tag2upload and trust

[Scott Kitterman]

On June 17, 2024 5:23:41 AM UTC, Russ Allbery  wrote:
>Bastian Blank  writes:
>
>> But maybe you can answer the question:  Given the .dsc file, how can
>> you, and more critical the public, verify that you and only you signed
>> that upload?
>
>Why is this, specifically, important?
>
>I can turn that question around: given the .dsc file, how can I find the
>Git tree that the maintainer vetted and intended to upload to the archive?
>Why should I have any faith in the archive if I cannot verify that?
>
>I don't think this is a useful way to talk about the security guarantees
>that we can provide.  You are massively overindexing on a very specific
>implementation detail that does not prove what you seem to think it
>proves.
>
I think if you want to step away from the implementation details, the more 
abstract point is that you don't need data from outside the archive (or a 
mirror of the archive) in order to verify that the source package you 
downloaded has not been modified since then and who uploaded it.

You may not think that this property of our package archive is particularly 
important, but not everyone agrees.

As it happens though you can't tell if what's in the archive matches the 
uploader intent with tag2upload either.  All you can vet is that the tag2upload 
service claims it does.  You may think that's better, but neither of them are 
entirely free of risk.

Scott K

Re: A thought experiment regarding tag2upload and trust

[Scott Kitterman]

On Monday, June 17, 2024 12:25:28 AM EDT Louis-Philippe Véronneau wrote:
> On 2024-06-15 5 h 03 a.m., Philip Hands wrote:
> 
> > Sean Whitton  writes:
> > ...
> > 
> >> The ftpmaster team have refused to trust uploads coming from the
> >> tag2upload service.  This GR is to override that decision.
> > 
> > 
> > Full disclosure:
> > 
> > 
> >I'm a happy dgit user. The support I've had from Ian for dgit (when I
> >messed things up, generally) has been outstandingly good, and has
> >generally resulted in a change to dgit that prevents me (and others)
> >from messing up in a similar manner. It strikes me that tag2upload is
> >another stride in the same direction, so I'd like to have the chance
> >to use it, because I suspect that it will also make contributing to
> >Debian easier, less error-prone, and just more pleasant.
> > 
> > 
> > [Note: in the following, I am NOT trying to suggest a technical fix, so
> > 
> >   please don't start nitpicking the details -- it's just a thought
> >   experiment that I hope might shed some light on the situation]
> > 
> > 
> > If it were easy to deploy an instance of tag2upload in my house,
> > populated with a sub-key of my GPG key, I would probably set that up
> > (and then start worrying about the security of the sub-key ;-) ).
> > 
> > If I did that, I believe the FTP masters would still accept my uploads.
> > 
> > Should they?  or is it perhaps the case that they are objecting to the
> > idea that tag2upload is capable of reliably generating a source package
> > from a git tag. (I personally trust Ian when he says that it is capable)
> > 
> > If Ian were to offer a hosting service for such personal tag2upload
> > instances, in a way that he assured me could not be used to sign
> > packages unless I had signed a matching git-tag, I would be willing to
> > trust his assurances, and may well take him up on the offer.
> > 
> > It seems to me that such a centralised service is more likely to do
> > things like keep the keys in an HSM, and have effective separation of
> > the components, than something set up by a random developer at home, so
> > one could argue that it's going to be more secure than the self-hosted
> > version.
> > 
> > Would the FTP masters still be OK with that?  If not, what's changed?
> > 
> > If that's OK, but tag2upload as proposed is not, are we really drawing a
> > line based on what name is on the signing key?
> > 
> > Would it make any difference to the FTP masters if there was some way
> > for me to assert that I trust the tag2upload service/key to build/sign
> > source packages for me?
> > 
> > For instance, if one had to sign something with a GPG key that matches
> > the one that later signs a gpg tag, before tag2upload would be willing
> > to process one's signed tags, would that make the FTP masters happier?
> > 
> > Personally, I'm not convinced that would really add anything, since if
> > one has sufficient control of the key to push a signed tag, then one's
> > also going to be able to sign a statement that you want tag2upload to
> > act on that tag, but I thought that describing the options might help
> > narrow down what the perceived problem is.
> > 
> > Of course, without something describing exactly what the problem is from
> > the FTP master's point of view, it's very hard to judge the merits of
> > their position.
> > 
> > Cheers, Phil.
> 
> 
> Thanks for this thought experiment. Although I was already in favor of 
> the proposal, it helped me get a better grasp of what is at stake in 
> this GR.
> 
> As many others have asked already, if there is really an opposition from 
> the FTP masters to the t2u proposal as stated in the draft GR, I urge 
> them to make it heard, especially with regards to Phil's email.

Given recent email on the list, are you still confused about this?

Socially, I think this whole thing is awful.  The objection was clearly stated 
5 years ago and then after 5 years of silence, a GR out of nowhere claiming an 
unwillingness to engage.  So far as I'm aware, no one on the FTP Team has been 
able to find a record of any discussion between the FTP Team and the tag2upload 
developers on this topic since 2019.

Is this how we want Debian to work?

Scott K




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

Re: Security review of tag2upload

[Scott Kitterman]

On Sunday, June 16, 2024 3:59:40 PM EDT Russ Allbery wrote:
> Scott Kitterman  writes:
> > Yes.  I think that's the core of the disagreement.  In my view, when I
> > type the passphrase for my key, I'm asserting responsibility for the
> > contents of what I'm signing.  It doesn't mean it is correct or
> > uncompromised, but I am taking responsibility for it.
> 
> Right.  And I come from a culture that emphasized blameless postmortems
> and systems design and a way of thinking about security review from a
> similar perspective, which is that assigning responsibility is not in and
> of itself a useful thing to do.  Just because someone is responsible
> doesn't mean that we're more secure.  It may mean that you have someone
> you can punish afterwards, but it's very questionable how much that helps
> with security, really.
> 
> Assigning responsibility is, in that model, only important to the degree
> to which it will change people's actual behavior towards behavior that is
> more secure, either before or after the fact.  If one assigns
> responsibility for something that isn't realistically under their control,
> or in a way that doesn't cause their behavior to change, the argument is
> that nothing is truly accomplished from a security standpoint.  It's an
> illusion of security without actual security.
> 
> One of my goals in doing security design is to try to reduce the degree to
> which humans are performing repetitive validation tasks because humans are
> not good at maintaining constant vigilance.  We know this from a bunch of
> empircal studies on, for example, airport screening.  If a human does a
> repetitive task with a very low rate of true positives, their attention
> will fade and there will be a lot of false negatives.  Asking humans to do
> this is a recipe for failure, and making the humans responsible for doing
> this correctly and threatening them with consequences for not doing it
> correctly only slightly decreases the risk of failure.
> 
> This is exactly why reproducible builds are so important: that involves
> finding a way for computers to do the sorts of repetitive validation tasks
> that computers are good at and that humans are very bad at.

I don't equate responsibility and blame.  If I'm responsible for something and 
it blows up, then that means I'm responsible to help clean up the mess, 
regardless of if the thing that went wrong is my fault or not.

Not security related, but a couple of times I have (as a member of the FTP 
Team) removed packages that shouldn't have been removed.  Even though it 
wasn't particularly my fault (in the cases I'm remembering, the rm bugs had 
been filled out unclearly or incorrectly, I was still responsible to straighten 
it out and I did.  I don't think that we are that different in our views of 
what's important, but we do describe it a bit differently.

Scott K


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

Re: Security review of tag2upload

[Scott Kitterman]

On June 16, 2024 6:23:18 PM UTC, Russ Allbery  wrote:
>Scott Kitterman  writes:
>
>> I think it's just that I view a signature by a mechanized service as
>> something different that a signature made by an actual person.
>> Technically you are correct, but I think it's fundamentally different.
>> I don't think the computer is responsible for anything.  I think it has
>> to trace to a person if you want to talk about responsibility.
>
>Okay, thanks, I think this is the core of our disagreement.  Let me sum up
>my side, just to be very clear about what I think the disagreement is.
>
>I don't believe that "a signature made by an actual person" is something
>that exists in the real world.  Humans do not sign things.  We do not have
>an OpenPGP implementation in our heads.  Signatures are always made by
>software, running on a possibly compromised computer, directed by humans.
>Any link between the human and the signature is a point of possible
>attack.
>
>For the existing source package signatures, a simplified sequence looks
>like this:
>
>human --> (1) dpkg-buildpackage --> (2) debsign --> (3) archive
>
>For tag2upload, a simplified sequence looks like:
>
>human --> (1) Git --> (2) tag2upload --> (3) debsign --> (4) archive
>
>In our current system, the source package signature can be traced back to
>(2).  In the tag2upload case, the source package signature can be traced
>back to (3) using the existing techniques and, with more work and new
>techniques, all the way back to (1).
>
>In neither case can the source package signature be traced back to a
>human, which is what I am arguing makes them similar.  What we're arguing
>about is which system has the better design (both security and otherwise)
>for the pieces prior to (2) in the first case and (3)/(1) in the second
>case.
>

Yes.  I think that's the core of the disagreement.  In my view, when I type the 
passphrase for my key, I'm asserting responsibility for the contents of what 
I'm signing.  It doesn't mean it is correct or uncompromised, but I am taking 
responsibility for it.

Scott K

Re: Security review of tag2upload

[Scott Kitterman]

On Sunday, June 16, 2024 12:46:41 PM EDT Russ Allbery wrote:
> Scott Kitterman  writes:
> > I agree that there's a risk that what the uploader thought they were
> > uploading and what they actually uploaded are different, but that's
> > independent of tag2upload or not.
> 
> But it's not independent; tag2upload makes this story somewhat better.
> tag2upload is based on a signed Git tag and moves the source package
> construction off of the uploader's system onto more-secure project
> infrastructure.  It therefore moves the uploader's signature closer to
> their intent: it's a signature over the thing that they are more likely to
> have directly reviewed, not over a build artifact derived from their Git
> tree.

I can see that, but that leads to what I view as a problem.  The thing in the 
archive is signed by a machine, not the human who decided it should be 
uploaded.

> > I also agree there are tradeoffs on all this.  In the particular case of
> > source package construction, there's a tradeoff between doing it on a
> > centralized, managed service with a known configuration that is internet
> > exposed versus the variety of unknowns associated with individual
> > developer machines.
> 
> Right, for some value of Internet-exposed that can be fairly restrictive.
> 
> > There are different risks for the end user.  Currently dget uses
> > dscverify by default before unpacking a source package.  I'm not an
> > expert at all, so I don't have any appreciate for the perceived risks
> > that led to that being the default (IIRC, it wasn't always).  I am
> > assuming that wasn't random.  I'm not sure how that would work in this
> > new paradigm.
> 
> Well, it obviously still works (once it's aware of the tag2upload key) but
> the signature is by the entity that constructed the source package, so
> dscverify will trace the signature back to the tag2upload server and not
> to the uploader's system.

It's signed by tag2upload, not the human that decided to upload it.  
Personally, I think that's significant.

> >> I think it would be hugely valuable to have something like a "dgit
> >> verification mode" where you can ask dgit, which already has all the
> >> source package construction logic, to take a tag2uplod-generated source
> >> package, start from the tag object and signature, and reproduce that
> >> source package and verify it.  Except for the retrieval of the signed
> >> Git tag, in theory all of that could be done locally.  I'm not sure how
> >> hard that would be (this comes back to the question of how difficult it
> >> is to ensure that the tag2upload source construction algorithm is
> >> easily reproducible), but I think something like that would go a long
> >> way towards providing some really interesting security properties.
> > 
> > I think this is much more manageable if you assume the whole world uses
> > git all the time for everything and git is the interface, but that's not
> > reality.
> 
> I'm extremely confused.  Of course you can assume that for any package
> signed with tag2upload.  tag2upload will only act on Git repositories and
> therefore anything that it has worked on necessarily had to use Git as the
> interface.
> 
> Maybe you thought I was implying that this dgit verification mode would
> work with general source packages and not just tag2upload packages?  No,
> it cannot, because in the general case we have absolutely no idea how to
> map a source package in the archive back to a Git tree.  That's exactly
> the problem that tag2upload is trying to solve.  For non-tag2upload
> packages, we still have to rely on the source package as the farthest back
> that we can trace the code without diverging into package-specific
> analysis and diverging maintainer workflows.

No, I understood that.  I guess I view this somewhat differently.  In my mind 
the signature on a source package is a developer saying that they believe it 
should be in the Debian archive and the archive tools verify that the human 
making that assertion has the authority to do so.  In my view, the tag2upload 
signature is something fundamentally different.

> > Personally, I think the ability to interact with the archive to do the
> > verification and not relying on things that are not the archive for the
> > code to verify is an important property of the existing system and I
> > don't think it's feasible to maintain it in a tag2upload world.
> 
> Here too, I don't understand exactly what you are saying.  All of the
> source packages uploaded to the archive via tag2upload will verify.  They
> have valid OpenPGP signatures.  That OpenPGP signature traces the
> provenance of the sou

Re: Security review of tag2upload

[Scott Kitterman]

On Sunday, June 16, 2024 12:01:31 PM EDT Russ Allbery wrote:
> Scott Kitterman  writes:
> > Yes and no.  The difference is that currently, I can download the source
> > package and verify it myself.  Not just who signed it and with what key,
> > but that the signature verifies.  I don't need to trust assurances from
> > any service.
> 
> No, that's not quite true.  You're still trusting assurances from the
> uploader's system.  The uploader did not, in general, directly check the
> artifact whose signature you're verifying; they, and you, are trusting
> that the source package construction was done correctly from their working
> tree.
> 
> There's been a lot of discussion of the implications of the xz backdoor
> for source package construction, but one of the takeaways that I took from
> it is to be even less sure of the security of the uploader systems that
> are generating our source packages.  Imagine if xz had been backdoored to,
> say, inject the installation of a malicious maintainer script into source
> packages constructed on that system.  How long would it have been before
> we noticed?  The malicious code would have been signed by the uploader and
> all the signatures would verify without difficulty.
> 
> Certainly we would have noticed eventually.  Probably we would have
> noticed before the next stable release.  But I'm not at all sure we would
> have noticed before a lot of Debian uploader systems were backdoored and
> potentially a lot of uploader keys were stolen depending on uploader key
> storage practices.  And there are probably sneakier attacks that I haven't
> thought of.

I agree that there's a risk that what the uploader thought they were uploading 
and what they actually uploaded are different, but that's independent of 
tag2upload or not.  I also agree there are tradeoffs on all this.  In the 
particular case of source package construction, there's a tradeoff between 
doing it on a centralized, managed service with a known configuration that is 
internet exposed versus the variety of unknowns associated with individual 
developer machines.

There are different risks for the end user.  Currently dget uses dscverify by 
default before unpacking a source package.  I'm not an expert at all, so I 
don't have any appreciate for the perceived risks that led to that being the 
default (IIRC, it wasn't always).  I am assuming that wasn't random.  I'm not 
sure how that would work in this new paradigm.  

> > From the perspective of Debian, the project, that's presumably not
> > significant and can be accounted for by updating our tools.  From the
> > perspective of some Debian users, I'm less certain of the significance.
> 
> I think it would be hugely valuable to have something like a "dgit
> verification mode" where you can ask dgit, which already has all the
> source package construction logic, to take a tag2uplod-generated source
> package, start from the tag object and signature, and reproduce that
> source package and verify it.  Except for the retrieval of the signed Git
> tag, in theory all of that could be done locally.  I'm not sure how hard
> that would be (this comes back to the question of how difficult it is to
> ensure that the tag2upload source construction algorithm is easily
> reproducible), but I think something like that would go a long way towards
> providing some really interesting security properties.

I think this is much more manageable if you assume the whole world uses git 
all the time for everything and git is the interface, but that's not reality.  
Personally, I think the ability to interact with the archive to do the 
verification and not relying on things that are not the archive for the code to 
verify is an important property of the existing system and I don't think it's 
feasible to maintain it in a tag2upload world.

Maybe that's OK, but I don't think it's nothing and it should be acknowledged 
as a cost of moving in this direction.

Scott K

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

Re: [RFC] General Resolution to deploy tag2upload

[Scott Kitterman]

On Sunday, June 16, 2024 12:26:48 AM EDT Sean Whitton wrote:
> Hello,
> 
> On Sat 15 Jun 2024 at 06:03pm +02, Joerg Jaspert wrote:
> > On 17258 March 1977, Sean Whitton wrote:
> >> So, why am I proposing a GR?
> > 
> > This one took me by surprise, honestly.
> > 
> > Looking into my notmuch, the last time tag2upload came up in my
> > ftpmaster inbox was in 2019. Between then and now there doesn't appear to
> > be any serious contact with us about it. There had been mentionings on
> > some mailing list somewhere, but nothing coming to us, that I can
> > find.
> 
> In recent years, you have stepped in with your expertise in a number of
> emergencies, and I am most grateful for that.
> 
> But with respect, you have not otherwise been active in the ftpmaster
> team, and you didn't significantly participate in the original
> tag2upload discussions.  So I think you may be missing things.
> 
> We have been seeking help behind the scenes over the past four years.
> No progress was made, so we decided to draft a GR.
> 
> > Even then, back in 2019, one of the major points that ftpteam members
> > raised had been "the archive has to be the final point to check if an
> > upload is accepted" and that we do retain *all* user signatures of
> > source packages, and that such a service must provide the same level
> > of possible verification. Some other requirements on the signature too
> > (collision resistant, need to be verifyable with only stuff included
> > in the source package). Also something about not using Perl, but meh,
> > lets ignore that one here.
> > 
> > So, 5 years of (hopefully) development, but the major point (this should
> > *not* bypass/circumvent archive upload checks and restrictions) did not
> > get addressed. More like, entirely ignored.
> 
> Like Russ, I'm grateful for how you've set out some things more clearly
> in this message.  I'm looking forward to reading your reply to him.
> 
> I would ask you not to characterise the disagreement we are having as
> merely over a technical detail.
> It's the essence of tag2upload that the tag metadata is minimal, and
> easily generated by a short shell script, like git-debpush.
> 
> We did not ignore your position: we argued against it.  No-one from
> ftpmaster has responded to our arguments for wanting the metadata to be
> minimal.  So as I say, I'm looking forward to your reply to Russ.

I don't think this is fair.  Joerg is paraphrasing an email he sent the last 
time (that I can find) this was discussed[1]:

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

My local mail archive is incomplete, but I only find one reply from the 
tag2upload developers that proposes some possible mechanisms to address this 
concern [2].  I don't find any arguments against it or claims that the metadata 
has to be minimal.  As far as I can tell, none of the design changes Ian 
suggested might mitigate this concern are included in the current design.  
While I'm not an FTP Master, I have been active on the team as an FTP 
Assistant during most of this time.

Before the posting of the draft GR, I simply have no evidence of any 
communication regarding tag2upload with the FTP Team since 2019.  Since 2019, 
I have one mention of tag2upload in an email that by either of you in a 
message Ian sent to debian-project in 2023.

I know we are supposed to assume good faith, but this whole thing certainly 
felt like an ambush to me when you proposed it.

Scott K

[1] https://lists.debian.org/msgid-search/87lfvdw1y3@ganneff.de
[2] https://lists.debian.org/msgid-search/
23911.41752.922344.263...@chiark.greenend.org.uk

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

Re: Security review of tag2upload

[Scott Kitterman]

On June 16, 2024 6:44:35 AM UTC, Russ Allbery  wrote:
>Scott Kitterman  writes:
>
>> I appreciate the thought and effort that went into this review.
>
>> If I'm following your description correctly, the tag2upload "package" flow 
>> is:
>
>> developer --> salsa --> tag2upload --> ftp.upload.debian.org
>> machine   --> dgit-repos
>
>> Is that right?
>
>Yes, I think so.
>
>> While it may not matter from a post attack detection security trace
>> perspective, I think there are more routine trace activities that this
>> complicates.  A couple of examples are the signed by listing in the
>> tracker.d.o news section for packages and who-uploads from devscripts.
>
>> While making package signing information less visible isn't directly a
>> security issue, it does seem like a complication that makes it harder to
>> keep up with what's going on.
>
>> Would you consider these kind of indirect effects relevant from a
>> security analysis perspective or are they just non-security concerns
>> from your POV?
>
>I made the assumption that, if tag2upload were deployed, those tools would
>be modified to pick up the signer information from the *.changes fields
>where tag2upload puts it.  That metadata is put into both the *.dsc and
>the *.changes files.
>
>As with the other parts of this proposed design, that does require
>trusting tag2upload to do the authentication check properly, so a
>compromised tag2upload server could write erroneous trace information and
>therefore would not be detected by either of those tools.
>
>A tag2upload server compromise is fairly serious.  A compromise of any of
>tag2upload, dak, or the buildds have roughly equally serious potential
>impact on the archive as far as I can tell, although the details differ.
>In all three cases, you need reproducible builds to reliably detect the
>compromise, although in the tag2upload case you only need reproducible
>source builds for the specific set of source transformations that
>tag2upload is willing to perform, which I believe is a much easier problem
>than the reproducible binary builds required to detect buildd or dak
>compromises.  dak, uniquely, can meddle with either source *or* binary
>packages, but dak meddling with source packages will break the signatures
>on those packages, so is somewhat easier to detect than dak meddling with
>binary packages.
>
>(This is assuming I'm not missing some security control in dak, which is
>entirely possible because I've not done a comprehensive security review of
>dak and am not certain of all the details of the architecture.  If I'm
>missing something, please do correct me!)


Yes and no.  The difference is that currently, I can download the source 
package and verify it myself.  Not just who signed it and with what key, but 
that the signature verifies.  I don't need to trust assurances from any service.

From the perspective of Debian, the project, that's presumably not significant 
and can be accounted for by updating our tools.  From the perspective of some 
Debian users, I'm less certain of the significance.

Scott K

Re: [RFC] General Resolution to deploy tag2upload

[Scott Kitterman]

On June 16, 2024 4:38:03 AM UTC, Sean Whitton  wrote:
>Hello,
>
>On Fri 14 Jun 2024 at 06:06pm GMT, Scott Kitterman wrote:
>
>>
>> I'm a bit confused by the claim that no infrastructure changes are needed for
>> this to go forward.
>>
>> If I have been following the proposal correctly, source packages will be
>> signed by tag2upload and not the uploader.  Doesn't that mean changes are
>> going to be needed so that we know in the archive who uploaded the package?
>>
>
>Ah, do you mean how tracker.d.o shows (signed by: f...@bar.org) for a
>sponsored upload?
>
That's one place it shows up.

Today I can download any source package in the archive and verify who uploaded 
the package and is responsible for its contents.  It doesn't matter if I 
download it from the main archive or a mirror.  Personally, I think that's an 
important characteristic of our package archive, which is lost by tag2upload.

Scott K

Re: Security review of tag2upload

[Scott Kitterman]

On Tuesday, June 11, 2024 9:39:04 PM EDT Russ Allbery wrote:
> Hi all,
> 
> Below is the security review that I did of the tag2upload design.
> 
> I am not a neutral party, in the sense that I think tag2upload is a good
> idea and should be deployed.  However, I do these types of security
> reviews professionally, and I tried to approach this review the same way
> that I would approach a major work project that needed a security review
> to ensure we weren't deploying something with security issues.  I
> encourage any Debian community member with security expertise to check my
> work; with security reviews, the more eyes, the better.
> 
> I will also post this review on my web site, probably later tonight if I
> have time.

I appreciate the thought and effort that went into this review.

If I'm following your description correctly, the tag2upload "package" flow is:

developer --> salsa --> tag2upload --> ftp.upload.debian.org
machine   --> dgit-repos

Is that right?

While it may not matter from a post attack detection security trace 
perspective, I think there are more routine trace activities that this 
complicates.  A couple of examples are the signed by listing in the 
tracker.d.o news section for packages and who-uploads from devscripts.

While making package signing information less visible isn't directly a 
security issue, it does seem like a complication that makes it harder to keep 
up with what's going on.

Would you consider these kind of indirect effects relevant from a security 
analysis perspective or are they just non-security concerns from your POV?

Scott K


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

Re: [RFC] General Resolution to deploy tag2upload

[Scott Kitterman]

On Friday, June 14, 2024 9:23:03 PM EDT Russ Allbery wrote:
> Scott Kitterman  writes:
> > Maybe.  Maybe this breaks the thing into two parts in a way it wasn't
> > before If you verify the signature on the source package and the key is
> > in the keyring, you know that the package was uploaded by someone
> > authorized to do so and that the code you have is what they signed.
> > With tag2upload you have neither.  You have tag2upload's claim of who
> > signed the tag and the source package constructed by tag2upload.  The
> > connection to what the uploader intended to upload is completely
> > indirect.
> 
> I guess I consider separating authentication from authorization to be a
> pretty routine thing to do, since I've worked on lots of systems that do
> that.  But yes, it is a change from dak's perspective in that it is no
> longer the sole agent involved in authentication checks and it has to
> trust that tag2upload did its part correctly.
> 
> > I don't think there's any real mystery about this, but the claim in the
> > draft GR was that there was an unwillingness to communicate.
> 
> I cannot speak for the authors of the draft GR, but the claim that I would
> make is that there seems to be a lot of reluctance on the part of the FTP
> team to communicate *why* they think that trusting tag2upload is a
> problem.  My conversation with Ansgar felt typical to me: vague assertions
> of security problems without an explanation of what those assertions are
> based on.
> 
> Again, this is their perogative under the Debian constitution, although it
> has reached a point that I personally find a bit rude.  But the project
> can decide how much weight to put on those assertions.
> 
> With any luck, there's an explanation already waiting in my inbox while
> I'm writing this and I'll be happily wrong.  :)
> 
> I guess my assumption is that the security objections are based on a gut
> feeling or vibes, which makes them hard to explain.  That's a real thing,
> and I am familiar with the feeling, but I also don't expect it to be that
> persuasive to other people.  When it comes down to rejecting substantial
> amounts of work that other people have put into solving a problem they
> care deeply about, I feel like it's my responsibility to really dig in and
> figure out what my vibes are based on or to let go of my objection.
> That's my personal take; obviously other people can have their own
> opinions on that score.
> 
> If the objection is that there should be one and only one piece of
> software that verifies package upload signatures, meh, sure, all other
> things being equal it's better to only have to trust one system than two,
> but the whole point is that all other things aren't equal.  Additional
> complexity is always a drawback, but it's also often the cost of adding
> new features.  If that's the sole objection, it seems pretty weak to me.
> 
> If the objection is that the implementation of the tag2upload security
> checks is not secure, then that is a very real problem that would need to
> be fixed and someone should spit out the details so that we can have a
> real discussion.  But I have a hard time imagining that this is a blocking
> architectural objection.  It's clearly possible to securely verify a Git
> tag signature, modulo concerns about SHA-1 hashes that have been discussed
> exhaustively elsewhere.  If tag2upload is doing it wrong, then tag2upload
> can be fixed.
> 
> But this is all speculation on my part.  I don't actually know what the
> objection is because no one has explained it, at least that I have seen
> and understood.  Maybe I just missed it.
> 
> > Some or all of them may be unwilling to continue to be responsible for
> > managing the security of the archive once the security of the system has
> > been (in what I believe to be their view) compromised.
> 
> You narrowly dodged me going off on a long rant about one of my pet peeves
> about the computer security profession, but I had a nice dinner with my
> family and decided to spare everyone.  :)
> 
> I guess the main thing that I will say to this is that I certainly hope
> people are not feeling this way because I think that would be an unhealthy
> way to approach a dispute.  I guess this gets into personal philosophy,
> but I think it's important to not hold one's positions so tightly that
> they become brittle.  I find that when I do that, *I* become brittle, and
> it's a deeply unpleasant experience.
> 
> It's not very helpful to think of systems as secure or insecure.  Security
> is always and forever a tradeoff.  This is particularly true of the sort
> of discussion where we're having, where no one is identifying a concrete
> attack that could 

Re: [RFC] General Resolution to deploy tag2upload

[Scott Kitterman]

On Friday, June 14, 2024 6:37:40 PM EDT Russ Allbery wrote:
> Scott Kitterman  writes:
> > On Friday, June 14, 2024 5:25:33 PM EDT Russ Allbery wrote:
> >> It requires that the signature on the Git tag be correctly checked and
> >> that fingerprint be put into the *.dsc file, yes.
> >> 
> >> It doesn't require that dak then also trust the authorization checks.
> > 
> > Yes.  It does.  Since DAK has no way to check the signature of the tag
> > against the keyring, it has to trust the source package signature done
> > by tag2upload.  The only two choices are blindly trust tag2upload is
> > correct or don't accept uploads from tag2upload.
> 
> That's exactly what I just said.  It has to trust that tag2upload verified
> the signature on the Git tag correctly.  It does not have to trust that
> tag2upload performed the authorization check correctly; it has the
> fingerprint and can redo that itself.
> 
> It is entirely correct that deployment of tag2upload means that there are
> two separate systems performing the OpenPGP signature verification for
> upload, and dak has to trust tag2upload's performance of that
> verification.  This is inherent in the design: dak and tag2upload are
> verifying signatures over different types of objects, and the verification
> of the tag signature is not useful without also performing the
> transformation to a source package.  That is exactly what the whole
> tag2upload server is there to do.
> 
> dak should not be doing the source package transformation, because that is
> a much more complicated process and therefore a larger security attack
> surface.  That's why it's done in a sandbox with a bunch of privilege
> separation.  That does indeed mean that dak has to trust the tag2upload
> verification of the original Git tag and its verification of the semantics
> of that Git tag, because that's part and parcel with the rest of the work
> that tag2upload is doing.  The tag2upload developers believe that the
> schemes proposed for trying to make the original signature portable to the
> generated *.dsc file are too awkward and complex to be supportable, and
> personally I agree.
> 
> But this is entirely separate from the *authorization* check.  After
> tag2upload uploads the *.dsc and *.changes file to dak, dak is in
> possession of the key fingerprint of the original signer, the source
> package name, the suite, and so forth.  It can redo the *authorization*
> check itself if it so chooses.  The only thing it can't do is the
> *authentication* check.

Maybe.  Maybe this breaks the thing into two parts in a way it wasn't before 
If you verify the signature on the source package and the key is in the 
keyring, you know that the package was uploaded by someone authorized to do so 
and that the code you have is what they signed.  With tag2upload you have 
neither.  You have tag2upload's claim of who signed the tag and the source 
package constructed by tag2upload.  The connection to what the uploader 
intended to upload is completely indirect.

> > My impression (and I may be wrong, because it was awhile ago and since
> > I'm not an FTP Master I wasn't super focused on it) is that the
> > fundamental issue is tag2upload inherently requiring DAK to blindly
> > accept anything tag2upload signs and the FTP delegates not being
> > comfortable with that.
> 
> Yes, I believe that's the core disagreement.  I don't believe there is any
> way around that without breaking one or more design goals of tag2upload.

I don't think there's any real mystery about this, but the claim in the draft 
GR was that there was an unwillingness to communicate.  While there is a 
legitimate core to the draft GR, it feels to me like there's a lot of puffery 
around it that makes the whole endeavor seem questionable.

> It's not clear to me why it is considered a blocker for signature
> verification in the tag2upload case to be done by a different piece of
> software running on limited-access Debian project infrastructure instead
> of in dak, a piece of software running on limited-access Debian project
> infrastructure.  But that's fine; it doesn't need to be clear to me.  I
> believe it is in the remit of the FTP team delegation to make that
> decision, but there is also a constitutional process for appealing that
> decision to the project as a whole.  The tag2upload developers have made
> their case, the FTP team can make their case for why they don't want to
> allow this, and the project can decide.  That's how our system works.
> 
> > That was the issue last time this was discussed (IIRC) and it doesn't
> > appear that anything has changed.  I don't see how it can with the
> > current architecture.
> 
> I agree.
> 
> > I suspe

Re: [RFC] General Resolution to deploy tag2upload

[Scott Kitterman]

On Friday, June 14, 2024 5:25:33 PM EDT Russ Allbery wrote:
> Ansgar   writes:
> > On Fri, 2024-06-14 at 11:45 -0700, Russ Allbery wrote:
> >> Sorry, I don't understand.  What isn't complete?  I just explained how
> >> dak could continue to enforce all the same authorization checks as it
> >> does today.  This is part of the design as proposed.  The key
> >> fingerprint of the original tag signer is present in the Git-Tag-Info
> >> header in the *.dsc file as uploaded to dak.
> > 
> > This would require the check to be implemented correctly in tag2upload.
> > Otherwise whatever check dak performs is fairly useless.
> 
> It requires that the signature on the Git tag be correctly checked and
> that fingerprint be put into the *.dsc file, yes.
> 
> It doesn't require that dak then also trust the authorization checks.

Yes.  It does.  Since DAK has no way to check the signature of the tag against 
the keyring, it has to trust the source package signature done by tag2upload.  
The only two choices are blindly trust tag2upload is correct or don't accept 
uploads from tag2upload.

> > We would also have a new critical system written and maintained by 1.2
> > people in a fairly old-style Perl dialect that have previously not kept
> > up with promises to maintain software stacks (e.g., systemd-shim which
> > then had to be replaced by other people with something else).
> 
> Yes, the tag2upload developers implemented the service the way that they
> implemented it, and the proposed GR would say that they can deploy that
> implementation.  Asking them to redo that work in a different programming
> language or with a substantially different architecture before it can be
> deployed is not, at this point, a reasonable request, even apart from the
> general principle that Debian is a volunteer project and no one is
> required to do work.
> 
> I think that some of the posts on this thread are exactly backwards in
> their understanding of human motivation.  Blocking someone's work from
> being used until it's done the way that you would have done it yourself is
> not motivating, it's horribly demotivating.  Seeing your work deployed
> live and actively used by Debian does not eliminate the motivation to make
> any further changes; rather, it increases the willingness to do further
> work drastically.

My impression (and I may be wrong, because it was awhile ago and since I'm not 
an FTP Master I wasn't super focused on it) is that the fundamental issue is 
tag2upload inherently requiring DAK to blindly accept anything tag2upload 
signs and the FTP delegates not being comfortable with that.  I think that was 
clearly communicated and they didn't like that answer and here we are.

That was the issue last time this was discussed (IIRC) and it doesn't appear 
that anything has changed.  I don't see how it can with the current 
architecture.

I suspect a vote of no confidence by the project in the FTP Masters would not 
be super motivating either.

Scott K

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

Re: [RFC] General Resolution to deploy tag2upload

[Scott Kitterman]

On Friday, June 14, 2024 2:45:55 PM EDT Russ Allbery wrote:
> Scott Kitterman  writes:
> > On June 13, 2024 3:29:21 PM UTC, Russ Allbery  wrote:
> >> I don't understand why this would be a blocker given that dak can redo
> >> the authorization check at the same point that it does authorization
> >> checks now, should it so desire.  This does require a small change to
> >> dak to retrieve the key fingerprint from the source package in the case
> >> where the source package is signed with the tag2upload key, but that
> >> doesn't seem too difficult.
> > 
> > I think that if the proposers want to direct use of a specific design
> > via GR, it ought to be complete.
> 
> Sorry, I don't understand.  What isn't complete?  I just explained how dak
> could continue to enforce all the same authorization checks as it does
> today.  This is part of the design as proposed.  The key fingerprint of
> the original tag signer is present in the Git-Tag-Info header in the *.dsc
> file as uploaded to dak.

Can, but doesn't currently.  Elsewhere it has been claimed that tag2upload can 
be implemented with no changes elsewhere and I think that's just not true.

> > It's unclear to me how the FTP Masters could ask for this after the GR,
> > since the GR takes anything to do with tag2upload out of their hands
> > going forward.
> 
> I don't believe this is a correct interpretation of how GRs that override
> a delegate decision are applied in Debian.
> 
> For one, absolutely nothing about a GR or any other action in Debian
> constrains what FTP Masters can *ask* for.  Surely that's obvious.  It
> would only constrain what FTP Masters can *demand*.  One would hope that,
> in the presence of new guidance from the project as a whole about the
> technical direction, FTP Masters and the tag2upload developers would work
> collaboratively together to improve the entire architecture.  Nothing in
> the GR prevents that; that's never been how we interpret GRs.
> 
> Second, the specific thing that the GR requires of FTP Master is that
> tag2upload be allowed to upload source packages signed with its key,
> following the architecture spelled out here.  That architecture includes
> providing dak, and everyone else looking at the *.dsc file, with the
> fingerprint of the original tag signer.  It does not preclude dak from
> performing the normal authorization checks for uploads to the archive,
> only from rejecting packages because they are uploaded through tag2upload.

Which means that in the future, the tag2upload developers can make whatever 
changes they want and the FTP team is required to accept them?

> > Post GR, it's not clear to me who gets to decide if changes are needed
> > without another GR.
> 
> This was much-discussed after both
> https://www.debian.org/vote/2007/vote_002 and
> https://www.debian.org/vote/2007/vote_003.  Kurt is authoritative on this
> point, I think, since it's a question of constitutional interpretation,
> but my understanding of the project consensus is that a GR is not
> forever-binding.  We all understand that circumstances change in the
> future and we do not need to strictly follow the exact text of a GR into
> the indefinite future.  It's not a law.  The exact time frame is not
> defined anywhere, but I would think of it as a sort of "slow decay" where,
> over time, the GR should be seen as a directional statement but the exact
> architecture should and will change based on new requirements, new issues,
> and more experience.

Thanks.  That's slightly before my time, so I didn't know about it.  I think 
it makes sense.

I'm still concerned about how this is going to work in practice.  the 
tag2upload developers seem to be very confident that they have a good design 
that is ready to be deployed and once the FTP Masters are overridden on this, 
until such time as this natural decay runs, there's no incentive for them to 
cooperate.

Is anyone volunteering to do the DAK changes to use Git-Tag-Info header to get 
the signature if the source package is signed by a tag2upload key?

It doesn't feel like this is complete enough to tie the FTP Team's hands over 
it.  I have some questions about the security review, which I will ask in that 
thread, so I won't go into those here.

Scott K

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

Re: [RFC] General Resolution to deploy tag2upload

[Scott Kitterman]

On June 14, 2024 10:01:38 AM UTC, Sean Whitton  wrote:
>Hello zigo,
>
>On Fri 14 Jun 2024 at 11:39am +02, Thomas Goirand wrote:
>
>> Please read his lightning talk "debconf22-94-lightning-talks.webm". Here's 
>> the
>> first to talk in the video:
>>
>> https://meetings-archive.debian.net/pub/debian-meetings/2022/DebConf22/
>>
>> What I found super nice with his design is that:
>> * there's no need to modify anything on the Debian infrastructure
>> * there's no need for a GR or a change of any Debian current policy.
>
>The work has already been done to prepare the additional infrastructure
>(note that there is no need to *modify* any existing infrastructure),
>and to prepare this GR.
>We are enthusiastic to complete the remaining work.  The mere fact that
>change is required shouldn't hold us back from going for what we think
>is the best solution, if there are people willing to implement it.
>
>> * packages continue to be signed with your own DD key
>>
>> Why can't we move to this route, with standardized tooling?
>
>Well, to put it simply, because it's better to do things using only
>signed git tags than to do something highly Debian-specific.
>It is better if new contributors don't have to learn about source
>packages and dput at all.  It is also much more convenient for existing
>contributors.  Take a look at how git-debpush works -- it's really very
>simple and lightweight.  I think you'll like it.
>

I'm a bit confused by the claim that no infrastructure changes are needed for 
this to go forward.

If I have been following the proposal correctly, source packages will be signed 
by tag2upload and not the uploader.  Doesn't that mean changes are going to be 
needed so that we know in the archive who uploaded the package?

Scott K

Re: [RFC] General Resolution to deploy tag2upload

[Scott Kitterman]

On June 13, 2024 3:29:21 PM UTC, Russ Allbery  wrote:
>Scott Kitterman  writes:
>
>> I agree that this isn't a major design issue, but I think it is
>> something that I think needs to be addressed before deployment of
>> tag2upload.  The need is certainly rare, but when it's needed, it's
>> needed because it's important.
>
>I don't understand why this would be a blocker given that dak can redo the
>authorization check at the same point that it does authorization checks
>now, should it so desire.  This does require a small change to dak to
>retrieve the key fingerprint from the source package in the case where the
>source package is signed with the tag2upload key, but that doesn't seem
>too difficult.

I think that if the proposers want to direct use of a specific design via GR, 
it ought to be complete.  It's unclear to me how the FTP Masters could ask for 
this after the GR, since the GR takes anything to do with tag2upload out of 
their hands going forward. Post GR, it's not clear to me who gets to decide if 
changes are needed without another GR.

Scott K

Re: [RFC] General Resolution to deploy tag2upload [and 2 more messages]

[Scott Kitterman]

On June 13, 2024 10:46:59 AM UTC, Ian Jackson  
wrote:
>Scott Kitterman writes ("Re: [RFC] General Resolution to deploy tag2upload"):
>> If I am understanding you correctly, tag2upload is only relevant to the XZ 
>> Utils type attack if the maintainer uses the upstream git rather than the 
>> upstream provided tarball as the basis for their Debian work.  Is that right?
>
>Yes.  It is precisely using the upstream git, rather than the upstream
>tarball, that eliminates the gap through which the exploit activation
>was smuggled in this case.
>
>(Whether the maintainer could uwe the upstream tarball as the
>.orig.tar.gz, while using upstream git as the basis for the package
>contents, is a complicated question.)
>
>> If so, it seems to me that is entirely tangential to this proposed GR.
>
>No, because it is not sufficient to base the maintainer git repository
>on the upstream git.  It is also necessary that something checks that
>those files in the .orig.tar.gz which aren't patched in
>debian/patches/ correspond precisely to the git tree the maintainer is
>working with.
>
>This check is done by `dgit push-source`, and by tag2upload.
>But it is often not done by other workflows.  (Because there are so
>many workflows, it is difficult to make fully general statements.)

Maybe it's a matter of perspective, but I don't think that it is reasonable to 
claim tag2upload as helpful relative to xz-utils.  Even if tag2upload had been 
available before the bad upload was made, it wouldn't have been helpful since 
it wouldn't have been usable to upload it.

I agree that it might help with similar situations as long as a number of other 
conditions are met, which are not the most common cases.  Ultimately, I think 
the claim has so many unwritten caveats that it's not useful relative to the GR.

Scott K

Scott K

Re: [RFC] General Resolution to deploy tag2upload

[Scott Kitterman]

On June 13, 2024 3:02:48 PM UTC, Joerg Jaspert  wrote:
>On 17259 March 1977, Ian Jackson wrote:
>
>>> Thanks.  Then possibly it is sufficient for ftpmaster just to disable
>>> tag2upload's whole key until the keyring update is pushed.
>> I'm not sure this is a sufficient answer.  We don't want uploads by
>> revoked keys to appear on *.dgit.d.o either.
>
>> Joerg, is there some way that this fingerprint block information could
>> be made available in a more timely manner?  Ideally we would update
>> push.dgit.d.o to use this information, regardless of tag2upload.
>> (And the t2u conversion system should use it too.)
>
>> I think maybe we should take this to a different venue, than this
>> thread on -vote.  How about a bug against ftp.d.o and/or
>> dgit-infrastructure ?
>
>I think this is a minor issue, actually. It does not happen often. For
>the time it will, we can have something like "ftpmaster pushes a list of
>fingerprints via $mechanism" (ssh forced command is widely used for
>similar things, for example).
>
>That's really simple to implement.

I agree that this isn't a major design issue, but I think it is something that 
I think needs to be addressed before deployment of tag2upload.  The need is 
certainly rare, but when it's needed, it's needed because it's important.

It also suggests to me that it's premature to freeze and mandate the current 
design via GR.

Scott K

Re: [RFC] General Resolution to deploy tag2upload

[Scott Kitterman]

On June 12, 2024 8:03:59 PM UTC, Luca Boccassi  wrote:
>On Wed, 12 Jun 2024 at 19:24, Russ Allbery  wrote:
>>
>> "Adam D. Barratt"  writes:
>> > On Wed, 2024-06-12 at 10:43 -0700, Russ Allbery wrote:
>>
>> >> There was more confusion about this point than I had anticipated, so I
>> >> want to emphasize that the dgit-repos server is not a forge, is not a
>> >> competitor to Salsa, doesn't replace Salsa in any way, and is not
>> >> something that people interact with the way that they interact with
>> >> Salsa.  It's much closer to a Git equivalent of archive.debian.org: a
>> >> persistent historical record accessible via the Git protocol and (as I
>> >> discovered during this thread) a cgit web interface.
>>
>> > In that sense, it's more like snapshot.debian.org, I think?
>>
>> Yes, apologies, that's a much better analogy.
>
>But you don't push to snapshot, it's just a backup method, it doesn't
>take any input from DDs (AFAIK? Am I wrong?). Given
>https://browse.dgit.debian.org/ exists and has tons of stuff already,
>and this proposal for tag2upload doesn't exist yet, I gather that dgit
>is already a thing that is used independently of tag2upload? I mean,
>that's how it was explained to me yesterday anyway.
>
>So I don't think this analogy works. One couldn't say "let's remove
>archive.debian.org, just push to snapshot.debian.org", but one could
>say "let's remove salsa.debian.org, just push to dgit.debian.org".

I think it is more accurate to say that they are mirrors.  They both contain 
details of current and historical packages.  The difference is that snapshot is 
downstream of the archive, while these putative the tag2upload repositories are 
upstream.

It's it being upstream of the primary archive that makes it far more security 
sensitive.

Scott K

Re: [RFC] General Resolution to deploy tag2upload

[Scott Kitterman]

On Wednesday, June 12, 2024 10:20:45 AM EDT Ian Jackson wrote:
> Scott Kitterman writes ("Re: [RFC] General Resolution to deploy 
tag2upload"):
> > On Tuesday, June 11, 2024 6:25:02 PM EDT Sean Whitton wrote:
> > > - it improves the traceability and auditability of our source-only
> > > 
> > >   uploads, in ways that are particular salient in the wake of xz-utils.
> > 
> > As I understand it, Debian was affected by the xz-utils hack, in
> > part, because some artifacts were inserted into an upstream tarball
> > that were not represented in the upstream git.  Please explain how
> > use of tag2upload is relevant to this scenario?  I'm afraid I don't
> > follow.
> 
> Disclaimer: I don't know precisely the Debian xz's maintainer's
> workflow.
> 
> tag2upload, like dgit, ensures and insists that the git tree you are
> uploading corresponds precisely [1] to the generated source package.
> 
> If you base your Debian git maintainer branch on the upstream git (as
> you should) and there is a discrepancy between the contents of the
> upstream git branch, and the .orig.tar.gz you're using, the upload
> will fail.
> 
> In the xz case, if the .orig.tar.gz is upstream's, that would have
> detected the attack.  More realistically, since the attacker was
> targeting Debian, they would instead have had to put all of the
> malicious code into the git repository, which is possible, but riskier
> - so it makes the attack harder, or easier to detect, but doesn't rule
> it out.
> 
> There are some cavests to this.
> 
> I believe some maintainers maintain a "upstream tarball imports"
> branch, which has upstream git as its ancestor, but whose tree
> contents are the upstream tarballs.  They then base the Debian branch
> on that.  That workflow is vulnerable to "random stuff" in the
> tarballs.
> 
> It would also be possible to create a debian/patches/ patch [2]
> representing the difference between git and the tarball.  There are
> various tools in Debian that might make such a patch, including (I
> think) dpkg-source, gbp and perhaps dgit, depending on what workflow
> and options and so on.
> 
> There are probably other workflows that have similar weaknesses.
> I wouldn't recommend any of them.
> 
> 
> Stepping back a bit, the underlying theme is (obviously) that the
> upstream tarball wasn't great, in this case.
> 
> In Debian we have historically had a strong culture of wanting to use
> upstream release tarballs.  That made a lot of sense 20-30 years ago
> when almost all free software projects released tarballs, and
> considered them primary, and the VCS situation was a total mess.
> 
> Nowadays, for most projects, the upstream developers work in git.  So
> git is the source code.  Upstream provides tarballs via some
> semi-automated process, but it's not what they work with.  Ie the
> tarballs are an intermediate build product.
> 
> In Debian we are supposed to use the source code.  We should be using
> the same thing as upstream.
> 
> There are other reasons why tarballs can be worse, than that they
> could be maliciously modified.  Often tarballs contain prebuilt stuff
> of various kinds.  In Debian we usually want to build everything from
> source.  That's much easier to get right if we start from the actual
> source!
> 
> Ian.
> 
> 
> [1] Modulo "patches-applied" vs "patches-unapplied" and some other
> fiddly details which aren't relevant to this discussion.
> 
> [2] Assuming a gbp workflow and `3.0 (quilt)`, for the moment.

If I am understanding you correctly, tag2upload is only relevant to the XZ 
Utils type attack if the maintainer uses the upstream git rather than the 
upstream provided tarball as the basis for their Debian work.  Is that right?

If so, it seems to me that is entirely tangential to this proposed GR.  Any 
maintainer that wants to do that now, can and no maintainer is forced to do so 
if Debian deploys tag2upload, per the GR.  I think it would be useful if the 
GR focused on the benefits of the GR and did not try to market itself based on 
the threat of the day.

Scott K


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

Re: [RFC] General Resolution to deploy tag2upload

[Scott Kitterman]

On Tuesday, June 11, 2024 6:25:02 PM EDT Sean Whitton wrote:
> - it improves the traceability and auditability of our source-only
>   uploads, in ways that are particular salient in the wake of xz-utils.

As I understand it, Debian was affected by the xz-utils hack, in part, because 
some artifacts were inserted into an upstream tarball that were not 
represented in the upstream git.  Please explain how use of tag2upload is 
relevant to this scenario?  I'm afraid I don't follow.

Scott K

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

Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)

[Scott Kitterman]

On April 4, 2024 12:59:34 PM UTC, Andreas Tille  wrote:
>Hi Scott,
>
>Am Thu, Apr 04, 2024 at 12:42:11PM + schrieb Scott Kitterman:
>> I'm interested to understand what you think this has to do with the DPL 
>> election or the role of the DPL within the project?
>
>I would like to learn what options I have to realise paragraph
>
>   Packaging standards
>
>of my platform.

Thanks.

Obviously the DPL has an outsized voice in Debian.  When the DPL says 
something, it will tend to get more attention within the project.

Beyond that, what specific powers of the DPL will help you realize this goal?  
In other words, why do you need to be DPL to do this?

Scott K

Re: Question to all voters: Is team upload in some example case OK? (Was: Question to all candidates: What are your technical goals)

[Scott Kitterman]

On April 4, 2024 12:32:45 PM UTC, Andreas Tille  wrote:
>Hi,
>
>in the light of the previous discussion I have a question to all voters.
>Due to bug #1066377 more than 30 testing removal warnings hit my mailbox
>today (I stopped counting after 30).  While the Debian Med package
>clustalo is the only package that's responsible for this due to its
>Build-Dependency from libargtable2-dev there is quite some dependency
>tree inside Debian Med team also affecting packages relevant for
>COVID-19 etc.  This small lib is not a key package which is important
>for all things I'm writing below.  Its used as Build-Depends by 6 other
>packages.
...
>
>What do you think?
>

Andreas,

I'm interested to understand what you think this has to do with the DPL 
election or the role of the DPL within the project?

Scott K

Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"

[Scott Kitterman]

On November 13, 2023 12:29:20 PM UTC, "Lisandro Damián Nicanor Pérez Meyer" 
 wrote:
>On Mon, 13 Nov 2023 at 07:55, Aigars Mahinovs  wrote:
>[snip]
>> Even regardless of the specific legal wording in the legislation itself, the 
>> point 10
>> of the preamble would be enough to to fix any "bug" in the legislation in
>> post-processing via courts. As in - if any interpretation of the wording of 
>> the
>> directive is indeed found to be hampering open source development,
>> then it is clearly in error and contrary to the stated intent of the 
>> legislation.
>
>According to the current wording if, for some reason, I am held to be
>responsible for $whatever, then I should go to court. Me, who lives in
>south america (because yes, they are looking for culprits no matter
>where they live). They already won.
>
>So, why not try and get the wording correctly from starters?
>
This is precisely my concern.  Even if I win (because of some words about 
legislative intent or whatever), the moment I have to hire a lawyer to deal 
with it, I've already lost.  This may not be a problem for Debian, but it's 
definitely a potential issue for small upstream projects.

I do free software development because I enjoy it and it makes the world a 
better place.  There's a real limit to how far I am willing to carry 
legal/financial risks to do so.

Scott K

Re: Call for vote: public statement about the EU Legislation "Cyber Resilience Act and Product Liability Directive"

[Scott Kitterman]

On November 12, 2023 5:09:26 PM UTC, Luca Boccassi  wrote:
>On Sun, 12 Nov 2023 at 15:10, Santiago Ruano Rincón
> wrote:
>>
>> Dear Debian Fellows,
>>
>> Following the email sent by Ilu to debian-project (Message-ID:
>> <4b93ed08-f148-4c7f-b172-f967f7de7...@gmx.net>), and as we have
>> discussed during the MiniDebConf UY 2023 with other Debian Members, I
>> would like to call for a vote about issuing a Debian public statement 
>> regarding
>> the EU Cyber Resilience Act (CRA) and the Product Liability Directive
>> (PLD). The CRA is in the final stage in the legislative process in the
>> EU Parliament, and we think it will impact negatively the Debian
>> Project, users, developers, companies that rely on Debian, and the FLOSS
>> community as a whole. Even if the CRA will be probably adopted before
>> the time the vote ends (if it takes place), we think it is important to
>> take a public stand about it.
>>
>> - GENERAL RESOLUTION STARTS -
>>
>> Debian Public Statement about the EU Cyber Resilience Act and the
>> Product Liability Directive
>>
>> The European Union is currently preparing a regulation "on horizontal
>> cybersecurity requirements for products with digital elements" known as
>> the Cyber Resilience Act (CRA). It's currently in the final "trilogue"
>> phase of the legislative process. The act includes a set of essential
>> cybersecurity and vulnerability handling requirements for manufacturers.
>> It will require products to be accompanied by information and
>> instructions to the user. Manufacturers will need to perform risk
>> assessments and produce technical documentation and for critical
>> components, have third-party audits conducted. Discoverded security
>> issues will have to be reported to European authorities within 24 hours
>> (1). The CRA will be followed up by the Product Liability Directive
>> (PLD) which will introduce compulsory liability for software. More
>> information about the proposed legislation and its consequences in (2).
>
>These all seem like good things to me. For too long private
>corporations have been allowed to put profit before accountability and
>user safety, which often results in long lasting damage for citizens,
>monetary or worse. It's about time the wild-west was reined in.
>
>> While a lot of these regulations seem reasonable, the Debian project
>> believes that there are grave problems for Free Software projects
>> attached to them. Therefore, the Debian project issues the following
>> statement:
>>
>> 1.  Free Software has always been a gift, freely given to society, to
>> take and to use as seen fit, for whatever purpose. Free Software has
>> proven to be an asset in our digital age and the proposed EU Cyber
>> Resilience Act is going to be detrimental to it.
>> a.  It is Debian's goal to "make the best system we can, so that
>> free works will be widely distributed and used." Imposing requirements
>> such as those proposed in the act makes it legally perilous for others
>> to redistribute our works and endangers our commitment to "provide an
>> integrated system of high-quality materials _with no legal restrictions_
>> that would prevent such uses of the system". (3)
>
>Debian does not sell products in the single market. Why would any
>requirement be imposed, how, and on whom? SPI? Debian France?
>
>> b.  Knowing whether software is commercial or not isn't feasible,
>> neither in Debian nor in most free software projects - we don't track
>> people's employment status or history, nor do we check who finances
>> upstream projects.
>
>We do know whether something is commercial or not though - for
>example, we don't have to provide Debian with warranty to our users,
>because we know publishing images on debian.org is not a commercial
>activity.
>The second statement I find hard to follow, what would employment
>status have to do with this?
>
>> c.  If upstream projects stop developing for fear of being in the
>> scope of CRA and its financial consequences, system security will
>> actually get worse instead of better.
>
>Why would projects stop developing? If it's a product sold on the
>single market, then it's right that it is subject to these rules. If
>it's not a product, then these rules don't affect it, just like rules
>on warranties.
>
>> d.  Having to get legal advice before giving a present to society
>> will discourage many developers, especially those without a company or
>> other organisation supporting them.
>
>Same as above. If you are not selling anything, why would you need
>legal advice, any more than you already do? The EU Single Market has
>many, many rules, this is not the first and won't be the last.
>
>> 2.  Debian is well known for its security track record through practices
>> of responsible disclosure and coordination with upstream 

Re: Possible draft non-free firmware option with SC change

[Scott Kitterman]

On September 12, 2022 8:23:22 PM UTC, Bill Allombert  
wrote:
>Le Sun, Sep 11, 2022 at 08:19:26AM +0200, Simon Josefsson a écrit :
>> The problem is caused by hardware manufacturer chosing to require
>> non-free works for their use.  The blame for that choice lies on the
>> hardware manufacturer, not on Debian.  Accepting the blame for someone
>> else's choices and taking on the responsibility solve the consequences
>> of that choice seems misguided to me.  It makes it harder for users to
>> experience the frustration of such hardware themselves.  I disagree they
>> always get the non-free installer eventually: some end up learning about
>> the problem and chose better hardware.  Some end up reverse engineering
>> their hardware, and contributing to a free solution.  Some dislike other
>> distributions taking a less rigid stance on non-free works, and will
>> come up with work-arounds to get Debian to work on the hardware.  If
>> Debian takes on itself to solve the problems with non-free hardware, I
>> think we are in more difficult position to ask for a change.
>
>Seconded.
>We fought against lack of Linux drivers, then against the lack of free
>drivers. Now, since in a lot of situation it is not tenable not to
>provide Linux drivers (because Linux is the dominant server OS),
>since it is not tenable to provide only non-free drivers (because
>entreprise distros do not ship them), the move is toward smaller and
>smaller drivers loading larger and larger non-free firmware.
>
>Debian should not trick users into downloading non-free files.

All this is, is a preference for permanent non-free firmware that can't be 
updated or fixed.  I don't think it serves our users at all.

Personally, I can't remember the last time I successfully (as in with 
networking) installed a system using the official installer.  It's probably 
over a decade ago.

I'm thrilled that the project is exploring providing a working installer.

Scott K

Re: General Resolution: Liquidate donated assets as soon as possible

[Scott Kitterman]

On June 19, 2022 7:03:00 PM UTC, Micha Lenk  wrote:
>Hi Antoine,
>
>Am 19.06.22 um 19:31 schrieb Antoine Beaupré:
>> I second this GR.
>> I understand people might not *agree* with it, but I still think it's
>> worth discussing it more, especially in the open.
>
>For discussing things, whether in the open or not, you don't need to start or 
>second a general resolution. Usually it is the other way round. First you have 
>a discussion, then a GR -- yet only if necessary.
>
>> I also feel there was a consensus over the *spirit* of the proposal
>> here, if not the letter. It seems we all *not* want Debian to speculate
>> on donated assets. Yes, maybe there's a better way to phrase this, but
>> let's not make perfect the ennemy of good and start tackling this
>> problem because, right now, we still *do* have that problem and I don't
>> see any other action taken to solve it.
>
>While I agree that a resolution would help us, I'm not convinced a *general* 
>resolution would be the right tool at this point in time.
>
>In general I think we should avoid GRs in areas where we have delegations in 
>place and no reason to overrule the delegates.

Strong agree.

Scott K

Re: General Resolution: Liquidate donated assets as soon as possible

[Scott Kitterman]

On June 19, 2022 2:40:01 AM UTC, "Louis-Philippe Véronneau"  
wrote:
>Someone pointed out "assets" is very broad, and that would include
>things like hardware donations (something I don't think would be wise).
>
>I would hereby like to amend my proposal by replacing "assets" by
>"financial assets":
>
> Text of GR 
>
>Donations to the Debian project of *financial* assets other than the
>TO's currency of choice should be liquidated as soon as possible.
>
> End Text of GR 

I'd suggest you also provide a definition.  Do you intend to prevent a TO from 
accepting donated frequent flyer miles and keeping them long enough to provide 
an airplane ticket to someone who can't otherwise afford to go to Debconf?  I'd 
say that the current text would require them to be converted to cash and I 
don't think that would be the best thing.

Scott K

Re: Ballot option 2 - Merely hide Identities of Developers Casting a Particular Vote and allow verification

[Scott Kitterman]

On Wednesday, February 23, 2022 6:22:00 PM EST Sam Hartman wrote:
> > "Judit" == Judit Foglszinger  writes:
> Judit> Give the opportunity to vote for secret voting without
> Judit> needing to additionally vote for unrelated/only slightly
> Judit> related constitution changes; for example for the change of
> Judit> mode of voting from email to something not defined.
> 
> Even if you don't want to move toward some different voting system, do
> we really want to require a constitutional amendment if say the
> secretary wanted to move voting to a salsa-authenticated website to make
> it easier and more accessible to our members?
> Back when the constitution was passed, email was so obvious for this
> sort of thing that it wasn't a real limitation.
> 
> Today, I think there are all sorts of reasons we might  prefer a
> different way to interact with the voting system, and  I don't want to
> need to change the constitution every time we want to make such a
> change.

So far the rate of change in voting systems leads me to believe this is a 
quite manageable burden.  And no, I don't think switching to some web based 
system would be an improvement.

Scott K

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

Re: Ballot option 2 - Merely hide Identities of Developers Casting a Particular Vote and allow verification

[Scott Kitterman]

Seconded/sponsored.

Scott K

On Wednesday, February 23, 2022 5:44:34 PM EST Judit Foglszinger wrote:
> I propose a ballot option for the GR
> "Hide Identities of Developers Casting a Particular Vote"
> that makes the following changes to the constitution.
> 
> 1) Do not make the identity of a voter casting a particular vote public.
> 
> 6) Codify that our election system must permit independent verification
>of the outcome given the votes cast and must permit developers to
>confirm their vote is included in the votes cast.
> 
> So it's the proposed GR minus the changes
> not directly related to introducing secret votes.
> 
> I ask for seconds aka sponsors for this Option.
> 
> Rationale
> =
> 
> Give the opportunity to vote for secret voting without needing to
> additionally vote for unrelated/only slightly related
> constitution changes;
> for example for the change of mode of voting
> from email to something not defined.
> 
> As it was mentioned in the discussion,
> there might be no consensus on which options are direcly related -
> This option regards the need to allow verification (6))
> as directly related to secret votes, because otherwise
> they would become completely unverifiable.
> 
> Summary of Changes
> ==
> 
> 1) Do not make the identity of a voter casting a particular vote
>public.
> 
> 6) Codify that our election system must permit independent verification
>of the outcome given the votes cast and must permit developers to
>confirm their vote is included in the votes cast.
> 
> 
> 4.2. Procedure
> @@ -228,9 +246,10 @@ earlier can overrule everyone listed later.
> 
>Votes are taken by the Project Secretary. Votes, tallies, and
>results are not revealed during the voting period; after the
>vote the Project Secretary lists all the votes {+cast in sufficient
> detail that anyone may verify the outcome of the election from the votes
> cast. The+} {+   identity of a developer casting a particular vote is
> not made+} {+   public, but developers will be given an option to
> confirm their vote is included in the votes+} cast.
> 
> @@ -371,8 +390,7 @@ earlier can overrule everyone listed later.
>   necessary.
> 
>   The next two weeks are the polling period during which
>   Developers may cast their votes. [-Votes in leadership elections are-]
> [-  kept secret, even after the election is finished.-]{++}



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

Re: Renaming the FTP Masters

[Scott Kitterman]

On November 3, 2021 9:27:08 PM UTC, Felix Lechner  
wrote:
>Hi,
>
>I would like to rename the FTP Masters team—ideally via a General Resolution.
>
>Since the murder of George Floyd, the average fate of Black lives has
>received much attention. Even the tech sector picked up the
>"master/slave" topic over a year ago. [2][3][4]
>
>There should be little controversy. With a high pass rate, we could
>all come together as a group—for our shared love of Debian and free
>software!
>
>What do you think about the text below, please? Thanks for reading!
>
>Kind regards
>Felix Lechner
>
>[1] https://en.wikipedia.org/wiki/Murder_of_George_Floyd
>[2] https://www.wired.com/story/tech-confronts-use-labels-master-slave/
>[3] 
>https://www.cnet.com/news/master-and-slave-tech-terms-face-scrutiny-amid-anti-racism-efforts/
>[4] 
>https://www.nytimes.com/2021/04/13/technology/racist-computer-engineering-terms-ietf.html
>
>* * *
>
>PROPOSED TEXT
>
>In recognizance of the awful history of slavery, the Debian project
>will rename the "FTP Masters" team. For a long time, the word "master"
>has been associated with the grave injustices of slavery. [1]
>
>While there is a tradition in computing to label primary equipment as
>a "master" and replicated equipment as "slaves" [2] the use of the
>word "masters" for a group of people with special privileges [3]
>shocks the conscience.
>
>Within that context, the team's use of the title "wizard" [4] was also
>problematic. The Ku Klux Klan and its spinoffs used the title "wizard"
>to style high officials. [5] The team will likewise discontinue the
>use of the term "wizard" to designate any current or former members.
>
>Nothing in this resolution shall impair the continued use of the
>"master/slave" analogy for technical equipment.
>
>"Without a struggle, there can be no progress." (Frederick Douglass)
>
>[1] https://en.wikipedia.org/wiki/History_of_slavery
>[2] https://en.wikipedia.org/wiki/Master/slave_(technology)
>[3] "The FTP masters can do everything in the archive.",
>https://wiki.debian.org/Teams/FTPMaster
>[4] "The FTP Wizard role consists of former team members",
>https://ftp-master.debian.org/
>[5] https://en.wikipedia.org/wiki/Grand_Wizard
>

I'd suggest if you want to change the name via GR, the text of the GR should 
give the new name.  Otherwise, it could drag on for a very long time.

Regardless of how one might feel about changing the names, it should be done 
quickly if it's to be done.

Scott K

Re: [draft] Cancel this year's in-person Debian Developers Conference DebConf20

[Scott Kitterman]

On Tuesday, June 2, 2020 12:12:21 AM EDT Bdale Garbee wrote:
> Scott Kitterman  writes:
> > It's almost like this discussion about a GR was a premature waste of
> > everyone's time.
> 
> It's also possible that discussion about a possible GR influenced the
> ultimate decision in a useful way.
> 
> [shrug]

Sure, but doing business by threat of GR is a horrible way to run things.

What I would have hoped is that project members would trust the people that 
they have (indirectly) delegated the responsibility to run Debconf to to do a 
good job and only once there is something that's enough of a problem to 
require a project wide decision to change their decision consider a GR.

There's enough to do to make the Debian project go that I don't think we need 
to engage in project level micromanagement like this.

Scott K

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

Re: [draft] Cancel this year's in-person Debian Developers Conference DebConf20

[Scott Kitterman]

On Monday, June 1, 2020 6:12:30 PM EDT Ivo De Decker wrote:
> Hi,
> 
> On 5/22/20 2:43 PM, Holger Levsen wrote:
> > On Fri, May 22, 2020 at 02:40:55PM +0200, Martin Zobel-Helas wrote:
> >> This is a draft for a GR I would like to propose.
> >> 
> >> Cancel this year's in-person Debian Developers Conference DebConf20
> > 
> > [...]
> > 
> > I'd second that, thanks. However, I would prefer if the DebConf organizers
> > cancel themselves. (And I would also prefer we would wake up soon and this
> > nightmare is over. I just don't think that this will happen anytime soon.)
> 
> FWIW, it seems the organizers decided it's not happening:
> 
> http://meetbot.debian.net/debconf-team/2020/debconf-team.2020-06-01-18.01.lo
> g.html
> 
> " #action terceiro to send a short announcement that there will
> be no in-person conference in 2020 and further details will follow"
> 
> Ivo

It's almost like this discussion about a GR was a premature waste of 
everyone's time.

Scott K

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

Re: What does Israel/Local Authorities say about DC20?

[Scott Kitterman]

On Friday, May 22, 2020 12:43:56 PM EDT Sam Hartman wrote:
> [I hope someone on the DebConf team side is willing to summarize the
> results of this discussion to debian-vote]
> 
> > "Stefano" == Stefano Rivera  writes:
> Stefano> Hi Sam (2020.05.22_14:51:42_+)
> 
> >> The interesting thing is what the WHO says about travel and
> >> minimizing international travel.
> 
> Stefano> I was surprised that it doesn't try to dissuade the events
> Stefano> entirely.  What it does say is: 1. Work with your local
> Stefano> authorities.  2. Have a plan for dealing with an outbreak
> Stefano> at your event.
> 
> In the mail opening registration, there wasn't any discussion of having
> talked to Israel/the local authorities about the conference.
> There was only an assertion that it looked like things might be okay.
> 
> 1) To the extent that we have contacted the local authorities it seems
> like it would be good to write up the advice we have gotten.
> 
> 2) It sounds like the advice from the WHO is to work with local
> authorities.
> It seems like we really ought to follow that advice and reach out.
> I'd go so far as to say that holding a conference without good contacts
> to local health authorities and good lines of communication/support
> would be irresponsible.
> Now, for all I know that's in progress or has already happened.
> 
> 
> 3) Once we do get advice (or now if we already have that advice) I think
> that would be valuable input to the debian-vote discussion.

Or we might even want to step back and let the delegated team for this effort 
do their job.

Personally, I'll vote against any such GR that is proposed before the team 
makes an actual decision.  I think the idea of a GR to override a decision 
that a delegate hasn't made yet is horrible as a general precedent for how 
Debian works.

Scott K

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

Re: Q to all candidates: NEW queue

[Scott Kitterman]

On Friday, March 27, 2020 9:37:28 AM EDT Lucas Nussbaum wrote:
> On 27/03/20 at 09:23 -0400, Scott Kitterman wrote:
> > On Friday, March 27, 2020 8:40:11 AM EDT Lucas Nussbaum wrote:
> > > On 27/03/20 at 12:23 +0100, Martin Pitt wrote:
> > > > At least during my many years of Ubuntu archive administration I've
> > > > actually seen quite a lot of packages which contained
> > > > non-distributable
> > > > files, had hilariously broken maintainer scripts (which could then
> > > > also
> > > > damage *other* software on your system), and the like. For these an
> > > > initial NEW review was quite important.
> > > > 
> > > > That proposal is assuming that the "package gets reviewed, a bug is
> > > > filed"
> > > > step actually happens timely, but that is precisely the problem --
> > > > with
> > > > such a workflow we would essentially stop having NEW review and just
> > > > hope
> > > > that someone catches bad packages before they get released. So IMHO
> > > > this
> > > > is not a solution, and only causes buggy packages to creep into
> > > > unstable.
> > > 
> > > So in my original mail, I proposed that new packages would get
> > > immediately accepted into unstable, but would still require a review
> > > before migrating to testing. I believe that it's an interesting
> > > compromise,
> > > because:
> > > - while in unstable, they would get tested by our regular QA tools, that
> > > 
> > >   are likely to find some of the issues ftpmasters would have found
> > > 
> > > - it makes it possible for the maintainer to get early feedback from
> > > 
> > >   users, and to continue working on packaging reverse dependencies.
> > > 
> > > - it's unstable, so even if it's severely broken, it's probably not a
> > > 
> > >   big deal. We have lots of packages in unstable that have been severely
> > >   broken for years anyway.
> > > 
> > > - it protects 'testing' (and our stable releases) from unreviewed
> > > 
> > >   packages.
> > > 
> > > Of course this only works if Debian doesn't get sued for copyright
> > > infringement too often. I wonder if that would be a problem (it's
> > > probably less likely to be a problem for packages in 'main' than for
> > > packages in 'non-free').
> > > 
> > > Lucas
> > 
> > What's "too often"?
> 
> I don't know. Has it happened in the past? How frequently does ftpmaster
> run into things that would/could trigger a lawsuit?

I'm not aware of it ever happening and I think that's the acceptable 
frequency.  Such lawsuits are insanely expensive to defend.  I don't know how 
often it happens, it's not like we track it that way.  We did catch one really 
high risk package this month and it wasn't the code that was risky, it was the 
data.  So it happens.

Scott K

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

Re: Q to all candidates: NEW queue

[Scott Kitterman]

On Friday, March 27, 2020 8:40:11 AM EDT Lucas Nussbaum wrote:
> On 27/03/20 at 12:23 +0100, Martin Pitt wrote:
> > At least during my many years of Ubuntu archive administration I've
> > actually seen quite a lot of packages which contained non-distributable
> > files, had hilariously broken maintainer scripts (which could then also
> > damage *other* software on your system), and the like. For these an
> > initial NEW review was quite important.
> > 
> > That proposal is assuming that the "package gets reviewed, a bug is filed"
> > step actually happens timely, but that is precisely the problem -- with
> > such a workflow we would essentially stop having NEW review and just hope
> > that someone catches bad packages before they get released. So IMHO this
> > is not a solution, and only causes buggy packages to creep into unstable.
> 
> So in my original mail, I proposed that new packages would get
> immediately accepted into unstable, but would still require a review
> before migrating to testing. I believe that it's an interesting compromise,
> because:
> - while in unstable, they would get tested by our regular QA tools, that
>   are likely to find some of the issues ftpmasters would have found
> - it makes it possible for the maintainer to get early feedback from
>   users, and to continue working on packaging reverse dependencies.
> - it's unstable, so even if it's severely broken, it's probably not a
>   big deal. We have lots of packages in unstable that have been severely
>   broken for years anyway.
> - it protects 'testing' (and our stable releases) from unreviewed
>   packages.
> 
> Of course this only works if Debian doesn't get sued for copyright
> infringement too often. I wonder if that would be a problem (it's
> probably less likely to be a problem for packages in 'main' than for
> packages in 'non-free').
> 
> Lucas

What's "too often"?

Scott K

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

Re: Question to Brian: why not submit your plan for a Debian Foundation to a GR ?

[Scott Kitterman]

On Wednesday, March 18, 2020 6:41:42 PM EDT Brian Gupta wrote:
> On Wed, Mar 18, 2020 at 4:30 PM Neil McGovern  wrote:
> > On Thu, Mar 19, 2020 at 12:57:55AM +0800, Martin Michlmayr wrote:
> > > * Louis-Philippe Véronneau  [2020-03-18 12:52]:
> > > > Would you care to elaborate on what "the Yorba determination" is? I
> > > > couldn't find anything online about this...
> > > 
> > > There was a time when the IRS didn't approve any new 501(c)(3)
> > > applications for open source related organizations and basically put
> > > them on ice.
> > > 
> > > I thought this got resolved though in the meantime (years ago).
> > > 
> > > https://blogs.gnome.org/jnelson/2014/06/30/the-new-501c3-and-the-future-> 
> > > > > of-free-software-in-the-united-states/ https://opensource.org/node/840
> > 
> > The two links from Martin are probably the best background reading. the
> > tldr versions is: making FOSS is not enough to gain 501c3 status by
> > itself.
> 
> Applications for non-profit status need to be done carefully as they are
> scrutinized in most jurisdictions. Looking at the BOLO, it seems the IRS is
> particularly on the lookout for commercially developed Open Source Software.
> 
>"The members of the organizations are usually the for-profit business or
> for-profit support technicians of the software."
> 
> I think Debian has a very good case here, and at least to my eyes doesn't
> fit that description. I think it's worth the effort to try. As they say
> "nothing ventured, nothing gained."
> 
> Cheers,
> Brian

Well, I think there's a down side risk here too.  If Debian were to apply to 
create it's own foundation in the US (certainly in the US, possibly anywhere), 
that would be a very clear signal to SPI that we were planning to replace 
them.  So we file for the new non-profit and spend possibly years without an 
alternative to SPI while we've already told them they are going to be 
replaced.

That probably isn't motivating for a high level of service.  Then if we get 
turned down, we get to go back to them and say "That thing where we were going 
to fire you?  Can we pretend that never happened?".  Not a great position to be 
in.

I'd suggest we need to be far more certain that such a change is both needed 
and likely to be successful.  "Meh, let's give it a shot" isn't really a great 
plan.

Scott K

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

Re: What are your thoughts on discourse?

[Scott Kitterman]

On Wednesday, March 18, 2020 9:28:21 AM EDT Jonathan Carter wrote:
> Hi Raphaël
> 
> On 2020/03/18 12:00, Raphael Hertzog wrote:
> > I would like all the candidates to reply to this question on discourse:
> > https://discourse.debian.net/t/dear-dpl-candidates-what-are-your-thoughts-> 
> > > on-discourse/75
> Done.
> 
> > The kind of discussions that we have in debian-vote is very much suited
> > for something like discourse where we can +1 with like, etc.
> > 
> > I would encourage others DD asking questions to try to use discourse and
> > just use the mail to inform of the discussion started on discourse.
> 
> As I said on the post, I think it's better to keep questions to the DPL
> candidates on this list, rather than test Discourse for DPL Q midway
> through a DPL election.
> 
> And I also forgot to mention, nice initiative I do think that it has
> potential.

Thanks for keeping the focus here.

I've used discourse to attempt communication with Python upstream, which uses 
it.  It worked OK for a specific topic that I joined to focus on and discuss, 
but as a general discussion medium, like every single web thing I've tried, I 
think it's hopeless.

This is a free project, so people can talk wherever they want, but people are 
going to be left behind.

Scott K

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

Re: Some thoughts about Diversity and the CoC

[Scott Kitterman]

On December 12, 2019 2:57:55 PM UTC, Ian Jackson 
 wrote:
>Scott Kitterman writes ("Re: Some thoughts about Diversity and the
>CoC"):
>> I think you reinforce my original point.  In this case, the 'other
>> side' isn't the proposer of the option, it's me.
>> 
>> What I'm hearing is that the CoC isn't for people like me because
>> you are completely dismissive of my discomfort.
>
>For the avoidance of any doubt, I didn't support the use of a
>different word here (ie, instead of "diversity") because I thought
>using "diversity" in this way was a CoC violation.  I don't read
>anyone in this thread as asserting that "diversity" in Sam's proposal
>title was a CoC violation or that the CoC was a reason for deprecating
>that term in this context.
>
>Rather I supported use of a different word because I didn't want to
>have this dispute about init systems and software freedom mixed up
>with some "culture wars" debate about personal pronouns or whatever.
>
>Like it, sadly, now is.  If we had avoided the use of the word
>"diversity" originally in the original proposals (like I did in mine)
>this whole thread of conversation would have been avoided.
>
>I don't think the use of a different word made any of the options
>weaker.  If it did then there would have been a tradeoff: use a
>stronger word, and risk distraction/derailing/whatever; vs. use weaker
>language and avoid that risk.  Since I thought the non-"diversity"
>language was no weaker, I thought there wasn't a tradeoff there.
>
>It seemed to me that changing it was a no-brainer no matter whether
>you agree with me about "CoC stuff" (if I can put it like that), or
>agree with (say) you, Scott.  (I think we are quite far apart on
>that.)
>
>When making a political statement or resolution like this, it is a
>good idea to limit your content to the stuff you actually care about,
>and not put in anything controversial but unrelated.  This is true
>even if the controversial points are actually something you believe
>in.  One shouldn't unnecessarily alienate possible allies in a fight
>over one topic, even if they might be opponents on some other topic.
>So I think using a different word made my proposals more powerful
>because it helped them appeal to a wider community.
>
>If you want to have a wider conversation about "CoC stuff" then fine,
>I guess, but maybe it would be best not to have it now ?  Or maybe we
>can talk about it over a beer sometime or something (you and I, I
>mean, and yes this is a concrete offer, if circumstances make it
>convenient).
>
>I hope that helps makes sense of my position and maybe defuses some of
>your unease.

Sure.  Also, I've had several hours working on non-Debian stuff to reset my 
outrage filters a bit.

I will continue to be concerned about the use of the CoC and it's goals to 
constrain speech where it's not needed.  I don't think further discussion on 
the topic is needed now, but if I see what I think is overreach in the future, 
you'll likely hear from me again.

We're less far apart on the goals of the CoC than I imagine you think.  It's 
highly likely, however, that I'm going to lean in favor of keeping things 
narrowly focused to achieve those goals because I place a high value on free 
expression (which is not the same thing as saying people should get a free pass 
to behave badly towards others).

Scott K

Re: Some thoughts about Diversity and the CoC

[Scott Kitterman]

On December 12, 2019 3:01:26 PM UTC, Sam Hartman  wrote:
>>>>>> "Scott" == Scott Kitterman  writes:
>
>
>Scott> I think you reinforce my original point.  In this case, the
>Scott> 'other side' isn't the proposer of the option, it's me.
>
>Scott> What I'm hearing is that the CoC isn't for people like me
>Scott> because you are completely dismissive of my discomfort.
>
>Given that Simon has his preference, what would you prefer to have
>happened?
>Are you saying you wish there were options on the ballot both with and
>without diversity?
>Are you asking for your concern to be acknowledged, but perhaps not for
>some other change?
>How would you like for us to value both Simon   's position and your
>concern?
>
>These are serious questions.
>I don't want to be dismissive, and I understand how it might come
>across
>that way.

I think when people personally feel excluded/diminished/pick your term then 
it's appropriate to work on how to frame things to see how to make them feel 
welcome (e.g. if someone is more comfortable being referred to by they, then I 
think it's appropriate to use it).  That's not how I read Simon's request.  I 
read as being speculative that maybe the wording might make someone 
uncomfortable, not about anything they were directly experiencing.

To me that's on the other side of a reasonableness line.  In my view it's 
trying to solve a problem that doesn't actually exist.  In a global volunteer 
project that touches thousands of people, the question of what is guaranteed 
not to offend anyone is actually pretty easy to answer: nothing or vanishingly 
close to it.

I believe the approach of solving 'maybe someone will be offended' problems 
preemptively leads to significantly greater restrictions on speech than are 
needed to meet the goal of the CoC (which I think is a good goal).

Given that the word diversity was being used in a very normal way and no one 
was claiming to feel excluded by its use, I think the right response would have 
been "thanks for the input, we'll keep an eye out for it being a problem".

No, I don't think more options would help.

What I would like to have happen is for people to confine their language 
complaints to either narrow cases that are well established to be problematic 
or things that make them personally feel unwelcome in the project.  I recognize 
I might not get that.

Thanks for listening,

Scott K

Re: Some thoughts about Diversity and the CoC

[Scott Kitterman]

On December 12, 2019 12:23:21 PM UTC, Sam Hartman  wrote:
>>>>>> "Scott" == Scott Kitterman  writes:
>
>   Scott> TLDR: Words have meanings and I find it deeply offensive when
>Scott> one group tries to hijack them for their own ends.  This
>Scott> entire discussion makes me less comfortable with
>Scott> participating in Debian.
>I agree that happens sometimes.
>I agree that's even happened in Debian.
>
>I really don't think it happened here.
>Simon  did not try to narrow the meaning of diversity.
>He talked about why people might not want to use the word.
>
>And (this is key), the *other side agreed*.
>Listening to someone, hearing their concern and finding there's a way
>to
>meet your needs and theirs that both sides are happy with is in my
>opinion not hijacking.
>
>--Sam

I think you reinforce my original point.  In this case, the 'other side' isn't 
the proposer of the option, it's me.

What I'm hearing is that the CoC isn't for people like me because you are 
completely dismissive of my discomfort.

Scott K

Re: Some thoughts about Diversity and the CoC

[Scott Kitterman]

TLDR: Words have meanings and I find it deeply offensive when one group tries 
to hijack them for their own ends.  This entire discussion makes me less 
comfortable with participating in Debian.

Didn't have the energy to write the long version.

Scott K

On December 11, 2019 3:50:06 PM UTC, Sam Hartman  wrote:
>TL;DR: Treating people with respect is hard and very contextual.
>Choosing to change how you talk about something to make people more
>comfortable doesn't always mean you were obligated to make that change.
>Sometimes you're just promoting connection.
>
>>>>>> "Scott" == Scott Kitterman  writes:
>
>Scott> On November 27, 2019 2:54:04 PM UTC, Simon McVittie
> wrote:
>>> On Wed, 27 Nov 2019 at 11:27:13 +, Chris Lamb wrote:
>>>> May I gently request we replace the use of the word "diversity"
>>>> throughout the "init systems and systemd" General Resolution
>>>> prior to it being subject to a plebiscite?
>>> 
>>> Thank you for raising this, Chris.
>>> 
>>> I agree. I have been uncomfortable with this in the context of
>>> "init diversity" efforts, but I didn't raise it in the past
>>> because I couldn't articulate clearly why I felt that it was a
>>> problem.  Since it's now on-topic, here's my best attempt at
>>> 
>>> I would hate to see diversity and inclusion of people (the
>>> meaning of the word used in the name of the Diversity Team)
>>> harmed by creating a perception that the term "diversity" has
>>> been devalued by stretching it to encompass technical
>   >> preferences, because I think diversity and inclusion of people is
>>> much too important to let that happen.
>
>   Scott> I am deeply saddened by this message.  I think it is entirely
>Scott> misguided, but I fail to come up with a way to explain it
>   Scott> that is no one will think violates our code of conduct.  It's
>   Scott> things like this that are causing me to start to view it as a
>Scott> mistake.
>
>Scott, let me take a crack, because I too was deeply conflicted by that
>message, especially as I think about the CoC.
>
>First, there's a sense in which I agree with removing the term
>diversity.
>It's clear that Simon's message  represents a position that resonates
>with a number of participants in the discussion.
>Those people are  in effect saying "We'd feel more welcome in this
>discussion if you'd change the term.  Also, it might make it more
>likely
>your preferred option is selected."
>
>The people using the term diversity thought about it and decided that
>they did want to be more welcoming and probably even that they agreed
>with the political analysis.
>So they proposed changing the term.
>That's great.
>The CoC encourages us to listen, and to show respect for others.
>And I think considering changing the framing of the discussion to
>include people is a great thing to do.
>The emphasis is on *considering* (and of course when you consider and
>conclude it is a good idea, doing).
>
>So in this instance, based on what we saw in the discussion, I think
>the
>term change is great.
>
>We've seen a trend that there are a number of people who are
>uncomfortable using concepts like diversity, war, censorship, and free
>speech that are globally loaded as part of analogies in a Debian and
>free software context.
>As I understand it, the CoC says we should consider these needs.
>
>But others actually value those analogies.  No, Debian is not a
>government.  Moderating content we distribute is not the same as
>government censorship.  And yet, Debian has power in the world.  And
>some of those analogies have power because members of our community
>would like to see Debian as a force for freedom; they would like to
>reflect values both globally and locally.  And so they find using the
>same words powerful in both contexts.  We exclude them by denying them
>their analogies; that has a cost.  That kind of exclusion can be
>disrespectful.
>
>It's a balance.
>Just because following the principles in the CoC, we change our
>terminology does not mean that was the only reasonable thing to do.
>In some situations, we also could have been respectful by acknowledging
>the concern, considering it, understanding why we make a choice that
>makes some uncomfortable, and continuing to make that choice.  "Hey,
>we're not trying to be jerks by talking about freedom of speech.  We
>hear and acknowledge the difference you're pointing at, but this
>analogy allows us to celebrate something that is important to 

Re: Option G update (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Scott Kitterman]

On Friday, December 6, 2019 3:59:43 PM EST Kurt Roeckx wrote:
> On Fri, Dec 06, 2019 at 09:04:39PM +0100, Guillem Jover wrote:
> > Hi!
> > 
> > Ok, so here's what I'd like (or would have liked) to get into the ballot,
> > given the new context after the addition of the combined D+G option. But
> > it's not very clear to me whether this will be acceptable or not to the
> > Secretary, and what would be the actual procedure to replace the existing
> > option G with this one (as long as enough of the original sponsors are
> > fine with it), as I've found the way the procedure was applied/interpreted
> > to be rather confusing or perhaps not matching my memory of previous
> > instances.
> 
> You're really cutting this short, sending an email 4 hours before the
> vote starts, and we're not at 3 hours before the start. I'm going to
> need to see at least 5 people seconding this update before 23 UTC,
> so 2 hours left, to allow this update.

I count there are 5 now.

Scott K

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

Re: Option G update [signed] (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Scott Kitterman]

On Friday, December 6, 2019 3:51:50 PM EST Guillem Jover wrote:
> [ Sorry, resending signed this time around. :/ ]
> 
> Hi!
> 
> Ok, so here's what I'd like (or would have liked) to get into the ballot,
> given the new context after the addition of the combined D+G option. But
> it's not very clear to me whether this will be acceptable or not to the
> Secretary, and what would be the actual procedure to replace the existing
> option G with this one (as long as enough of the original sponsors are
> fine with it), as I've found the way the procedure was applied/interpreted
> to be rather confusing or perhaps not matching my memory of previous
> instances.
> 
> The changes to the original G are:
>  - Addition of Principles section title.
>  - s/tradeoffs/trade-offs/g.
>  - Addition of Guidance section.
> 
> I'm CCing all the previous sponsors explicitly, just in case.
> 
> 
> X<
> Title: Reaffirm our commitment to support portability and multiple
> implementations
> 
> Principles
> ~~
> 
> The Debian project reaffirms its commitment to be the glue that binds
> and integrates different software that provides similar or equivalent
> functionality, with their various users, be them humans or other software,
> which is one of the core defining traits of a distribution.
> 
> We consider portability to different hardware platforms and software
> stacks an important aspect of the work we do as a distribution, which
> makes software architecturally better, more robust and more future-proof.
> 
> We acknowledge that different upstream projects have different views on
> software development, use cases, portability and technology in general.
> And that users of these projects weight trade-offs differently, and have
> at the same time different and valid requirements and/or needs fulfilled
> by these diverse views.
> 
> Following our historic tradition, we will welcome the integration of
> these diverse technologies which might sometimes have conflicting
> world-views, to allow them to coexist in harmony within our distribution,
> by reconciling these conflicts via technical means, as long as there
> are people willing to put in the effort.
> 
> This enables us to keep serving a wide range of usages of our distribution
> (some of which might be even unforeseen by us). From servers, to desktops
> or deeply embedded; from general purpose to very specifically tailored
> usages. Be those projects hardware related or software based, libraries,
> daemons, entire desktop environments, or other parts of the software
> stack.
> 
> Guidance
> 
> 
> In the same way Debian maintainers are somewhat constrained by the
> decisions and direction emerging from their respective upstreams,
> the Debian distribution is also somewhat constrained by its volunteer
> based nature, which has as another of its core defining traits, not
> willing to impose work obligations to its members, while at the same
> time being limited by its members bounded interests, motivation, energy
> and time.
> 
> Because of these previous constraints, trying to provide guidance in
> a very detailed way to apply the aforementioned principles, is never
> going to be satisfactory, as it will end up being inexorably a rigid
> and non-exhaustive list of directives that cannot possibly ever cover
> most scenarios, which can perpetuate possible current tensions.
> 
> These will always keep involving case by case trade-offs between what
> changes or requests upstreams might or might not accept, or the upkeep
> on the imposed deltas or implementations the Debian members might need
> to carry on. Which can never be quantified and listed in a generic and
> universal way.
> 
> We will also keep in mind that what might be considered important for
> someone, might at the same time be considered niche or an uninteresting
> diversion of time for someone else, but that we might end up being on
> either side of the fence when sending or receiving these requests.
> 
> We will be guided, as we have been in many other Debian contexts in the
> past, by taking all the above into account, and discussing and evaluating
> each situation, and respecting and valuing that we all have different
> interests and motivations. That is in our general interest to try to
> work things out with others, to compromise, to reach solutions or find
> alternatives that might be satisfactory enough for the various parties
> involved, to create an environment where we will collectively try to
> reciprocate. And in the end and in most cases it's perhaps a matter of
> just being willing to try.
> X<

Seconded.

Scott K


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

Re: Proposal to overturn init systems premature GR

[Scott Kitterman]

On Tuesday, December 3, 2019 12:13:03 PM EST Sam Hartman wrote:
> I note that our voting system does have recourse for people who believe
> that the vote is called to early.
> 
> They can vote FD above other options.
> And in this specific case, voting G>FD> other options
> would send a clear message that we should develop options based on G.

I don't have a strong opinion on the outcome of the vote, but I do have a 
strong opinion about this.

I think short circuiting the discussion process casts into question the 
legitimacy of the process.

I think you are wrong here.  How can one know where to rank option G when it's 
clearly incomplete.  I don't know if I like it or not.  Let's finish the work 
on getting the ballot right and then vote.

If you think this discussion has been fun, consider the fun of doing it over 
again next year with accusations of DPL bad faith thrown in.

Please wait.

Scott K

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

Re: Please drop/replace the use of the term "diversity"

[Scott Kitterman]

On November 27, 2019 2:54:04 PM UTC, Simon McVittie  wrote:
>On Wed, 27 Nov 2019 at 11:27:13 +, Chris Lamb wrote:
>> May I gently request we replace the use of the word "diversity"
>> throughout the "init systems and systemd" General Resolution prior to
>> it being subject to a plebiscite?
>
>Thank you for raising this, Chris.
>
>I agree. I have been uncomfortable with this in the context of "init
>diversity" efforts, but I didn't raise it in the past because I
>couldn't
>articulate clearly why I felt that it was a problem.  Since it's now
>on-topic, here's my best attempt at that:
>
>The diversity team, and wider efforts around diversity in Debian and
>in software in general, have used "diversity" as a catch-all term for
>personal characteristics of our contributors and community members when
>discussing inclusion and how we treat people, as a way to avoid having
>to enumerate specific characteristics (which would tend to lead to
>focus
>on those characteristics at the expense of others).
>
>If we use the same word in discussions around technical decisions, this
>raises some concerns for me. Jokes about the emacs and vi religions
>aside, technical preferences are not really the same thing as the
>characteristics we normally refer to by "diversity". Of course, we
>should treat the people who hold those preferences with respect, but
>that isn't the same as considering implementation of their preference
>to be an ethical imperative for Debian.
>
>To take a deliberately slightly absurd example, preferring Gentoo over
>Debian is not an inclusion or diversity issue; we welcome constructive
>contributions to Debian from people who would prefer to be using Gentoo
>(notably some of our upstreams!), but we do not consider it to be an
>ethical imperative to expand the scope of Debian to encompass
>everything
>Gentoo does.
>
>I would hate to see diversity and inclusion of people (the meaning of
>the word used in the name of the Diversity Team) harmed by creating a
>perception that the term "diversity" has been devalued by stretching
>it to encompass technical preferences, because I think diversity and
>inclusion of people is much too important to let that happen.
>
>Conflating diversity of people with diversity of implementation could
>easily also harm our technical decisions, in either direction:
>
>* it could influence technical decisions away from making a choice as
>  a project, and towards creating infrastructure to make that choice on
>  individual systems, by developers who do not wish to be perceived to
>  be opposing "diversity" in the interpersonal/Diversity Team sense of
>  the word;
>
>* conversely, it could influence technical decisions *towards* making a
>  choice as a project, and *away from* making that choice on individual
>  systems, by developers who might believe this use of "diversity" is
>  disingenuous (even if it was not intended as such).
>
>The extent to which we make choices project-wide, and the amount of
>technical cost we are willing to accept to be able to make those
>choices
>onto individual systems, seem like something that we should decide
>based
>on their merits. Whatever the result of the imminent vote might be,
>I would like it to be chosen for the right reasons.

I am deeply saddened by this message.  I think it is entirely misguided, but I 
fail to come up with a way to explain it that is no one will think violates our 
code of conduct.  It's things like this that are causing me to start to view it 
as a mistake.

Scott K

Re: Draft text on Init Systems GR

[Scott Kitterman]

On November 16, 2019 10:50:59 PM UTC, Kurt Roeckx  wrote:
>On Sat, Nov 16, 2019 at 05:40:10PM +, Dmitry Bogatov wrote:
>> 
>> [2019-11-15 11:52] Ian Jackson 
>> > Dmitry, I suggest instead, this change to your original text:
>> 
>>  Being able to run Debian systems with init systems other than
>>  systemd continues to be value for the project. Package not
>>  working with pid1 != systemd is RC bug, unless it was designed
>>  by upstream to work exclusively with systemd and no support for
>>  running without systemd is available.
>> 
>> > That means that if upstream drop the init script, or say they do
>not
>> > care about non-systemd, we in Debian will still ship the init
>script
>> > (and apply needed patches if they exist).
>> >
>> > What do you think ?
>> 
>> Yes, I agree with your proposed change.  We need four more votes for
>> this wording appear on ballot, I guess.
>
>Someone needs to be clear that something is proposed, and that
>it's being seconded. I don't see Ian either actually proposing it
>as an option, nor seconding it. As far as I understand, you actually
>made a different proposal without any seconds.
>
>I guess that "is RC bug" overrides the power of a delegate (the
>release team). The delegation
>(https://lists.debian.org/debian-devel-announce/2019/01/msg9.html)
>says "Which issues are release-critical (RC)".

If this language survives, I'll propose an amendment to make it clear this is 
not intended.  Overriding the Release Team in this GR would be a bad idea.

As I've mentioned before, these need to be framed in terms of policy, not 
RCness.

Scott K

Re: Proposal: General Resolution on Init Systems and systemd Facilities

[Scott Kitterman]

On November 15, 2019 3:26:31 AM UTC, Russ Allbery  wrote:
>Scott Kitterman  writes:
>
>> This option makes multiple references to RC and non-RC bugs based on
>> actions of the policy editors.
>
>> It's my understanding that determining if a bug is RC or not is a
>> Release Team function, not the policy editors.
>
>> Would it be better to use something like 'severe policy violation'
>(and
>> it's opposite) than Release Critical?
>
>No objections here but I think it's a minor issue.  These are generally
>kept in sync except that the release team is free to declare violations
>of
>a Policy must to not be release-critical in the service of getting a
>release out and scoping the amount of work we're committing to do. 
>(The
>contrary should *not* be true and only is due to lack of resources;
>anything that the release team considers release-critical should be a
>must
>in Policy, and bug reports are welcome in any place this is not in
>sync.)
>
>If a Policy must is declared not release critical for release after
>release, I'd like to synchronize and downgrade it to a should.  The
>goal
>is for both policies to say the same thing except for temporary
>exceptions.

Okay.  My thought is that it's cleaner to state this GR is about the project 
position on policy and not about the Release Team's execution of its delegated 
authority if we stay away from the RC terminology.

We may all know what we mean now, but GRs seem to get referenced for a very 
long time.  I think it's worth it for 15 years from now Debian to be as clean 
and clear as we can now.

Scott K

Re: Proposal: General Resolution on Init Systems and systemd Facilities

[Scott Kitterman]

On November 14, 2019 8:08:28 PM UTC, Sam Hartman  wrote:
>
>
>I'd like to propose the following resolution.
>
>Seconds are not required, but it would be valuable to get confirmation
>that the three choices contained in this proposal are worth having on
>the ballot.
>So, rather than seconding the proposal it would be useful if people
>would ack choices here they'd like to see on the ballot.
>
>Amendments will require seconds as usual.
>
>Timeline: I think that two weeks for discussion of this GR seems about
>right based on what's happened in the last week.  The constitution
>allows the DPL to change the discussion period by up to a week.  The
>discussion period is normally reset by the proposer accepting any
>amendment or making a modification to the proposal.  If an amendment is
>accepted, I am likely to use that power such that the discussion period
>is the longer of two weeks from when the secretary sends mail to
>debian-devel-announce, or seven days past the time of the last
>amendment
>being accepted.  In other words, if I accept an amendment in the next
>week, I'm likely to keep the total discussion period at two weeks.
>
>That said, if it looks like we need more time, I can always lengthen
>the
>discussion period.
>I do not see any circumstances under which I'd like to shorten the
>voting period for this proposal.
>
>
>version: d429a990a09
>Changes since initial draft:
>
>
>* Clarify that packages may need to handle early boot in an
>init-system-specific manner in choice 1
>
>* Clean up wording around the requested policy change in choice 1
>
>* Adopt Russ's option B for choice 1 at least until we get clear
>  direction from that community.
>
>* Adopt Russ's option C for choice 2.
>
>* Adopt something similar to Russ's option D for choice 3
>
>* Add my name to choices to make life easier on the secretary as others
>get sufficient seconds.
>
>* Revise the title of choice 3 to avoid concerns that it is insulting
>  to proponents of systemd.
>
>
>
>
>
>Using its power under Constitution section 4.1 (5), the project issues
>the following statement describing our current position on Init
>systems, Init system diversity, and the use of systemd facilities. 
>This
>statement describes the position of the project at the time it is
>adopted.  That position may evolve as time passes without the need to
>resort to future general resolutions.  The GR process remains
>available if the project needs a decision and cannot come to a
>consensus.
>
>Choice hartmans1: Affirm Init Diversity
>
>Being able to run Debian systems with init systems other than systemd
>continues to be something that the project values.  With one
>exception, the Debian Project affirms the current policy on init
>scripts and starting daemons (policy 9.3.2, 9.11).  Roughly, packages
>should include init scripts to start services that are included.
>Policy notes that early boot services like those started from
>/etc/rcS.d may be tied closely to the init system in use and thus may
>need to be handled differently for each init system.  Init
>scripts are the lowest common denominator across all init systems.
>Packages may include support for init systems like systemd service
>units in addition to init scripts.  Current policy makes it an RC bug
>to include a service unit without an init script.
>
>Policy editors are requested to amend policy; a package having a
>service unit but without an init script is no longer an RC bug, but
>including an init script is appropriate for a non-maintainer upload.
>Policy editors are requested to consider whether there are cases where
>removing an init script that used to be provided should be RC because
>it would break a system on upgrade.
>
>Once the community of users of an alternate init system have said that
>a solution is sufficiently functional for them, others should not
>generally second guess this determination.
>
>systemd unit files included in the package may use any systemd feature
>or service at the package maintainer's discretion, provided that this
>is consistent with other Policy requirements and the normal
>expectation that packages shouldn't depend on experimental or
>unsupported (in Debian) features of other packages.
>
>Init scripts must use only facilities common to all supported init
>systems in Debian and therefore may not use services that depend on
>systemd.
>
>Similarly, packages may freely use other systemd facilities such as
>timer units, subject to the above constraints, but not also supporting
>non-systemd systems is a (non-RC) bug and non-maintainer uploads to add
>that support are appropriate.
>
>systemd facilities may be used at the discretion of package
>maintainers, but modification of Policy to adopt systemd facilities
>instead of existing approaches is discouraged unless an equivalent
>implementation of that facility is available for other init systems.

This option makes multiple references to RC 

Re: Q to both: facilitating meetups

[Scott Kitterman]

On March 29, 2017 8:16:40 PM EDT, Mehdi Dogguy <me...@dogguy.org> wrote:
>Hi Scott,
>
>On 29/03/2017 13:34, Scott Kitterman wrote:
>> On Wednesday, March 29, 2017 11:25:29 AM Mehdi Dogguy wrote:
>> ...
>>> I believe the Roadmap will help us for the first subject and the
>partners
>>> program, once in place, will bring new (useful) workflows on the
>>> organization side.
>> ...
>> 
>> IIRC, last year your campaign included this idea of roadmaps.  Do you
>have 
>> examples from your first year of roadmaps in use or being developed?
>> 
>
>I am not sure I understood your question. Can you please rephrase it?

In your platform from last year [1], you discussed this Roadmap (I mistakenly 
recalled roadmaps, but you described it singularly).

How is the Roadmap going?  Is it defined?  Where can I read about what's been 
accomplished?  Is helping Debian and if so, how?

That's a slightly more verbose expression of the question.  Does that help?

Scott K

[1] https://www.debian.org/vote/2016/platforms/mehdi#roadmap

Re: Q to both: facilitating meetups

[Scott Kitterman]

On Wednesday, March 29, 2017 11:25:29 AM Mehdi Dogguy wrote:
...
> I believe the Roadmap will help us for the first subject and the partners
> program, once in place, will bring new (useful) workflows on the
> organization side.
...

IIRC, last year your campaign included this idea of roadmaps.  Do you have 
examples from your first year of roadmaps in use or being developed?

Scott K


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

Re: Proposed GR: State exception for security bugs in Social Contract clause 3

[Scott Kitterman]

On Thursday, January 12, 2017 02:26:59 PM Sean Whitton wrote:
> Hello,
> 
> On Thu, Jan 12, 2017 at 03:11:46AM +0000, Scott Kitterman wrote:
> > Here's an example of possible unintended consequences:
> > 
> > Currently we enumerate no specifics about exceptions to when things
> > should be public.  Once we have a foundational list of acceptable
> > reasons to not be public (security would be the only one), then it's
> > easy to infer that's the complete list.
> > 
> > Would this GR prohibit the tech ctte practice of private deliberations
> > about recommendations for new members?  I think it might.
> > 
> > I've worked in private with other DDs to resolve disputes within the
> > project.  Often a quiet conversation out of the public glare can make
> > solutions possible that wouldn't happen if all discussion was public.
> > Does this GR prohibit that?  Maybe.
> 
> Thank you for your e-mail -- I now understand your objection.
> 
> All the other wording in clause 3 is about bug reports against the
> Debian system.  The examples that you give are about unresolved issues
> in the Debian project -- disputes between people, rather than problems
> in source and binary packages.  I find the line between the Debian
> system and the Debian project to be fairly sharp.  I'd be interested to
> hear if you disagree.
> 
> The header of clause 3 ("We will not hide problems") admittedly could
> refer to your examples.  Would it help if my GR text were amended to
> append "in the Debian system" to the header of the clause?

That then has the opposite problem.  It clearly narrows the notion of not 
hiding problems and I don't think that's good either.

I'm still at don't monkey with foundational documents to solve non-problems.

Scott K

P.S.  I am subscribed.  Please don't cc me.

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

Re: Proposed GR: State exception for security bugs in Social Contract clause 3

[Scott Kitterman]

On January 11, 2017 4:47:30 PM EST, Sean Whitton <spwhit...@spwhitton.name> 
wrote:
>Hello Scott,
>
>On Tue, Jan 10, 2017 at 07:04:02PM -0500, Scott Kitterman wrote:
>> Yes, but all your proposed GR does is move the problem one definition
>> to the right.
>
>I don't follow this objection.  The SC is not meant to contain
>exhaustive details of policies.  At present, though, I think it goes
>too
>far the other way.  This GR is intended to nudge it closer to the right
>level of detail.

I think there is always risk of unintended consequences.  

I don't think the proposed GR solves any problems (at most it substitutes an 
argument about security issues being embargoed at all for an argument about 
what's reasonable - we can be reasonable without a GR).

Here's an example of possible unintended consequences:

Currently we enumerate no specifics about exceptions to when things should be 
public.  Once we have a foundational list of acceptable reasons to not be 
public (security would be the only one), then it's easy to infer that's the 
complete list.

Would this GR prohibit the tech ctte practice of private deliberations about 
recommendations for new members?  I think it might.

I've worked in private with other DDs to resolve disputes within the project.  
Often a quiet conversation out of the public glare can make solutions possible 
that wouldn't happen if all discussion was public.  Does this GR prohibit that? 
 Maybe.

If we need this, do we need this or another GR  to authorize debian-private?

It's a can of worms we don't need to open.

>> Are you aware of any newcomers that have been negatively affected
>this
>> way?
>
>I'm not.  I could imagine it happening to a younger version of myself,
>though.

I think we're better of spending project time and effort on real things that 
need doing and not on imaginary problems.

Scott K

Re: Proposed GR: State exception for security bugs in Social Contract clause 3

[Scott Kitterman]

On Tuesday, January 10, 2017 04:45:36 PM Sean Whitton wrote:
> Hello,
> 
> In my original proposal e-mail, I should have said more about why I
> think this is a good idea.  My apologies for not having done so.
> 
> No-one who understands how GNU/Linux distributions work thinks that
> there is anything problematic about short-term embargos of information
> about serious security bugs.  However, the SC is not just for those
> people: it's also something for newcomers to read.
> 
> Imagine a newcomer who finds SC clause 3 very attractive: they
> particularly value transparency about development.  Then they learn that
> certain information is held in a separate, non-public bug tracker, and
> their initial enthusiasm for Debian is somewhat dampened.  If we pass
> this GR, we can avoid leaving a bad taste in that newcomer's mouth.
> That's good for Debian.
> 
> On Mon, Jan 09, 2017 at 11:51:37PM -0500, Scott Kitterman wrote:
> > What is the definition of serious and what is the definition of
> > limited?
> 
> Intentionally not specified, so that it's left up to the judgement of
> those implementing the social contract (i.e. the current body of
> developers, esp. the security team).
> 
> The SC is full of words that work like this.

Yes, but all your proposed GR does is move the problem one definition to the 
right.  Are you aware of any newcomers that have been negatively affected this 
way?

Scott K


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

Re: Proposed GR: State exception for security bugs in Social Contract clause 3

[Scott Kitterman]

On Monday, January 09, 2017 09:00:58 PM Russ Allbery wrote:
> Scott Kitterman <deb...@kitterman.com> writes:
> > On Monday, January 09, 2017 07:08:19 PM Sean Whitton wrote:
> >> === BEGIN GR TEXT ===
> >> 
> >> Title: State exception for security bugs in Social Contract clause 3
> >> 
> >> 1. Debian has a longstanding practice of sharing information about
> >> 
> >>serious security bugs with only the security team.  This is so that
> >>they can co-ordinate release of the information with other vendors.
> >> 
> >> 2. The third clause of our Social Contract says that "We will not hide
> >> 
> >>problems."  However, the practice of embargoing information about
> >>serious security bugs could be seen as the hiding of problems.
> >> 
> >> 3. Resolve to append the following to clause 3 of the Social Contract:
> >> An exception is made for serious security problems.  Information
> >> about these may be kept confidential for a limited period of time,
> >> so that a release of information may be co-ordinated with other
> >> vendors.
> >> 
> >> === END GR TEXT ===
> > 
> > What is the definition of serious and what is the definition of limited?
> 
> My preference would be to just reuse the distros disclosure policy, as
> that's been hashed out in public among the security community and is used
> by all the various Linux distributions.
> 
> http://oss-security.openwall.org/wiki/mailing-lists/distros
> 
> Please note that the maximum acceptable embargo period for issues
> disclosed to these lists is 14 to 19 days, with embargoes longer than
> 14 days (up to 19) allowed in case the issue is reported on a Thursday
> or a Friday and the proposed coordinated disclosure date is thus
> adjusted to fall on a Monday or a Tuesday. Please do not ask for a
> longer embargo. In fact, embargo periods shorter than 7 days are
> preferable. Please notify upstream projects/developers of the affected
> software, other affected distro vendors, and/or affected Open Source
> projects before notifying one of these mailing lists in order to
> ensure that these other parties are OK with the maximum embargo period
> that would apply (and if not, then you may have to delay your
> notification to the mailing list), unless you're confident you'd
> choose to ignore their preference anyway and disclose the issue
> publicly soon as per the policy stated here.
> 
> Note that this still lets you make exceptions if upstream wants a longer
> embargo period (by holding off on notifying distros and contacting other
> distributions out of band).  It's hard to make this decision in advance
> for everything; there are always challenging special circumstances.  (I as
> a DD would be fine with our security team making that call in exceptional
> situations.)
> 
> I don't think there's much point in defining serious.  If we have a
> disclosure policy, then it doesn't matter as much.

I don't think this sort of thing is amenable to being specifically defined in 
a way that's really suitable for foundational documents.  Has anyone ever 
seriously questioned the appropriateness of the Security Team's practices 
based on the Social Contract?

I don't think we should be monkeying with the Social Contract to solve a non-
problem.

Scott K

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

Re: Proposed GR: State exception for security bugs in Social Contract clause 3

[Scott Kitterman]

On Monday, January 09, 2017 07:08:19 PM Sean Whitton wrote:
> === BEGIN GR TEXT ===
> 
> Title: State exception for security bugs in Social Contract clause 3
> 
> 1. Debian has a longstanding practice of sharing information about
>serious security bugs with only the security team.  This is so that
>they can co-ordinate release of the information with other vendors.
> 
> 2. The third clause of our Social Contract says that "We will not hide
>problems."  However, the practice of embargoing information about
>serious security bugs could be seen as the hiding of problems.
> 
> 3. Resolve to append the following to clause 3 of the Social Contract:
> 
> An exception is made for serious security problems.  Information
> about these may be kept confidential for a limited period of time,
> so that a release of information may be co-ordinated with other
> vendors.
> 
> === END GR TEXT ===

What is the definition of serious and what is the definition of limited?

Scott K

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

Re: devotee currently not sending replies

[Scott Kitterman]

On Monday, November 30, 2015 03:13:07 PM Sam Hartman wrote:
> > "Kurt" == Kurt Roeckx  writes:
> Kurt> On Sun, Nov 29, 2015 at 03:44:02PM +0100, Kurt Roeckx wrote:
> >> On Sun, Nov 29, 2015 at 01:58:56AM +0100, Kurt Roeckx wrote:
> >> > It seems devotee is currently not working properly.  Some
> >> 
> >> people > have received an error message, I've mailed them to vote
> >> again.
> >> 
> >> > I've temporary disabled processing of the incomming mails.  The
> >> > acknowledges will come once I'm certain I fixed the issue.
> >> 
> >> So I let it run, but it seems more things are broken.  I can
> >> actually replay things, so if you got an error there should be no
> >> need to vote again.
> 
> Kurt> I believe everything is fixed now and people should have
> Kurt> gotten an ACK if they voted properly.
> 
> 
> I   've sent two votes and gotten no acks.
> What information can I provide to help you debug?

FYI,  I got a reply to a vote about 20 minutes before you mail was sent, so 
it's not failing completely.

Scott K

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

Re: General Resolution: Fix Minor Bugs in Constitution

[Scott Kitterman]

On Friday, October 30, 2015 08:00:30 PM Philip Hands wrote:
> Sam Hartman  writes:
> >- GENERAL RESOLUTION STARTS -
> >
> >
> >Constitutional Amendment: TC Supermajority Fix
> >
> >Prior to the Clone Proof SSD GR in June 2003, the Technical
> >Committee could overrule a Developer with a supermajority of 3:1.
> >
> >Unfortunately, the definition of supermajorities in the SSD GR has a
> >off-by-one  error.  In the new text a supermajority requirement is met
> >only if the ratio of votes in favour to votes against is strictly
> >greater than the supermajority ratio.
> >
> >In the context of the Technical Committee voting to overrule a
> >developer that means that it takes 4 votes to overcome a single
> >dissenter.  And with a maximum committee size of 8, previously two
> >dissenters could be outvoted by all 6 remaining members; now that
> >is no longer possible.
> >
> >This change was unintentional, was contrary to the original intent
> >of the Constitution, and is unhelpful.
> >
> >For the avoidance of any doubt, this change does not affect any
> >votes (whether General Resolutions or votes in the Technical
> >Committee) in progress at the time the change is made.
> > 
> >Therefore, amend the Debian Constitution as follows:
> > Index: doc/constitution.wml
> > ===
> > --- doc/constitution.wml(revision 10982)
> > +++ doc/constitution.wml(working copy)
> > @@ -913,7 +913,7 @@
> > 
> >   
> >   
> >   
> >An option A defeats the default option D by a majority
> > 
> > -  ratio N, if V(A,D) is strictly greater than N * V(D,A).
> > +  ratio N, if V(A,D) is greater or equal to  N * V(D,A)
> > and V(A,D) is strictly greater than V(D,A).> 
> >   
> >   
> >   
> >If a supermajority of S:1 is required for A, its
> >majority ratio
> >
> >Constitutional Amendment: Fix duplicate section numbering.
> >
> >The current Debian Constitution has two sections numbered A.1.
> >This does not currently give rise to any ambiguity but it is
> >undesirable.
> >
> >Fix this with the following semantically neutral amendment:
> > - Renumber the first section A.1 to A.0.
> >
> >- GENERAL RESOLUTION ENDS -
> 
> Seconded.
> 
> Cheers, Phil.

Seconded.

Scott K


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

Re: Restated Amendment: We Choose Wording of the Day

[Scott Kitterman]

Yes.  that's the one I recalled that I liked.  Seconded.

Scott K

On Wednesday, September 09, 2015 01:08:39 AM Sam Hartman wrote:
> See  https://lists.debian.org/debian-vote/2015/09/msg00016.html
> for the message to second if you choose to do that.
> Rationale copied below.
> 
> 
> As I discussed, in Andreas's resolution, I think that the strategic
> voting fix introduces more problems than it serves.  INstead, I propose
> that we don't fix that, but trust ourselves to propose ballot options
> that are statement-of-the-day-like ballot options not requiring a
> super-majority when doing so is wise.  I think that doing so is
> generally a good idea when you have a super-majority option and its
> opposite on the same ballot--when there is substantial contraversy about
> whether to move in the direction of the super-majority option or some
> other option on the same ballot.
> 
> I have chosen to retain the preference for the default option in the TC.
> If four members of the TC really cannot live with an option, we're
> better off with more discussion or taking it to a GR.
> 
> Even in the Init system discussion, which I think is the most
> controversial decision to come before the TC, several of the TC members
> who preferred options that did not win explained what changes would need
> to be made for them to consider options similar to the one that won to
> be acceptable (ranked above FD).
> As it happened, four TC members didn't think no decision was better than
> the decision we got: if four members had ranked the winning option below
> FD, the chair would not have had the opportunity to use his casting
> vote.
> 
> We also have some strong evidence from emails where some TC members
> explained their balloting decisions including what they ranked above FD
> that the tactical voting people were afraid of didn't happen.
> 
> We're actually quite good at deciding whether another round of painful
> discussion is worth the cost or not, and when people we've appointed to
> make these decision decide that it is, I'd rather not second guess them.


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

Re: draft alternative proposal: fix problem at the root

[Scott Kitterman]

On Tuesday, December 02, 2014 10:50:30 PM Michael Gilbert wrote:
 On Tue, Dec 2, 2014 at 6:42 PM, Daniel Kahn Gillmor wrote:
  On 12/02/2014 06:13 PM, Jakub Wilk wrote:
  This is an interesting proposal. But it's a big change, so I think it
  should be thoroughly discussed before I could second it.
  
  I agree some discussion would be useful, but seems like it's a lot
  simpler than all the other noodling with term-limits that has gone on
  thus far.  What kind of thorough discussion would you like to have?
  
  It seems like the proposal is simple:
   * Do away with the Technical Committee entirely.
  
  The main questions this raises are:
  
  How would we deal with conflicts that would currently be addressed by
  the TC?  Hopefully, the answers would be something like: collaboration
  and teamwork, negotiation, mediation, and GRs (in that order).
  
  Do we believe that those resolution mechanisms would be more or less
  likely to cause strife within the project (or outside the project) than
  would resolution by the current TC mechanism?
 
 Disbanding the TC would likely do more harm than good.  There would be
 no way to conclude a disagreement.
 
 I suggested this before:
 
 TC actions should be limited solely to disagreement mediation, and only
 when that doesn't involve a conflict of interest pertaining to one of the
 TC members,
 and only when all other attempts at reconciliation have tried and
 failed.
 
 I would like to see all of section 6.1 removed and replaced by
 something simple, limited, and to the point like that.

I hadn't brought it up yet, since I thought it was best dealt with non-
constitutionally, but now that we're on the topic ...

I think it would be better if ctte members did not bring disputes to the ctte 
and then vote on the resolution of that dispute.  Doing so significantly 
undermines the legitimacy of the ctte.  This could either be prohibited by a 
simple rule of the ctte among themselves or constitutionally.

Personally, I think a constitutional measure is overkill, but it would resolve 
one of the concerns that has me wondering about the value of the ctte as a 
going concern for the project.

Scott K


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/6086302.igJis5fxYo@kitterman-optiplex-9020m

Re: GR proposal, Call for Seconds - term limit for the tech-ctte

[Scott Kitterman]

On Monday, December 01, 2014 12:20:25 PM Stefano Zacchiroli wrote:
 [ Cross post -vote, -project ; M-F-T: to -vote.
 
   For more background information on the development of this proposal,
   see https://lists.debian.org/debian-vote/2014/11/msg00274.html ]
 
 I'm hereby formally submitting the GR proposal included below between
 dashed double lines, and calling for seconds.  With respect to past
 discussions on the -vote mailing list, this is the proposal code-named
 2-S; see [1,2] for (the last known versions of) alternative proposals.
 
 [1]: https://people.debian.org/~zack/gr-ctte-term-limit/
 [2]: http://git.upsilon.cc/?p=text/gr-ctte-term-limit.git;a=tree
 
 ===
 The Constitution is amended as follows:
 
 ---
 --- constitution.txt.orig 2014-11-17 18:02:53.314945907 +0100
 +++ constitution.2-S.txt  2014-11-21 16:56:47.328071287 +0100
 @@ -299,8 +299,20 @@
 Project Leader may appoint new member(s) until the number of
 members reaches 6, at intervals of at least one week per
 appointment.
 -5. If the Technical Committee and the Project Leader agree they may
 +5. A Developer is not eligible to be (re)appointed to the Technical
 +   Committee if they have been a member within the previous 12 months.
 +6. If the Technical Committee and the Project Leader agree they may
 remove or replace an existing member of the Technical Committee.
 +7. Term limit:
 + 1. On January 1st of each year the term of any Committee member
 +who has served more than 42 months (3.5 years) and who is one
 +of the two most senior members is set to expire on December
 +31st of that year.
 + 2. A member of the Technical Committee is said to be more senior
 +than another if they were appointed earlier, or were appointed
 +at the same time and have been a member of the Debian Project
 +longer. In the event that a member has been appointed more
 +than once, only the most recent appointment is relevant.
 
6.3. Procedure
 
 ---
 
 As a transitional measure, if this GR is passed after January 1st, 2015,
 then the provision of section §6.2.7.1 is taken to have occurred on January
 1st, 2015.
 ===
 
 I'd like to thank Anthony Towns for introducing the term limit idea
 several months ago [3] and for his help in polishing it through several
 rounds of feedback on the -vote mailing list.
 
 [3]: https://lists.debian.org/debian-project/2014/05/threads.html#00054
 
 Cheers.

We discussed, and I thought there was consensus around, the idea that due to 
the recent ctte churn, the transitional measure was no longer needed.

As an amendment, I propose the transitional measure be removed.

Scott K

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

Re: GR proposal, Call for Seconds - term limit for the tech-ctte

[Scott Kitterman]

On Monday, December 01, 2014 04:59:53 PM Colin Tuckley wrote:
 On 01/12/14 16:50, Scott Kitterman wrote:
  As an amendment, I propose the transitional measure be removed.
 
 Why not support the amendment from Lucas instead which has more or less
 the same effect?

It has the ~same effect right now, but behaves differently in the future.  When 
we vote, I think it would be a better choice if the transitional language 
weren't there.  I'd like to see all the options be as good as possible before 
the vote.

Scott K

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

Re: GR proposal, Call for Seconds - term limit for the tech-ctte

[Scott Kitterman]

On Monday, December 01, 2014 12:28:58 PM Hubert Chathi wrote:
 On Mon, 01 Dec 2014 11:50:27 -0500, Scott Kitterman deb...@kitterman.com 
said:
  -
  --
  
  As a transitional measure, if this GR is passed after January 1st,
  2015, then the provision of section §6.2.7.1 is taken to have
  occurred on January 1st, 2015.
  =
  ==
  
  I'd like to thank Anthony Towns for introducing the term limit idea
  several months ago [3] and for his help in polishing it through
  several rounds of feedback on the -vote mailing list.
  
  [3]:
  https://lists.debian.org/debian-project/2014/05/threads.html#00054
  
  Cheers.
  
  We discussed, and I thought there was consensus around, the idea that
  due to the recent ctte churn, the transitional measure was no longer
  needed.
 
 Due to that way things are worded, the transitional measure for this
 proposal would cause TC memberships to start expiring December 31,
 *2015* (i.e. next year), because the review period at the beginning of
 the year causes expiries to happen at the end of that year, as opposed
 to happening immediately.

I'm OK with that (i.e. not surprised).  I think we've had enough turnover for 
awhile without enforcing more.  The point of term limits is to get new blood 
onto the ctte.  We'll have plenty of that shortly.

Scott K

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

Re: GR proposal, Call for Seconds - term limit for the tech-ctte

[Scott Kitterman]

On Monday, December 01, 2014 09:12:47 PM Stefano Zacchiroli wrote:
 On Mon, Dec 01, 2014 at 11:50:27AM -0500, Scott Kitterman wrote:
  We discussed, and I thought there was consensus around, the idea that
  due to the recent ctte churn, the transitional measure was no longer
  needed.
 
 You recall correctly, but a simple removal of the transitional measure
 would have very different effects on the various proposals.  So what I
 did instead is to try to uniform the *effects* of the various proposals,
 so that the removal (or not) of transitional measures would result in
 the same net result --- as much as permitted by the intrinsic
 differences in the proposals, that is.
 
 I've done that between draft #2 and draft #3 (as usual, based on my own
 perception of consensus) and discussed the rationale behind my choices
 when announcing the last draft [1]. It would have been useful to hear
 about this back then.
 
 [1]: https://lists.debian.org/debian-vote/2014/11/msg00274.html
 
 But right now, I'm not sure to understand what your main concern is, and
 I'd appreciate if you could elaborate a bit more. With the current
 transitional measure, the proposal 2-S will de facto do nothing for a
 full year. The first expiries will kick in only on January 1st, 2016.
 That is the same that you would obtain with, say, proposal without any
 transitional measure.
 
 If you propose an amendment for 2-S (my proposal, the one that seems
 to have received enough seconds now) to remove the transitional measure,
 that will mean that the first expiries will happen on January 1st, 2017.
 That's 2 years before seeing any effect whatsoever for the GR. Yes,
 we've had some churn in the tech-ctte as of lately, but IMHO not that
 much to justify such a delay.
 
 Is that the goal you actually want to achieve?
 
 Cheers.

Yes.  The goal of the proposals is to turn over approximately two per year and 
we've just lost three, so I think that's reasonable.  It also puts an forced 
retirements well past the recent turmoil and the Jessie release.

When making something as fundamental as constitutional change, I think it's 
good to have it only affect things far enough in the future that people's 
emotions about today are less likely to be wrapped up in it.

After quite some period of  minimal turnover, we're already ahead of the game.

Scott K

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

Re: [DRAFT] Maximum term for tech ctte members

[Scott Kitterman]

On Thursday, November 20, 2014 12:33:28 PM Sam Hartman wrote:
  Lucas == Lucas Nussbaum lu...@debian.org writes:
 Lucas (Elaborating on the context a bit given the discussion spread
 Lucas over some time -- two options have been proposed: - expire
 Lucas the 2 most senior members - expire the 2-R most senior
 Lucas members, with R the number of resignations over the last 12
 Lucas months)
 
 Lucas What we want to encourage is, I think, a sane and healthy
 Lucas turnover in the TC. Ideally, this would happen automatically:
 Lucas members would just resign when they feel that bringing fresh
 Lucas manpower is profitable to the TC overall. However, there's a
 Lucas number of social reasons why this doesn't work so well.
 Lucas which might weaken the TC a bit too much.  With the '2-R'
 Lucas schema, I have an additional incentive to resign: if I
 Lucas resign, I 'save' someone else more senior than me from
 Lucas getting expired.  (And given I'm not so active anymore,
 Lucas instead of weakening the TC further, my resignation might
 Lucas even reinforce the TC).
 
 
 Lucas The '2-R' schema could even result in an internal TC
 Lucas discussion: OK, the Project wants us to change two
 Lucas members. Are there people that feel like resigning now? Or
 Lucas should we just fallback to the default of expiring the two
 Lucas most senior members?  I think that if this happened, it
 Lucas would be very healthy for the TC.
 
 I think such discussions would be good.
 
 I don't think this conflicts with what  I said about term limits earlier
 this morning.
 While I do think that 4-5 years is a good term length, I do think a lot
 of churn can be bad, and 2-r makes a lot of sense to me for the reason
 you give above.

[responding here because it's the end of the thread right now, not sure where 
better]

Given that we've just had significant turnover in th TC, might it not make 
sense to have the first term expirations set for a year or two from now?  That 
would keep this discussion well separated from any current turmoil and I think 
it's reasonably clear that we don't, at the moment, suffer from a lack of 
turnover in the TC (which AIUI is the motivation for this).

Scott K


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1451239.ITZlMzDDEA@kitterman-optiplex-9020m