Can we come up with a way that we have the settings variable around for now, 
only to allow transitioning, and then add it as a proper feature in 3.2.

As for the feature, I think we could choose a path like passlib does: A list of 
2 (n>=1) algorithms. The first one will be used for signing, and all of them 
for verification. We could then limit the set of options to sensible algorithms 
(or put some algorithms on a blocklist, such as md5). But I think that's 
nothing we should add the day before the final release.

Cheers,

Markus

On Mon, Aug 3, 2020, at 8:48 AM, Mariusz Felisiak wrote:
> It seems that adding DEFAULT_HASHING_ALGORITHM setting is an acceptable 
> solution, we have one remaining question: Do we keep the setting around?
>  1. we can treat DEFAULT_HASHING_ALGORITHM as a transitional setting, 
> limit its values to `sha1` and `sha256`, and deprecate it immediately. 
> Florian said: *"From a security perspective I wonder if we should limit 
> this that the existing sha1 and the new sha256 algos. We really don't 
> ever want anyone to put md5 there and it is really just a transitional 
> setting.", "...setting this to sha256, running with it and then 
> changing it to sha512 will be a hard cut. There will be no migration 
> path like there would be for sha1. Imo that limits the usefulness of 
> such a setting for long term usage and makes it questionable if we want 
> to support such usage."*
>  2. we can treat DEFAULT_HASHING_ALGORITHM as a new feature and allows 
> any secure hash algorithm supported by hashlib. Simon said: *"**It does 
> add one more setting but it feels like having this configurable project 
> wide will be a plus as it will allow the ecosystem to rely on it and 
> hopefully make audit of large Django application a bit easier when 
> having specific hashing requirements.".*
> Personally I think we should choose the first option because it's 
> safer. 
> 
> *We're delaying the 3.1 release until tomorrow.*
> 
> Best,
> Mariusz
> 
> 
> -- 
> 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/023a0518-a58c-48c6-8b36-9d5fb7a7c108n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-developers/023a0518-a58c-48c6-8b36-9d5fb7a7c108n%40googlegroups.com?utm_medium=email&utm_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/17636c67-cdb5-4cf9-bb95-b10b8cc0885d%40www.fastmail.com.

Reply via email to