Re: Status of 3.1 release blockers.

Thank you. אורי u...@speedy.net On Fri, Aug 7, 2020 at 8:24 AM Mariusz Felisiak wrote: > > *> After I signed up and logged in, I reverted to Django 3.0, and then one > user was logged out (who should be logged in) and another user got the > exception `Incorrect padding` (from > `base64.b64deco

Re: Status of 3.1 release blockers.

*> After I signed up and logged in, I reverted to Django 3.0, and then one user was logged out (who should be logged in) and another user got the exception `Incorrect padding` (from `base64.b64decode(session_data.encode('ascii'))`). * This is a separate issue, see #31864

Re: Status of 3.1 release blockers.

Hi, Have you tested multiple servers with Django versions 3.0 and 3.1 with `DEFAULT_HASHING_ALGORITHM = 'sha1'`? I created a branch with this setting, with Django 3.1, and then I used it on our staging server. After I signed up and logged in, I reverted to Django 3.0, and then one user was logged

Re: Status of 3.1 release blockers.

Hi Markus, I don't see a clear path to do this, we cannot add a setting that accepts a string and immediately (in the next release) change it to a list, this will require a deprecation path etc. and will be really confusing to users. IMO we can reconsider this new feature in the next releas

Re: Status of 3.1 release blockers.

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 a

Re: Status of 3.1 release blockers.

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. F

Re: Status of 3.1 release blockers.

On Saturday, August 1, 2020 at 12:53:09 PM UTC+2 Florian Apolloner wrote: > And also, how to define this setting to its default value in Django >> versions <= 3.0. >> > > You don't, this is not supported. > Sorry I probably didn't fully understand the question. Either way; this setting is not u

Re: Status of 3.1 release blockers.

On Saturday, August 1, 2020 at 7:16:57 AM UTC+2 Uri wrote: > 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? > You have to set it to `sha1` and then when all your instances

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: 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()

Re: Status of 3.1 release blockers.

Hi James, To the first release candidate (July 20) we will backport doc fixes and even cleanups, so you have time to finish this change. Documentation fixes generally are generally more freely backported even to the last release branch. Best, Mariusz -- You received this message because yo

Re: Status of 3.1 release blockers.

I've been working on documentation updates to get the DEP 10 governance listed in the docs, but it's unlikely I'll be able to PR it until this weekend. How do people feel about that also being included in 3.1? It's not exactly a feature change, and it arguably corrects a bug in that the docs as the

Re: Status of 3.1 release blockers.

Hi y'all, The feature freeze was yesterday, so we've branched stable/3.1.x today and Claude has updated the translations catalogs. We're planning to do the alpha release in this week, after fixing two confirmed regressions: https://code.djangoproject.com/ticket/31566 https://code.djangoproject.

Re: Status of 3.1 release blockers.

> > I think we should also address: > > https://code.djangoproject.com/ticket/30678 > > > - GDAL 3 support > > as release blocker, because more and more instal

Re: Status of 3.1 release blockers.

Hi Mariusz, I think we should also address: https://code.djangoproject.com/ticket/30678 - GDAL 3 support as release blocker, because more and more installations will have GDAL 3 by default and the backwards compatibility issues are serious. I'll try to prepare a patch ASAP. As this is only aff

Status of 3.1 release blockers.

Hi y'all, Time to begin release process for the next major release, Django 3.1! The 3.1 feature freeze is scheduled (according to https://code.djangoproject.com/wiki/Version3.1Roadmap) for May 11. We'll probably release the alpha a few days later. We have a few larger patches we want to finish