Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 3 Jul 2017 20:18:57 +0200
From: Solar Designer <>
Subject: Re: accepting new members to (linux-)distros lists

On Mon, Jul 03, 2017 at 02:51:27PM +0100, John Haxby wrote:
> What I would say though is that embargoed issues that go on a bug
> tracker should be not be visible to anyone that doesn't have an actual
> need to know.  If an internal bug tracker is generally open to anyone
> internal then for the purposes of embargo it might as well be public.

I think "might as well be public" is an exaggeration, but this would in
fact be against distros list policy.

> It _should_ be self-evident that "need to know" includes making sure
> entries in internal bug trackers need to be similarly restricted but I
> do wonder if it's worth calling that out explicitly?

You're right.  I'm not sure.  This isn't the only thing we could call
out explicitly.  If we start listing examples of what's allowed and
what's not, then another one or two would be about testing/QA of fixes,
which Gentoo's internal "Pre-Release Disclosure of Vulnerability
Information" policy mentions explicitly:

I added a link to it to the distros list wiki page yesterday, referring
to it as an example.

If we include such examples directly in the list policy specification,
it'd become lengthy and redundant, and I don't want it to be.  Maybe
this should be a set of examples clarifying yet separate from the list
policy specification.

> PS For contributing back I have given myself a "must try harder" mark.

Thanks.  Please let us know at which specific tasks you'll try harder.


Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ