Re: Status of 3.1 release blockers.

I also think, when the old hashing algorithm is deprecated, it's better to convert sessions to the new hashing algorithm without logging out users and without raising errors or exceptions. Is it possible? And notice that the Django user may change this setting only in the future, such as in Django

Re: Status of 3.1 release blockers.

Hi Mariusz, How do you propose running several versions of Django 3.0 and 3.1 with this PR and setting? Does it have to be defined, or is it enough using the default setting? And when upgrading Django to 3.1, what is the default setting if this setting is not explicitly defined? And how will it af

Re: Status of 3.1 release blockers.

I like the state of your proposed PR Mariusz. 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 requiremen

Re: Status of 3.1 release blockers.

I've created a draft PR13262 with the new setting for the default hashing algorithm. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this

Re: Rethink (?) how we handle security headers.

> I would suggest that the redirection part be moved to a different middleware. I doubt this would have any noticeable performance impact on any application. I’d like to see profiling data before imposing such a change on users. Also I find myself using the Django redirect with several different

Re: Status of 3.1 release blockers.

Hey Uri. We’re not going to patch 3.0 now. (Risk of regression is too high — it’s why we have the backporting policy.) It’s 3.1’s job to be “forward compatible” - folks should be able to update. This is a difficult case in that it requires allowing running the old version at the same time as the

Re: Status of 3.1 release blockers.

Hi Carlton, I think a possible solution can be if Django 3.0 will be patched to handle sessions created by 3.1. This will allow both downgrading Django and running Django on several servers with 3.0 and 3.1 in parallel. If this is too late now to do it before releasing 3.1, maybe you can postpone

Re: Status of 3.1 release blockers.

Hi Uri. > On 31 Jul 2020, at 12:11, ⁨אורי⁩ <⁨u...@speedy.net⁩> wrote: > > On Fri, Jul 31, 2020 at 12:28 PM Mariusz Felisiak > wrote: > Markus reported a release blocker #31842 > related with running an app on > mu

Re: Status of 3.1 release blockers.

On Fri, Jul 31, 2020 at 12:23 PM Raffaele Salmaso wrote: > On Fri, Jul 31, 2020 at 12:12 PM Carlton Gibson > wrote: > What about: > retry 😅 django 3.1 * add a global settings set to sha1 * configure settings template to use sha256 so a new project will start with new algorithm * add a warning t

Re: Status of 3.1 release blockers.

On Fri, Jul 31, 2020 at 12:34 PM Markus Holtermann wrote: > No, it won't move the problem to 3.2. The problem is that 3.0 only knows > about sha1. 3.1 and later know about sha1 and sha256. Meaning, any > >=3.1,<4.0 version can decode and verify signed data from 4.0 and before. > Sorry, s/3.2/3.1/

Re: Status of 3.1 release blockers.

No, it won't move the problem to 3.2. The problem is that 3.0 only knows about sha1. 3.1 and later know about sha1 and sha256. Meaning, any >=3.1,<4.0 version can decode and verify signed data from 4.0 and before. Cheers Markus On Fri, Jul 31, 2020, at 12:08 PM, Raffaele Salmaso wrote: > On F

Re: Status of 3.1 release blockers.

On Fri, Jul 31, 2020 at 12:12 PM Carlton Gibson wrote: > Yes, perhaps: default to the future sounds better. > What about: django 3.2 * add a global settings set to sha1 * configure settings template to use sha256 so a new project will start with new algorithm * add a warning to sha1 usage and in

Re: Status of 3.1 release blockers.

On Fri, Jul 31, 2020 at 12:28 PM Mariusz Felisiak < felisiak.mari...@gmail.com> wrote: > Markus reported a release blocker #31842 > related with running an app > on multiple servers with different versions of Django (3.0.x or 3.1). > I think it might

Re: Status of 3.1 release blockers.

> I think this just move the migration problem from 3.2 to 4.0. My thought was the instant warning helped with that... BUT... What about the other way: add a migration setting set to new algorithm, so > who really need sha1 can opt-in to old algorithm? > Yes, perhaps: default to the future sound

Re: Status of 3.1 release blockers.

On Fri, Jul 31, 2020 at 11:47 AM Carlton Gibson wrote: > Add the new setting default to sha1. > Raise a DeprecationWarning unless it’s set to sha256 (so folks can opt-in > to the future.) > Remove setting, and change default to sha256, when 4.0? > > Does that sound right? (Grrr.) > I think this j

Re: Status of 3.1 release blockers.

It looks like we need to add the algorithm to the function signatures, as per the PR, but also add a (immediately deprecated) migration setting, so folks can opt-in to the new algorithm when they’re updated. Add the new setting default to sha1. Raise a DeprecationWarning unless it’s set to sha256

Re: Status of 3.1 release blockers.

Thank you for summarizing our IRC discussion, Mariusz. To be clear, the problem occurs during the upgrade process where more than 1 server is involved. That might be the case in small deployments with just 2 servers, where the time of two Django versions running simultaneously is likely small, o

Re: Status of 3.1 release blockers.

Markus reported a release blocker #31842 related with running an app on multiple servers with different versions of Django (3.0.x or 3.1). Signatures created on servers with Django 3.1 are not valid on Django 3.0, it's not only about signing.loads()