Re: Provide a simpler way to default runserver IP/port to 0.0.0.0:8000

[Shai Berger]

I am -1 on adding a setting to handle a use-case that can be handled by users 
with a 6-line file:

On Monday 28 November 2016 16:05:39 Shai Berger wrote:
> 
> It seems all you need in the overridden runserver is:
> 
> from (...)runserver import Command as BaseCommand
> 
> class Command(BaseCommand):
>   def handle(self, *args, **options):
>   options.setdefault('addrport', '0.0.0.0:8000')
>   super(Command, self).handle(*args, **options)
> 
> What am I missing?

Re: Methodology for increasing the number of PBKDF2 iterations

[Martin Koistinen]

Tobias,

Thanks for the comprehensive benchmarking and summary of the situation! I 
agree on all points, but I'd like to add, that we should err on the side of 
high iterations for the simple fact that most developers would sooner 
accept the risk of a DoS long before the risk of compromised user accounts.

Also, if a developer is experienced/motivated enough to *lower* the hash 
iterations, s/he'll be more likely to also be experienced/motivated enough 
to put other controls in place to compensate.


Best,
- Martin

On Sunday, January 15, 2017 at 5:45:02 PM UTC-5, Tobias McNulty wrote:
>
> I'm not sure the DoS concern is really something that can be addressed 
> here. Regardless of the number of iterations we choose, POSTing to the 
> login form will always be a target, unless it's appropriately protected 
> (i.e., with some combination of rate limiting, recaptcha, and/or something 
> at the network level). A run-of-the-mill cloud server that doesn't limit 
> access to the Python app in some way is simply never going to be a match 
> for a malicious person with a laptop, let alone a more sophisticated attack.
>
> I created a tox.ini 
> 
>  to 
> run Martin's benchmark with multiple Django & Python versions. A couple 
> notes:
>
>- I ran this several times on Circle CI using Ubuntu 12.04 
> 
>with Python 2.7.7, 3.3.3, 3.4.3, and 3.5.0, and Ubuntu 14.04 
> 
>with 2.7.12, 3.3.6, 3.4.4, and 3.5.2. To view the results, expand the 
> "tox" 
>section under the "Test" header.
>- All results are what one would expect: Python 2.7.7 and Python 3.3.x 
>are ~3-4x slower than Python 2.7.8+ and Python 3.4+, and there are no 
>inexplicably slow outliers, like the official Python 3.5.2 installer for 
> OS 
>X.
>
> My local results are as follows:
>
>- Ubuntu 16.04 w/a Core i5 @ 3.50GHz:
>   - 62-65ms for 100,000 iterations
>   - 100-106ms for 165,000 iterations
>- Mac OS 10.12, Core i5 @ 2.7GHz:
>   - 117-120ms for 100,000 iterations
>   - 195-203ms for 165,000 iterations
>
> I really don't know how we can pick a number that'll work for everyone, 
> but I'm all for setting it high and allowing people to decrease the number 
> of iterations or, better yet, switch to the hasher that the docs 
> recommend everyone use anyway 
> 
>  
> (Argon2). If we define 100-120ms as acceptable performance, 100k would seem 
> reasonable based on the results above and posted elsewhere in this thread.
>
> Martin, FWIW, I can confirm that the Python 3.5.2 installer from 
> python.org demonstrates the same 3x slower behavior on my Mac that you 
> saw. The Python 3.5.2 I installed from Homebrew does not, nor does the 
> official python.org installer for Python 3.6. Based on the absence of any 
> similar outliers in the above tests, however, I still think the conclusion 
> here should be to fix the underlying Python build (if it's really creating 
> a performance issue for you or anyone else), not hold back Django from 
> bumping its default number of PBKDF2 iterations. Dropping Python 2.7 
> support still means we lose a large swath of definitely-slow PBKDF2 
> implementations: 24.4% of installs where the Python version was known were 
> using 2.7.5 or 2.7.6 in the chart Alex posted.
>
> The point about switching Django's default to Argon2 is an intriguing one. 
> In the event there are still a bunch of slow PBKDF2 implementations out 
> there with Python 3.5+, one benefit of dramatically increasing PBKDF2 
> iterations is that it might push more people to Argon2. :-D On a more 
> serious note, I'll reply separately to that thread to save this one for the 
> original topic.
>
> Tobias
>
> -- 
>
>
> *Tobias McNulty*Chief Executive Officer
>
> tob...@caktusgroup.com 
> www.caktusgroup.com
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2e28907c-0a63-4201-835f-e6a0f141002b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Time based one time password and django ?

[Alexander Dutton]

There's also , which is fairly easy
to integrate into a Django project.

As a long-term user of (but rare contributor to) Django I'd say the ease
of using one of a number of third-party solutions points to keeping it
out of core.

Relatedly, integrating custom auth (i.e. not just username/password)
would be easier if the Django admin site deferred to LOGIN_URL by
default instead of presenting its own login form. An example issue is
when one uses some sort of web server SSO module with
RemoteUserMiddleware, and then the admin site presents asks for a
username and password for already-authenticated non-staff (who have no
local credentials).

Yours,

Alex



On 16/01/17 16:28, Gavin Wahl wrote:
> I have a project that implements TOTP and U2F as a third-party
> package: https://github.com/gavinwahl/django-u2f
> 
> On Sunday, January 15, 2017 at 3:47:56 AM UTC-7, ludovic coues wrote:
> 
> Hello,
> 
> After reading the recent thread on authentification in django, I
> wondered about the chance of getting a 2-step auth mechanism in
> django.contrib.
> 
> Time based one time password, or TOTP, is now part of the RFC 6238.
> For those who don't know it, it use a shared secret and current time
> to produce 6 digit number. That number change every 30 seconds and is
> used to confirm login after entering a correct username and password.
> 
> As far as I can tell, there is no such thing present in django
> currently. But I don't know if it's because nobody have done the  work
> or if there are reason to not include 2-step solution in django.
> 
> -- 
> 
> Cordialement, Coues Ludovic
> +336 148 743 42
> 
> -- 
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/7a3b3837-5c24-4984-abb8-d68d9ce31459%40googlegroups.com
> .
> 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fb94cbfa-5987-4aa7-e74a-6fa53ce05cce%40alexdutton.co.uk.
For more options, visit https://groups.google.com/d/optout.

Re: Time based one time password and django ?

[Gavin Wahl]

I have a project that implements TOTP and U2F as a third-party 
package: https://github.com/gavinwahl/django-u2f

On Sunday, January 15, 2017 at 3:47:56 AM UTC-7, ludovic coues wrote:
>
> Hello, 
>
> After reading the recent thread on authentification in django, I 
> wondered about the chance of getting a 2-step auth mechanism in 
> django.contrib. 
>
> Time based one time password, or TOTP, is now part of the RFC 6238. 
> For those who don't know it, it use a shared secret and current time 
> to produce 6 digit number. That number change every 30 seconds and is 
> used to confirm login after entering a correct username and password. 
>
> As far as I can tell, there is no such thing present in django 
> currently. But I don't know if it's because nobody have done the  work 
> or if there are reason to not include 2-step solution in django. 
>
> -- 
>
> Cordialement, Coues Ludovic 
> +336 148 743 42 
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7a3b3837-5c24-4984-abb8-d68d9ce31459%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Time based one time password and django ?

[Tim Graham]

There is also a ticket: https://code.djangoproject.com/ticket/25612 
"django.contrib.auth should include support for 2fa out of the box".

On Sunday, January 15, 2017 at 6:22:30 AM UTC-5, Florian Apolloner wrote:
>
> Hi,
>
> yes we'd very much like to have 2fa in Django. At the minimum we'd like to 
> support TOTP and U2F. The idea on why exactly those two is relatively 
> simple: They either cost nothing or are low cost and the two are so 
> different that if they both work, most other authentication flows will 
> probably work too.
>
> I am not aware of any prior work for django.contrib. Either way, changes 
> like this will require an idea first and then a DEP (which I'll happily 
> shepard).
>
> Cheers,
> Florian
>
> On Sunday, January 15, 2017 at 11:47:56 AM UTC+1, ludovic coues wrote:
>>
>> Hello, 
>>
>> After reading the recent thread on authentification in django, I 
>> wondered about the chance of getting a 2-step auth mechanism in 
>> django.contrib. 
>>
>> Time based one time password, or TOTP, is now part of the RFC 6238. 
>> For those who don't know it, it use a shared secret and current time 
>> to produce 6 digit number. That number change every 30 seconds and is 
>> used to confirm login after entering a correct username and password. 
>>
>> As far as I can tell, there is no such thing present in django 
>> currently. But I don't know if it's because nobody have done the  work 
>> or if there are reason to not include 2-step solution in django. 
>>
>> -- 
>>
>> Cordialement, Coues Ludovic 
>> +336 148 743 42 
>>
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/850e461c-87bb-4bec-bc47-9fa26609b08a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Check if dependencies are up to date

[Adam Johnson]

Woops I misunderstood the original idea. YPlan's *pip-lock* isn't for
checking if the packages are the latest versions as on PyPI, it just checks
the current virtualenv is in sync with the requirements.txt file(s) that
define it - e.g. if a developer adds a new dependency, the rest of the team
need to install it. For us this boils down to a vagrant provision, so
that's what the message says.

I agree, requires.io is a nice service for this.

On 16 January 2017 at 14:18, James Bennett  wrote:

> On Mon, Jan 16, 2017 at 4:47 AM, Adam Johnson  wrote:
>
>> We implemented something similar at YPlan but discovered that it wasn't a
>> good idea as a system check, because if a dependency changes from another
>> devs work then often Django can't even start and run the system check.
>> Especially a problem when upgrading Django itself! Instead we implemented
>> it as a function that runs in manage.py before Django is even loaded.
>>
>
> On top of this, a cleaner solution is to use a monitoring service (like
> https://requires.io/) to keep track of dependencies and get notified of
> issues (especially useful since those services can break down issues like
> "this is out of date" versus "this has known security issues").
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/ms
> gid/django-developers/CAL13Cg9cqjBa_kyncL-jjOCk57iLbHyV6e7Ae
> fyQTwccQhyQSA%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM1tyPmM7C4n85a7CUmxLskn_tP8NY5C6vLKrO25oZjbJA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Check if dependencies are up to date

[James Bennett]

On Mon, Jan 16, 2017 at 4:47 AM, Adam Johnson  wrote:

> We implemented something similar at YPlan but discovered that it wasn't a
> good idea as a system check, because if a dependency changes from another
> devs work then often Django can't even start and run the system check.
> Especially a problem when upgrading Django itself! Instead we implemented
> it as a function that runs in manage.py before Django is even loaded.
>

On top of this, a cleaner solution is to use a monitoring service (like
https://requires.io/) to keep track of dependencies and get notified of
issues (especially useful since those services can break down issues like
"this is out of date" versus "this has known security issues").

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg9cqjBa_kyncL-jjOCk57iLbHyV6e7AefyQTwccQhyQSA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Check if dependencies are up to date

[Adam Johnson]

>
> I believe this also can be used by Django itself as there are some cases
> where contrib apps override core command functionality (I believe this
> happens for staticfiles app overriding runserver)
>

The signals as proposed can't really be used for the staticfiles override,
since that requires subclassing and wrapping a function to change the
handler ( source

). If there are other use cases I think they'd also normally be better
handled by more specific signals, e.g. post_migrate
,
rather than a generic all-commands signal.

On 16 January 2017 at 12:52, Dmitry Gladkov 
wrote:

> Hello,
>
> While I was reading this email I got an idea about generic Django command
> signals that might be useful for extending command functionality without
> subclassing the Command class and relying on INSTALLED_APPS order.
> Something like this:
>
> from django.core.management.signals import pre_command, post_command
>
> def handle_pre(sender, instance):
> instance.stdout.write('Hello World')
>
> def handle_post(sender, instance):
> instance.stdout.write('Bye World')
>
> pre_command.connect(handle_pre, command='runserver')
> post_command.connect(handle_post, command='runserver')
>
> I believe this also can be used by Django itself as there are some cases
> where contrib apps override core command functionality (I believe this
> happens for staticfiles app overriding runserver)
>
> Should I create a ticket about it?
>
> --
> Best wishes,
> Dmitry Gladkov
>
> On 16 January 2017 at 14:47, Adam Johnson  wrote:
>
>> Hi Mathieu,
>>
>> We implemented something similar at YPlan but discovered that it wasn't a
>> good idea as a system check, because if a dependency changes from another
>> devs work then often Django can't even start and run the system check.
>> Especially a problem when upgrading Django itself! Instead we implemented
>> it as a function that runs in manage.py before Django is even loaded.
>>
>> We open sourced our work as https://github.com/YPlan/pip-lock . Check it
>> out.
>>
>> On Mon, 16 Jan 2017 at 04:18, mathieu.tortuyaux <
>> mathieu.tortuy...@gmail.com> wrote:
>>
>>> Hello everyone,
>>>
>>> I would propose this new Django feature. Now you can check if your
>>> dependencies are up-to-date (e.g with `hypothesis` in attachment picture)
>>> (it runs with Python2.7 && Python3.6).
>>> It is a good habit to check if dependencies are up-to-date, especially
>>> for security reasons.
>>>
>>> I did not find any references about this in Django issues
>>>
>>> So I wondering if I can have any feedback on this ?
>>>
>>> Thank you for taking time to read these words.
>>>
>>> Mathieu Tortuyaux
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>>
>>> 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 https://groups.google.com/group/django-developers.
>>>
>>>
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/django-developers/5a6fb42e-e5c8-4608-9b20-19fc829473b1%
>>> 40googlegroups.com
>>> 
>>> .
>>>
>>>
>>> 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 https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/django-developers/CAMyDDM1CeOVQoH8jN35OwxOJUbhVr99gMtchg
>> FsxbPZXac2tcw%40mail.gmail.com
>> 
>> .
>>
>> 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 

Re: Check if dependencies are up to date

[Dmitry Gladkov]

Hello,

While I was reading this email I got an idea about generic Django command
signals that might be useful for extending command functionality without
subclassing the Command class and relying on INSTALLED_APPS order.
Something like this:

from django.core.management.signals import pre_command, post_command

def handle_pre(sender, instance):
instance.stdout.write('Hello World')

def handle_post(sender, instance):
instance.stdout.write('Bye World')

pre_command.connect(handle_pre, command='runserver')
post_command.connect(handle_post, command='runserver')

I believe this also can be used by Django itself as there are some cases
where contrib apps override core command functionality (I believe this
happens for staticfiles app overriding runserver)

Should I create a ticket about it?

--
Best wishes,
Dmitry Gladkov

On 16 January 2017 at 14:47, Adam Johnson  wrote:

> Hi Mathieu,
>
> We implemented something similar at YPlan but discovered that it wasn't a
> good idea as a system check, because if a dependency changes from another
> devs work then often Django can't even start and run the system check.
> Especially a problem when upgrading Django itself! Instead we implemented
> it as a function that runs in manage.py before Django is even loaded.
>
> We open sourced our work as https://github.com/YPlan/pip-lock . Check it
> out.
>
> On Mon, 16 Jan 2017 at 04:18, mathieu.tortuyaux <
> mathieu.tortuy...@gmail.com> wrote:
>
>> Hello everyone,
>>
>> I would propose this new Django feature. Now you can check if your
>> dependencies are up-to-date (e.g with `hypothesis` in attachment picture)
>> (it runs with Python2.7 && Python3.6).
>> It is a good habit to check if dependencies are up-to-date, especially
>> for security reasons.
>>
>> I did not find any references about this in Django issues
>>
>> So I wondering if I can have any feedback on this ?
>>
>> Thank you for taking time to read these words.
>>
>> Mathieu Tortuyaux
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>>
>> 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 https://groups.google.com/group/django-developers.
>>
>>
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/django-developers/5a6fb42e-e5c8-4608-9b20-
>> 19fc829473b1%40googlegroups.com
>> 
>> .
>>
>>
>> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/django-developers/CAMyDDM1CeOVQoH8jN35OwxOJUbhVr
> 99gMtchgFsxbPZXac2tcw%40mail.gmail.com
> 
> .
>
> 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CA%2BkbqrUn%2BRnpfuO48WSo%2B8rrtxy%3D%2BUyQK%2Btn14ADbN2m5NcGtQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Check if dependencies are up to date

[Adam Johnson]

Hi Mathieu,

We implemented something similar at YPlan but discovered that it wasn't a
good idea as a system check, because if a dependency changes from another
devs work then often Django can't even start and run the system check.
Especially a problem when upgrading Django itself! Instead we implemented
it as a function that runs in manage.py before Django is even loaded.

We open sourced our work as https://github.com/YPlan/pip-lock . Check it
out.

On Mon, 16 Jan 2017 at 04:18, mathieu.tortuyaux 
wrote:

> Hello everyone,
>
> I would propose this new Django feature. Now you can check if your
> dependencies are up-to-date (e.g with `hypothesis` in attachment picture)
> (it runs with Python2.7 && Python3.6).
> It is a good habit to check if dependencies are up-to-date, especially for
> security reasons.
>
> I did not find any references about this in Django issues
>
> So I wondering if I can have any feedback on this ?
>
> Thank you for taking time to read these words.
>
> Mathieu Tortuyaux
>
>
>
>
>
>
>
>
> --
>
>
> 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 https://groups.google.com/group/django-developers.
>
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/5a6fb42e-e5c8-4608-9b20-19fc829473b1%40googlegroups.com
> 
> .
>
>
> 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM1CeOVQoH8jN35OwxOJUbhVr99gMtchgFsxbPZXac2tcw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Switching the default password hasher to Argon2 (was: Methodology for increasing the number of PBKDF2 iterations)

[urijah]

One issue is that as far as I know, only PBKDF2 is officially approved by 
the NIST 
 
for password hashing. Many security standards explicitly or implicitly 
(e.g. "strong cryptography") defer to the NIST, and even if Argon2  is 
theoretically superior, using it can cause compliance/auditing issues.

On Monday, January 16, 2017 at 5:19:27 AM UTC+5:30, Tobias McNulty wrote:
>
> On Thu, Jan 5, 2017 at 10:58 AM, Martin Koistinen  > wrote:
>
>> Slightly off-topic, this presents a really nice case for switching to 
>> Argon2 via argon2_cffi (supported in Django 1.10+). Its super fast (C-lib) 
>> and resistant to GPU/ASIC brute-forcing. So, where as an attacker's 8-GPU 
>> hashing machine would probably have something on the order of 24,000X more 
>> hashing capability for SHA256 than a typical Django server, I estimate that 
>> the same hardware (8 GPUs) would only have about 20-30X more hashing 
>> capability than a typical server. (Note, the anecdotal evidence across the 
>> internet supporting this is pretty thin).
>>
>
> This is an interesting point. Argon2 is recommended over PBKDF2 by OWASP 
> 
>  and 
> even Django itself 
> . 
> From 
> what I understand, the only reason it's *not* the default now is the 3rd 
> party dependency, which does require a C compiler and the libffi library to 
> build, if a wheel isn't available for your OS. In a minimal Python 
> 3.5-alpine Docker image, I needed the following packages before I could 
> `pip install argon2_cffi` (which themselves had a collective ~12 additional 
> dependencies):
>
>- gcc
>- musl-dev (libc headers)
>- libffi
>- libffi-dev
>
> Could anyone familiar with the draft DEP 7: Dependency Policy 
>  
> and/or the addition of the Argon2 hasher 
> 
>  
> comment on the suitability of argon2_cffi (or not) for consideration under 
> DEP 7? I think it meets most if not all of the "maturity" guidelines in the 
> policy, with the one exception being that it presents an interesting test 
> case for the footnote 
> 
>  
> on the "dependencies that require C extensions are *probably* not 
> acceptable" statement. There are wheels available for argon2_cffi on a 
> large number of platforms, but I still had to compile it manually on Alpine 
> Linux (a popular OS for minimal Docker images) and for Python 3.6 on my Mac 
> (there is a wheel available when using Python 3.5 on a Mac).
>
> I have trouble imagining that there are many production Django apps out 
> there that don't compile *something* in their requirements file (e.g., 
> psycopg2 or Pillow), in which case argon2_cffi essentially requires no 
> extra lift. That said, it is pretty incredible that beginners can (still) 
> install Django just about anywhere they have Python without compiling 
> anything at all.
>
> I wonder if there's an alternative to forcibly requiring it, where most 
> users would eventually do so for production use, but had greater 
> flexibility when running locally? Only the security-minded will go through 
> the trouble of changing the default password hasher currently, so ideally 
> users would get a stronger nudge than they do now when it comes time to 
> deploy to production. Making a switch here also has the added benefit of 
> circumventing some of the concerns around increasing PBKDF2 iterations 
>  
> over time.
>
> Tobias
> -- 
>
>
> *Tobias McNulty*Chief Executive Officer
>
> tob...@caktusgroup.com 
> www.caktusgroup.com
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1fca9868-c0a9-45ad-baf9-c09baac11b16%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Check if dependencies are up to date

[mathieu.tortuyaux]

Hello everyone, 

I would propose this new Django feature. Now you can check if your 
dependencies are up-to-date (e.g with `hypothesis` in attachment picture) 
(it runs with Python2.7 && Python3.6).
It is a good habit to check if dependencies are up-to-date, especially for 
security reasons. 

I did not find any references about this in Django issues

So I wondering if I can have any feedback on this ?

Thank you for taking time to read these words. 

Mathieu Tortuyaux

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5a6fb42e-e5c8-4608-9b20-19fc829473b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Switching the default password hasher to Argon2 (was: Methodology for increasing the number of PBKDF2 iterations)

[Josh Smeaton]

Hah, sure, exactly like that! Is it documented?

Yes, yes it 
is. 
https://docs.djangoproject.com/en/1.10/topics/auth/passwords/#using-argon2-with-django

On Monday, 16 January 2017 20:12:23 UTC+11, Florian Apolloner wrote:
>
>
>
> On Monday, January 16, 2017 at 3:56:44 AM UTC+1, Josh Smeaton wrote:
>>
>> I think adding argon2_cffi to extra_requires could be a good idea, so 
>> that users can pip install Django[argon2_cffi]. 
>>
>
> You mean like https://github.com/django/django/blob/master/setup.py#L53 
> *scnr* 
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0111a880-a8b6-4d4a-9ff5-470b2ecdca65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Presenting DCP, a compatibility layer for Django (feedback welcome)

[James Bennett]

On Sun, Jan 15, 2017 at 1:09 PM, Pkl  wrote:

> My bad, if people are guaranteed 2 x 24-month cycles before a feature gets
> removed, it's already much better. However, the same pattern as previously
> appears in docs : "each feature release will continue to have a few
> documented backwards incompatibilities where a deprecation path isn’t
> possible or not worth the cost.". I might be paranoid, but I foresee lots
> of dependency breakages in the future, if incompatibilities continue to be
> introduced at developer's will History proved even seemingly harmless
> django modifications (ex. import aliases removed) broke external code,
> sometimes forcing "commit reverts" in django code.
>

Just to clarify, the future plan -- beginning with Django 2.0, the next
release after 1.11, which is about to feature-freeze -- is:

1. Releases go in a cycle of X.0, X.1, X.2, (X+1).0. So, for example, 2.0,
then 2.1, then 2.2, then 3.0.
2. Each X.2 is an LTS.
3. Code which runs with no deprecation warnings on an LTS will also run
(though may raise deprecation warnings) on the next LTS.
4. Thus, any time you run on an LTS with no deprecation warnings, you know
you're safe to upgrade to the next LTS. And once you clear any new
deprecation warnings on the new LTS, you know you're clear to upgrade to
the one after that.

Regarding backwards-incompatible changes in general: they do happen, but
they also follow the guidelines in the API stability document. When they
occur, it's because there's a security issue or larger bug being solved.
Additionally, many of the seemingly-large list of such changes each release
are, if you dig into them, changes to private/internal or at least
undocumented APIs not covered by the stability policy, but we've learned
people still rely on those APIs and so we document changes to them even if
we don't guarantee stability in them.

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAL13Cg8_0BRpu1b_zz2Dx_YXcLaXGXw8Qw0jfA_uDhaxt%3DD_%3Dw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Switching the default password hasher to Argon2 (was: Methodology for increasing the number of PBKDF2 iterations)

[Florian Apolloner]

On Monday, January 16, 2017 at 3:56:44 AM UTC+1, Josh Smeaton wrote:
>
> I think adding argon2_cffi to extra_requires could be a good idea, so that 
> users can pip install Django[argon2_cffi]. 
>

You mean like https://github.com/django/django/blob/master/setup.py#L53 
*scnr* 

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5d6087d4-e8c5-48eb-8d0e-15f3a7216b5f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Presenting DCP, a compatibility layer for Django (feedback welcome)

[James Pic]

If you've been maintaining several django apps for several versions of
Django (ie. stable, oldstable, lts) then it's pretty easy to imagine how
useful this can be. The deprecation policy removes the need of a
compatibility layer for code that should support only one version of
Django, but does not help maintaining code that should support several
versions of Django, which is a pretty cool challenge if you ask me :P

Thanks for doing this, looking forward to use it to make new django
versions easier to support in apps, keep up the great work B)

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALC3Kafd-0UQxd156YCrt4gnrXsW%3DHoGPcwW-HQm3PLrEW%2BE1Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.