Date: Fri, 30 Jun 2017 15:22:09 +0200 From: Solar Designer <solar@...nwall.com> To: oss-security@...ts.openwall.com Subject: Re: accepting new members to (linux-)distros lists On Wed, Jun 28, 2017 at 10:02:40PM +0200, Solar Designer wrote: > I came up with many current tasks/roles that a new or existing member > could usefully help with, thereby contributing to the team effort. > Currently the wiki page lists a total of 18 such items: 5 technical and > 13 administrative. I'd prefer that new membership requests include > specifics on what the new member will contribute - this can be work on > some of these 18 items or/and something else. This is now up to 22 items: I've split one in two, and added three more. The full list is at: http://oss-security.openwall.org/wiki/mailing-lists/distros#contributing-back No volunteers so far? I know some of you are actually helping with these, but I'd prefer that you explicitly take responsibility for them. We got to improve how we run these lists in order to counter-balance the possible negative effects of embargoes and of new members joining. The alternative, you know, is shutting the lists down. > Right now, most of these things I listed are everyone's and thus no > one's responsibility (and they often fall back on me as list admin). > I want this to change. Ideally, we'd list specific distros for each one > of these tasks/roles... and if something required is not done or goes > wrong per one of those roles, we'll ask them to explain why and correct > that for further occasions. This will also serve to verify that they're > still active and paying attention, replacing my responsiveness tests. > > Here are the current tasks/roles to choose from or/and add to: > > Technical (in arbitrary order): > 4. Generalize the reported issues to see if other closely related issues > exist (e.g., if a bug is reported against one implementation of X, see > if a similar bug exists in another implementation of X and inform the > list of either result) I split the above one in two: 4. Check if related issues exist in the same piece of software (e.g., same bug class common across the software, or other kinds of bugs exist in its problematic component), and inform the list either way 5. Check if related issues exist in implementations of similar functionality in other software (e.g., forked code including the same bug, or the same error made independently), and inform the list either way This is significant amount of work, and with so many distro members (as we already have) I'd be OK with different (sets of) distros volunteering for these two sub-tasks. > Administrative (roughly in chronological order, although many of these > activities overlap): > 4. Evaluate relevance to other parties, such as the upstream, other > affected distros (not present here), and other Open Source projects, see > if the report mentions notifying any of these, communicate your findings > and possible concerns to the reporter and the list, and stay on top of > the resulting discussion until a decision is made on who else to > possibly notify (or not) and any such notifications are in fact made The above item should have partially addressed Simon's feedback: yes, we do intend to notify upstreams (and have been doing so), but we need a decision and at least the reporter's approval for this first. I've now revised the wording to: 4. Evaluate relevance to other parties such as the upstream, other affected distros (not present on the (sub-)list), and other Open Source projects, see if the report mentions notifying any of these, communicate your findings and possible concerns to the reporter and the list, and stay on top of the resulting discussion until a decision is made on who else to possibly notify (or not) and any such notifications are in fact made (with the reporter's approval) The change from "not present here" to "not present on the (sub-)list" is to address the special case of someone sending to linux-distros an issue that would also be relevant to the distros list (which currently includes two *BSD's). If this happens, we'll need to notice, decide, get the reporter's approval, and finally move the discussion from linux-distros to distros. This certainly sounds overly complicated and formalized to me, but I hope we'll be doing it quickly in practice, like I think we have been already - but I also hope someone in particular will take responsibility for this happening. And I've also added explicit "with the reporter's approval", because in any such cases the ultimate say is the reporter's. Having considered the special case mentioned above made me realize we also have this task, newly inserted into the list: 5. Determine if the reported issues are Linux-specific, and if so help ensure that (further) private discussion goes on the linux-distros sub-list only (thus, not spamming and unnecessary disclosing to the non-Linux distros) We have been trying to do this already, but like with most of these tasks it was everyone's and no one's responsibility. This got to change. I also listed this new task, reusing number 13: 13. Keep track of per-report and per-issue handling and disclosure timelines (at least times of notification of the private list and of actual public disclosure), at regular intervals produce and share statistics (most notably, the average embargo duration) as well as the raw data (except on issues that are still under embargo) by posting to oss-security > 12. Help evaluate new (linux-)distros list membership requests per the > current criteria (participating in the corresponding oss-security > threads) > > 13. Vouch for people wanting to join in on behalf of a new distro member > as long as you are confident of their trustworthiness, expected proper > use of the list, and contributions The above are now the only two items on their own sub-list of "Administrative tasks not strictly requiring (linux-)distros list membership (thus, open for contributions by the wider community)". And there's another new sub-list, currently with just one item: Administrative tasks mostly unrelated to (linux-)distros lists (but relevant to the wider community) 1. Help ensure that each message posted to oss-security contains the most essential information (e.g., vulnerability detail and/or exploit) directly in the message itself (and in plain text) rather than only by reference to an external resource, and add the missing information (e.g., in your own words, by quoting with proper attribution, and/or by creating and attaching a properly attributed text/plain export of a previously referenced web page) and remind the original sender of this requirement (for further occasions) in a "reply" posting when necessary > Finally, I also came up with specific policy on handling of embargoed > information. Most of this was taken for granted so far, and this worked > well, but there were a few gray areas. The currently proposed policy, > which list members have to agree to, is as follows: > > Aside from your participation in discussions with the reporter and on > the (linux-)distros lists (including possibly continuing to CC other > prior recipients of the information), the information you receive > through the (linux-)distros lists must not be made public, shared, nor > even hinted at anywhere beyond the need-to-know within your distro's > team, until the agreed upon public disclosure date/time, the reporter's > explicit approval, or substantially complete publication by others. To hopefully address Simon's feedback, I moved "the reporter's explicit approval" to the beginning of list, so that it stands out. The current wording is: [...] except with the reporter's explicit approval, until the agreed upon public disclosure date/time or substantially complete publication by others. The beginning of this paragraph and further paragraphs are unchanged. Alexander
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.