Re: follow-up to report 22

[Graham Percival]

On Fri, Nov 05, 2010 at 10:03:02AM +0100, David Kastrup wrote:
> What leaves sort of a bad aftertaste here, I think, is that there is a
> semi-official "inner circle"

Please read my email from two months ago
http://www.mail-archive.com/address@hidden/msg30917.html
and tell me what is "semi-official" about it?

> This sort of institutional "people to be trusted" circle rather than an
> ad-hoc "people I want to discuss this with in private" selection made on
> the spot for the problem at hand (particularly social problems) appears,
> hm, too convenient?

I'm not certain if you've had a chance to the comments on the
lilypond report forum -- right now the web server isn't
responding.  Thankfully, I wrote everything in vi before posting
it there, so I shall reproduce the relevant parts.

["you" here refers to Valentin, not David]
------ from my comment 1
the famous book "Producing Open Source Software" by Karl
Fogel explicitly recommends having a private list:

"But here is one of the rare instances where secrecy is
appropriate. You can't have votes about potential committers
posted to a public mailing list, because the candidate's feelings
(and reputation) could be hurt. Instead, the usual way is that an
existing committer posts to a private mailing list consisting only
of the other committers, proposing that someone be granted commit
access. The other committers speak their minds freely, knowing the
discussion is private."
http://producingoss.com/en/consensus-democracy.html#electorate

------ from my comment 2
Now, you are asking "should an OSS project have any kind of
private mailing list?"  Well, if you really think we need to
discuss this now, instead of working on 2.14... and since you
obviously don't trust my judgement when I recommend that we
_don't_ delay the release for this... then fine, let's talk about
it.  I will outline two imaginary scenarios.

1)  In a few months from now, I decide that James Lowe (a
documentation editor for the past 12 months) should have git push
access.  So I send an email to the public, archived lilypond-devel
mailing list, asking if other people agree.  However, Carl looks
through the git history, and notices that I've made corrections to
his patches about 40% of the time, so he replies to the public,
archived mailing list to say that he disagrees with giving James
push access.  I argue against him, but in the end I have to admit
that there is a non-trivial chance that James could push a commit
which breaks compilation.  I therefore tell James in our public,
archived lilypond-devel list that he is not qualified for git push
access yet.  James is disappointed, and reduces his volunteer
effort.  [again, this is a IMAGINARY scenario]

2)  It turns out that we have a serious [IMAGINARY] security hole
in LilyPond!  One of our scripts actually ships with "/usr/bin/env
python", which means that there's a local root exploit.  We start
discussing this on our public, archived lilypond-devel mailing
list, and start working on a patch.  Unfortunately, Monseiur Chat
Noir, an evil music composition student, notices the discussion.
Ecole Paris-Nord has recent switched from Finale to using LilyPond
for its music composition classes... but Monsieur Chat Noir is now
able to access any computer in the school as the root user.  He
installs keyloggers on all computers, collects passwords, changes
grades, and does Evil Stuff.  When the school realizes that their
use of LilyPond resulted in getting hacked, they immediately ban
all open-source software and switch back to Finale.

I do not believe that either scenario is particularly attractive,
and they could both be avoided with private discussion between
developers.  The first secenario is the most commonly-cited
example in favor of private discussion amongst developers,
including in Fogel's "Producing Open Source Software".  Do you
have an alternate suggestion for how to handle this case?  The
second scenario brings up the "responsible disclosure" debate.
Some people disagree, but most computer security experts believe
that it is better to give a software project some amount of time
(10 days?  30 days?) to prepare a fix for a security flaw, instead
of going public immediately.

------ from my comment 3
Before discussing anything specific, I want to settle the abstract
question "should an OSS project have any kind of private mailing
list?".  You have two options:

1) Give an argument why they should not.  In particular, explain
why Kurt Fogel is wrong.  Explain how we should discuss giving
people git access in a public, archived forum.  Explain how we can
safely discuss unpatched security flaws in public.

2) Agree that an OSS project can, in theory, have a private
mailing list.
-----


- Graham Percival