Some thoughts on our security policy as we head towards 1.0
James Bennett
world go, it's not bad. But it could be better, and I think that as we
get closer to Django 1.0 it's increasingly important for it to *be* better.
Currently the policy says that a security fix will "probably mean a
new release of Django, but in some cases it may simply be patches
against current releases."
So far under that policy, we've had one security fix issued which
affected the 0.95 release (the compile-messages bug), but no new
release of Django was issued. The patch against 0.95 which fixes it is
not in the Django 0.95 download package on djangoproject.com, and a
new user downloading 0.95 for the first time will probably never
realize that there was a bug or that a patch for it exists.
Even worse, there was another bug -- the LazyUser bug fixed in
revision 3754[2] which is obviously security-related, but was never
posted to django-announce. Even someone who's doing everything we
recommend, security-wise, will likely remain unaware of that one.
Worst of all, we're not and never will be the only people distributing
Django; Debian unstable has a Django 0.95 package, and Fedora Extras
(a set of repositories which is enabled by default on Fedora) has
Django 0.95 RPMs for Fedora Core 5 and Fedora Core 6. The Debian
package is a stock 0.95 and, hence, is missing both the
compile-messages fix and the LazyUser fix. I haven't yet found a way
to peek inside the Fedora RPM, but I strongly suspect that it's also a
stock 0.95.
(incidentally, I've already posted bug reports to Debian with pointers
to the appropriate patches; if/when I can open up and verify the
Fedora RPM I'll do the same for it)
So. How can we make this work better?
The first thing we need to do is have some clear way of obtaining
"current release plus security fixes". A few possible methods come to
mind:
1. When a security fix is released without a new Django release
accompanying it, update the current release tarball listed on the
download page. Upside: the official release tarball will always have
the latest security fixes applied. Downside: the release tarball
won't match the tagged release in Subversion, and won't be consistent
over time; this introduces a support headache of "OK, you're using
0.95, but did you download it before Security Fix X, or after?"
2. Automatically push out a minor release on any security fix, no
matter how trivial; under this scheme, the compile-messages fix would
have pushed out, say, 0.95.1 and the LazyUser fix would have pushed
out 0.95.2. Upside: keeps the latest release tarball updated without
losing sync with trunk (since the minor versions could be tagged in
Subversion). Downside: more administrative overhead to tag, package
and announce the releases.
3. Start and maintain a "0.95-bugfixes" branch which does nothing but
apply security fixes. Upside: it's consistent with what we already do
for 0.90 and 0.91, and we'll probably create this branch anyway when
0.96 lands (since we maintain security fixes for current + two
previous releases). Downside: doesn't update the release tarball, so
you have to go to Subversion for security fixes.
Personally, I think the best route is a combination of the second and
third options. Here's how it would work:
* Any time a major release lands, automatically create a "bugfixes"
branch for it; for example, part of the release process for 0.96 would
include the creation of a "0.96-bugfixes" branch in Subversion.
* Any time a security fix is issued, it gets applied to the relevant
"bugfixes" branch, then a new minor release packaged from it. So the
first security fix in 0.96 would be applied to 0.96-bugfixes, and
0.96.1 would immediately be packaged and released from that.
* The official tarball on the download page would always be the most
recent release, regardless of whether it's a major or minor release,
and would mention the full version number; so, for example, the
download page might say "the most recent stable version of Django is
0.96.3; download it here" (and we would link to the 0.96.3 tarball).
Related to this, I think it'd help if we err more on the side of
caution when deciding whether something is a "security fix" or not; if
there's a chance that it is, then it is and we should treat it as
such, regardless of whether it was reported as security issue or not
(this would, hopefully, prevent the non-announcement of things like
the LazyUser bug from happening in the future).
The second thing we need to do is coordinate better with people who
are packaging Django for distribution (e.g., Debian and Fedora). We
should probably have official documentation on how to package and
distribute Django, and that documentation should, at the very least,
mention these things:
1. People who are maintaining third-party distributions of Django
should (don't have to, but should) let us know who they are, so we can
do a better job of getting information to them about important fixes
(e.g., "pre-announcing" security fixes and such). We might also want
to create roles for them in Trac to make it easier for them to forward
bug reports "upstream" when their users find things that we need to
fix.
2. People who are maintaining third-party distributions should at
least follow django-announce, so they'll be notified of security fixes
and releases.
Down the road, it might also be useful to have some sort of designated
liasion from the dev team to third-party package maintainers, both so
they'd have someone they know they can contact on the Django team, and
so we'd have someone who knows and can get in touch with third-party
package maintainers.
And that's a lot to think about and discuss, so I'll stop there for
now, but if anybody's got other concerns/ideas about the security
policy, I think we should get them out in the open and discuss them;
this is already really important stuff that we could be doing better,
and is only going to get more important as we get closer to 1.0 :)
[1] http://www.djangoproject.com/documentation/contributing/#reporting-security-issues
[2] http://code.djangoproject.com/changeset/3754
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
Matias Hermarud Fjeld
> * Any time a security fix is issued, it gets applied to the relevant
> "bugfixes" branch, then a new minor release packaged from it. So the
> first security fix in 0.96 would be applied to 0.96-bugfixes, and
> 0.96.1 would immediately be packaged and released from that.
+1, A new minor version number is just the right thing for this.
--
Matias
Deryck Hodge
>
> 1. When a security fix is released without a new Django release
> accompanying it, update the current release tarball listed on the
> download page. Upside: the official release tarball will always have
> the latest security fixes applied. Downside: the release tarball
> won't match the tagged release in Subversion, and won't be consistent
> over time; this introduces a support headache of "OK, you're using
> 0.95, but did you download it before Security Fix X, or after?"
>
> 2. Automatically push out a minor release on any security fix, no
> matter how trivial; under this scheme, the compile-messages fix would
> have pushed out, say, 0.95.1 and the LazyUser fix would have pushed
> out 0.95.2. Upside: keeps the latest release tarball updated without
> losing sync with trunk (since the minor versions could be tagged in
> Subversion). Downside: more administrative overhead to tag, package
> and announce the releases.
>
> 3. Start and maintain a "0.95-bugfixes" branch which does nothing but
> apply security fixes. Upside: it's consistent with what we already do
> for 0.90 and 0.91, and we'll probably create this branch anyway when
> 0.96 lands (since we maintain security fixes for current + two
> previous releases). Downside: doesn't update the release tarball, so
> you have to go to Subversion for security fixes.
>
> Personally, I think the best route is a combination of the second and
> third options. Here's how it would work:
>
+1 on point 2. I think you must have a new point release with a
security fix, no matter how trivial the patch or how dangerous or not
one might feel like categorizing the flaw. I'm not sure you need the
overhead of a bugfixes branch with each release. You have the tag for
the release, and then presumably a tag of each bug fix release. Just
pull the tag, apply the patch, cut a new release, and tag again.
Would save some on branches and the growth of the repo.
Along these lines, it wouldn't hurt to nail down a release
numbering/lettering schema, just for consistency. With the impending
1.0 release, we could end up with 1.0 release candidates. So all
together questions arise, do we designate release candidates with -rc
or -RC, -alpha, -a or -b? Do we use points for security releases only
or other minor bug fixes? Do we ever roll a point release for
something other than security? (I could see this with 1.0 becoming
1.0.1, etc. but maybe not.) So do we need letters to differentiate
bug fixes from security releases -- 1.0.a or 1.0.1.a or 1.0.1a.
Practice seems varied across FS/OS projects, so I think just picking a
schema and sticking to it is all that's critical. Just something to
think about in terms of policy.
I think these questions are all the domain of a release manager and
one is a crucial need as 1.0 nears, which I think Jacob mentioned in
his how-to-prep-for-1.0 mail. Hmmmmm...... <sniff, sniff>. I think
James has the smell of a release manager. :-)
Cheers,
deryck
Deryck Hodge
> liasion from the dev team to third-party package maintainers, both so
> they'd have someone they know they can contact on the Django team, and
> so we'd have someone who knows and can get in touch with third-party
> package maintainers.
>
I think this is hard to maintain if the package maintainer doesn't
work him/herself to maintain the relationship. Other options for
handling security so that maintainers and others like them stay
informed:
1) Create a security page for listing all reported security problems
and the patches or releases that addressed the flaw. i.e.
djangoproject.com/security.
2) Work with someone from CVE to get a proper CVE number applied,
where they can also track information about the flaw and fixes.
3) Send security announcements to vender-sec to catch OS distributions
first, then followup to bugtraq, secunia, etc.
Cheers,
deryck
Deryck Hodge
> now, but if anybody's got other concerns/ideas about the security
> policy, I think we should get them out in the open and discuss them;
> this is already really important stuff that we could be doing better,
> and is only going to get more important as we get closer to 1.0 :)
>
Last one from me and then I'll be quiet.... (just wanted to hit each
idea in it's own mail) :-)
We might want to think about PGP signing each release, security or
otherwise, and providing the public key to verify the release is
authentic.
Cheers,
deryck
Michael Radziej
James Bennett wrote.
> 1. When a security fix is released without a new Django release
> accompanying it, update the current release tarball listed on the
> download page. Upside: the official release tarball will always have
> the latest security fixes applied. Downside: the release tarball
> won't match the tagged release in Subversion, and won't be consistent
> over time; this introduces a support headache of "OK, you're using
> 0.95, but did you download it before Security Fix X, or after?"
-1, this is a support nightmare, as you say yourself. And also for
sysadmins: "Hey, what has John installed here? Is this the version with
or without the security fix? Gosh, I better reinstall it since John is
on vacation in Norway ..."
> 2. Automatically push out a minor release on any security fix, no
> matter how trivial; under this scheme, the compile-messages fix would
> have pushed out, say, 0.95.1 and the LazyUser fix would have pushed
> out 0.95.2. Upside: keeps the latest release tarball updated without
> losing sync with trunk (since the minor versions could be tagged in
> Subversion). Downside: more administrative overhead to tag, package
> and announce the releases.
+1. Actually, every distribution that uses packaging will create a new
"miniscule release" if we don't. And, is there any major project that
does not put out a new release for a security fix?
> 3. Start and maintain a "0.95-bugfixes" branch which does nothing but
> apply security fixes. Upside: it's consistent with what we already do
> for 0.90 and 0.91, and we'll probably create this branch anyway when
> 0.96 lands (since we maintain security fixes for current + two
> previous releases). Downside: doesn't update the release tarball, so
> you have to go to Subversion for security fixes.
-1. This means that users of the release will use flawed code. You can't
expect people to search for *past* security announces. Wuha. I couldn't
bare the blogs saying "hey, django hands out releases with known
security bugs".
>
> Personally, I think the best route is a combination of the second and
> third options. Here's how it would work:
>
> * Any time a major release lands, automatically create a "bugfixes"
> branch for it; for example, part of the release process for 0.96 would
> include the creation of a "0.96-bugfixes" branch in Subversion.
> * Any time a security fix is issued, it gets applied to the relevant
> "bugfixes" branch, then a new minor release packaged from it. So the
> first security fix in 0.96 would be applied to 0.96-bugfixes, and
> 0.96.1 would immediately be packaged and released from that.
> * The official tarball on the download page would always be the most
> recent release, regardless of whether it's a major or minor release,
> and would mention the full version number; so, for example, the
> download page might say "the most recent stable version of Django is
> 0.96.3; download it here" (and we would link to the 0.96.3 tarball).
Hmmm, isn't that just a more explicit definition approach 2? If you find
it easier, create a bugfix branch with the major release, but this
doesn't matter much for the users. I'd say do it as it pleases the
committers.
> Related to this, I think it'd help if we err more on the side of
> caution when deciding whether something is a "security fix" or not; if
> there's a chance that it is, then it is and we should treat it as
> such, regardless of whether it was reported as security issue or not
> (this would, hopefully, prevent the non-announcement of things like
> the LazyUser bug from happening in the future).
Yes, please. The flup issue (disabling flup debug mode) comes to my mind
as such a case where I would have liked to get an announcement, even if
it's not sure whether there's really a leak.
> The second thing we need to do is coordinate better with people who
> are packaging Django for distribution (e.g., Debian and Fedora). We
> should probably have official documentation on how to package and
> distribute Django, and that documentation should, at the very least,
> mention these things:
>
> 1. People who are maintaining third-party distributions of Django
> should (don't have to, but should) let us know who they are, so we can
> do a better job of getting information to them about important fixes
> (e.g., "pre-announcing" security fixes and such). We might also want
> to create roles for them in Trac to make it easier for them to forward
> bug reports "upstream" when their users find things that we need to
> fix.
>
> 2. People who are maintaining third-party distributions should at
> least follow django-announce, so they'll be notified of security fixes
> and releases.
As long as we find out about distributors, why not contact them from our
side, in addition?
Michael
James Bennett
> Hmmm, isn't that just a more explicit definition approach 2? If you find
> it easier, create a bugfix branch with the major release, but this
> doesn't matter much for the users. I'd say do it as it pleases the
> committers.
I like having a bugfixes branch for each major release, because we're
already committed to providing legacy support for current + two
previous releases, and so the bugfixes branch becomes a natural place
to do that work. Since we'd be creating it eventually anyway, we might
as well create it up-front and use it as an easy way to track security
fixes for pushing minor releases.
> Yes, please. The flup issue (disabling flup debug mode) comes to my mind
> as such a case where I would have liked to get an announcement, even if
> it's not sure whether there's really a leak.
It can, under some circumstances, end up showing a traceback which
includes settings values, so there is a problem there. I've committed
the patch for it into 0.95-bugfixes, and it'll be in 0.95.1.
> As long as we find out about distributors, why not contact them from our
> side, in addition?
I've already reported bugs to the folks who are maintaining the Debian
and Fedora packages; hopefully that'll get us started on staying in
touch with distributors.
Patricio Olivares
> I like having a bugfixes branch for each major release, because we're
> already committed to providing legacy support for current + two
> previous releases, and so the bugfixes branch becomes a natural place
> to do that work. Since we'd be creating it eventually anyway, we might
> as well create it up-front and use it as an easy way to track security
> fixes for pushing minor releases.
Hi,
what about going all the way instead?
* for release nn:
* release nn-1 ==> bugfixes + security fixes
* release nn-2 ==> security fixes only (or nothing)
* releases with each security fix or with "enough"
non-security bugfixes
It would be nice to consider not only the security-related
fixes. I know that you talked about being a little flexible
(by mentioning the LazyUser case), but I'm meaning to backport *all*
the non-security bugfixes (or at least the most of them) to the
maintenance branch too. Maybe this will not go in 0.95.1 but it could
be considered from the 0.96 release onward.
By the way, I think that this is the policy that the python-dev
folks follow (see pep 6).
Of course I don't know how much work that means for the
django-xx-bugfixes maintainer (that means you) so I'm only expressing
a wish here.
Anyway, even discarding this, the security-only branch is better than
the present situation. Thanks for that!
d...@simon.net.nz
locked to core-devs only), which lists any found vulnerabilities, when
they were patched and what versions were affected, and a
best-course-of-action e.g.:
Vulnerability: <some name, CVE number etc>
Date Discovered: <...>
Potential Risk: <high, medium, low, etc>
Brief Description: <...>
Versions Affected: 0.95 etc
Action: <upgrade to...>
--Simon