From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leo Famulari Subject: FW: [oss-security] accepting new members to (linux-)distros lists Date: Wed, 28 Jun 2017 17:36:09 -0400 Message-ID: <20170628213609.GA14802@jasmine.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:54136) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dQKds-0002Iy-BP for guix-devel@gnu.org; Wed, 28 Jun 2017 17:36:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dQKdp-0004SY-1A for guix-devel@gnu.org; Wed, 28 Jun 2017 17:36:56 -0400 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:36813) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dQKdo-0004Qp-BT for guix-devel@gnu.org; Wed, 28 Jun 2017 17:36:52 -0400 Received: from localhost (c-73-165-1-160.hsd1.pa.comcast.net [73.165.1.160]) by mail.messagingengine.com (Postfix) with ESMTPA id BDF607E7B1 for ; Wed, 28 Jun 2017 17:36:50 -0400 (EDT) Content-Disposition: inline List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: guix-devel@gnu.org --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable It was hinted at ~1 week ago in the public "Stack Clash" discussion on oss-security, but now there has been an announcement: the private linux-distros early-notice security discussion and coordination mailing list is accepting new members: http://seclists.org/oss-sec/2017/q2/638 The criteria are listed in the forwarded message below. I'd say we can meet them. Perhaps they'd say that Guix is too obscure, but I don't have any idea how many users we have. We'd need to have a good plan for #7, "Be able and willing to contribute back". I'm assuming we'd have somebody to vouch for us (#9). I've seen some members of Guix express doubts about the utility of private discussion forums like linux-distros, and I'm sympathetic. In fact, even without early notification, we are usually shipping security updates for embargoed issues within 24 hours of public disclosure, and usually within a few hours. And for non-embargoed issues, we are shipping fixes earlier than the major distros very often. I read the "security update round-ups" on LWN, and typically they are full of bugs we already fixed. So, perhaps it wouldn't make a big difference in most cases. But, the "Stack Clash" issues took us by surprise and we spent a few days writing and testing our fixes. We are committed to supporting 32-bit platforms where these bugs are apparently easy to exploit. Without access to the exploits or detailed discussion, it was very difficult to know if our fixes actually worked. So, we could have responded more quickly and effectively with early notice. What do people think? Is anyone else interested in applying to join this mailing list? Is anyone else willing to stick to the rules and to participate? Leo ----- Forwarded message from Solar Designer ----- Date: Wed, 28 Jun 2017 22:02:40 +0200 =46rom: Solar Designer To: oss-security@lists.openwall.com Subject: [oss-security] accepting new members to (linux-)distros lists User-Agent: Mutt/1.4.2.3i Hi, I have finally specified the criteria for accepting new members to the (linux-)distros lists. I intend to process the requests, which are to be posted to new threads each (one thread per distro wanting to join). I put quite some thought (and experience so far) into these criteria, but I welcome any comments and suggested changes this community might have. The list of criteria will be maintained on the wiki: http://oss-security.openwall.org/wiki/mailing-lists/distros#membership-crit= eria Currently, to be eligible for (linux-)distros list membership, your distro should: 1. Be an actively maintained Unix-like operating system distro with substantial use of Open Source components 2. Have a userbase not limited to your own organization 3. Have a publicly verifiable track record, dating back at least 1 year and continuing to present day, of fixing security issues (including some that had been handled on (linux-)distros, meaning that membership would have been relevant to you) and releasing the fixes within 10 days (and preferably much less than that) of the issues being made public (if it takes you ages to fix an issue, your users wouldn't substantially benefit from the additional time, often around 7 days and sometimes up to 14 days, that list membership could give you) 4. Not be (only) downstream or a rebuild of another distro (or else we need convincing additional justification of how the list membership would enable you to release fixes sooner, presumably not relying on the upstream distro having released their fixes first?) 5. Be a participant and preferably an active contributor in relevant public communities (most notably, if you're not watching for issues being made public on oss-security, which are a superset of those that had been handled on (linux-)distros, then there's no valid reason for you to be on (linux-)distros) 6. Accept the list policy: http://oss-security.openwall.org/wiki/mailing-lists/distros#list-policy-and= -instructions-for-members (also quoted below) 7. Be able and willing to contribute back, preferably in specific ways announced in advance (so that you're responsible for a specific area and so that we know what to expect from which member), and demonstrate actual contributions once you've been a member for a while: http://oss-security.openwall.org/wiki/mailing-lists/distros#contributing-ba= ck (also quoted below) 8. Be able and willing to handle PGP-encrypted e-mail 9. Have someone already on the private list, or at least someone else who has been active on oss-security for years but is not affiliated with your distro nor your organization, vouch for at least one of the people requesting membership on behalf of your distro (then that one vouched-for person will be able to vouch for others on your team, in case you'd like multiple people subscribed) Membership requests should provide answers per each of these criteria. 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. 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): 1. Propose (other) ways to fix, work around, or mitigate the reported issues 2. Develop and share fixes, workarounds, or mitigations 3. Review and/or test the proposed patches and point out potential issues with them (such as incomplete fixes for the originally reported issues, additional issues you might notice, and newly introduced bugs) 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) 5. Produce and share well-reasoned estimates for the time required to handle the issues under embargo (such as to (re)negotiate the public disclosure date and/or to choose between the different ways to handle an issue) Administrative (roughly in chronological order, although many of these activities overlap): 1. Promptly review new issue reports for meeting the list's requirements and confirm receipt of the report and, when necessary, inform the reporter of any issues with their report (e.g., obviously not actionable by the distros) and request and/or propose any required yet missing information (most notably, a tentative public disclosure date) 2. See if the proposed public disclosure date is within list policy, and if not then insist on getting this corrected and propose a suitable earlier date 3. Evaluate if the issue (or one of the issues) is effectively already public (e.g., a fix is committed upstream with a descriptive message) or/and is low severity and thus the report (or its portion pertaining to the issue) should be made public right away for one or both of these reasons, get a few other list members to confirm this understanding, and if there are no objections then communicate this strong preference to the reporter 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 5. If multiple issues are reported at once, see if any of them can reasonably be made public sooner than the rest, and if so help untangle them and stay on top of their disclosure process 6. If CVE IDs are requested, the report is valid, and you're a CNA, assign those (requesting any required information from the reporter first) 7. If the report does not mention CVE IDs (neither requests nor provides them, and doesn't mention the reporter having requested them elsewhere), yet the report is valid and it looks like distros will need CVE IDs, and you're a CNA, ask the reporter whether they have already requested CVE IDs elsewhere, then assign those if they haven't been requested elsewhere 8. Stay on top of issues to ensure progress is being made, remind others when there's no apparent progress, as well as when the public disclosure date for an issue is approaching and when it's finally reached (unless the reporter beats you to it by making their mandatory posting to oss-security first) 9. Monitor relevant public channels (mailing lists, code repositories, etc.) and inform the reporter and the list in case an issue is made public prematurely (that is, leaks or is independently rediscovered) 10. Make sure the mandatory oss-security posting is made promptly and is sufficiently detailed, and remind the reporter if not 11. If exploit(s) were shared on the list, make sure that either they're included in the oss-security posting along with the issue detail or the posting includes an announcement of planned later posting of the exploits (with the delay being within list policy), and in the latter case also make sure that the later posting is in fact made as planned, and remind the reporter if not 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 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. Neither you nor others you inform may use the information for anything other than getting the issue fixed for your distro's users and, only in rare extreme cases, for deployment of maximally non-revealing changes to maintain security of your distro's infrastructure most essential to the distro users' security in face of the security issue being dealt with. The need-to-know condition is met only if the person needs to participate in one of these two activities. Before you share the information with others within your distro's team based on their need-to-know, you need to get these people to agree to these same terms, optionally (and preferably) with the additional limitation that they may not share the information further (not even with others on the team, not even based on need-to-know) without explicit approval by you or another individual directly subscribed to the (linux-)distros list for your distro. In the unfortunate event that you happen to share or/and use the information beyond what's allowed by this policy (thus, creating a leak), you must urgently (right after you became aware of the leak) inform the reporter and the (linux-)distros (sub-)list you had received the information from of the leak and of its extent (if readily known). You must also conduct an internal investigation of the leak, and inform the reporter and the list of the exact extent of the leak (to the best of your knowledge) and of measures (intended to be) taken to prevent such leaks going forward. The above is the main policy definition, but in case you prefer the Traffic Light Protocol, in its terms this is TLP:AMBER with the need-to-know condition as specified above and with the following additional limitation on sharing: you must not share the information with anyone outside of your distro's team, including not within the rest of your organization nor with your clients or customers, including not in any derived form (not even through delivering or deploying undocumented fixes). Once the embargo is over, this is TLP:WHITE. I am sorry for the long message. I quote these pieces from the wiki in here to allow for quoting in a possible discussion thread - such as for distros (both those already on the private lists and not) to volunteer for specific roles (please do!) Alexander ----- End forwarded message ----- --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAllUIUUACgkQJkb6MLrK fwhbIhAAv6a6eIPSJxVyBJFHJxWPI6OKp9e8M0PQC/f6C44A9PpKqOZ0obvXmVm4 pjVTBlFHyyUCUzQhRILLBiTY1ClixMdbEzFOY95+gQjqWuK8TWHSs/0a40m0Ag25 dkeEq/3rjmGyKez4aYlHU/PZgsJP3RsP7LZR9K5BXAJhvKgyYlWvLj4XNnUv74ZW zajKJLOKuzP71ulbzF4Yd4ZxXLeHh+5vvTV+TtRacUTmfwzVu0xlUKmcaliK6tnA 1VYP6+e++ylZWIya3rHXNLVIXSz8Ipmk7Duw1duel9lX6LhW/0cnQTrUQ0ZDdVdo f/1mXntna9bq4cqAcrq8dPqCiNx7vdwf3CrEcBBBmo0O86+iXI2rEsBDOx/FGKIb g379IPxDh3h2ZuGySnB8RPtadJPkn9PW+ZcDDRnhTtDYeODZocIQUgtlXMAQSvkK gdcvvwsJM2kBb8JPd5PQdF8JzHkJgIhKT9HWMv4EI7PzqYSmGWuxx2n0IGZ1PPLX RtAN6zxjoLW/PstrANHYMDbvlb340waB2b2+3vehJqiS8h6JmRG3gKkOOf1cPAyi Z2MkipVD0z8jnzY4o88jxPBG/zxA7MtbKJhfsPjWoPQZy9SqZWB6jG6AKk4edvFm VAGENm48Sxg6TLUqzMZl9R5Bjo38j3+C4GXG/MDcAvQ2RvoWxGc= =3NvE -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM--