[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Sean Whitton dijo [Mon, Jan 09, 2017 at 07:08:19PM -0700]:
> 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
agreed to begin with that NM interviews are part of a public process:

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

Attachment: signature.asc
Description: Digital signature

Reply to: