6 ms·

I think that the issue is compounded here by the fact that Django is a framework which will be used in hundreds or thousands (or more) of applications deployed

I think that the issue is compounded here by the fact that Django is a framework which will be used in hundreds or thousands (or more) of applications deployed all over the world. Any security issue with the framework itself instantly puts thousands of apps at risk. If you have a single app then you can discount this kind of attack, but when you are producing code that will be used in thousands of other apps, it would be irresponsible to do so.

tptacek 17y ago
I think a feature that is catastrophically insecure when deployed at Slicehost is pretty much D.O.A. anywhere, and that Patrick explained it nicely. I'm sorry for being glib, but something about this Django request rubbed me the wrong way. I get the impression (probably unjustified) that tomorrow the dev team is going to say, "well, that timing problem was the only thing anyone found, so we're good to go". In fact, if they're serious about peer review, the fact that it took 15 seconds to find a critical vulnerability would be a good reason to hold it back for many weeks and to ensure that several competent people signed off on it. I'm conflicted though, because every other mainstream framework has this functionality, and it's not that complicated to build. I wish they'd stop advertising goofy security "features" like "salts" and key rotation, though.
- simonw 17y ago
  I'm sorry I rubbed you the wrong way - that certainly wasn't my intention. We're serious about peer review. We want to get this right.
- jacobian 17y ago
  We've not checked this in yet precisely because, as you say, that good review is important. We don't have anyone in our core community who's a security expert, so that's precisely why we've tried to reach out to the broader web development community for review. I'm really sorry that the request rubbed you the wrong way. In fact, it completely sucks: you're pretty much the perfect kind of person we wanted to interest in this. So on a meta level, do you have any suggestions about how to word or structure requests like this in the future? Can you clarify what, exactly, rubbed you the wrong way? Is there something different we should/could have done? Your main suggestion here seems to be that we give it some time (right?) and I hear that loud and clear. I agree it'd be silly to call for a review on Monday and check it in on Thursday. We've always been a pretty conservative bunch of committers; our community's pretty used to waiting while features get the review they deserve. The problem is that there's a chicken and egg situation with any code that's not committed (or is out on a branch). The vast majority of contributors (let alone developers) only see what's on trunk, so anything that's not yet there gets a simply pitiful number of eyes on it. Once something's committed/merged, a whole lot more people see it (which is why we always end up finding bugs in "stable" code only after it's merged). But shipping insecure code is just awful. As a maintainer, it's hard for me to tell whether a lack of feedback indicates a lack of issues or a lack of interest. Regardless: thanks for your help and advice. I really appreciate it.
  - nopal 17y ago
    If Django's core community doesn't have anyone who can evaluate these types of code changes effectively, it might be wise to have the Django Foundation hire a crypto consultant. It seems like there'd be a great market in post-Docs looking for this type of work.
    - jacobian 17y ago
      I'm curious: do you have any idea what that'd cost? My impression is that anyone who's actually worth paying would cost well beyond what the DSF could actually afford. That said, stuff like this is why the DSF exists in the first place, so it's a worthy idea.
- ubernostrum 17y ago
  In fact, if they're serious about peer review, the fact that it took 15 seconds to find a critical vulnerability would be a good reason to hold it back for many weeks and to ensure that several competent people signed off on it. Meanwhile... http://groups.google.com/group/django-developers/msg/7e0e53c6617178a7 http://groups.google.com/group/django-developers/msg/7e0e53c... (I don't have the final say on that, of course, but considering that I hadn't even seen the code until today I just don't see any way to both be a responsible release manager and ship this in Django 1.2)

tptacek 17y ago

I think a feature that is catastrophically insecure when deployed at Slicehost is pretty much D.O.A. anywhere, and that Patrick explained it nicely. I'm sorry for being glib, but something about this Django request rubbed me the wrong way. I get the impression (probably unjustified) that tomorrow the dev team is going to say, "well, that timing problem was the only thing anyone found, so we're good to go". In fact, if they're serious about peer review, the fact that it took 15 seconds to find a critical vulnerability would be a good reason to hold it back for many weeks and to ensure that several competent people signed off on it. I'm conflicted though, because every other mainstream framework has this functionality, and it's not that complicated to build. I wish they'd stop advertising goofy security "features" like "salts" and key rotation, though.

simonw 17y ago
I'm sorry I rubbed you the wrong way - that certainly wasn't my intention. We're serious about peer review. We want to get this right.
jacobian 17y ago
We've not checked this in yet precisely because, as you say, that good review is important. We don't have anyone in our core community who's a security expert, so that's precisely why we've tried to reach out to the broader web development community for review. I'm really sorry that the request rubbed you the wrong way. In fact, it completely sucks: you're pretty much the perfect kind of person we wanted to interest in this. So on a meta level, do you have any suggestions about how to word or structure requests like this in the future? Can you clarify what, exactly, rubbed you the wrong way? Is there something different we should/could have done? Your main suggestion here seems to be that we give it some time (right?) and I hear that loud and clear. I agree it'd be silly to call for a review on Monday and check it in on Thursday. We've always been a pretty conservative bunch of committers; our community's pretty used to waiting while features get the review they deserve. The problem is that there's a chicken and egg situation with any code that's not committed (or is out on a branch). The vast majority of contributors (let alone developers) only see what's on trunk, so anything that's not yet there gets a simply pitiful number of eyes on it. Once something's committed/merged, a whole lot more people see it (which is why we always end up finding bugs in "stable" code only after it's merged). But shipping insecure code is just awful. As a maintainer, it's hard for me to tell whether a lack of feedback indicates a lack of issues or a lack of interest. Regardless: thanks for your help and advice. I really appreciate it.
- nopal 17y ago
  If Django's core community doesn't have anyone who can evaluate these types of code changes effectively, it might be wise to have the Django Foundation hire a crypto consultant. It seems like there'd be a great market in post-Docs looking for this type of work.
  - jacobian 17y ago
    I'm curious: do you have any idea what that'd cost? My impression is that anyone who's actually worth paying would cost well beyond what the DSF could actually afford. That said, stuff like this is why the DSF exists in the first place, so it's a worthy idea.
ubernostrum 17y ago
In fact, if they're serious about peer review, the fact that it took 15 seconds to find a critical vulnerability would be a good reason to hold it back for many weeks and to ensure that several competent people signed off on it. Meanwhile... http://groups.google.com/group/django-developers/msg/7e0e53c6617178a7 http://groups.google.com/group/django-developers/msg/7e0e53c... (I don't have the final say on that, of course, but considering that I hadn't even seen the code until today I just don't see any way to both be a responsible release manager and ship this in Django 1.2)