Re: Rename salt to mask in CSRF

2020-02-19 Thread Ram Rachum 
Cool, PR here:  https://github.com/django/django/pull/12479

On Thu, Feb 20, 2020 at 1:59 AM Adam Johnson  wrote:

> I guess it's not a very big change so could be worth it to increase
> readability.
>
> On Wed, 19 Feb 2020 at 16:12, Ram Rachum  wrote:
>
>> In any case, if it's decided that it's a worthwhile change, I'll be happy
>> to make the patch.
>>
>> On Wed, Feb 19, 2020 at 10:31 AM Adam Johnson  wrote:
>>
>>> The wikipedia page says:
>>>
>>> In cryptography, a salt is random data that is used as an additional
>>>> input to a one-way function that hashes data, a password or passphrase.
>>>> Salts are used to safeguard passwords in storage.
>>>
>>>
>>> Ram is right - this variable is not a salt in that definition. We aren't
>>> using a one-way hash function, but a reversible rotational cipher function.
>>> The 'salt' is really the key/mask/one-time-pad to that cipher function.
>>>
>>> I think "mask" and "unmask" are more correct terms to use in the code
>>> and docstrings. Not sure if it's worth the effort to change though
>>>
>>>
>>> On Wed, 19 Feb 2020 at 06:39, Matemática A3K 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Feb 18, 2020 at 3:31 AM Ram Rachum 
>>>> wrote:
>>>>
>>>>> Hi guys,
>>>>>
>>>>> Recently I was working with Django's CSRF protection, customizing it
>>>>> to my needs, and discussing with co-workers exactly how it works and how 
>>>>> it
>>>>> has protection against the BREACH attack being used to retrieve the CSRF
>>>>> key.
>>>>>
>>>>
>>>> https://github.com/django/django/pull/11919#issuecomment-549000592
>>>>
>>>>
>>>>> Relevant code here:
>>>>> https://github.com/django/django/blob/master/django/middleware/csrf.py#L45
>>>>>
>>>>> One point of confusion is the use of the term salt in Django's source
>>>>> code. People expect salt to mean the same as salt in the database, that
>>>>> works quite differently and doesn't mask the actual secret.
>>>>>
>>>>> I'm not a security expert so I may be wrong, but I think that
>>>>> "One-time pad", "XOR mask" or just "mask" would be more accurate terms.
>>>>>
>>>>> I propose to change the "salt" to "mask" everywhere these terms appear
>>>>> in the CSRF code, and similarly "unsalt" to "unmask". As far as I know 
>>>>> this
>>>>> wouldn't affect functionality at all, because the term "salt" doesn't
>>>>> appear in actual tokens.
>>>>>
>>>>> What do you think?
>>>>>
>>>>
>>>> I think the term is accurate in the domain -
>>>> https://en.wikipedia.org/wiki/Salt_(cryptography) - no need to rename
>>>> it.
>>>>
>>>>
>>>>>
>>>>> Ram.
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Django developers (Contributions to Django itself)" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to django-developers+unsubscr...@googlegroups.com.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/django-developers/3cf02beb-e292-4991-b75e-2f3f6e28d371%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/django-developers/3cf02beb-e292-4991-b75e-2f3f6e28d371%40googlegroups.com?utm_medium=email_source=footer>
>>>>> .
>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Django developers (Contributions to Django itself)" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to django-developers+unsubscr...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/django-developers/CA%2BFDnhKZdF2QbSy9cL643t9eugzHm6GMaeXtxFVCgHEvYHJwSQ%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/django-developers/CA%2BFDnhKZdF2QbSy9cL643t9eugzHm6GMaeXtxFVCgHEvYHJwSQ%40mail.gmail.com?utm_

Re: Rename salt to mask in CSRF

2020-02-19 Thread Ram Rachum 
In any case, if it's decided that it's a worthwhile change, I'll be happy
to make the patch.

On Wed, Feb 19, 2020 at 10:31 AM Adam Johnson  wrote:

> The wikipedia page says:
>
> In cryptography, a salt is random data that is used as an additional input
>> to a one-way function that hashes data, a password or passphrase. Salts are
>> used to safeguard passwords in storage.
>
>
> Ram is right - this variable is not a salt in that definition. We aren't
> using a one-way hash function, but a reversible rotational cipher function.
> The 'salt' is really the key/mask/one-time-pad to that cipher function.
>
> I think "mask" and "unmask" are more correct terms to use in the code and
> docstrings. Not sure if it's worth the effort to change though
>
>
> On Wed, 19 Feb 2020 at 06:39, Matemática A3K 
> wrote:
>
>>
>>
>> On Tue, Feb 18, 2020 at 3:31 AM Ram Rachum  wrote:
>>
>>> Hi guys,
>>>
>>> Recently I was working with Django's CSRF protection, customizing it to
>>> my needs, and discussing with co-workers exactly how it works and how it
>>> has protection against the BREACH attack being used to retrieve the CSRF
>>> key.
>>>
>>
>> https://github.com/django/django/pull/11919#issuecomment-549000592
>>
>>
>>> Relevant code here:
>>> https://github.com/django/django/blob/master/django/middleware/csrf.py#L45
>>>
>>> One point of confusion is the use of the term salt in Django's source
>>> code. People expect salt to mean the same as salt in the database, that
>>> works quite differently and doesn't mask the actual secret.
>>>
>>> I'm not a security expert so I may be wrong, but I think that "One-time
>>> pad", "XOR mask" or just "mask" would be more accurate terms.
>>>
>>> I propose to change the "salt" to "mask" everywhere these terms appear
>>> in the CSRF code, and similarly "unsalt" to "unmask". As far as I know this
>>> wouldn't affect functionality at all, because the term "salt" doesn't
>>> appear in actual tokens.
>>>
>>> What do you think?
>>>
>>
>> I think the term is accurate in the domain -
>> https://en.wikipedia.org/wiki/Salt_(cryptography) - no need to rename it.
>>
>>
>>>
>>> Ram.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-developers+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/3cf02beb-e292-4991-b75e-2f3f6e28d371%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/3cf02beb-e292-4991-b75e-2f3f6e28d371%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CA%2BFDnhKZdF2QbSy9cL643t9eugzHm6GMaeXtxFVCgHEvYHJwSQ%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CA%2BFDnhKZdF2QbSy9cL643t9eugzHm6GMaeXtxFVCgHEvYHJwSQ%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>
>
> --
> Adam
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/SokWmLcIkds/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM1Q8zicOH_PvZcSsXGM1fjhVZ2Yq5K6%3D6JT43XG5zqu1Q%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM1Q8zicOH_PvZcSsXGM1fjhVZ2Yq5K6%3D6JT43XG5zqu1Q%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANXboVbEVQ0d2TmzuKhqDt8t0iQtbgdfdD9MCT7g396ESGaHbw%40mail.gmail.com.

Rename salt to mask in CSRF

2020-02-18 Thread Ram Rachum 
Hi guys,

Recently I was working with Django's CSRF protection, customizing it to my 
needs, and discussing with co-workers exactly how it works and how it has 
protection against the BREACH attack being used to retrieve the CSRF key.

Relevant code 
here: https://github.com/django/django/blob/master/django/middleware/csrf.py#L45

One point of confusion is the use of the term salt in Django's source code. 
People expect salt to mean the same as salt in the database, that works 
quite differently and doesn't mask the actual secret.

I'm not a security expert so I may be wrong, but I think that "One-time 
pad", "XOR mask" or just "mask" would be more accurate terms.

I propose to change the "salt" to "mask" everywhere these terms appear in 
the CSRF code, and similarly "unsalt" to "unmask". As far as I know this 
wouldn't affect functionality at all, because the term "salt" doesn't 
appear in actual tokens.

What do you think? 


Ram.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3cf02beb-e292-4991-b75e-2f3f6e28d371%40googlegroups.com.

Re: Use "raise from" where appropriate, all over the codebase

2020-02-08 Thread Ram Rachum 
FYI: I opened a thread on Python-ideas where we continued the discussion on
my `raise as` proposal, Shai's proposal, etc.:
https://mail.python.org/archives/list/python-id...@python.org/thread/KM7NRNFZHALOBKJUXVYQL2SLDP3MAANW/

On Fri, Feb 7, 2020 at 1:16 PM Ram Rachum  wrote:

>
>
> On Fri, Feb 7, 2020 at 12:23 PM Carlton Gibson 
> wrote:
>
>> > I'm basing it on the fact that Carlton approved this PR for the style
>> guide: https://github.com/django/django/pull/12350
>>
>> No. I don't think we should merge that change. (It's "approved" qua
>> itself before reviewing, and dependent on the main PR.)
>>
>> To be clear. I think the default implicit chaining should be used unless
>> there's specific reason not to.
>>
>> (In hindsight I should have come to this conclusion before agreeing to
>> the original smaller cleanup.)
>>
>> C.
>>
>
> I understand. Hypothetical question: If the syntax was `raise as
> NewException`, without having to give the old exception a name, would that
> change your decision?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANXboVZKMnnGFEGXdK7Yw0u8QAeiNCWH_n_%2BDqaFXbwKji5MOQ%40mail.gmail.com.

Re: Use "raise from" where appropriate, all over the codebase

2020-02-07 Thread Ram Rachum 
On Fri, Feb 7, 2020 at 12:23 PM Carlton Gibson 
wrote:

> > I'm basing it on the fact that Carlton approved this PR for the style
> guide: https://github.com/django/django/pull/12350
>
> No. I don't think we should merge that change. (It's "approved" qua itself
> before reviewing, and dependent on the main PR.)
>
> To be clear. I think the default implicit chaining should be used unless
> there's specific reason not to.
>
> (In hindsight I should have come to this conclusion before agreeing to the
> original smaller cleanup.)
>
> C.
>

I understand. Hypothetical question: If the syntax was `raise as
NewException`, without having to give the old exception a name, would that
change your decision?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANXboVayH%2BmwUGgAwX1b4BgDp2T7FtAPO5bfYnkY9gf%2BVy3AgA%40mail.gmail.com.

Re: Use "raise from" where appropriate, all over the codebase

2020-02-07 Thread Ram Rachum 
On Fri, Feb 7, 2020 at 12:27 AM Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello Ram,
>
> On 6 Feb 2020, at 19:08, Ram Rachum  wrote:
>
> In other words, "raise from" is the inevitable future, it's just that
> we're not in a rush to get there.
>
>
> I'm not sure how you came to this conclusion; I'm not seeing this in
> Carlton's and Mariusz' answers.
>

I'm basing it on the fact that Carlton approved this PR for the style
guide: https://github.com/django/django/pull/12350

I'm not sure though whether he intends to merge it.

In any case, I think it'll be sad if people will just get used to
misleading exception chaining messages.

Shai Berger wrote:
> > > it's very rare to have a legitimate exception
> > > without a "raise from" inside an except clause. In almost any
> > > context in which "during handling of..." is correct, the raising is
> > > done deeper in the stack.
> > >
> I think the conclusion should be to ask for a change in Python, not
> Django. The rule "if an exception is raised explicitly from an except
> clause then it is considered raised-from" seems simple enough to me.

That's an interesting idea, but there are 2-3 problems with it that make it
close to impossible.

An alternative suggestion would be to allow syntax that automatically sets
the cause to be the last-caught exception. I would suggest the `raise as`
syntax, which was one of the rejected alternatives in PEP 409
<https://www.python.org/dev/peps/pep-0409/#alternatives> for a different
usecase

try:
1/0

except ZeroDivisionError:

raise as ValueError('Whatever')

My suggestion is that this `raise as` line would have the same effect as
`raise ValueError('Whatever') from zero_division_error`, while also
preventing the need to add `as zero_division_error` in the line above.

I think this solves most of the problems with the previous suggestion. What
do you think? Want to write a PEP together? :)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANXboVbzHfPVc8uB4nmjy8UzEJBCFYfahKEKt2PcMc3dV3PvPA%40mail.gmail.com.

Re: Use "raise from" where appropriate, all over the codebase

2020-02-06 Thread Ram Rachum 
Hi guys,

I'm disappointed that you're against this change... But I understand that
you have a different perspective. Here's my last-ditch effort to convince
you.

If I understand correctly, you both agree that using "raise from" in this
context is better than using plain raise, just that the benefits are not
worth the price of a bulk update to Django. In other words, "raise from" is
the inevitable future, it's just that we're not in a rush to get there.

Keep in mind that the thing I care about is not just usage of "raise from"
in Django, but in any Python package which is relevant. Most Python
developers don't know about this difference between "During the handling
of" and "The above exception was the direct cause", because "raise from"
isn't that prevalent yet. This is a chicken-and-egg problem, because as
long as project maintainers don't use "raise from", the exception chaining
wouldn't show the correct text, and people would get used to the fact that
they can't rely on this text to be correct.

Like any chicken-and-egg problem of changing people's habits, the best we
could hope is to move it forward at a glacial pace-- A situation somewhat
similar to the move to Python 3. If Django were to adopt this practice, it
would help in getting other projects to do that too, and for people to pay
attention to that line of text.


Thanks,
Ram.

On Thu, Feb 6, 2020 at 4:48 PM Mariusz Felisiak 
wrote:

> I agree with Carlton, I don't see much (if any) value in the bulk update.
>
> Best,
> Mariusz
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/ibEOt3A9c2M/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/ab6abbb0-f651-4271-b84c-a3bacaba9482%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/ab6abbb0-f651-4271-b84c-a3bacaba9482%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANXboVaNK7YrWohu8jDcJCG3h43ngHqUqYOCxShV8W_O8rj8pw%40mail.gmail.com.

Re: Use "raise from" where appropriate, all over the codebase

2020-01-22 Thread Ram Rachum 
I made a pull request for the style guide if anyone would like to review:
https://github.com/django/django/pull/12350

On Mon, Jan 20, 2020 at 6:05 PM Ram Rachum  wrote:

> Jon: That's awesome! I also liked R101. I didn't think of that.
>
> Adam: I thought so too, but after going over dozens of R100 cases, I
> didn't find even one where a raise without "from" inside an except clause
> was justified. I challenge you to show me even one such example.
>
> On Mon, Jan 20, 2020 at 12:06 PM Adam Johnson  wrote:
>
>> Nice work Jon. I don't think we can generally apply R100 though - thre
>> are definitely cases where "raise" inside an exception handler is not
>> *caused* by the other exception - but maybe that's a sign refactoring is
>> needed.
>>
>> On Sun, 19 Jan 2020 at 22:52, Jon Dufresne 
>> wrote:
>>
>>>
>>> > I think it's rare enough that personally, I would have liked to have a
>>>> > Flake8 / PyLint rule like that enforces it, and allow ignoring it
>>>> > with a comment. (As much as I hate Lint ignore comments.)
>>>>
>>>> That makes sense. And you know, flake8 supports plugins... a couple of
>>>> web searches and "pip search flake8 | grep {raise,from,chain}" didn't
>>>> pull anything which seems relevant, but if so, it can be written.
>>>>
>>>
>>> As a weekend project, I wrote a flake8 plugin to handle this at:
>>> https://pypi.org/project/flake8-raise/
>>>
>>> I'm not advocating this necessarily included by the Django test suite,
>>> but it can be used to review the PR. Either way, it was fun to write.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-developers+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/CADhq2b4m40efQkorgji9-erXri9qSAb1VJBv%3DZ3HrOL6ksOJAQ%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/django-developers/CADhq2b4m40efQkorgji9-erXri9qSAb1VJBv%3DZ3HrOL6ksOJAQ%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>>
>>
>> --
>> Adam
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANXboVbjPhmAK-p%3DCmNACu%2BX5bnLt7gW7X9wVBXJvQSdHnLvsg%40mail.gmail.com.

Re: Use "raise from" where appropriate, all over the codebase

2020-01-20 Thread Ram Rachum 
Jon: That's awesome! I also liked R101. I didn't think of that.

Adam: I thought so too, but after going over dozens of R100 cases, I didn't
find even one where a raise without "from" inside an except clause was
justified. I challenge you to show me even one such example.

On Mon, Jan 20, 2020 at 12:06 PM Adam Johnson  wrote:

> Nice work Jon. I don't think we can generally apply R100 though - thre are
> definitely cases where "raise" inside an exception handler is not *caused*
> by the other exception - but maybe that's a sign refactoring is needed.
>
> On Sun, 19 Jan 2020 at 22:52, Jon Dufresne  wrote:
>
>>
>> > I think it's rare enough that personally, I would have liked to have a
>>> > Flake8 / PyLint rule like that enforces it, and allow ignoring it
>>> > with a comment. (As much as I hate Lint ignore comments.)
>>>
>>> That makes sense. And you know, flake8 supports plugins... a couple of
>>> web searches and "pip search flake8 | grep {raise,from,chain}" didn't
>>> pull anything which seems relevant, but if so, it can be written.
>>>
>>
>> As a weekend project, I wrote a flake8 plugin to handle this at:
>> https://pypi.org/project/flake8-raise/
>>
>> I'm not advocating this necessarily included by the Django test suite,
>> but it can be used to review the PR. Either way, it was fun to write.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CADhq2b4m40efQkorgji9-erXri9qSAb1VJBv%3DZ3HrOL6ksOJAQ%40mail.gmail.com
>> 
>> .
>>
>
>
> --
> Adam
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANXboVYGg33WfP0jLWNPkKLBeL49gnbf%3DP5BM12NUPNzMeNJyg%40mail.gmail.com.

Re: Use "raise from" where appropriate, all over the codebase

2020-01-18 Thread Ram Rachum 
On Sat, Jan 18, 2020 at 5:05 PM Shai Berger  wrote:

> [snip]

But as it turns out, `from` puts the
> original exception on the `__cause__` in *addition* to `__context__`:
>
> [snip]
> So that is not a concern.
>

Awesome! I did not know that.



> > Regarding automatically enforcing this format going forward: I looked
> > at the list of Flake8 rules  and
> > couldn't find anything about it.
> >
>
> Indeed, I don't think there can be -- it cannot be a style violation to
> run into an error while handling another error...
>

I think it can be, as it's very rare to have a legitimate exception without
a "raise from" inside an except clause. In almost any context in which
"during handling of..." is correct, the raising is done deeper in the stack.

I think it's rare enough that personally, I would have liked to have a
Flake8 / PyLint rule like that enforces it, and allow ignoring it with a
comment. (As much as I hate Lint ignore comments.)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANXboVYxb%2BMeOHp%3De4gzqroKWkHzLjeGXy55qJyRLQQVcUPrWg%40mail.gmail.com.

Re: Use "raise from" where appropriate, all over the codebase

2020-01-18 Thread Ram Rachum 
Hi Uri,

All the files were edited manually by me. I used a crude regex to find the
relevant locations: "except .{3,100}raise"

I bet that there are a few cases that my regex didn't cover, but it
probably covered 90%, so we can first decide whether we want this change,
and later worry about the other 10%.

‪On Sat, Jan 18, 2020 at 2:37 PM ‫אורי‬‎  wrote:‬

> Ram,
>
> I noticed that 100 files changed in this commit. Did you edit each file
> manually before you committed, or was it some script doing it for you?
>
> If it was a script or program, can I see it?
>
> Uri.
> אורי
> u...@speedy.net
>
>
> On Sat, Jan 18, 2020 at 11:55 AM Ram Rachum  wrote:
>
>> Hi guys,
>>
>> I recently made a big ticket/PR to Django, and Shai Berger told me I
>> should first talk about it in this mailing list.
>>
>> This is the ticket: https://code.djangoproject.com/ticket/31177 and its
>> PR: https://github.com/django/django/pull/12339
>>
>> It's a generalization of this ticket that I opened and wrote a patch for
>> a few days ago: https://code.djangoproject.com/ticket/31166 It was
>> discussed and merged.
>>
>> Basically, I think that in any place where we catch an exception, and
>> then wrap it with our own exception for whatever reason, we should use the
>> "raise new_exception from old_exception" syntax rather than just "raise
>> new_exception".
>>
>> This means that when Python displays the stacktrace (and when we display
>> it in the debug page,) this will make it have a text of "this exception is
>> the direct result of" instead of "During handling of the above exception,
>> another exception occurred". This is more accurate, because the latter
>> basically means "there was an error in the process of error-handling,"
>> which is absolutely not the case for us, and could mislead a user.
>>
>> Note that we already started transitioning to "raise from", slowly:
>>  - Commit by Mariusz Felisiak:
>> https://github.com/django/django/commit/84dcd1624784c2239f96a97b3151145a85dfbbe3
>>  - Commit by Diederik van der Boor:
>> https://github.com/django/django/commit/25f21bd2376603c8e233a0a0e5a726a0fdfdd33e
>>  - Commit by Thomas Allison:
>> https://github.com/django/django/commit/3e8b7333904f1ab6aa18eeb508659256f3644816
>>
>> What do you think?
>>
>>
>> Thanks,
>> Ram.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/25086cdc-24ab-4f0a-bdb9-9756551ac170%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/25086cdc-24ab-4f0a-bdb9-9756551ac170%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/ibEOt3A9c2M/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CABD5YeHpYTz06M4ywKKmGB8P%3DAhj6Sv3P7K7%3DjB%3DYpCz6wpxLQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CABD5YeHpYTz06M4ywKKmGB8P%3DAhj6Sv3P7K7%3DjB%3DYpCz6wpxLQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANXboVaYugrK3V19GEK0BWmUDOFVsvpiwNDuWr9wKcswQGeQHg%40mail.gmail.com.

Re: Use "raise from" where appropriate, all over the codebase

2020-01-18 Thread Ram Rachum 
Hi Tom and Adam,

I do agree that Python's chained exceptions can be confusing. Of course,
when you really need that exception information to troubleshoot something,
it's an absolute godsend. In any case, the way Python chains exceptions
when showing them is orthogonal to this proposed change. Python already
displays the exceptions chained even if we don't use "raise from", the only
thing that "raise from" changes is the text that Python puts between the 2
chained exceptions.

Regarding automatically enforcing this format going forward: I looked at
the list of Flake8 rules <https://www.flake8rules.com/> and couldn't find
anything about it.

On Sat, Jan 18, 2020 at 12:57 PM Adam Johnson  wrote:

> Agree with Tom here.
>
> Is there anything we can do to control the way python displays them?
>
> And how would we ensure the format is kept going forwards? Is there a
> flake8 rule/plugin we could activate to enforce it?
>
> On Sat, 18 Jan 2020 at 10:23, Tom Forbes  wrote:
>
>> I agree with this change from a correctness standpoint but I would like
>> to make the point that chained exceptions might be slightly annoying when
>> displayed via console output, as you see the inner exception first and have
>> to scroll up to see the exception you actually have to handle.
>>
>> Tom
>>
>> On 18 Jan 2020, at 09:55, Ram Rachum  wrote:
>>
>> 
>>
>> Hi guys,
>>
>> I recently made a big ticket/PR to Django, and Shai Berger told me I
>> should first talk about it in this mailing list.
>>
>> This is the ticket: https://code.djangoproject.com/ticket/31177 and its
>> PR: https://github.com/django/django/pull/12339
>>
>> It's a generalization of this ticket that I opened and wrote a patch for
>> a few days ago: https://code.djangoproject.com/ticket/31166 It was
>> discussed and merged.
>>
>> Basically, I think that in any place where we catch an exception, and
>> then wrap it with our own exception for whatever reason, we should use the
>> "raise new_exception from old_exception" syntax rather than just "raise
>> new_exception".
>>
>> This means that when Python displays the stacktrace (and when we display
>> it in the debug page,) this will make it have a text of "this exception is
>> the direct result of" instead of "During handling of the above exception,
>> another exception occurred". This is more accurate, because the latter
>> basically means "there was an error in the process of error-handling,"
>> which is absolutely not the case for us, and could mislead a user.
>>
>> Note that we already started transitioning to "raise from", slowly:
>>  - Commit by Mariusz Felisiak:
>> https://github.com/django/django/commit/84dcd1624784c2239f96a97b3151145a85dfbbe3
>>  - Commit by Diederik van der Boor:
>> https://github.com/django/django/commit/25f21bd2376603c8e233a0a0e5a726a0fdfdd33e
>>  - Commit by Thomas Allison:
>> https://github.com/django/django/commit/3e8b7333904f1ab6aa18eeb508659256f3644816
>>
>> What do you think?
>>
>>
>> Thanks,
>> Ram.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/25086cdc-24ab-4f0a-bdb9-9756551ac170%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/25086cdc-24ab-4f0a-bdb9-9756551ac170%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/74BA6A05-D971-47EF-A0B6-4EF1149E83E6%40tomforb.es
>> <https://groups.google.com/d/msgid/django-developers/74BA6A05-D971-47EF-A0B6-4EF1149E83E6%40tomforb.es?utm_medium=email_source=footer>
>> .
>>
> --
> Adam
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-

Use "raise from" where appropriate, all over the codebase

2020-01-18 Thread Ram Rachum 
Hi guys,

I recently made a big ticket/PR to Django, and Shai Berger told me I should 
first talk about it in this mailing list.

This is the ticket: https://code.djangoproject.com/ticket/31177 and its PR: 
https://github.com/django/django/pull/12339

It's a generalization of this ticket that I opened and wrote a patch for a 
few days ago: https://code.djangoproject.com/ticket/31166 It was discussed 
and merged.

Basically, I think that in any place where we catch an exception, and then 
wrap it with our own exception for whatever reason, we should use the 
"raise new_exception from old_exception" syntax rather than just "raise 
new_exception".

This means that when Python displays the stacktrace (and when we display it 
in the debug page,) this will make it have a text of "this exception is the 
direct result of" instead of "During handling of the above exception, 
another exception occurred". This is more accurate, because the latter 
basically means "there was an error in the process of error-handling," 
which is absolutely not the case for us, and could mislead a user.

Note that we already started transitioning to "raise from", slowly:
 - Commit by Mariusz Felisiak: 
https://github.com/django/django/commit/84dcd1624784c2239f96a97b3151145a85dfbbe3
 - Commit by Diederik van der Boor: 
https://github.com/django/django/commit/25f21bd2376603c8e233a0a0e5a726a0fdfdd33e
 - Commit by Thomas Allison: 
https://github.com/django/django/commit/3e8b7333904f1ab6aa18eeb508659256f3644816

What do you think? 


Thanks,
Ram.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/25086cdc-24ab-4f0a-bdb9-9756551ac170%40googlegroups.com.

Re: Using `SECRET_KEY` in password hashers

2015-06-09 Thread Ram Rachum 
On Tue, Jun 9, 2015 at 9:56 AM, Curtis Maloney <cur...@acommoncreative.com>
wrote:

> So, the benefit of your case is it's one more step for an attacker if they
> want to brute-force your password database -- that they _also_ need to
> steal your PASSWORD_SECRET.
>
> The downside is, in the very case where they _do_ steal it, you must
> immediately invalidate every password by changing your PASSWORD_SECRET.
> Which at least gives you a simple knob for doing just that, but may not be
> desirable.
>

"you must immediately invalidate": Well, you don't have to. If you don't,
you still get the protection that you have with the password-specific hash,
which is exactly what Django has today. In other words, when this system
breaks, it becomes as secure as Django's current solution.


>
> IIRC you should be able to easily implement this as a custom password
> hasher...
>

Yep, that's true.


>
> --
> C
>
>
> On 9 June 2015 at 16:01, Ram Rachum <r...@rachum.com> wrote:
>
>> If the leak happened because someone got into your code repo, you're
>> right. (I can't rule out a scenario where someone got your SECRET_KEY with
>> some other method, like analyzing data that was generated with the secret
>> key.)
>>
>> But even if there's a leak, then you're in a situation not worse than
>> where we are today. Since you're still using a random salt in addition to
>> the SECRET_KEY and you're using a hash function that takes non-negligible
>> time. So best-case scenario, passwords become harder to crack, worst-case
>> scenario, they're as hard to crack as they are with the current
>> implementation. So isn't this an improvement?
>>
>> On Tue, Jun 9, 2015 at 8:55 AM, Shai Berger <s...@platonix.com> wrote:
>>
>>> On Tuesday 09 June 2015 08:23:03 Ram Rachum wrote:
>>> > On Tue, Jun 9, 2015 at 8:22 AM, Curtis Maloney <
>>> cur...@acommoncreative.com>
>>> > wrote:
>>> > > On 9 June 2015 at 15:16, Ram Rachum <ram.rac...@gmail.com> wrote:
>>> > >>
>>> > >> What do you think about using the project's `SECRET_KEY` as an
>>> > >> additional salt in Django's password hashers?
>>> >
>>> > > I think it'd royally screw you over if you ever had to change your
>>> secret
>>> > > key [due to suspected leak, for example] as now all your passwords
>>> are
>>> > > invalid.
>>> > >
>>> > Okay, so how about if we use a separate secret?
>>> >
>>>
>>> How is it different? If you suspect a leak that forces you to change the
>>> secret
>>> key, wouldn't you be forced to change this secret as well?
>>>
>>> Shai.
>>>
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CANXboVavc8o3HZ%3DuP54PaD9CYgV25S8gPjBLfJhoBJSLSKtwKA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/django-developers/CANXboVavc8o3HZ%3DuP54PaD9CYgV25S8gPjBLfJhoBJSLSKtwKA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/fuJ5mbl8X5E/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAG_XiSDFPjTX%3DwxXz%2BFc5wrwC02YCmy3w5JNobDpa9gk9wx1gw%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAG_XiSDFPjTX%3DwxXz%2BFc5wrwC02YCmy3w5JNobDpa9gk9wx1gw%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANXboVaawF%2BYm8h3CBrU7EY29XS__d2QJoqrjhYAO5dzYoxKKg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using `SECRET_KEY` in password hashers

2015-06-09 Thread Ram Rachum 
If the leak happened because someone got into your code repo, you're right.
(I can't rule out a scenario where someone got your SECRET_KEY with some
other method, like analyzing data that was generated with the secret key.)

But even if there's a leak, then you're in a situation not worse than where
we are today. Since you're still using a random salt in addition to the
SECRET_KEY and you're using a hash function that takes non-negligible time.
So best-case scenario, passwords become harder to crack, worst-case
scenario, they're as hard to crack as they are with the current
implementation. So isn't this an improvement?

On Tue, Jun 9, 2015 at 8:55 AM, Shai Berger <s...@platonix.com> wrote:

> On Tuesday 09 June 2015 08:23:03 Ram Rachum wrote:
> > On Tue, Jun 9, 2015 at 8:22 AM, Curtis Maloney <
> cur...@acommoncreative.com>
> > wrote:
> > > On 9 June 2015 at 15:16, Ram Rachum <ram.rac...@gmail.com> wrote:
> > >>
> > >> What do you think about using the project's `SECRET_KEY` as an
> > >> additional salt in Django's password hashers?
> >
> > > I think it'd royally screw you over if you ever had to change your
> secret
> > > key [due to suspected leak, for example] as now all your passwords are
> > > invalid.
> > >
> > Okay, so how about if we use a separate secret?
> >
>
> How is it different? If you suspect a leak that forces you to change the
> secret
> key, wouldn't you be forced to change this secret as well?
>
> Shai.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANXboVavc8o3HZ%3DuP54PaD9CYgV25S8gPjBLfJhoBJSLSKtwKA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using `SECRET_KEY` in password hashers

2015-06-08 Thread Ram Rachum 
Okay, so how about if we use a separate secret?

On Tue, Jun 9, 2015 at 8:22 AM, Curtis Maloney <cur...@acommoncreative.com>
wrote:

> I think it'd royally screw you over if you ever had to change your secret
> key [due to suspected leak, for example] as now all your passwords are
> invalid.
>
> --
> Curtis
>
>
> On 9 June 2015 at 15:16, Ram Rachum <ram.rac...@gmail.com> wrote:
>
>> Hi,
>>
>> What do you think about using the project's `SECRET_KEY` as an additional
>> salt in Django's password hashers? The advantage would be that they'll be
>> harder to crack, as an attacker would need access both to the database
>> table and the code for the secret key. The disadvantage I can think of is
>> that you couldn't change your `SECRET_KEY` without breaking old passwords
>> (so maybe we need a separate secret in the settings.)
>>
>> What do you think?
>>
>>
>> Thanks,
>> Ram.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/617aecb6-3156-49d1-859a-f55efb9f54f2%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/617aecb6-3156-49d1-859a-f55efb9f54f2%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/fuJ5mbl8X5E/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAG_XiSAS2o1EMSn5HQd-60Q2KutQ5uUUmYORQxsZeVM8rWbWpQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAG_XiSAS2o1EMSn5HQd-60Q2KutQ5uUUmYORQxsZeVM8rWbWpQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANXboVYME4BKs-vQwyV3i-P4CqfX8juLtMwKuNeuss5pFELM1g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Using `SECRET_KEY` in password hashers

2015-06-08 Thread Ram Rachum 
Hi,

What do you think about using the project's `SECRET_KEY` as an additional 
salt in Django's password hashers? The advantage would be that they'll be 
harder to crack, as an attacker would need access both to the database 
table and the code for the secret key. The disadvantage I can think of is 
that you couldn't change your `SECRET_KEY` without breaking old passwords 
(so maybe we need a separate secret in the settings.) 

What do you think? 


Thanks,
Ram.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/617aecb6-3156-49d1-859a-f55efb9f54f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why can't templates access properties

2015-05-27 Thread Ram Rachum 
Created: https://code.djangoproject.com/ticket/24863#ticket

On Wed, May 27, 2015 at 2:56 AM, Curtis Maloney <cur...@acommoncreative.com>
wrote:

> Feel free to open a ticket, as it will give a place to retain the
> discussion.
>
> Perhaps start with the use case for having additional properties on a
> QuerySet :)
>
> --
> Curtis
>
> On 27 May 2015 at 07:14, Ram Rachum <ram.rac...@gmail.com> wrote:
>
>> I found the cause of my problem: `django.db.models.Manager.from_queryset`
>> copies all the methods from the `QuerySet` class to the `Manager` class,
>> but it doesn't copy the properties.
>>
>> What do you think about opening an issue for
>> making `django.db.models.Manager.from_queryset` copy over properties as
>> well?
>>
>>
>> On Tuesday, May 26, 2015 at 10:19:25 PM UTC+3, Tim Graham wrote:
>>>
>>> Accessing properties in templates should work as far as I know. Maybe
>>> there is an error in your application.
>>>
>>> On Tuesday, May 26, 2015 at 2:27:40 PM UTC-4, Ram Rachum wrote:
>>>>
>>>> Hi,
>>>>
>>>> I noticed that when I use variables in Django templates that access
>>>> object properties, it doesn't work. (e.g. I have {{ foo.bar }} while bar is
>>>> a Python property.)
>>>>
>>>> See the documentation for variables in Django templates:
>>>>
>>>> https://docs.djangoproject.com/en/1.8/ref/templates/language/#variables
>>>>
>>>> It indeed doesn't mention properties.
>>>>
>>>> Why should properties not work through template? I can't think of a
>>>> good reason.
>>>>
>>>>
>>>> Thanks,
>>>> Ram.
>>>>
>>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/7188bfd5-632d-4333-868f-180540a8193c%40googlegroups.com
>> <https://groups.google.com/d/msgid/django-developers/7188bfd5-632d-4333-868f-180540a8193c%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/e6SOZNs0GVU/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAG_XiSCa5%3DS3JNyJ0zNwBAmkObj9%2B3oyOeKUE_1a8yYu7%3DgoNA%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAG_XiSCa5%3DS3JNyJ0zNwBAmkObj9%2B3oyOeKUE_1a8yYu7%3DgoNA%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANXboVaq%2BsW3MmCirheR_NQPyDnyPst7a_9xAQTxkK3fkkc80g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Why can't templates access properties

2015-05-26 Thread Ram Rachum 
I found the cause of my problem: `django.db.models.Manager.from_queryset` 
copies all the methods from the `QuerySet` class to the `Manager` class, 
but it doesn't copy the properties.

What do you think about opening an issue for 
making `django.db.models.Manager.from_queryset` copy over properties as 
well? 

On Tuesday, May 26, 2015 at 10:19:25 PM UTC+3, Tim Graham wrote:
>
> Accessing properties in templates should work as far as I know. Maybe 
> there is an error in your application.
>
> On Tuesday, May 26, 2015 at 2:27:40 PM UTC-4, Ram Rachum wrote:
>>
>> Hi,
>>
>> I noticed that when I use variables in Django templates that access 
>> object properties, it doesn't work. (e.g. I have {{ foo.bar }} while bar is 
>> a Python property.)
>>
>> See the documentation for variables in Django templates:
>>
>> https://docs.djangoproject.com/en/1.8/ref/templates/language/#variables
>>
>> It indeed doesn't mention properties.
>>
>> Why should properties not work through template? I can't think of a good 
>> reason. 
>>
>>
>> Thanks,
>> Ram.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7188bfd5-632d-4333-868f-180540a8193c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Why can't templates access properties

2015-05-26 Thread Ram Rachum 
Hi,

I noticed that when I use variables in Django templates that access object 
properties, it doesn't work. (e.g. I have {{ foo.bar }} while bar is a 
Python property.)

See the documentation for variables in Django templates:

https://docs.djangoproject.com/en/1.8/ref/templates/language/#variables

It indeed doesn't mention properties.

Why should properties not work through template? I can't think of a good 
reason. 


Thanks,
Ram.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b453d6a3-a35e-408c-962c-7c742c72a218%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A general way to batch SQL queries in Django

2015-02-28 Thread Ram Rachum 
Hi everyone,

Thank you for your answers.

Arkade: You mentioned transactions. I believe they're not relevant here
because every read is still executed synchronously (i.e. Django process
waits for database to respond.)

Tom: Thank you for understanding what I'm looking for :)

You said "The only way I could see it having any non-marginal effect is if
you have high latency to your database server. But then you have a lot
of problems."
Well, I'm using Heroku, so a database query that takes 1ms on my local dev
machine takes 3ms there, presumably because on my dev machine the database
is running on the same machine as the Django server, where in Heroku the
database is on a separate machine. I think that many other people are in
the same scenario, so allowing to do multiple queries in the same roundtrip
would be helpful to many people.

Here is what I'm currently thinking about: Can we make Django do multiple
separate queries (SQL queries are separated by a semicolon right? Sorry for
being a noob) and send them one after another before blocking on reading
any of them? Only then when everything is sent, start reading and
populating querysets. *Is this possible to do with Django?*


Thanks for your help,
Ram Rachum.

On Sat, Feb 28, 2015 at 12:40 AM, Michael Manfre <mman...@gmail.com> wrote:

> Stored procedures, at least with MSSQL, provide another way of returning
> multiple result sets with a single SQL statement. The queries will be
> parsed and executed faster due to stored procedures being parsed and
> compiled when created, instead of when executed. A stored procedure will
> also allow you to get more complex results with a few simple queries,
> instead of a single complex query.
>
> Using stored procedures adds complexity to a Django project and should be
> used sparingly. From my personal experience, the extra server resources to
> have more instances running to service requests is usually better than
> having the extra complexity of using stored procedures in a Django project.
>
> Regards,
> Michael Manfre
>
> On Fri, Feb 27, 2015 at 2:46 PM, Tom Evans <tevans...@googlemail.com>
> wrote:
>
>> On Fri, Feb 27, 2015 at 3:19 PM, aRkadeFR <cont...@arkade.info> wrote:
>> > What do you mean by a single roundtrip?
>>
>> He means asking the database server to consider multiple queries
>> (concurrently?), and return data once all of them are available. In
>> pseudo code:
>>
>> people, jobs, cities = DB.fetch_multi(
>> Person.objects.all(),
>> Job.objects.all(),
>> City.objects.all())
>>
>> MySQL's C API supports executing multiple SQL statements in a single
>> round trip, the data sets are made available in turn to the client API
>>
>> http://dev.mysql.com/doc/refman/5.7/en/c-api-multiple-queries.html
>>
>> however, each statement is executed in turn, not concurrently, so the
>> only speed up you would have is that there is only one query to parse,
>> and a few small packets less sent to the database server... The
>> database connection is not torn down between requests to the database.
>>
>> The only way I could see it having any non-marginal effect is if you
>> have high latency to your database server. But then you have a lot of
>> problems.
>>
>> Cheers
>>
>> Tom
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers  (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CAFHbX1%2BMgfwHL%3DL8hjgRMyf%2B2-Rap9L01PF9cxERFqU6c8uHdA%40mail.gmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/3Lk-HEF16iI/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAGdCwBuxXXST

Re: A general way to batch SQL queries in Django

2015-02-27 Thread Ram Rachum 
Thank you for the explanation. I still wonder though: you asked what the
result set would look like, given it's two different tables. What I want is
multiple result sets, but in only one roundtrip. Is it possible to send
multiple SQL queries to the database in one roundtrip? We'd need the second
query to use information from the first for the session usecase, but even
if we can't use the information from the first query, it'll still be useful
for other cases.

Is it possible to send multiple queries in a single roundtrip?

Sent from my phone.
On Feb 27, 2015 4:13 PM, "Josh Smeaton" <josh.smea...@gmail.com> wrote:

> The concept of batched SELECT statements doesn't really exist in SQL,
> unless the relations you're selecting have identical column types. Example:
>
> SELECT name, age_in_years FROM person
> UNION ALL
> SELECT item_name, quantity FROM item;
>
> The UNION here means combine the results of each query into the one result
> set. A query like this probably isn't useful though, because you have no
> way of knowing which row belongs to which relation (or model). UNION
> queries are useful for specific kinds of queries, not as a general purpose
> batch method.
>
> Can you see the issue with trying to batch queries that aren't exactly the
> same?
>
> SELECT a, b FROM T1
> UNION ALL
> SELECT d, e, f from T2;
>
> What would the result set look like if this was possible?
>
> Your example of session and user could be made to use a single query if
> the session had a foreign key to the user table. It doesn't though, because
> you don't *need* users for sessions to work. This is why django has to
> parse the session data to determine whether or not it has to load a user
> object.
>
> To answer your questions, no, django doesn't let you batch up multiple
> select statements. It can't, because that's not how SQL works. Connection
> pooling should help reduce the initialisation time of creating the
> connection, and multiple select statements can be sent over that single
> connection though, which is the closest you're going to get.
>
> Regards,
>
> On Friday, 27 February 2015 23:14:05 UTC+11, Ram Rachum wrote:
>>
>> Hi guys,
>>
>> After asking this question on django-users:
>>
>> https://groups.google.com/forum/#!topic/django-users/EuPduHjSNos
>>
>> And in several other forums, and not finding a solution, I've reached a
>> conclusion: It would be really helpful to allow batching SQL queries in
>> Django. I should preface by saying I'm not very good at SQL and I don't
>> know how the ORM works exactly, so maybe what I'm saying is wrong in some
>> way, if so please correct me.
>>
>> I know Django already support bulk insertion, but what I want is to make
>> multiple SQL reads, of various kinds, and have them populate multiple model
>> instances. This is important for lowering the number of database roundtrips
>> that Django does.
>>
>> I gave one example for when this need arises in the above link; another
>> example is how on every request, Django fetches the session, it then parses
>> the session, looks for the user ID, and then fetches the user. This is a
>> waste. If Django could do a combined query that fetches both the session
>> and the user in SQL, this would be best. I'm not good at SQL, so I'm not
>> sure whether it can be done. But that's just one example of where you can
>> save a roundtrip to the database.
>>
>> Am I right that Django doesn't currently let you do that? Do you think
>> it's possible to make Django do that?
>>
>>
>> Thanks,
>> Ram.
>>
>>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/3Lk-HEF16iI/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/a888777b-de4c-4ef6-b351-afc620601f64%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/a888777b-de4c-4ef6-b351-afc620601f64%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from

A general way to batch SQL queries in Django

2015-02-27 Thread Ram Rachum 
Hi guys,

After asking this question on django-users:

https://groups.google.com/forum/#!topic/django-users/EuPduHjSNos

And in several other forums, and not finding a solution, I've reached a 
conclusion: It would be really helpful to allow batching SQL queries in 
Django. I should preface by saying I'm not very good at SQL and I don't 
know how the ORM works exactly, so maybe what I'm saying is wrong in some 
way, if so please correct me.

I know Django already support bulk insertion, but what I want is to make 
multiple SQL reads, of various kinds, and have them populate multiple model 
instances. This is important for lowering the number of database roundtrips 
that Django does.

I gave one example for when this need arises in the above link; another 
example is how on every request, Django fetches the session, it then parses 
the session, looks for the user ID, and then fetches the user. This is a 
waste. If Django could do a combined query that fetches both the session 
and the user in SQL, this would be best. I'm not good at SQL, so I'm not 
sure whether it can be done. But that's just one example of where you can 
save a roundtrip to the database.

Am I right that Django doesn't currently let you do that? Do you think it's 
possible to make Django do that? 


Thanks,
Ram.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d111bd3b-3ca7-426d-83a1-047e9f56c641%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea about authentication

2013-10-03 Thread Ram Rachum 
Hi everybody,

I've submitted the patch, and corrected it, and it's been sitting on the
issue tracker for 2 weeks without anyone commenting. Does anyone care to
discuss this? I want to have this merged in, or discuss any problems in
merging it in.


On Sun, Sep 15, 2013 at 11:27 PM, Ram Rachum <ram.rac...@gmail.com> wrote:

> Submitted patch:
>
> https://code.djangoproject.com/ticket/21105#comment:1
>
> On Sunday, September 15, 2013 10:09:55 PM UTC+3, Donald Stufft wrote:
>
>>
>> On Sep 15, 2013, at 2:59 PM, Florian Apolloner <f.apo...@gmail.com>
>> wrote:
>>
>> Hi Ram,
>>
>> On Sunday, September 15, 2013 12:34:03 PM UTC+2, Ram Rachum wrote:
>>>
>>> Florian, I'm not sure that you read my message carefully enough. I'm *not
>>> *proposing to reduce the time that PBKDF2  takes to hash.
>>>
>>
>> By replacing the password with a hash before running it through PBKDF2
>> you are reducing that time for every password longer than the hash… And
>> given the way PBKDF2 works you'll reduce it by quite a bit (note that all
>> of this only applies to passwords longer than the hash, so it's probably
>> pretty academical). Either way, we'd at least need a new hasher class since
>> it would be backwards incompatible. Independent of that we'd have to
>> evaluate if pre-hashing the password could make  PBKDF2 less secure
>> (probably not to likely, but who knows).
>>
>>
>> According to Thomas Porin in the context of bcrypt pre-hashing the
>> password is fine (and we already do this in Django 1.6). I see no reason
>> the same wouldn't hold true for PBKDF2.
>>
>> -
>> Donald Stufft
>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
>> DCFA
>>
>>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/iuSE5Y4R3hg/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CANXboVazQU4bF_vBtD4y0vxq54mkcjrR-ZaFknmpuyJrFRHMEw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Idea about authentication

2013-09-15 Thread Ram Rachum 
Submitted patch:

https://code.djangoproject.com/ticket/21105#comment:1

On Sunday, September 15, 2013 10:09:55 PM UTC+3, Donald Stufft wrote:
>
>
> On Sep 15, 2013, at 2:59 PM, Florian Apolloner 
> <f.apo...@gmail.com> 
> wrote:
>
> Hi Ram,
>
> On Sunday, September 15, 2013 12:34:03 PM UTC+2, Ram Rachum wrote:
>>
>> Florian, I'm not sure that you read my message carefully enough. I'm *not 
>> *proposing to reduce the time that PBKDF2  takes to hash.
>>
>
> By replacing the password with a hash before running it through PBKDF2 you 
> are reducing that time for every password longer than the hash… And given 
> the way PBKDF2 works you'll reduce it by quite a bit (note that all of this 
> only applies to passwords longer than the hash, so it's probably pretty 
> academical). Either way, we'd at least need a new hasher class since it 
> would be backwards incompatible. Independent of that we'd have to evaluate 
> if pre-hashing the password could make  PBKDF2 less secure (probably not to 
> likely, but who knows).
>
>
> According to Thomas Porin in the context of bcrypt pre-hashing the 
> password is fine (and we already do this in Django 1.6). I see no reason 
> the same wouldn't hold true for PBKDF2.
>
> -
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 
> DCFA 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Idea about authentication

2013-09-15 Thread Ram Rachum 
Florian, I'm not sure that you read my message carefully enough. I'm *not 
*proposing 
to reduce the time that PBKDF2 takes to hash. I'm proposing to keep that 
time just as long, but make it independent on the password length.

On Sunday, September 15, 2013 1:12:31 PM UTC+3, Florian Apolloner wrote:
>
>
>
> On Sunday, September 15, 2013 11:45:29 AM UTC+2, Ram Rachum wrote:
>
>> What if instead of calculating the PBKDF2 hash of the password, we'll 
>> calculate the PBKDF2 hash of its SHA1 hash? Then the time of checking 
>> passwords wouldn't depend on their length, and we wouldn't even have to 
>> place a limit of 4096 characters on passwords-- An attacker could try a 
>> 1MB-long password but it would slow us down the same amount as trying 
>> "123456" would. 
>>
>
> PBKDF2 takes long by design… A better long term solution would be to rate 
> limit password attempts…
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Idea about authentication

2013-09-15 Thread Ram Rachum 
Thanks Curtis!

I thought about my idea and realized it makes a brute-force attack easier, 
and we'd have to make the hashing stronger to compensate... Making the 
computation time longer for the real users logging in... So yeah, it won't 
help.

But then I had another idea. So PBKDF2 takes a longer time to calculate for 
longer passwords. Maybe the solution is to fix that? That would be more 
elegant than limiting passwords to 4096 (because then dos attackers can 
still attack using 4096-long passwords, and while not as slow as 
megabytes-long password, it's still slow.)

What if instead of calculating the PBKDF2 hash of the password, we'll 
calculate the PBKDF2 hash of its SHA1 hash? Then the time of checking 
passwords wouldn't depend on their length, and we wouldn't even have to 
place a limit of 4096 characters on passwords-- An attacker could try a 
1MB-long password but it would slow us down the same amount as trying 
"123456" would. 

What do you think? 

On Sunday, September 15, 2013 12:25:32 PM UTC+3, Curtis Maloney wrote:
>
> Actually, you'd just speed up their attack, since most failed attempts 
> would be quicker than others.
>
> If you look in the crypto utils, you'll see a "constant time compare" ... 
> this is a common thing in crypto circles to avoid leaking "how close" the 
> guess was by how quickly the mismatch was found.
>
> This is a class of "side channel attach"... worth reading up on if you 
> want to get further into crypto: 
> http://en.wikipedia.org/wiki/Side_channel_attack
>
> --
> Curtis
>
>
>
> On 15 September 2013 19:00, Ram Rachum <ram.r...@gmail.com 
> >wrote:
>
>> Hi guys,
>>
>> I just saw the new release announcement and I had an idea.
>>
>> What if, in addition to sorting the hard to compute hash for every 
>> password, we will also store the sha 1 hash of the first 5 characters ofthe 
>> password's sha1 hash? Wouldn't this allow us to quickly rule out 99% of 
>> passwords, thereby defending against dos attacks, while atthe same time not 
>> letting an attacker who obtained the hashes to get the passwords?
>>
>> I'm not a security expert, just brainstorming.
>>
>> Thanks,
>> Ram.
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@googlegroups.com
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Idea about authentication

2013-09-15 Thread Ram Rachum 
Hi guys,

I just saw the new release announcement and I had an idea.

What if, in addition to sorting the hard to compute hash for every password, we 
will also store the sha 1 hash of the first 5 characters ofthe password's sha1 
hash? Wouldn't this allow us to quickly rule out 99% of passwords, thereby 
defending against dos attacks, while atthe same time not letting an attacker 
who obtained the hashes to get the passwords?

I'm not a security expert, just brainstorming.

Thanks,
Ram.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Why not switch hasher when number of iterations changes?

2013-03-18 Thread Ram Rachum 
Wonderful, thank you!


On Mon, Mar 18, 2013 at 10:59 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> On 18 mars 2013, at 21:51, Ram Rachum <ram.rac...@gmail.com> wrote:
>
> > Why does Django switch to the new hasher only if the algorithm was
> changed, and not if the number of iterations (which could be critical)
> changed?
>
> See https://code.djangoproject.com/ticket/19043.
>
> --
> Aymeric.
>
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/0MYBpHOyZGE/unsubscribe?hl=en
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Why not switch hasher when number of iterations changes?

2013-03-18 Thread Ram Rachum 
Look at this code:

https://github.com/django/django/blob/master/django/contrib/auth/hashers.py#L55

Why does Django switch to the new hasher only if the algorithm was changed, 
and not if the number of iterations (which could be critical) changed?


Thanks,
Ram.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Can you confirm Stack Overflow answer about `.exists()`?

2013-01-18 Thread Ram Rachum 
It's done more like explaining a side-effect than explaining the *purpose* of
the method. It shouldn't be "notice that when you use `exists`, it has the
following effects on efficiency", but "`exists`'s entire purpose is to get
higher efficiency in situations where you don't want to access the data."


On Fri, Jan 18, 2013 at 6:08 PM, Javier Guerra Giraldez
<jav...@guerrag.com>wrote:

> On Fri, Jan 18, 2013 at 10:58 AM, Ram Rachum <r...@rachum.com> wrote:
> > I suggest copying your explanation into the documentation.
>
> it's already there:
>
> " This means that calling QuerySet.exists() is faster than
> bool(some_query_set), but not by a large degree. If some_query_set has
> not yet been evaluated, but you know that it will be at some point,
> then using some_query_set.exists() will do more overall work (one
> query for the existence check plus an extra one to later retrieve the
> results) than simply using bool(some_query_set), which retrieves the
> results and then checks if any were returned."
>
> [
> https://docs.djangoproject.com/en/1.4/ref/models/querysets/#django.db.models.query.QuerySet.exists
> ]
>
>
> --
> Javier
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Can you confirm Stack Overflow answer about `.exists()`?

2013-01-18 Thread Ram Rachum 
Thanks Carl!

I suggest copying your explanation into the documentation.


Thanks,
Ram.


On Fri, Jan 18, 2013 at 5:26 PM, Carl Meyer <c...@oddbird.net> wrote:

> Hi Ram,
>
> On 01/18/2013 06:25 AM, Ram Rachum wrote:
> > Can someone who's familiar with Django internals please confirm or deny
> > the following answer to my question?
> >
> > http://stackoverflow.com/a/14369747/76701
>
> That answer is correct. A common situation for evaluating a queryset in
> a boolean context is that you're about to use the results if there are
> any, in which case it's more efficient to fetch all the data right away
> rather than doing a COUNT query and then a second query to fetch all the
> data.
>
> The only time "exists()" is more efficient is when _all_ you want is to
> know whether there are any matching rows; you're not going to do
> anything with the rows themselves.
>
> When the existence-check is just a path on the way to the "real" use of
> the queryset, you can be quick and implicit; when the existence check is
> all that you care about, you say so explicitly by using "exists()".
>
> Carl
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Can you confirm Stack Overflow answer about `.exists()`?

2013-01-18 Thread Ram Rachum 
Can someone who's familiar with Django internals please confirm or deny the 
following answer to my question?

http://stackoverflow.com/a/14369747/76701


Thanks,
Ram.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/wK7fQ1q_SsYJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Python 3 port - all tests now pass on 2.7.2 and 3.2.2 with the same codebase

2011-12-09 Thread Ram Rachum 
In which Django release are we hoping to release this port? 1.4 or 1.5?


Ram.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/Y8-2tS9lth4J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

how to save image in postgreSQL database

2011-05-19 Thread Ram 
Hello everyone i am new to python and Django learning it for college
project in which i want to save image in postgreSQL database which i
am sending from my URL, please help me with that i will be thankful to
all of you

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.