I'm really feeling for our Rails Core friends... they're getting
blasted right now for not having a complete policy for releasing and
communicating urgent security flaws. I'm not poking fun, this is pretty
serious stuff.

Read here for some of the comments they're getting today via
Reddit.com:
"Mandatory security patch issued for Rails, but the vulnerability is
not disclosed. "
http://programming.reddit.com/info/cvlr/comments

Rather than poke fun or make light of the today's situation with Rails,
I'd rather like to turn the focus on the Django project and play the
"But what if it happened to you?" game.

I heard way-back-when that Django was security-audited, and found to be
secure, but that was (I think) before Django was open-sourced, and I
don't remember seeing many details.. However, doing a quick search for
"security" of the Dev list shows this message from Jacob:
http://groups.google.com/group/django-developers/msg/682543e6c084ff75

Should someone commission a new audit given the amount of code changes
in Django since last year? (It would be a great opportunity for some
company <cough Google cough ThoughtWorks cough WorldOnline /> to
sponsor.

A few questions:
1) If there was critical security flaw found in Django (any version)
today, are there plans in place on how to deal with it? If so, are
those plans posted anywhere? If not, let's roll up our sleaves and do
it! :-)

2) Is there a Django mailing list for security alerts? If not, let's
create one!

3) What are some projects to emulate in terms of "They do security
right"? I've heard Debian has good policies and execution on those
plans. Any others?

Having an emergency plan ready to go the moment a security issue crops
up is one of those things that will really ease the mind of an
"enterprise" flirting with the idea of going Django. It's also an area
where Django can really shine compared to other web frameworks (Python
or otherwise).

-Jason

I'm on the Apache security list, and I'll offer my 2c's on how they  
do it.

1) A security@ email alias which is private and is a alias for the  
core developers. be prepared for a *LOT* of spam, and a lot of questions
which should have been asked on dev@ or users@. Certain security  
providers like to send stuff with GPG encryption. make sure that you  
have a GPG key with good trust paths
so that they can send encrypted information to you.

2) Acknowledge each email on it, the security 'researchers' like  
prompt feedback, and will post on full-disclosure if they
don't feel like they are getting a fast enough response.

3) a vendors-announce@ mailing list which goes to the major vendors  
who use django. people like redhat, debian, and possibly
some of the large ISPs who provide django hosting. They usually get  
notified that there is an issue (not what it is) and the expected  
announce date
so they can have some resources to deal with it when it comes out.  
you should also notify agencies like CERT and get a CVE id for the  
issue.

4) a regular announce@ mailing list for the rest of us mortals.

apache also has a private SVN repo for keeping track of issues, but  
I'm not sure if that is warranted here.. django is much smaller

5) when a security release happens, the release notes acknowledge the  
security research firm that found it. This will encourage them to  
tell you about it
first.

oh.. and security usually comes in waves.. now that a vulnerability  
has been found in Rails,  I expect it will attract several other  
research firms to look at rails (and django) very carefully.

On 10/08/2006, at 11:41 AM, Jason Huggins wrote:

--
Ian Holsman
I...@Holsman.net
http://peopleintopoker.com/ -- where the poker people go

[...]

See
http://www.djangoproject.com/documentation/contributing/#reporting-se...

If somebody did find a security problem, I would hope they would have
the presence of mind to look in the "how to contribute" document if they
could find no other way to contact people. Also note that the email
address there is the "obvious" one in some sense for reporting security
problems.

Finally, a little while ago somebody did report what they thought was a
security hole via Trac (an unfortunate choice, but that's the way it
goes) and it was looked at immediately.

Which policies in particular are you thinking about?

To provide some background about how distros work: Each professional
distribution (Debian, Suse, Mandrake, Red Hat, Ubuntu, Slackware,
*BSD, ...) has a security team that has representatives on the contacts
list specifically for notifying vendors of security problems in advance
of a release. It's why when you read about, e.g., an Apache release, you
also see most major distributions putting out update packages on the
same day. It isn't magic -- it's coordination and it's a very
professional group of people to work with.

Revolutionary ideas aren't really needed here, since the current
system(s) work fairly well and using proven practices in cases like this
is absolutely the right thing to do. The thing that seems to have bitten
Ruby on Rails (and is applicable to us as well) is that they have a
broad installation base via grass-roots support, rather than via
distributions. Python, for example, has had security flaws in the past
(usually due to third-party libraries) and they have handled the release
and disclosure process very well.

I'm not completely sure I agree with the way the Ruby team are handling
this release, but since I don't know the details yet, I can't really
work out what is happening; they may have very good justification for
the way they are doing it, or they may just be slightly shell-shocked.
It just didn't cross my radar on any of the security-related lists I'm
on that normally cover these types of security announcements. They are
the places that this "enterprise" group watch for results. Presumably
there was a post to the Ruby-users mailing list, wherever that is and
that is the other place people are going to be watching: if you're using
something that is essentially pre-release for mission-critical work, you
are implicitly taking on the responsibility of watching carefully for
things like this.

Regards,
Malcolm

On 8/9/06, Malcolm Tredinnick <malc...@pointy-stick.com> wrote:

Dave Thomas, who is heavily involved with Ruby yet not Rails-core, and
who I think has very good judgement, thinks the issue is severe enough
that they're doing the right thing to let people hear and upgrade
before full disclosure.

True, but Rails had lots of buzz and has -lots- of prod systems.  Of
the 2 people I talked to with prod rails systems, neither had heard of
this 3 hours after the posting.  I only knew because of luck on
prog.reddit.

Security is freaking hard.

Sorry I didn't read that first before posting here. Though I did a Trac
search for "security" and that page didn't come up in the first few
search results...

Though, looking at the guidelines, I wonder how the Django devs would
know who to contact in one-on-one private emails about the
vulnerability and the fix.

I guess I'm focused on three things:
1) How do Django devs handle security issues when notified? This looks
well covered in the existing reporting-security-issues doc.
2) How should the affected users be notified? Having read the above
doc, I think this could use some more detail.
3) Is there any sort of policy or promise on how many versions back
Django devs are willing to go back and support?

The implicit assumption of using pre 1.0 code (especially open source)
is that there are no promises... But there might need to be something
more explicit like ("we'll make our best effort to support the creation
of any critical security patches for version 'X' for at least Y number
of years after initial release). In the Rails case, they first said
"upgrade to the latest version to get the patch", which made many
people unhappy. Then they back-peddaled and said they'd work on patches
for the older versions, too. Might be better to state up-front how long
Django devs expect to support various versions so people can weigh the
risks of staying on an old release later on. This is a good thing to
decide on when 1.0 ships. By comparison, the Ubuntu project is very
upfront in how they promise to support each release.

- Jason

On 8/9/06, Jason Huggins <jrhugg...@gmail.com> wrote:

One would hope that anyone who's using Django is subscribed to
django-users and/or watches the Django blog (or that a company which
uses Django has a designated person doing that), because those would
be the obvious channels for notifying users that a security-related
patch/release had been issued.

The documentation page Malcolm linked states that patches will be
developed for the current release and the two releases previous to it.
That seems like a fairly sane policy, is roughly in line with what
some of the more popular Linux distros do.

--
"May the forces of evil become confused on the way to your house."
  -- George Carlin

Same here, programming.reddit.com is my most hit site these days...

But all the more reason for letting Django users know *before-hand*
where they should look for stuff like this (which list they should be
subscribed to or RSS feed to check). As Django user/dev, I would *not*
want to *first* hear about something like this on reddit. :-)

Maybe there should be some guideline like.. "If you're going to deploy
Django on a server accessible by the general public, subscribe to our
security RSS feed or mailing list to be notified as needed". Even then,
I can see how a policy like that is "tricky"... What's to keep an evil
blackhat from subscribing to the very same list so he he knows when to
get busy cracking sites using the same information?

-Jason

Ugh. May bad... I must have missed that. Right there it says, "[For
security issues, we'll] Halt all other development as long as is needed
to develop a fix, including patches against the current and two
previous releases."

Thanks for answering my questions, everyone. I'll try to read the docs
more closely next time... :-)

- Jason

On 8/9/06, Jason Huggins <jrhugg...@gmail.com> wrote:

I've been watching people go round and round about this in various
places today, and I have to say that I can respect the Rails team's
policy of not releasing full details of the vulnerability until after
their users have had a little time to patch. Full disclosure still
happens, but it's slightly safer for end users this way. A couple
other open-source projects I've used/been involved with have followed
a similar policy of "update ASAP, and we'll release details once
people have had time to patch", and it's caused no harm that I've
seen.

And as much as some people I've talked to have been wailing and
gnashing teeth about Rails being into Mac OS X 10.5 while Django
isn't, well, I don't envy somebody who gets shipped as part of a major
operating system when it comes time to issue security updates :)

--
"May the forces of evil become confused on the way to your house."
  -- George Carlin

This is pretty much a solved problem. It is coordinated through the
vendor security contacts lists that Ian was talking about. It happens
more often than you may realise: Apache or OpenSSL or the Linux kernel
or some other pervasive, critical component has a security hole
discovered and the release of the updates is coordinated and
simultaneous. So Apple would release the updates on the same day as
everybody else. If you do it well, you don't end up where people look at
you like Microsoft and think they can't trust the update (another
advantage of Open Source, too). Often the upstream source can supply the
patch, so the vendors need only audit it and do package rebuilds and
rush it through release QA (again, they'll often have priority paths
internally for security fixes).

Regards,
Malcolm

This would be less and less true as time goes because Django will spread
beyond early adopters to a new forming local communities. For example
there is russian Django's LiveJournal community where I suspect many
people read just that list and not django-users because either they're
already happy with local list or just don't feel comfortable enough with
English to read it on a dialy basis.