Hi all,
The PR[1] that adds Argon2 as a PasswordHasher is ready to be merged. It does
not make Argon2 the default. The reasons not to make it the default are:
1. Argon2 is young. (Its design, though, is uncontroversial.)
2. Argon2 requires C-bindings and thus does not work on every platform D
Hi all,
Ticket: https://code.djangoproject.com/ticket/26151
PR: https://github.com/django/django/pull/6059
This pull request suggests to rewrite the serialization in the
MigrationWriter to dedicated classes which are then used by a factory
function. The reasoning behind this is to reduce the co
I doubt that serialization support is "feature complete", given some recent
history. I guess it would be nice to have the hook so that users don't have
to wait for the next release of Django.
Django 1.8.1: Added support for serializing datetime.timedelta objects.
Django 1.9: Added support for se
Hi, everyone!
I confirmed this (21608) non critical security bug a while ago and have
sense then made a unit test and a fix for it.
I have not gotten any feedback on my PR yet, is there something more I need
to do to have someone look at this?
Best Regards
Tore Lundqvist
--
You received this
I may not understand the security implications here properly, but as far as
I can tell there isn't a strong enough case that Argon2 is fundamentally
better than PBKDF2 yet? At least no more than people's arguments that
BCrypt is better. I think retaining the simple out of the box experience
where y
I may not understand the security implications here properly, but as far as I can tell there isn't a strong enough case that Argon2 is fundamentally better than PBKDF2 yet?Barring any weakness in Blake2 we do not know about, Argon2 is way better than PBKDF2 as it is memory-hard. The gap between SH
It is once per user, but it's once for *EVERY* user when that scenario
occurs. That could easily bring a site down if sessions were invalidated or
you have short session times. It's far too likely someone will have
serious, hard to debug problems as a result of this magical behaviour.
I also stron
Thanks for feedback. Created ticket for the deprecation:
https://code.djangoproject.com/ticket/26154
On Thursday, January 21, 2016 at 3:06:39 AM UTC-5, Shai Berger wrote:
>
> On Thursday 21 January 2016 09:59:49 Aymeric Augustin wrote:
> > > On 21 janv. 2016, at 07:24, Josh Smeaton > wrote:
>
Hi Marc,
To be clear, I think we shouldn't make Argon2 the default just yet. I
would rather add it as an option for now and make it the default in a
later release. However, I would like to discuss what would block making
Argon2 the default already.
> It is once per user, but it's once for *EVE
In another thread about adding a "scheme" field to the Site model [1], I
floated the idea of moving the data stored by the Site model into a setting:
I've sometimes thought that the Site model violates the principle that you
shouldn't put configuration in your database. I guess there's some
use
+1 on setting. That's what I've ended up doing on all of my projects
anyhowways.
On Friday, January 29, 2016 at 2:45:02 PM UTC-6, Tim Graham wrote:
>
> In another thread about adding a "scheme" field to the Site model [1], I
> floated the idea of moving the data stored by the Site model into a
> On 29 janv. 2016, at 21:45, Tim Graham wrote:
>
> Do you think we'll be better off in the long run with a setting as opposed to
> storing the data in the database?
Yes.
--
Aymeric.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contribut
I have to agree here; it's pretty sloppy to not enforce an explicit boolean
value and can lead to subtle bugs. In addition to the one mentioned by
Maxime, consider the case of a nullable boolean field:
>>> bool(None)
False
Maybe that field has a better converter for possible values and explicit
Sorry, sbrandt noted the issue of subtle bugs, not Maxime.
On Friday, January 29, 2016 at 4:37:51 PM UTC-6, Chris Foresman wrote:
>
> I have to agree here; it's pretty sloppy to not enforce an explicit
> boolean value and can lead to subtle bugs. In addition to the one mentioned
> by Maxime, co
This is just that I'm doing in django-sites package:
https://github.com/niwinz/django-sites .
+ to have the similar approach in django (sites as settings).
On Fri, Jan 29, 2016 at 10:45 PM, Tim Graham wrote:
> In another thread about adding a "scheme" field to the Site model [1], I
> floated th
Any opposition to deprecating Cache.has_key()? Cache already implements
__contains__() so converting has_key() to "in" can be done with existing
versions of Django. Anyone using flake8 will get a warning about has_key()
usage: W601 .has_key() is deprecated, use 'in'.
--
You received this messa
Also the template BaseContext class has an undocumented has_key() method. I
wonder if that can be removed without a deprecation?
https://github.com/django/django/pull/6066
On Friday, January 29, 2016 at 6:11:54 PM UTC-5, Tim Graham wrote:
>
> Any opposition to deprecating Cache.has_key()? Cache
Isn't this so it complies with the dict interface? True, it's discouraged now,
but it's still there.
On 30 January 2016 10:42:12 am LHDT, Tim Graham wrote:
>Also the template BaseContext class has an undocumented has_key()
>method. I
>wonder if that can be removed without a deprecation?
>
>ht
What if this list of sites needs to be changed dynamically without app restart
(multitenancy)?
On Fri, Jan 29, 2016 at 12:45:02PM -0800, Tim Graham wrote:
> In another thread about adding a "scheme" field to the Site model [1], I
> floated the idea of moving the data stored by the Site model int
19 matches
Mail list logo