We should have a "security-log" on the wiki (although editing would be
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:
Date Discovered: <...>
Potential Risk:
Brief Descript
James Bennett wrote:
> 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
On 1/19/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
> 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
Hi,
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
On 1/19/07, James Bennett <[EMAIL PROTECTED]> wrote:
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 t
On 1/19/07, James Bennett <[EMAIL PROTECTED]> wrote:
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
On 1/19/07, James Bennett <[EMAIL PROTECTED]> 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
James Bennett wrote:
* 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 ne
I like our security policy[1]. As security policies in the open-source
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 releas
