Re: argon2 PasswordHasher

[Bas Westerbaan]

Hynek weighted in[1].  I think the PR is ready to merge.

Best wishes,

  Bas


[1] https://github.com/django/django/pull/5876#issuecomment-168411156

> On 27 Dec 2015, at 13:39, Florian Apolloner  wrote:
> 
> I do not see anything wrong in the PR and there is probably no reason not to 
> include it. It would be great if you could get feedback from dstufft and/or 
> hynek in #cryptography-dev -- not that we miss something.
> 
> Cheers,
> Florian
> 
> On Sunday, December 27, 2015 at 12:36:02 AM UTC+1, Bas Westerbaan wrote:
> Hello,
> 
> This morning I submitted a Pull Request[1], which adds a PasswordHasher for 
> argon2 – the winner of the Password Hashing Competition.[2]  Tim Graham 
> mentioned I should send an e-mail to this list to discuss it.
> 
> The patch is mostly pretty straight-forward.  I would like to add a few 
> remarks on some of the choices.
> 
> 1. There are two Python packages that implement argon2.  Both bind 
> libargon2[3].  The first is argon2_py[4], which uses ctypes.  The second is 
> argon2-cffi[5], which uses... cffi.  Bindings using cffi are more portable, 
> so I choose argon2-cffi.
> 
> 2. argon2 has four parameters: (i) variety ("type"), (ii) time cost ("t"), 
> (iii) memory cost ("m") and (iv) parallelism ("p").  There are two varieties: 
> argon2i and argon2d.  The first (argon2i) is safest against side-channel 
> attacks.  The second tries less hard to be secure against side-channel 
> attacks in favour of being more resilient against GPU brute-forcing.  For 
> web-apps, the first "argon2i" is the clear choice.  For the other parameters 
> I choose to use the same defaults as of argon2-cffi: t=2, m=512, p=2.  On a 
> i7-4790 @ 3.6Ghz the hash takes around 2ms to compute.
> 
> Best wishes,
> 
>   Bas
> 
> 
> 
> [1] https://github.com/django/django/pull/5876 
> 
> [2] https://password-hashing.net 
> [3] https://github.com/p-h-c/phc-winner-argon2 
> 
> [4] https://github.com/flamewow/argon2_py 
> 
> [5] https://github.com/hynek/argon2_cffi 
> 
> 
> -- 
> 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/NTfqP4eNVyA/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 https://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/9a3378d2-3a8b-4bd9-b1e0-d64e25475d02%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/12EFBCDD-B66A-4B50-906C-286A3574472F%40westerbaan.name.
For more options, visit https://groups.google.com/d/optout.

URL dispatching framework: feedback requested

[Marten Kenbeek]

A quick question: Aymeric suggested to merge django.conf.urls into django.urls 
as well. Does anyone think we should not make this move?

If no one disagrees, I will proceed with a new PR to make the move.

-- 
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/5e7d285c-ac2d-459e-92cd-25587d57b9ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Support for auto fields can be set by database triggers or default column values instead of django

[Owais Lone]

Hi, I'm trying to add support for auto-fields to django. By auto-fields, I 
mean fields that django skips during INSERT or UPDATE and let's the 
database assign a value. I'm using an existing ticket to track this: 
https://code.djangoproject.com/ticket/21454#comment:21

A working PR is present at: https://github.com/django/django/pull/5904

I would really appreciate if someone could take a look at it and guide me 
in the right direction.

Thanks

- Owais Lone
loneow...@gmail.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/373c16b1-5eaa-4b0d-87a5-83256f30694e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: structural & functional review of django documentation

[Doug Epling]

Hello Aymeric --

Yes indeed, I misunderstood.  Thank you for lining things out for me.  
Loosely, the group I am talking about is the group of a couple thousand who 
completed that survey in the first 48 hours.  It would be great to know why 
a lot of those ~2000 folks feel so stongly and positive about the 
documentation.  I don't know how to organize this.  With all due respect, I 
was hoping the mechanism you outlined could kick-in to facillitate this.

As for other thread in my proposal, the way I would approach this would be 
on a foundation of the mass media research of Phillip Palmgreen with 'uses 
and gratification' theory which is rooted deeply in Fishbein's 
'expectancy-value' theory with perhaps some Charles Osgood thrown in for 
good measure.  All this stuff is from the eighty's -- possibly somewhat 
out-of-date.  So, you are a mathematician, huh?  How are your statistics?  

And this might be some kind of non sequitur, but in any case, I looked at 
the text files from GitHub that comprise our published documentation.  I am 
attaching two files.  One is a list of words used 50 or more times.  I 
don't know how words like 'youll' made it in there, but a lot of these 
words are good candidates for the Glossary.  Also, enclosed is another file 
listing the file sources for these words.

Thanks again,

On Saturday, January 2, 2016 at 4:51:15 AM UTC-5, Aymeric Augustin wrote:
>
> On 2 janv. 2016, at 05:48, Doug Epling > 
> wrote: 
>
> > First is, has been, a discussion open for spectators but limited 
> participants to core members.  Asside from its subject pertaining current 
> state and future path, all other details are above my pay grade. 
>
> Hi Doug, 
>
> I’m afraid there’s a misunderstanding of how this community operates. 
>
> "Team members” — we de-emphazised the “core dev” terminology in 2014 
> because it over-valued writing code — are people who have made consistent, 
> constructive contributions to Django, usually starting small and then 
> moving on to more ambitious projects. Albeit slow, this process is the best 
> way we have found for new contributors to gain trust from existing 
> contributors. 
>
> There needs to be some mechanism to give a consistent direction to the 
> Django project. Currently we have two layers of decision: community 
> consensus and technical board arbitration vote. Obviously voices of team 
> members matter more in community discussions. We hope that’s because of 
> their experience with Django and the quality of what they say, not just 
> because they carry a “team member” flag. Arbitration votes almost never 
> happen. (There was only one, ever, to drop support for IE8 from the admin.) 
>
> In practice, team members tend to have busy professional lives outside of 
> Django. This has stalled many projects in the past. For this reason we 
> structured our organization in order to empower community members as much 
> as possible and to require as little input from the Django team as 
> possible. 
>
> We wouldn’t find a core-only conversation nearly as useful as a 
> community-wide discussion. Perhaps that’s why core panels have fallen out 
> of fashion at DjangoCons during the last couple of years. And we definitely 
> don’t want contributors to censor themselves because of perceived pay 
> grade. 
>
> The only pre-requisite to tackling massive projects such as “let’s 
> restructure the whole documentation” is to have built enough trust from the 
> current team for everyone to know that you will complete it in good 
> conditions. Building that trust requires completing successfully small 
> projects, then increasingly large ones. Team membership may be offered at 
> some point in that process. 
>
> I hope this helps, 
>
> -- 
> Aymeric. 
>
>

-- 
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/676fbf93-acee-4c23-8444-a4c2d93b0ca3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
base.txt, signing.txt, database-functions.txt, generic-editing.txt, 
admindocs.txt, sql.txt, modwsgi.txt, email.txt, admin.txt, api.txt, 
flatpages.txt, index.txt, distributions.txt, middleware.txt, 
mixins-single-object.txt, commands.txt, forms-api.txt, 
conditional-expressions.txt, coding-style.txt, organization.txt, relations.txt, 
deployment.txt, custom-management-commands.txt, design-philosophies.txt, 
howto-release-django.txt, widgets.txt, mixins2.txt, actions.txt, 
api-stability.txt, utils2.txt, custom-file-storage.txt, tutorial01.txt, 
install2.txt, submitting-patches.txt, lookups2.txt, install.t

Re: structural & functional review of django documentation

[Doug Epling]

Hello Aymeric --

Yes indeed, I misunderstood.  Thank you for lining things out for me.  
Loosely, the group I am talking about is the group of a couple thousand who 
completed that survey in the first 48 hours.  It would be great to know why 
a lot of those ~2000 folks feel so stongly and positive about the 
documentation.  I don't know how to organize this.  With all due respect, I 
was hoping the mechanism you outlined could kick-in to facillitate this.

As for other thread in my proposal 
, the way I would approach 
this would be on a foundation of the mass media research of Phillip 
Palmgreen with 'uses and gratification' theory which is rooted deeply in 
Fishbein's 'expectancy-value' theory with perhaps some Charles Osgood 
thrown in for good measure.  All this stuff is from the eighty's -- 
possibly somewhat out-of-date.  So, you are a mathematician, huh?  How are 
your statistics?  

And this might be some kind of non sequitur, but in any case, I looked at 
the text files from GitHub that comprise our published documentation.  I am 
attaching two files.  One is a list of words used 50 or more times.  I 
don't know how words like 'youll' made it in there, but a lot of these 
words are good candidates for the Glossary.  Also, enclosed is another file 
listing the file sources for these words.

Thanks again,

On Saturday, January 2, 2016 at 4:51:15 AM UTC-5, Aymeric Augustin wrote:
>
> On 2 janv. 2016, at 05:48, Doug Epling > 
> wrote: 
>
> > First is, has been, a discussion open for spectators but limited 
> participants to core members.  Asside from its subject pertaining current 
> state and future path, all other details are above my pay grade. 
>
> Hi Doug, 
>
> I’m afraid there’s a misunderstanding of how this community operates. 
>
> "Team members” — we de-emphazised the “core dev” terminology in 2014 
> because it over-valued writing code — are people who have made consistent, 
> constructive contributions to Django, usually starting small and then 
> moving on to more ambitious projects. Albeit slow, this process is the best 
> way we have found for new contributors to gain trust from existing 
> contributors. 
>
> There needs to be some mechanism to give a consistent direction to the 
> Django project. Currently we have two layers of decision: community 
> consensus and technical board arbitration vote. Obviously voices of team 
> members matter more in community discussions. We hope that’s because of 
> their experience with Django and the quality of what they say, not just 
> because they carry a “team member” flag. Arbitration votes almost never 
> happen. (There was only one, ever, to drop support for IE8 from the admin.) 
>
> In practice, team members tend to have busy professional lives outside of 
> Django. This has stalled many projects in the past. For this reason we 
> structured our organization in order to empower community members as much 
> as possible and to require as little input from the Django team as 
> possible. 
>
> We wouldn’t find a core-only conversation nearly as useful as a 
> community-wide discussion. Perhaps that’s why core panels have fallen out 
> of fashion at DjangoCons during the last couple of years. And we definitely 
> don’t want contributors to censor themselves because of perceived pay 
> grade. 
>
> The only pre-requisite to tackling massive projects such as “let’s 
> restructure the whole documentation” is to have built enough trust from the 
> current team for everyone to know that you will complete it in good 
> conditions. Building that trust requires completing successfully small 
> projects, then increasingly large ones. Team membership may be offered at 
> some point in that process. 
>
> I hope this helps, 
>
> -- 
> Aymeric. 
>
>

-- 
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/00f54342-b056-4b8d-8165-c921777cc11d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
404
ability
able
abstract
accept
accepted
accepts
access
according
account
action
actions
actually
add
added
adding
addition
additional
address
adds
admin
aggregate
algorithm
alias
allow
allowed
allows
already
also
always
another
anything
apache
api
app
appear
application
applications
applied
apply
appropriate
apps
arent
args
argument
arguments
around
article
associated
attribute
attributes
authentication
author
authors
automatically
availability
available
avoid
aware
back
backend
backends
bar
base
based
basic
becomes
behavior
best
better
block
blog
book
bo

Re: structural & functional review of django documentation

[Doug Epling]

Hi Ned --

That is an excellent point! There was some back-and-forth about bread crumbs.  
It would be awesome if we not only implemented that, but used it to track 
user's progress through the docs, and collect this info.

Thanks,

-- 
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/da51873a-7606-4c69-8788-c3e97471ce17%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: structural & functional review of django documentation

[Scot Hacker]

The written quality of the Django docs has been a selling point for years, 
but discoverability has never been great. I wanted to add two notes:

1) The front page of the docs says docs are organized into four sections 
(Tutorials, Topic Guides, Reference Guides,  How-To Guides). And it's been 
proposed that we add a fifth docstring-generated API Reference as well. But 
remember that most people looking to solve a problem under deadline start 
with search, not taxonomy. Search results do *seem* to be labeled with the 
section of the docs they come from, but the sections referenced don't 
 actually correspond to the four sections we say use!  If I search for 
"forms" I get results that claim to come from "API Reference," "Using 
Django," "Release Notes," which don't match the names of our four sections. 
 I propose that A) search results clearly indicate the doc sections that we 
claim we use for organization; B) Search results be grouped by type (e.g. 
show all results from Using Django first, followed by all results from API 
Reference)... or whatever. Or a user could use checkboxes to select which 
section of the docs they want to search. Or faceted search results so users 
can quickly toggle or filter the sources of the search results? There are a 
lot of ways to solve this - just pointing out that our search experiences 
could be  sharper and more customizable.

2) I've encountered a number of situations where search didn't help because 
I didn't yet know enough to search for the right thing. I remember early in 
my Django experience trying to figure out how to have a "global variable" 
for my project and that search string not turning up what I needed to 
know... because what I really should have been searching for was "context 
processors".* I think we could make strides in search-ability through the 
indication of a tagging system. Tags could either be controlled through 
commits, or dynamic (users could tag topics on the fly, and a weighting 
system would apply to search results). 

* Even today, searching the docs for "context processor" does not take me 
quickly to a clean example of how to implement a context processor - I 
really have to dig for this information. 

./s

-- 
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/da7ae84d-7696-4705-b8a3-115c9ec40b94%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.