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:
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 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
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
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.