Does anyone else have feedback on this? I'd like to push it forward. On Sun, Aug 26, 2018 at 7:10 AM Adam Johnson <m...@adamj.eu> wrote:
> Members who are known to the security team to be maintaining codebases >> > on unsupported versions of Django will also be asked to provide >> details of how they plan to migrate to a supported version, and to >> assess whether they still require full notifiations once that >> migration is complete. Members who do not show progress in migrating >> toward supported versions may be removed from the list if the security >> team judges such removal appropriate. > > > This is asymmetric as it's only about those entities the security team > knows about - new members would be incentivized to not disclose/lie. Why > not ask everyone to disclose on joining and at each renewal, and have a > more explicit policy, e.g. if they're on an unsupported version two years > in a row, with no migration progress, they get removed? > > (There are also a couple misspellings - notifiations and regaring) > > On Sun, 26 Aug 2018 at 12:37, James Bennett <ubernost...@gmail.com> wrote: > >> There's been some discussion recently amongst the Django security team >> regarding the way we handle advance notifications of security isues, >> and whether we ought to change that. But since the security team is a >> pretty small group, we'd like to take the discussion public and get >> broader input before any decisions are made. >> >> >> The current state of notifications >> ---------------------------------- >> >> When a release is being prepared that fixes a notifiable security >> issue in Django, we currently send out two types of notifications: >> >> 1. A public notification sent to the django-announce mailing >> list. This notification includes the expected date of the release, >> the affected release series of Django, the number of issues to be >> fixed, and a general statement of the severity of the issues. A >> recent example of such a notification can be found here: >> https://groups.google.com/forum/#!topic/django-announce/niifyGP58-c >> >> 2. A non-public notification, sent to members of the security >> pre-notification list. All the information from the public >> notification is present, but this non-public notification also >> includes a full description of the issues, and the patches which >> will be applied to each version of Django. >> >> Both of these notifications are sent approximately one week in advance >> of the security release, whenever possible (there have been >> exceptional cases where a security isuee was publicly disclosed by >> someone else and the normal one-week period was bypassed in order to >> get the fix out as quickly as possible). >> >> The rationale for the public notification is to give anyone who wants >> it a heads-up that Django is preparing a security release; this lets >> users of Django get ready to update their dependencies and deploy the >> upgrade on the day it's released. >> >> The rationale for the non-public notification, which includes much >> more detail, is that there are entities which need to have that level >> of information in advance. >> >> >> The rationale and history of the non-public notification list >> ------------------------------------------------------------- >> >> The original security pre-notification list consisted solely of >> third-party redistributors of Django (such as Linux distributions >> which provide a Django package as part of their system). Providing the >> full details and patches allowed them to have updated packages >> available on the date of the security release, to better protect users >> of Django who prefer to install from their operating system's package >> manager. >> >> Later, the potential eligible entities for full notification expanded. >> Our security policy currently states that we will provide full >> notification to: >> >> > On a case-by-case basis, other entities who, in the judgment of the >> > Django development team, need to be made aware of a pending security >> > issue. Typically, membership in this group will consist of some of >> > the largest and/or most likely to be severely impacted known users >> > or distributors of Django, and will require a demonstrated ability >> > to responsibly receive, keep confidential and act on these >> > notifications. >> >> The full policy can be read at https://www.djangoproject.com/security/ >> >> The primary motiviation here is recognizing that while security >> breaches are bad in general, not all breaches are equally bad; some >> entities, if breached due to a publicly-known security issue in >> Django, would have much larger impact, either in terms of the number >> of people affected or the way in which they are affected. For example, >> there are installations of Django which handle sensitive personal >> financial or health data, which could have much more severe effects on >> users if breached. >> >> The membership of the list which receives full notification (including >> issue details and patches) is not public. For sake of providing some >> reference point in discussions, fewer than 20 unique email addresses >> currently receive these notifications, and several of the addresses >> are alternate contact routes for the same entity. >> >> >> Issues with the current system >> ------------------------------ >> >> Nobody seems to be against providing the major operating-system >> vendors with full advance notification; that's a reasonably standard >> practice, and we intend to continue doing that. >> >> There has been recent debate -- and as so often happens, it was >> motivated by separate unrelated things which occurred at about the >> same time -- about whether and how to continue providing full >> notification to other entities, and what the responsibilities of those >> entities should be. >> >> Here are some of the major issues: >> >> * There are many entities using Django which would fit the above >> description of high impact if breached. Very few of them are on the >> list, however, and there is a worrying pattern where entities which >> apply for and receive membership on the notification list overlap >> significantly with entities that employ prominent members of the >> Django community (i.e., Django committers). While this mostly seems >> to be caused by those entities not being aware of the full >> notification list, it can create an unfortunate impression that it's >> possible to "pay to play", and receive information others do not >> receive simply by hiring a Django committer. At the same time, >> getting every entity which meets the above high-impact definition >> onto the list would make its membership so large that >> confidentiality of security issues would be at risk simply from the >> number of people with full advance knowledge. >> >> * Some entities on the list are using or have been known to use >> unsupported versions of Django; their use case for the full >> notification includes using the patches to backport relevant fixes >> into private forks of older versions of Django. There is a worry >> that this removes some of the incentive for such organizations to >> upgrade to more recent, supported versions of Django. >> >> * While we reserve the right to remove anyone from the full >> notification list at any time, with or without explanation, there is >> currently no mechanism in place for verifying that all members of >> the list still wish to be on the list or that they all still meet >> the requirements for inclusion. >> >> * There are currently no enforced requirements for confidentiality >> regarding an entity's membership on the list, which raises concerns >> that some entities might use their membership on the list as a form >> of advertising (i.e., "our platform knows about Django security >> issues in advance; our competitors don't!"). To date, we are not >> aware of any entity advertising this as a competitive advantage, but >> we are aware of at least one case of an entity on the list >> disclosing its membership to its customers. >> >> >> Options under consideration >> --------------------------- >> >> One potential solution would be to reduce the list to its original >> constituency: major third-party vendors who package and distribute >> Django. In addition to Django's own history, there is precedent in >> other open-source projects notifying only to third-party >> packagers. This would have the disadvantage of removing a channel >> through which we were able to better ensure the security of Django >> users, however, and a mass removal of everyone except the packagers >> could damage our relationship with some of the major users of Django >> who have historically been on the list. >> >> Other options are more narrowly targeted at resolving specific issues, >> and include: >> >> * Rewriting the policy to make more clear what types of non-packager >> entities will be considered for membership. To take one example: the >> growth of cloud platforms which rely on Django, and the difficulty >> in coordinating rollout of updates across a large cloud provider's >> infrastructure, could lead to explicit language identifying cloud >> providers as a type of entity which can apply for full >> notifications. >> >> * Adding a requirement that members of the full notification list >> periodically -- say, on an annual basis -- re-verify that they meet >> the criteria for inclusion. For members who use notifications to >> backport fixes into older verisons of Django, this could include a >> requirement to show progress in upgrading to a supported version. >> >> * Imposing a requirement of confidentiality on list members, >> preventing them from disclosing their membership or engaging in any >> type of advertising based on their membership. >> >> >> Proposed change to Django's security policy >> ------------------------------------------- >> >> We propose that the text of Django's security policy, beginning at >> "Who receives advance notification", be changed as follows. >> >> >> Who receives full advance notifications >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> The full list of people and organizations who receive full advance >> notification of security issues is not and will not be made public. >> >> We also aim to keep this list as small as effectively possible, in >> order to better manage the flow of confidential information prior to >> disclosure. As such, our notification list is not simply a list of >> users of Django, and merely being a user of Django, even a large user >> of Django, is not a sufficient reason to be placed on the full >> notification list. >> >> The following types of people and organizations may be eligible for >> receiving full notification: >> >> * Operating-system vendors, and other major repackagers/redistributors >> of Django. >> >> * Major providers of "cloud" computing services or >> software-as-a-service platforms which heavily rely on Django. >> >> * Entities using Django who have large user bases and use Django to >> manage information that poses significant risk to users if >> breached. Examples include but are not limited to personal >> financial, legal or health information about users. >> >> Other types of entities may, rarely, be added if Django's security >> team feels such additions are appropriate and serve the goal of >> protecting users. >> >> Applications for notification (see below) will be considered on a >> case-by-case basis, and approved at the sole discretion of Django's >> security team. Merely meeting one or more of the criteria listed above >> does not guarantee that an entity will be added, and in the event of >> the security team not reaching consensus strongly in favor of an >> application, the default position will be to deny that application. >> >> >> Responsibilities of notification recipients >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> If you or your organization are added to the full notification list, >> you have the following respnsibilities: >> >> * Preserve the confidentiality of forthcoming security releases until >> Django has publicly disclosed the relevant issue(s) and packaged the >> relevant new release(s). It is expected that, prior to the date of >> Django's disclosure, third parties, including clients or customers >> of yours, will receive no more information from you than they would >> receive from subscribing to the django-announce mailing list and >> reading the public pre-notification described above. >> >> * Preserve the confidentiality of the notification list >> itself. Disclosing your membership to third parties (including >> clients or customers of yours), disclosing knowledge of other >> members' identities to third parties, or in any way advertising on >> the basis of your membership, is strictly forbidden. >> >> Additionally, list members must renew their membership annually. This >> consists of: >> >> * For packagers of Django, demonstrating that you still are packaging >> and distributing Django, and that the contact information provided >> is current for the person or persons in your organization who >> produce packages of Django. >> >> * For other entities: re-verifying that you or your organization still >> meet the criteria under which your membership was granted, and that >> the contact information provided is current for the person or >> persons in your organization who produce packages of Django. >> >> Renewal will be performed via the same mechanism as the original >> application, by contacting ``secur...@djangoproject.com``, but with >> the subject line "Security notification renewal". The due date of your >> renewal will be communicated to you at the time you are added to the >> list; if you were already a member of the list at the time renewal was >> added as a requirement, you should have received an email notifying >> you of your renewal date. >> >> Members who are known to the security team to be maintaining codebases >> on unsupported versions of Django will also be asked to provide >> details of how they plan to migrate to a supported version, and to >> assess whether they still require full notifiations once that >> migration is complete. Members who do not show progress in migrating >> toward supported versions may be removed from the list if the security >> team judges such removal appropriate. >> >> The security team may from time to time send reminders to list members >> regaring their responsibilities, but is not required to, and lack of a >> reminder will not serve as a defense against violation of these >> policies; being familiar with and abiding by these policies is the >> responsibility of each list member. >> >> Finally, just as with the initial application, the decision to keep >> any entity on Django's full notification list is at the sole >> discretion of the security team, and the security team reserves the >> right to remove any member at any time, for any reason or no reason, >> with or without warning or explanation. >> >> >> Requesting notifications >> ~~~~~~~~~~~~~~~~~~~~~~~~ >> >> If you believe that you, or an organization you are authorized to >> represent, fall into one of the groups listed above, you can ask to be >> added to Django’s notification list by emailing >> secur...@djangoproject.com. Please use the subject line "Security >> notification request". >> >> Your request must include the following information: >> >> * Your full, real name and the name of the organization you represent, >> if applicable, as well as your role within that organization. >> >> * A detailed explanation of how you or your organization fit at least >> one set of criteria listed above. >> >> * A detailed explanation of why you are requesting security >> notifications. Again, please keep in mind that this is not simply a >> list for users of Django, and the overwhelming majority of users >> should subscribe to django-announce to receive advanced notice of >> when a security release will happen, without the details of the >> issues, rather than request detailed notifications. >> >> * The email address you would like to have added to our notification >> list. >> >> * An explanation of who will be receiving/reviewing mail sent to that >> address, as well as information regarding any automated actions that >> will be taken (i.e., filing of a confidential issue in a bug >> tracker). >> >> * Once submitted, your request will be considered by the Django >> development team; you will receive a reply notifying you of the >> result of your request within 30 days. >> >> Please also remember that receiving full security notifications is a >> privilege granted at the sole discretion of the Django security team, >> and that, as stated above, this privilege can be revoked at any time, >> for any reason or no reason, with or without warning or explanation. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers (Contributions to Django itself)" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-developers+unsubscr...@googlegroups.com. >> To post to this group, send email to django-developers@googlegroups.com. >> Visit this group at https://groups.google.com/group/django-developers. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/CAL13Cg_qnDuRgdm2MO8%3D5JCNVb7eGtfvSLFMm7%3D6HZXhvkVJEw%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-developers/CAL13Cg_qnDuRgdm2MO8%3D5JCNVb7eGtfvSLFMm7%3D6HZXhvkVJEw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > > -- > Adam > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAMyDDM0LabBBgYYgTRcYPN_vo8v4vURTj3w75Uk0%2B4DwFqRLgg%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAMyDDM0LabBBgYYgTRcYPN_vo8v4vURTj3w75Uk0%2B4DwFqRLgg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAL13Cg93YNB3M1i0E-E7CwZt-Wyg8HiNrMGi6b%2BW3DJ8e2KKNQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
