Re: Rename salt to mask in CSRF

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, i

Re: Rename salt to mask in CSRF

#x27;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

Rename salt to mask in CSRF

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/mast

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

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: > > >

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

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

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

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 t

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

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 benef

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

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 g

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

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 1

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

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 go

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

> > 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. >>

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

lightly 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: >> >>  >>

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

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 ope

Re: Using `SECRET_KEY` in password hashers

d > hasher... > Yep, that's true. > > -- > C > > > On 9 June 2015 at 16:01, Ram Rachum 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 w

Re: Using `SECRET_KEY` in password hashers

are with the current implementation. So isn't this an improvement? On Tue, Jun 9, 2015 at 8:55 AM, Shai Berger 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: >

Re: Using `SECRET_KEY` in password hashers

Curtis > > > On 9 June 2015 at 15:16, Ram Rachum 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,

Using `SECRET_KEY` in password hashers

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 i

Re: Why can't templates access properties

a > QuerySet :) > > -- > Curtis > > On 27 May 2015 at 07:14, Ram Rachum 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 proper

Re: Why can't templates access properties

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: >> >&g

Why can't templates access properties

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/#variabl

Re: A general way to batch SQL queries in Django

his possible to do with Django?* Thanks for your help, Ram Rachum. On Sat, Feb 28, 2015 at 12:40 AM, Michael Manfre 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 execute

Re: A general way to batch SQL queries in Django

ple 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-user

A general way to batch SQL queries in Django

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 sayi

Re: Idea about authentication

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,

Re: Idea about authentication

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 > > > wrote: > > Hi Ram, > > On Sunday, September 15, 2013 12:34

Re: Idea about authentication

orian 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 would

Re: Idea about authentication

f "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 >wrote: > >> Hi guys, >> >> I just saw the new re

Idea about authentication

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, t

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

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 wrote: > > > Why does Django switch to the new hasher only if the algorithm was > changed, and not if the number

Why not switch hasher when number of iterations changes?

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 beca

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

e you don't want to access the data." On Fri, Jan 18, 2013 at 6:08 PM, Javier Guerra Giraldez wrote: > On Fri, Jan 18, 2013 at 10:58 AM, Ram Rachum wrote: > > I suggest copying your explanation into the documentation. > > it's already there: > > " This me

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

Thanks Carl! I suggest copying your explanation into the documentation. Thanks, Ram. On Fri, Jan 18, 2013 at 5:26 PM, Carl Meyer wrote: > Hi Ram, > > On 01/18/2013 06:25 AM, Ram Rachum wrote: > > Can someone who's familiar with Django internals please confirm or de

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

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

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

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 po