6 ms·

next step is to make this the default. unfortunately the django overlords think it's not important enough to be default.

by svlla 16y ago

jacobian 16y ago
A few things: First, There's no such things as "the django overlords". We're an open source community of thousands. Hundreds contribute. Dozens have commit access. Vry few among these contributors, and none (that I know of) on the commit team thinks that bcrypt support "is not important." If you'd like to prove me wrong, please cite your source. Now, this has been proposed a few times (http://code.djangoproject.com/ticket/5787 http://code.djangoproject.com/ticket/5787, http://code.djangoproject.com/ticket/5600 http://code.djangoproject.com/ticket/5600). Each time, substantive problems with the approach have been found. A few choice quotes from the discussion should illustrate the issues: Me, on #5600: "[T]here's a problem with supporting any hash schemes not in Python 2.3 (our lowest supported Python version): it means databases created with a different version of Python break when used under a lower one." (Now it's Python 2.4, and 2.5 soon, but the problem still holds.) Malcolm, on #5787: "As soon as you start generating passwords that are only computable based on an optional model, the database can only be used with Django installations that have that model available. This removes the ability to move the database around easily. Django operates on a "batteries included" philosophy for exactly that reason: runs anywhere without lots of extra dependencies." Worse, this third-party module (i.e. Python bcrypt module), last I checked, failed to build on Windows. As much as I hate supporting Windows, I recognize why we have to. What I'm trying to say is that the issue is technical, not personal or political as you seem to think. If the technical issues can be overcome, I don't see why bcrypt support couldn't be the default. Finally, I'll close with the obligatory note that open source projects get driven forward by people scratching their own itch. If this bothers you, fix it. If your fix is rejected, try again. If you think we're a bunch of asshats, fork the project. Do any of those things, and I'll respect you. Complain and sling personal attacks and I won't.
- stevelosh 16y ago
  This is why I chose to make this a separate app instead of embarking on a painful journey to get it into core. Those of us that run OSes that don't suck and don't use versions of Python that are older than the average hamster's lifespan can add two lines to their project and be more secure TODAY.
  - SoftwareMaven 16y ago
    And the others of us in the same situation greatly appreciate it.
- burgerbrain 16y ago
  If you can't hash passwords properly, you shouldn't be dealing with passwords at all. It's just damned irresponsible. "the django overlords" "Dozens have commit access." I suspect that's what he meant.
  - jacobian 16y ago
    > It's just damned irresponsible. Since you feel that strongly I can expect to see a patch from you fixing the technical issues I mentioned, right? You write it, I'll commit it. Go.
    - stevelosh 16y ago
      Look, I love Django, but to be fair this is kind of a bullshit response. There are things I hate about Git, and I could fix them myself, but I don't submit patches to Git. I just use Mercurial instead. "Send patches" isn't a be-all, end-all response to any criticism of an open source project.
      - jacobian 16y ago
        You're right. I get kinda pissed when people call me "dammed irresponsible" because I can't find the time to solve some technical problems. It implies a sense of entitlement to my time that rubs me the wrong way. You did exactly the right thing: figured out how to solve the problem regardless. That's something that'll motivate me; calling me stupid or irresponsible won't. So yeah, you're right, it is bullshit, and so is the attitude I responded to. Garbage in, garbage out, I suppose.
        stevelosh 16y ago
        Having several open source projects of my own, and contributing to a few more, I definitely know how you feel. Here's what I want to know about this in a nutshell: Does Django (the project as a whole) want to provide the best possible security, within reason, for its contrib.auth module? If not, why not, and why isn't it stated prominently in the documentation? Is bcrypt not the best possible security, or reasonably close to it? If not, why not? I'm not even remotely close to a cryptography expert, so although bcrypt's support for arbitrary work factors seems to provide very good security to me I know I could very well be horribly wrong in this thinking. Is providing bcrypt hashing for passwords in contrib.auth not within the realm of reasonable effort? This could mean rewriting bcrypt in pure Python and including it in contrib, to support Windows users. If not, why not? Perhaps rewriting bcrypt in Pure Python is not easy -- I haven't tried it myself. If bcrypt hashing is secure and reasonable to implement, and Django wants to provide the best security possible (within reason), why is this not a blocking issue for Django 1.3? I genuinely don't know the answers to any of these questions, so I'd really love to know.
- philipn 16y ago
  Looking at the py-bcrypt site, it looks like it has worked on Windows in the past. It should be possible to fix it to work on windows (I see a patch from a few months ago to fix a recent build problem on XP). py-bcrypt works with 2.4, too.
- svlla 16y ago
  the issue is one of priorities and it is clear to me that supporting python 2.3, or remaining batteries-included, or backward compatible, or whatever other excuse you can come up with is more important than having modern password security. perhaps if it seemed remotely likely that a patch that met most but perhaps not all of your requirements would have a chance of being accepted someone would do it. as it stands it seems to be futile given the unrealistic requirements.
- drdaeman 16y ago
  > This removes the ability to move the database around easily. Aren't warning in documentation "This setting requires this and that, so if you chose it don't expect your project to be easily portable. You have been warned." enough?

next step is to make this the default. unfortunately the django overlords think it's not important enough to be default.

by svlla 16y ago

next step is to make this the default. unfortunately the django overlords think it's not important enough to be default.

jacobian 16y ago

A few things: First, There's no such things as "the django overlords". We're an open source community of thousands. Hundreds contribute. Dozens have commit access. Vry few among these contributors, and none (that I know of) on the commit team thinks that bcrypt support "is not important." If you'd like to prove me wrong, please cite your source. Now, this has been proposed a few times (http://code.djangoproject.com/ticket/5787 http://code.djangoproject.com/ticket/5787, http://code.djangoproject.com/ticket/5600 http://code.djangoproject.com/ticket/5600). Each time, substantive problems with the approach have been found. A few choice quotes from the discussion should illustrate the issues: Me, on #5600: "[T]here's a problem with supporting any hash schemes not in Python 2.3 (our lowest supported Python version): it means databases created with a different version of Python break when used under a lower one." (Now it's Python 2.4, and 2.5 soon, but the problem still holds.) Malcolm, on #5787: "As soon as you start generating passwords that are only computable based on an optional model, the database can only be used with Django installations that have that model available. This removes the ability to move the database around easily. Django operates on a "batteries included" philosophy for exactly that reason: runs anywhere without lots of extra dependencies." Worse, this third-party module (i.e. Python bcrypt module), last I checked, failed to build on Windows. As much as I hate supporting Windows, I recognize why we have to. What I'm trying to say is that the issue is technical, not personal or political as you seem to think. If the technical issues can be overcome, I don't see why bcrypt support couldn't be the default. Finally, I'll close with the obligatory note that open source projects get driven forward by people scratching their own itch. If this bothers you, fix it. If your fix is rejected, try again. If you think we're a bunch of asshats, fork the project. Do any of those things, and I'll respect you. Complain and sling personal attacks and I won't.

stevelosh 16y ago
This is why I chose to make this a separate app instead of embarking on a painful journey to get it into core. Those of us that run OSes that don't suck and don't use versions of Python that are older than the average hamster's lifespan can add two lines to their project and be more secure TODAY.
- SoftwareMaven 16y ago
  And the others of us in the same situation greatly appreciate it.
burgerbrain 16y ago
If you can't hash passwords properly, you shouldn't be dealing with passwords at all. It's just damned irresponsible. "the django overlords" "Dozens have commit access." I suspect that's what he meant.
- jacobian 16y ago
  > It's just damned irresponsible. Since you feel that strongly I can expect to see a patch from you fixing the technical issues I mentioned, right? You write it, I'll commit it. Go.
  - stevelosh 16y ago
    Look, I love Django, but to be fair this is kind of a bullshit response. There are things I hate about Git, and I could fix them myself, but I don't submit patches to Git. I just use Mercurial instead. "Send patches" isn't a be-all, end-all response to any criticism of an open source project.
    - jacobian 16y ago
      You're right. I get kinda pissed when people call me "dammed irresponsible" because I can't find the time to solve some technical problems. It implies a sense of entitlement to my time that rubs me the wrong way. You did exactly the right thing: figured out how to solve the problem regardless. That's something that'll motivate me; calling me stupid or irresponsible won't. So yeah, you're right, it is bullshit, and so is the attitude I responded to. Garbage in, garbage out, I suppose.
      - stevelosh 16y ago
        Having several open source projects of my own, and contributing to a few more, I definitely know how you feel. Here's what I want to know about this in a nutshell: Does Django (the project as a whole) want to provide the best possible security, within reason, for its contrib.auth module? If not, why not, and why isn't it stated prominently in the documentation? Is bcrypt not the best possible security, or reasonably close to it? If not, why not? I'm not even remotely close to a cryptography expert, so although bcrypt's support for arbitrary work factors seems to provide very good security to me I know I could very well be horribly wrong in this thinking. Is providing bcrypt hashing for passwords in contrib.auth not within the realm of reasonable effort? This could mean rewriting bcrypt in pure Python and including it in contrib, to support Windows users. If not, why not? Perhaps rewriting bcrypt in Pure Python is not easy -- I haven't tried it myself. If bcrypt hashing is secure and reasonable to implement, and Django wants to provide the best security possible (within reason), why is this not a blocking issue for Django 1.3? I genuinely don't know the answers to any of these questions, so I'd really love to know.
philipn 16y ago
Looking at the py-bcrypt site, it looks like it has worked on Windows in the past. It should be possible to fix it to work on windows (I see a patch from a few months ago to fix a recent build problem on XP). py-bcrypt works with 2.4, too.
svlla 16y ago
the issue is one of priorities and it is clear to me that supporting python 2.3, or remaining batteries-included, or backward compatible, or whatever other excuse you can come up with is more important than having modern password security. perhaps if it seemed remotely likely that a patch that met most but perhaps not all of your requirements would have a chance of being accepted someone would do it. as it stands it seems to be futile given the unrealistic requirements.
drdaeman 16y ago
> This removes the ability to move the database around easily. Aren't warning in documentation "This setting requires this and that, so if you chose it don't expect your project to be easily portable. You have been warned." enough?