For what I can see, Invoke is just a revamped version of Fabric’s task running components.
Fabric 2.0 will "leverage Invoke for task running, leaving Fabric itself much more library oriented".
tbh, qualitative research like this has no predictive power. It's just a (few) case studies. The variables that are in these case studies cannot be controlled for, nor tested and/or predicted. All it gives is some example anecdotes. Unfortunately, a lot of social science research end up like this, because of the complexity of the problem. Thus, i wouldn't cite peopleware as research, but as anecdotal examples, or case studies.
Again, we believe that sessions and CSRF protection can be orthangonal (and that there are benefits to doing so). If you can prove otherwise, let us know!
There's also https://github.com/mozilla/django-session-csrf, an alternate CSRF implementation by Mozilla that does use session-linked CSRF tokens. So if you insist on "tokens must be session-linked", you can use that instead.
Yes, that's correct, in theory BREACH can be used to target any sort of secret embedded in the body of an HTTP response. CSRF tokens are the most common type of secret in that category, but there are others. However, we can't speak authoritatively to The Web or All Web Frameworks or anything, but we can advise our users on how they can protect themselves.
To your second point, security@djangoproject.com. It's documented in a bunch of places; where'd you look for it? I'll add it there, too :)
To the first point, we believe that Django's CSRF protection is as strong as session-linked CSRF protection, and adds CSRF protection to anonymous users (users without a session as well). In other words, it's a design decision, one that we believe doesn't compromise CSRF protection. If you believe otherwise, please get in touch (see above).
1) session and logged in/out user are two different things. Session is the way you store information about current user, no matter he is anonymouse or logged in.
2) I checked again for instance https://bitbucket.org/ - edit csrftoken cookie to any, 123123 for example. Reload the page and if site keeps working - Cookie Forcing with MITM will do the same thing using http: injector Set-Cookie
not only MITM, subdomains can do precisely same thing. Either bitbucked uses old django or django is vulnerable to it (which is, well, a severe vulnerability imo)
1) I know the difference between sessions and logging in. I didn't say anything about logging in; I said that our CSRF protection protects users without sessions. Not all sites use sessions (some for performance reasons, others for privacy reasons); must those sites be vulnerable to CSRF?
2) First, you should report this to Bitbucket: https://www.atlassian.com/security. And c'mon, disclosing a possible CSRF vulnerability on a public board is kinda irresponsible. Is responsible disclosure not something you practice?
SecondI don't know what Bitbucket is running, exactly, and exrapolating from Bitbucket to Django is pretty lazy. Frameworks != sites. Once again, we've spent quite of bit of time validating the design and implementation of Django's CSRF protection, and we believe it works. If you find proof otherwise, can you please send it to security@djangoproject.com, and not post it to Hacker News?
1) only to make sure we are on the same page. Now I see - we have different understanding of "session".
>Not all sites use sessions (some for performance reasons, others for privacy reasons);
what kind of site doesn't use sessions? To track a user you need a cookie right?
2) Frameworks != sites.
As I used to think, only framework is responsible for CSRF protection, hence I extrapolated. I sent it to security@ as soon as I found this email. I am trying to not proclaim anything but some websites from http://www.djangosites.org/ are vulnerable.
Ok, plausible attack I thought up based on what I could suck up from homakov's and various other posts:
1. User is browsing an HTTPS Django site and a HTTP site on WiFi.
2. Hacker is MITMing a connection (on WiFi), cannot decrypt SSL.
3. Changes user's CSRF token for Django via cookie-forcing.
4. Hacker can now use user's other HTTP session, and inject JS (or whatever) so their browser sends stuff to the HTTPS Django site, fully knowing their CSRF token (because we set it) and thus can forge requests easily.
Does Django mitigate something like that already? I think should be pretty easy to mitigate by using Django's signing to sign the session ID or something into the CSRF token?
An unrelated HTTP session cannot set a cookie for another domain (unless it's a subdomain in which you have the more serious issue of session theft or session fixation). The solution to both of these problems is HSTS with the includeSubDomains option.
I've just woken up and I haven't tested it, but off the cuff I believe HSTS will prevent the browser from trusting a plaintext HTTP response at all. So you cannot force a cookie if I understand the blog post correctly. You'd have to create a cookie inside of a verifiable HTTPS connection, which if you can do you've already executed a much worse attack.
I have anecdotes about how CoCs have improved communities, but I don't really want to play dueling anecdotes with you. It sucks that you've seen Coc's used as a bludgeon; I haven't.
However, it's sorta irrelevant here: we're not expecting this to really change much of anything, and we don't think the community needs improving. Like the FAQ says, "we know that the Django community is open, friendly, and welcoming. We want to make sure everyone else knows it too." The goal here is to articulate and write down the standards that we already basically follow but have been (until now) unwritten.
In fact, if you're worried about having the book thrown at you, you should be happy about this change. Before today, if I thought you were being a jerk, I could throw you off IRC or the mailing list or whatever and that was that. I was, until a few hours ago, essentially sole arbiter of standards in the Django community, and those standards were ones that basically lived in my head until earlier this year.
Now, those standards are written down, and there's a process and some oversight to make sure I don't unilaterally decide someone's worth hitting with the ban-hammer.
So really, if you're honestly concerned about being people ousted for violated community policies, this sort of documentation and process should make you feel more comfortable, not less. We're replacing a BDFL-ship with open documentation, a committee, and organizational oversight.
I appreciate and agree with the points you are making. I really was talking general, it seems like my points were taken a little too much in a python or django related vein.
I do think there are inherent problems with a CoC. You state that the rules probably won't change anything and I agree with that. I think that shows the power of an implicit agreement of conduct. Because even if a CoC tries to inform that, I remain unconvinced that it can.
I suppose mostly what I have a problem with is the concept of expectation itself. A CoC is a lightning rod that is cited when people feel wronged. You sort of turn that around by saying that I might feel safer with explicit rules, but I could just as well argue that the more explicit the rules are, the more suspect they are to being misused or misinterpreted. Because what they do is create the explicit expectation that they will be upheld. What part of them and in what manner is subject to interpretation and those "toxic" people are usually quite inventive when it comes to finding such transgressions. Managing expectations like that can be a very tricky thing.
I might be biased by my experience here, but I've just seen a little too often how making conduct a high ranking concern can create a vacuum that attracts politics.
In the end, I'm quite certain that you are right with the beginning of your second paragraph. Although I would still say - If it's not needed and it won't change anything, then why have it? (And yes, I read your FAQ, so feel free to ignore this question ;-) )
Her agenda masquerades as something genuinely good and productive, yet pushes something orthogonal and unrelated. She's on a crusade.
Most of the women I know in tech loathe these sorts of concern-trolls for giving feminists erroneous reputations of being hard to work with.
Also, who's angry? I just think it's stupid to engage with such destructive people, but then again I don't participate in the Django community in any way so it doesn't affect me one way or the other.
Also, giving them credence and strengthening their brand serves to help them undermine actual equality in our industry, but, again, I'm male, so it doesn't directly affect me. It's still stupid, though.
Please don't think of diversity as an issue that doesn't affect you, because you are a man. A lack of diversity affects all of us. More diverse groups perform better. If a lack of diversity is a result of artificial barriers being put into place (such as a community not welcoming new members), then that less the effect an individuals right to self-determiniation, and I believe that's an issue that effects all of us.
i concur. i know a few female software developers who are completely comfortable amongst an all male group, but are terrified of speaking up when there is a mixed group.
This type of feminist, and the ada group are known for this kind of behaviour specifically, are wont to turn on their own :
You're completely right: these documents articulate a set of standards that we've essentially been following from day 1. Nothing's really changed except that now we've written down the unspoken rules that nearly everybody followed because, you know, they're good people.
It's an "explicit is better than implicit" kinda of thing!
Sorry, I realize I am being harsh, and am grateful for all the work of the Django community organizers. Let me clarify my previous remarks.
The items under the "Be careful in the words that you choose" heading (which make up a significant part of the document), except for maybe the doxing clause, addresses an apparently antisocial audience, which is patronizing.
And what I mean by CYA-ish, is that the intent of the code seems to be to prevent worst-case scenarios. Whereas the HN and Hacker School guidelines aim to boost the level of discourse and friendliness, the Django code offers suggestions on how to avoid getting arrested.
