Transcript: Security Releases

Hello, and welcome to another episode of Django Chat, a weekly podcast on the Django Web Framework.

I'm Will Vincent, joined as always by Carlton Gibson. Hello, Carlton.

Hello, Will.

And this week, I thought we'd talk about security releases because there was a particularly

interesting one recently. And so I'll tee it up and then I'll let you do the talking

since you are one of the Django fellows. So Django has a great security policy and does

regular releases outside of the major releases. So major releases would be 2.0, 1.2, 3.0, which

came out in December. And then after that, there's 3.0, 0.1, 0.2, which are minor releases, which are

almost always security related. So let's talk about what's a normal process for that. And then

we'll get to this most recent one, which was a little bit interesting. Okay, so assuming it's

not like 3.0 which is a big release and they they we have a whole um beta release um sequence for

that so we first of all we'll do a an alpha and then there's a six weeks after that there's a

beta and then there's a release candidate and there's a final release so you can follow those

and they're kind of outside of the normal cadence but then there's a month there's basically a

monthly django release so it'll either be 3.0 or 3.0.1 or 3.0.2 and these are bug fixes in new

features essentially or data loss bugs which we will backport then to other versions so if you

know what's currently supported 1.11 is just about to go end of life upgrade if you're on that 2.2

and then 3.0 are current versions and so say there's a data loss a data loss bug in 2.2 we'll

we'll release a version of that and that's on the monthly schedule and that's normally at the

beginning of the month of the first the second the third you know whatever the first monday is

normally and then the other kind of release that you get as part of those is a security release

and normally that hit we will try and land those on the on the first monday of the month as well

just as the normal cycle you know um however you mentioned one recently where we put out mid-month

yes well yes well yeah so from from a distance um something emerged and within i think two days

it had gone through all the processes and was released to everyone but what what's the the

deep dive we can put a link right so yeah it was what was the specific bug that came out it was

okay so we'll find it or something no there was a there was a bug was a click there's a hijacking

right yeah so so now is the password reset yeah via the password reset form so um unicode god

bless you and this is why you have to be using a framework like django right because you would

never ever in a million years find this bug yourself and be able to fix this bug yourself

and secure your own system if you wrote this code by hand.

But because there's millions of people using it,

you get those fixes.

But if, for instance, you've got an email address,

mycut.com,

Example.com, right? That's the one we use in the test case.

But there's a Unicode character, which the Turkish lowercase i without a dot, right?

And that, when it's compared by a database, normally, Postgres, MySQL, well, SQLite doesn't have this issue,

but the normal lowercase i and this Turkish lowercase i without a dot, which are not the same character,

compare the same when you do a quality test in the database to look up the email address so in

principle somebody could register an address a unicode lookalike address for your email address

it'd have to be the same domain so it'd have to be like you know google.com or somewhere where

they could get an email address on the same domain or the main which lowercase the equivalent of

course um and then they could get sent the reset token for your password and then they could reset

your password they could capture your they could capture your account um and this was discovered

as a vulnerability on github and github published a blog post on their security blog telling the

world about it which obviously went to the front page of hacker news and then simon chalet who's

one of the major contributors to django uh was like uh hang on that affects us too and so this

was on them this was on like the monday or the tuesday and we had a release out on the wednesday

afternoon which is as quick as we can do it to be honest because it was it's potentially devastating

and i think also didn't marcus holderman he also did the code or because let's let's talk about

the names right because this like you know these people labor in the dark largely so github released

this thing uh simon chalet saw it or one it was one of the people who saw it and raised the flag

so marcus holderman as you said uh james bennett was yes i know james was up super late involved

uh marius the other jungle fellow was there i was working on it uh who else probably other people

uh yeah were directly involved but those people i definitely remember were on the ticket on the

issue and there was a lot of activity that went on behind the scenes to get it out and normally

normally we pre-announce a security release so normally we hit a week before we'll publicly

announce it and we have a security policy for you know if you need advanced notification

um normally that would be uh if you're like red hat and you're packaging django up for

your package manager you might need these security patches a little bit in advance just so you can

get get that patch in place so people can yum update their their installed django

this time we weren't able to do that because it was so high profile and so

pretend you know it's it's a big issue it's not a minor thing it's a big issue if it's not a minor

of thing so we just we announced it as soon

as we were sure we got the CVE which is

the there's a database of security issues

right yeah

which you need a number for.

So they've got these numbers, CVE 2019,

you know, 1,148 or whatever.

And we released it, you know, on the Wednesday.

Now, how can an average Django user know about this?

So it was tweeted out.

There's like, what's the best way?

And shout out, I launched a Django newsletter

with Jeff Triplett, django-news.com

that will mention things like this.

Because in this case, because I saw, you know, it was very, like the wording said, you know, this is like high priority.

But I'm, where should people look for this, right?

There's the security email feed, right?

What would be the number one place someone should look to, you know, when something like this happens where it's like, oh, you really do need to update now?

Okay, so there's a mailing list called Django Announce, which is a Google group, which you get an email for.

And we send, that's where we'll send the pre-announce saying that the security releases are coming.

So normally on a security release, you get a week's notice.

um for this one you got a day's notice because that was all we had uh then there's the django

blog which you should subscribe to anyway because you get notifications about you know django con

europe or you know the each each released there's a release blog post for each release which tells

you about the release what's in there what's you know what you need to do there's a twitter account

you can follow where else i think that's about it i think those are the the main sources then

django news email yeah well i i'll admit publicly i see that i'm actually not in the django announce

google group so i just signed up i'm in a half a dozen other ones but not that one so it depends

it depends what you like so the blog post comes out like immediately uh yeah i mean and so if

you've got an rs if you've got an rss read that you subscribe to that will appear in your rss

reader if you're on twitter that's automatically tweeted out so but twitter is easy to miss so i

wouldn't use that as a reliable source and then just be on that latest version whichever it is

so if you're on 2.2 be on 2.2.8 or 2.2.9 and then be ready to update to 2.2.10 when it's released

and do that monthly yeah if you're on you know if you're on the latest major release well and i

thought just this was a a great example of the small number of you know people in the dark who

make django happen make it secure you know again james bennett who's been involved with django for

forever the next day he was on a django software foundation uh monthly meeting um which i'm on now

and you know he was quite tired so he's going from one thing to another plus holding down a job and

same for basically everyone else this isn't their job they're not getting paid to do this they do

this because they care and yeah and you know you're the long-term contributors have been there

for ages they they are so knowledgeable it's just mind-blowing like james james was able to point to

the right RFC way, discuss it, or not the RFC, the technical dog.

where it discusses the exact algorithm you have to use to do safe comparison of unicode strings

and you know that knowledge just isn't i don't have it and you know 99 of people don't have

but james has got it and he what he doesn't know well florian will know or simon will know

you know and you know there's a a dozen people perhaps on the security team who really they

really know this stuff yeah yes well so as ever the more i learn about django the more i appreciate

all this work that's done to make it what it is and i actually i just quickly mentioned um

i was elected to the board so there's a django software foundation board so thank you community

um so i'm now one of seven people on that who meet monthly who and i'm the treasurer so deal with

things like paying the fellows sponsors we'll do an episode on that but i'm learning more about

Django and hopefully I'll share that with podcast listeners since I think most podcast listeners

don't know either much of how Django is run we all just take it for granted yeah no I mean it's

just pip install Django that's that's it no all right anything else this this is a short episode

but we wanted to highlight that security release because again in my world all the fire alarms are

going off and I was like oh my god like this is this is something we should highlight to people

because it doesn't just happen without action.

Yeah, no, all I'd say is sponsor the DSF, obviously.

But be on that latest version

and be prepared to update monthly.

It's just a point release.

We shouldn't break anything.

But if it's a security issue

and there's a small breaking change,

there's a small breaking change.

So one previously for the admin in 2.1,

we introduced read-only views.

And in 2.1, you could have a read-only parent

with editable inlines.

but it turned out that that wasn't going to be sustainably secure so we had to pull that out and

now if unless the parent model is editable the whole view will be read only and that's more

secure and you can work around that by implementing custom views but that was a breaking change we

made that with some great discussion we looked at alternatives and we looked at whether those

were sustainable and we're like no but if you're on the latest version it's an easy update and okay

there was a small breaking change if you're needing that you've got a code around it but

you know for security issues you can't you can't quibble yeah and yet another example of your

analogy of the car this is just maintenance if you're up to date it's easier to stay up to date

you have your test suite right and you just run it and you're good to go yeah it's like if you

need new tires you put new tires on because otherwise you crash yes um well thank you

everyone for listening thank you carlton for you and the fellows in the community that does all

this work i appreciate it and that is about it i think okay well thanks for joining us join us next

time bye-bye okay bye-bye