Date: Mon, 3 Jul 2017 20:18:57 +0200 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com 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: https://wiki.gentoo.org/wiki/Project:Security/Pre-Release-Disclosure 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. Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ