Adjusting Django's security notification policy

[James Bennett]

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 ``secu...@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

secu...@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.

[Adam Johnson]

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)

--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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.
For more options, visit https://groups.google.com/d/optout.

--

Adam

[James Bennett]

Does anyone else have feedback on this? I'd like to push it forward.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM0LabBBgYYgTRcYPN_vo8v4vURTj3w75Uk0%2B4DwFqRLgg%40mail.gmail.com.

[Carlton Gibson]

On Sunday, 30 September 2018 06:51:41 UTC+2, James Bennett wrote:

Does anyone else have feedback on this? I'd like to push it forward.

I don't know if this would fly but, given that pre-notification is mainly thought of for large-scale ("enterprise"?) deployments that can't realistically "Just Update!", 

could we make Corporate Sponsorship of the DSF a requirement for pre-notification? (These are big companies, with payroll. A sponsorship is loose change in this context, and may at least encourage trying to update...) 

(Just a thought.) 

C.

[Markus Holtermann]

Can: yes. Should: no.

I would be really saddened to see companies being able to buy security by throwing money at us. That makes us look like we can be bought. And that sends the wrong signal, from my perspective. Timely security updates should be available to everyone.

Should enterprises sponsor the DSF, open source projects, or the open source community in general: yes, absolutely.

What we could think about is something where companies above a yearly revenue of US$ x need to sponsor in order to be on a pre-notification list. But the moment we do that we put people's data at risk. A company that doesn't want to pay for that sponsorship and thus won't get pre-notifications may remain on an insecure version longer that they should or would if they had received a pre-notification. And that's terrible as well.

My 2¢

Markus

> --
> 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-develop...@googlegroups.com.
> To post to this group, send email to django-d...@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/b3f4aa4c-9b00-41ac-8668-87ffa570f2d6%40googlegroups.com.

[James Bennett]

On Wed, Oct 3, 2018 at 2:18 AM Markus Holtermann <in...@markusholtermann.eu> wrote:

Can: yes. Should: no.

Yeah, the idea's been proposed a couple times, and my stance on it is that I'd quit not just the security team, but everything Django-related, if we did that. Pay-to-play for security is not acceptable, period.

[Carlton Gibson]

Yes. That all sounds reasonable.

We DO timely releases to all (and we pre-announce so people know they’re coming).

It’s just this extra category of people who get the patch separately, early. There’s extra overhead in that. And it removes one motivation to update.

I’m kind of inclined to advocate the RoR approach or no pre-notification, but I accept the argument that in big enterprises it’s just not realistic to require people to keep up to date. It just feels like $$$ outsourcing work they should be doing without actually covering the cost of that.

I don’t see it as pay-for-access: beyond getting pre-notification you get no privileges. More it’s due-diligence. Using end-of-life software is arguably negligent. Companies doing it just need to take on the extra costs.

However… those are just thoughts… the wind goes the other way. No problem!

Thanks both.