#20868 closed Cleanup/optimization (fixed)
Security policy mentions nothing about sending emails to django-announce
Reported by: | Jim Garrison | Owned by: | nobody |
---|---|---|---|
Component: | Documentation | Version: | 1.5 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
This morning I happened to notice that Jacob posted a security announcement to the Django development blog, and I was surprised I had not received an email about it (like most other such announcements before it). I re-read the documentation on Django's security policies:
On the day of disclosure, we will take the following steps:
- Apply the relevant patch(es) to Django’s codebase. The commit messages for these patches will indicate that they are for security issues, but will not describe the issue in any detail; instead, they will warn of upcoming disclosure.
- Issue the relevant release(s), by placing new packages on the Python Package Index and on the Django website, and tagging the new release(s) in Django’s git repository.
- Post a public entry on the official Django development blog, describing the issue and its resolution in detail, pointing to the relevant patches and new releases, and crediting the reporter of the issue (if the reporter wishes to be publicly identified).
To my surprise, I realized that emails to django-announce are only incidentally triggered if the security issue happens to result in a new release of Django. But yet I had come to rely on such emails, assuming it was the preferred avenue for learning of Django security announcements. Despite having read the security policy document several times in my life, I never noticed this fine detail in it.
I think there are two potential solutions here:
- Add a note to the above list, saying all security issues will be sent to django-announce as well; or,
- Add a note above explicitly mentioning that only security issues that trigger a new release will be reported on django-announce
I of course prefer the first option, as it keeps in line with expectations people (including myself) may have developed.
Change History (6)
comment:1 by , 11 years ago
Triage Stage: | Unreviewed → Accepted |
---|---|
Type: | Uncategorized → Cleanup/optimization |
comment:2 by , 11 years ago
Jacob has just posted an announcement to django-announce; I'll leave this ticket open as a note that we should modify the text for our security policy to indicate django-announce is a channel that will be used.
comment:4 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Thanks for the suggestion, @garrison.
This particular announcement is a bit of an unusual case - to my knowledge, this is the first time we've made a security announcement that *hasn't* involved a new release of Django.
However, your point is a fair one -- we maintain django-announce as a low traffic mailing list specifically so that important messages get out there, and this is definitely an important message. I'll raise this with Jacob.