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

[Sean Whitton]

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

[Scott Kitterman]

Post by Sean Whitton
=== 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.
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

[Russ Allbery]

Post by Scott Kitterman

Post by Sean Whitton
=== 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.
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.

[Scott Kitterman]

Post by Russ Allbery

Post by Scott Kitterman

Post by Sean Whitton
=== 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.
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

[Moritz Mühlenhoff]

Post by Scott Kitterman
Has anyone ever
seriously questioned the appropriateness of the Security Team's practices
based on the Social Contract?

Not in the last 11 years since I'm around. If that came up before, Martin or
Wichert should know.

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

Agreed.

Cheers,
Moritz

[Lars Wirzenius]

Post by Moritz Mühlenhoff

Has anyone ever seriously questioned the appropriateness of the
Security Team's practices based on the Social Contract?

Not in the last 11 years since I'm around. If that came up before, Martin or
Wichert should know.

Man, Debian is just the _worse_ at hiding problems. Security issues?
We hide them by announcing them on a dedicated mailing list.

Now, it's true that we track security issues in a different, and
it's private, which is in contradiction to what the social contract
says:

We will keep our entire bug report database open for public view
at all times. Reports that people file online will promptly become
visible to others.

I'm not opposed to amending the SC to say that security issues my be
kept private for a limited time, but I'm not sure it's worth it. I
especially would like to avoid anything that results in nitpicking
details, either during a GR or in the future, about what is a security
issue, what is a serious issue, and what is a limited time, and what
punishments we should have for exceeding a time limit.

In my opinion, we already follow the spirit of not hiding bugs. We do
publish security issues. If anything, the SC might be amended to not
specify details of how we achieve the not-hiding of bugs. For example,
we don't track security bugs on bugs.debian.org (which is clearly "our
bug database"), but in a separate tracker. Is that a violation of the
SC as well? (That's a rhetorical question, and we will now commence a
long discussion about it in 3, 2, 1...)

As a constitutional document, the social contract should stick to
project values, not how to implement those.

[Bas Wijnen]

Post by Lars Wirzenius
Now, it's true that we track security issues in a different, and
it's private, which is in contradiction to what the social contract

It's also a service to our users and free software, so not doing it is also in
conflict with the SC. Such conflicts are not unusual. AFAIK we solve them by
deciding which is more important in this situation and doing that.

I do not think the SC needs to contain details on how that decision should be
made for every case. As stated, this case seems to be a non-problem and I
would prefer to not solve it.

Thanks,
Bas

[Russ Allbery]

Post by Lars Wirzenius
I'm not opposed to amending the SC to say that security issues my be
kept private for a limited time, but I'm not sure it's worth it.

Yup, this is where I'm at too.

Post by Lars Wirzenius
I especially would like to avoid anything that results in nitpicking
details, either during a GR or in the future, about what is a security
issue, what is a serious issue, and what is a limited time, and what
punishments we should have for exceeding a time limit.

Indeed.

Post by Lars Wirzenius
In my opinion, we already follow the spirit of not hiding bugs. We do
publish security issues. If anything, the SC might be amended to not
specify details of how we achieve the not-hiding of bugs. For example,
we don't track security bugs on bugs.debian.org (which is clearly "our
bug database"), but in a separate tracker. Is that a violation of the
SC as well? (That's a rhetorical question, and we will now commence a
long discussion about it in 3, 2, 1...)
As a constitutional document, the social contract should stick to
project values, not how to implement those.

Yeah, I should have been clearer in my message: while I think that's a
reasonable policy if we want a policy, if we're going to change the
foundation document, I feel like we should just delegate this decision to
the DPL or their delegates (which in this case would be the security
team).

But it does seem like a non-problem in that this is the first time I
recall it even coming up.

[Martin Bagge / brother]

Post by Lars Wirzenius
I'm not opposed to amending the SC to say that security issues my
be kept private for a limited time, but I'm not sure it's worth
it.

This.
Hear hear.

Post by Lars Wirzenius
I especially would like to avoid anything that results in
nitpicking details, either during a GR or in the future, about what
is a security issue, what is a serious issue, and what is a limited
time, and what punishments we should have for exceeding a time
limit.

And I do not think it's possible to remove every little corner of
these things.

SC3 says that the issues should be public promptly and I think that
"promptly" can be different time periods from case to case.
I rather not change the SC now if that means that we avoid changing
other things in it in the future. It should not be seen as a document
that needs updates first and foremost.

Some kind of background to why Sean proposed the GR from the beginning
would be nice btw, haven't worked out that yet.

- --
brother
http://sis.bthstudent.se

[Bdale Garbee]

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

I agree.

Bdale

[Sean Whitton]

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.

Post by Scott Kitterman
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.

[Scott Kitterman]

Post by Sean Whitton
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.

Post by Scott Kitterman
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

[Sean Whitton]

Hello Scott,

Post by Scott Kitterman
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.

Post by Scott Kitterman
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.

[Scott Kitterman]

Post by Sean Whitton
Hello Scott,

Post by Scott Kitterman
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.

Post by Sean Whitton

Post by Scott Kitterman
Are you aware of any newcomers that have been negatively affected

this

Post by Scott Kitterman
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

[Sean Whitton]

Hello,

Post by Scott Kitterman
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?

[Scott Kitterman]

Post by Sean Whitton
Hello,

Post by Scott Kitterman
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.

[Philip Hands]

Post by Scott Kitterman

Post by Sean Whitton
Hello,

Post by Scott Kitterman
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.

Quite.

I'm yet to be convinced that there exists anyone that would be upset by
the fact that our security team might abide by embargoes in supposed
defiance of 'not hide problems'. I am also not convinced that if there
does exist such a person, and they are capable of becoming upset enough
about it to be driven away from Debian, that that would be a great loss.

Cheers, Phil.

[Tobias Frost]

Post by Lars Wirzenius

Post by Scott Kitterman

Post by Sean Whitton
Hello,

Post by Scott Kitterman
Currently we enumerate no specifics about exceptions to when

things

Post by Scott Kitterman

Post by Sean Whitton

Post by Scott Kitterman
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

Post by Scott Kitterman

Post by Sean Whitton

Post by Scott Kitterman
easy to infer that's the complete list.
Would this GR prohibit the tech ctte practice of private

deliberations

Post by Scott Kitterman

Post by Sean Whitton

Post by Scott Kitterman
about recommendations for new members? I think it might.
I've worked in private with other DDs to resolve disputes within

the

Post by Scott Kitterman

Post by Sean Whitton

Post by Scott Kitterman
project. Often a quiet conversation out of the public glare can

make

Post by Scott Kitterman

Post by Sean Whitton

Post by Scott Kitterman
solutions possible that wouldn't happen if all discussion was

public.

Post by Scott Kitterman

Post by Sean Whitton

Post by Scott Kitterman
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

Post by Scott Kitterman

Post by Sean Whitton
in the Debian project -- disputes between people, rather than

problems

Post by Scott Kitterman

Post by Sean Whitton
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

Post by Scott Kitterman

Post by Sean Whitton
hear if you disagree.
The header of clause 3 ("We will not hide problems") admittedly

could

Post by Scott Kitterman

Post by Sean Whitton
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

Post by Scott Kitterman
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.

Quite.
I'm yet to be convinced that there exists anyone that would be upset by
the fact that our security team might abide by embargoes in supposed
defiance of 'not hide problems'. I am also not convinced that if there
does exist such a person, and they are capable of becoming upset enough
about it to be driven away from Debian, that that would be a great loss.
Cheers, Phil.

Seems that topic has been previously discussed already: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=129604

(just came across that bug by purechange yesterday)

[Ian Jackson]

Post by Tobias Frost
Seems that topic has been previously discussed already: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=129604

Good grief.

If it really is necessary to to make the point via a GR that our
handling of security problems is right and proper, I think this should
be done with a "matters of the day" GR, not a change to the foundation
documents.

"The Project notes that [arguments in favour]

The Project approves of the current approach to handling security
problems, and thanks the Debian Security Team, and the Stable and LTS
teams, for their hard work"

Or something.

Ian.

[Sean Whitton]

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

Good point.

Post by Scott Kitterman
P.S. I am subscribed. Please don't cc me.

Whoops, sorry about that.

[Joerg Jaspert]

Post by Sean Whitton
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.

Is there really anyone like this? And dampened by how much, when
thinking about it?

Also, this is IMO nothing for a foundational document. But some docs
around it as explanation on how real world handles things.

Adding something like this opens a wormhole of "lets add this extra
condition here" "and hey, this little one there too" and gets the
document from a nice simple "thats it" to a murky "its this, but
sometimes that, and other times this" and end up with a hell where you
can avoid everything because the definition gets too mushy.

Right now its plain simple and one has to have a real good reason to go
around it, which is why its only embargoed security stuff, time limited,
that does.

[Sean Whitton]

Hello,

Post by Joerg Jaspert
Also, this is IMO nothing for a foundational document. But some docs
around it as explanation on how real world handles things.

Do we have such a doc right now? Possibly somewhere on the wiki I'm
unaware of?

[Ian Jackson]

Post by Scott Kitterman
What is the definition of serious and what is the definition of limited?

It is excellent that Sean's proposal for the SC leaves that vague.

Of course we may want to actually implement some more formal policy,
but I don't think we should write that down in the SC where it is hard
to change.

Ian.

[Gunnar Wolf]

Post by Sean Whitton
Title: State exception for security bugs in Social Contract clause 3
(...)

I have been following this thread, and although four days might not
seem like a long time, I feel that me comenting here is due.

In this thread, Martin Bagge asked for some background to why Sean
proposed this. I recently processed Sean for the New Member process. I
must say, it is amazing that somebody with Sean's record of activity
had not yet become a full DD! Anyway, while going through the
interview with Sean, I did prompt him to submit this GR. I'm quoting
from the NM process here only with Sean's implicit approval, as it was

Post by Sean Whitton

I would also append a remark about security bugs to clause 3 of
the Social Contract. Sometimes known security bugs are kept
confidential until the security team can co-ordinate a release
with other vendors. It could be argued that this is an
exception to clause 3 of the Social Contract, so it would be
good to explain it there.

Right, fair and good point. Worth thinking about and maybe
submitting a clear, simple GR to patch the issue, I think.

Cool, I've made a note to look into this in the future.

And we should look into this and properly consider it, taking it
beyond just the archiving of a NM application.

Of course, I take it as my fault (maybe because I recognized Sean as
quite active already in the project, overestimating his grip of our
common practices and general views) that I didn't give enough
background on similar experiences we had in the past (i.e. the long
flamefest¹ that followed "Editorial amendments"² and that quite
clearly delayed Sarge for over a year), which in turn explain why our
community views GRs as something that should be very sparingly used.

¹ https://lists.debian.org/debian-devel/2004/04/thrd5.html#01929
https://lists.debian.org/debian-devel/2004/04/thrd5.html#01996
² https://www.debian.org/vote/2004/vote_003

I recognize a GR is quite a bit of a burden, mainly to our dear
project secretary. It also introduces a topic we should think and
write about for quite a long timeframe. In private conversation,
though, I told Sean I would like this to change — GRs should not be
seen as something to always avoid if possible. At some point I
remember seeing a pseudo-GR (that is, without official status,
conducted by an individual other than the Project Secretary; I don't
rememeber when this was, but that's not so relevant) for measuring the
developers' shared opinion on a given subject.

As you know, I am for fixing our defining documents when there is an
impedance with truth; that's why I helped draft and supported Nicolas'
GR¹ on declassifying debian-private and later resubmitted it². And,
yes, that's why I offered Sean to second his GR.

¹ https://www.debian.org/vote/2016/vote_002
² https://www.debian.org/vote/2016/vote_004

Now, the arguments that have been given so far regarding this topic
are strong, and I do think I should have thought better my answers as
an AM. I did feel a moral obligation to answer to this thread. I
understand Sean must be frustrated by the lack of empathy to his drive
for correcting reality impedance; maybe it should not be via an
amendment to a foundation document, but by prominently enough
(somebody please define "enough") clearly documenting that we adhere
to reasonable embargo disclosure guidelines, such as the one mentioned
by Russ.

[Sean Whitton]

Hello,

Post by Gunnar Wolf
Of course, I take it as my fault (maybe because I recognized Sean as
quite active already in the project, overestimating his grip of our
common practices and general views) that I didn't give enough
background on similar experiences we had in the past (i.e. the long
flamefest¹ that followed "Editorial amendments"² and that quite
clearly delayed Sarge for over a year), which in turn explain why our
community views GRs as something that should be very sparingly used.

For the record, I do not take Gunnar to be at any fault here. However,
it is true that had Gunnar not expected my GR to be uncontroversial, I
probably wouldn't have proposed it.

While I stand by my GR in principle, I agree with those who have said
that it is not worth spending time on something like this unless it's
going to pass without opposition. Since this GR /has/ turned out to be
quite controversial, I hereby withdraw it.

Post by Gunnar Wolf
Now, the arguments that have been given so far regarding this topic
are strong, and I do think I should have thought better my answers as
an AM. I did feel a moral obligation to answer to this thread. I
understand Sean must be frustrated by the lack of empathy to his drive
for correcting reality impedance; maybe it should not be via an
amendment to a foundation document, but by prominently enough
(somebody please define "enough") clearly documenting that we adhere
to reasonable embargo disclosure guidelines, such as the one mentioned
by Russ.

I just created this: https://wiki.debian.org/SocialContractFAQ

My understanding of the policy that Russ linked to was that the security
team are de facto bound to that policy because all the other distros are
following it. Is that right? If so, it could be added to the new FAQ.

After some polishing, maybe the WWW team could add a link to the new FAQ
from the Social Contract itself. That would adequately respond to the
reasons I had for proposing this GR: a newcomer who was particularly
concerned about transparency would soon find their way to this page.

[Russ Allbery]

Post by Sean Whitton
For the record, I do not take Gunnar to be at any fault here. However,
it is true that had Gunnar not expected my GR to be uncontroversial, I
probably wouldn't have proposed it.
While I stand by my GR in principle, I agree with those who have said
that it is not worth spending time on something like this unless it's
going to pass without opposition. Since this GR /has/ turned out to be
quite controversial, I hereby withdraw it.

To say very explicitly, particularly since you just became a DD
(congratulations and welcome!), there was absolutely nothing wrong with
you proposing this here! It turned out to not be something that people
generally got behind, but that happens, and this is totally the sort of
thing we should be able to talk about as a project and understand.

And even without amending the foundation documents, if anyone ever *is*
bothered by this statement, we now have a recent thread that we can point
them at that says quite a lot about how the project thinks about this
issue.

[Ian Campbell]

Post by Sean Whitton
My understanding of the policy that Russ linked to was that the security
team are de facto bound to that policy because all the other distros are
following it.  Is that right?  If so, it could be added to the new FAQ.

You should read up on Coordinated (or Responsible) Disclosure vs. Full
Disclosure (not an uncontroversial topic in itself), the choice of
which one is used for a given bug is usually the choice of the
person/organisation who _discovers_ the issue.

In cases where the discoverer favours Coordinated Disclosure either
Debian agrees to abide by the embargos which the discoverers wish to
use or we simply do not get told about issues until the embargo has
expired.

Most distros, including Debian, agree to abide by such embargos because
it is in our interests and our users' interests to do so.

So Debian abides by discoverers wishes for the same reasons as the
other distros do, I don't think it is quite accurate to say Debian does
so because other distros do.

The important thing (I think) is that the choice of disclosure process
is down to the discoverer and not to the distros. Distros which do not
abide by the discovers wishes risk simply being left out of the
disclosure process for future vulnerabilities.

Ian.

[Emilio Pozuelo Monfort]

Post by Sean Whitton
Hello,

Post by Gunnar Wolf
Of course, I take it as my fault (maybe because I recognized Sean as
quite active already in the project, overestimating his grip of our
common practices and general views) that I didn't give enough
background on similar experiences we had in the past (i.e. the long
flamefest¹ that followed "Editorial amendments"² and that quite
clearly delayed Sarge for over a year), which in turn explain why our
community views GRs as something that should be very sparingly used.

For the record, I do not take Gunnar to be at any fault here. However,
it is true that had Gunnar not expected my GR to be uncontroversial, I
probably wouldn't have proposed it.
While I stand by my GR in principle, I agree with those who have said
that it is not worth spending time on something like this unless it's
going to pass without opposition. Since this GR /has/ turned out to be
quite controversial, I hereby withdraw it.

Post by Gunnar Wolf
Now, the arguments that have been given so far regarding this topic
are strong, and I do think I should have thought better my answers as
an AM. I did feel a moral obligation to answer to this thread. I
understand Sean must be frustrated by the lack of empathy to his drive
for correcting reality impedance; maybe it should not be via an
amendment to a foundation document, but by prominently enough
(somebody please define "enough") clearly documenting that we adhere
to reasonable embargo disclosure guidelines, such as the one mentioned
by Russ.

I just created this: https://wiki.debian.org/SocialContractFAQ
My understanding of the policy that Russ linked to was that the security
team are de facto bound to that policy because all the other distros are
following it. Is that right? If so, it could be added to the new FAQ.
After some polishing, maybe the WWW team could add a link to the new FAQ
from the Social Contract itself. That would adequately respond to the
reasons I had for proposing this GR: a newcomer who was particularly
concerned about transparency would soon find their way to this page.

Maybe there should be a note about how we handle embargoed vulnerabilities here:

https://www.debian.org/security/faq

Cheers,
Emilio

[Ben Finney]

Post by Sean Whitton
While I stand by my GR in principle, I agree with those who have said
that it is not worth spending time on something like this unless it's
going to pass without opposition. Since this GR /has/ turned out to be
quite controversial, I hereby withdraw it.

I support your interest in bringing the topic for discussion; I agree
that the unfortunate inference you described can be reasonably read in
the text of SC §3.

While I agree with your decision to withdraw the GR, for reasons others
have expressed well, the discussion was short and useful. We need not
only GRs that pass without opposition; we can learn from even
controversial GR proposals, though as you point out they might quickly
become damaging, also.

So, thank you for starting this, and for finishing it gracefully.

Also: welcome to the project!

[Martin Bagge / brother]

Post by Ben Finney

Post by Sean Whitton
While I stand by my GR in principle, I agree with those who have
said that it is not worth spending time on something like this
unless it's going to pass without opposition. Since this GR /has/
turned out to be quite controversial, I hereby withdraw it.

I support your interest in bringing the topic for discussion; I
agree that the unfortunate inference you described can be
reasonably read in the text of SC §3.

This pretty much sums it up for me. I would like to extend a specific
thanks to Gunnar for the verbose background story.

Post by Ben Finney
So, thank you for starting this, and for finishing it gracefully.
Also: welcome to the project!

Indeed!

- --
brother
http://sis.bthstudent.se

[Sean Whitton]

Thank you to Russ and Ben for the encouragement!

Post by Ian Campbell
You should read up on Coordinated (or Responsible) Disclosure vs. Full
Disclosure (not an uncontroversial topic in itself), the choice of
which one is used for a given bug is usually the choice of the
person/organisation who _discovers_ the issue.
[...]
https://www.debian.org/security/faq

Thanks for reminding me about that existing FAQs page. I think that
Ian's e-mail, suitably edited, would be a great addition if both Ian and
the security team agreed. It could then be linked to from my new
SocialContractFAQ page on the wiki.