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
4.0 and even later. What will happen then?
אורי
u...@speedy.net


On Fri, Jul 31, 2020 at 11:46 PM Mariusz Felisiak <
felisiak.mari...@gmail.com> wrote:

> 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 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/c3b3025f-3830-464a-8c8c-883ec606720an%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABD5YeFwrijwMt81ijbBw2TST-phxBSTW%2BSF7iv4SneBa2oZHg%40mail.gmail.com.

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 affect
sessions in case of downgrading back to 3.0? Will it be possible to
downgrade also with the default setting?

Also, maybe it's better to document the answers to these questions in the
release notes and in the definition of the new setting. And also, how to
define this setting to its default value in Django versions <= 3.0. What do
you think?

אורי
u...@speedy.net


On Fri, Jul 31, 2020 at 11:46 PM Mariusz Felisiak <
felisiak.mari...@gmail.com> wrote:

> 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 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/c3b3025f-3830-464a-8c8c-883ec606720an%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABD5YeG1KNTg9YGfUqxTmV82qU1Khs_E-EwfUyR-OHcaornzZA%40mail.gmail.com.

Re: Status of 3.1 release blockers.

[charettes]

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

Simon

Le vendredi 31 juillet 2020 à 16:46:36 UTC-4, Mariusz Felisiak a écrit :

> 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 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/d8f9082f-a5e8-471c-84eb-91a9f0e708bbn%40googlegroups.com.

Re: Status of 3.1 release blockers.

[Mariusz Felisiak]

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 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/c3b3025f-3830-464a-8c8c-883ec606720an%40googlegroups.com.

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

[Adam Johnson]

> 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
“serverlwss” deployment setups.

On Thu, 30 Jul 2020 at 17:43, Claude Paroz  wrote:

> By the way, while reviewing the SecurityMiddleware, I would suggest that
> the redirection part be moved to a different middleware.
> http to https redirection should preferably be done at the Web server
> level, and for those doing that properly, they still pay for the unneeded
> (albeit small) overhead of the `SecurityMiddleware.process_request`.
>
> > 3. For new headers I think we could add a setting called e.g.
> ADD_HEADERS - a dict of keys to values that
> > CommonMiddleware (or similar) could add to outgoing responses' headers.
>
> +1 to that proposal.
>
> Claude
>
> --
> 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/3da2e385-551e-4905-83e8-7f2b99896f18o%40googlegroups.com
> 
> .
>
-- 
Adam

-- 
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/CAMyDDM0SUWKZMSiUFsjrEUAkMx1Egdt2QV6T9RP%3DiqqNbqEdLw%40mail.gmail.com.

Re: Status of 3.1 release blockers.

[Carlton Gibson]

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 new one, which isn’t something I’d like to
encourage, but I agree with Simon on the issue, we need to provide a path.

Kind  regards,
Carlton

On Fri, 31 Jul 2020 at 17:31, אורי  wrote:

> 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 this
> change (of hashing algorithm, if I understand correctly) to Django 3.2. And
> then of course, patch 3.0 and 3.1 to handle sessions created by 3.2.
>
> אורי
> u...@speedy.net
>
>
> On Fri, Jul 31, 2020 at 2:13 PM Carlton Gibson 
> wrote:
>
>> Hi Uri.
>>
>> On 31 Jul 2020, at 12:11, ⁨אורי⁩ <⁨u...@speedy.net⁩> wrote:
>>
>> 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 be related to an issue I reported - #31592
>> . Django 3.0 can't handle
>> sessions created by Django 3.1.
>>
>>
>> Yes, it’s related. Your issue was downgrading IIRC. This is “can’t
>> upgrade piecemeal” — but a solution may allow your use-case too.
>>
>> C.
>>
>> --
>> 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/AEC8D4F2-E042-4A6B-9E9D-7D0584BB42B4%40gmail.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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CABD5YeEVhj2T0Yq0q%3DESvKjEHfXddiTNtgo_M%2B%2BxDvSKs5xRYw%40mail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAJwKpyRKgSEmUH%2BZmtyC-6SFyZmTXNR7i3FVcoy5ik1azLjg3g%40mail.gmail.com.

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 this
change (of hashing algorithm, if I understand correctly) to Django 3.2. And
then of course, patch 3.0 and 3.1 to handle sessions created by 3.2.

אורי
u...@speedy.net


On Fri, Jul 31, 2020 at 2:13 PM Carlton Gibson 
wrote:

> Hi Uri.
>
> On 31 Jul 2020, at 12:11, ⁨אורי⁩ <⁨u...@speedy.net⁩> wrote:
>
> 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 be related to an issue I reported - #31592
> . Django 3.0 can't handle
> sessions created by Django 3.1.
>
>
> Yes, it’s related. Your issue was downgrading IIRC. This is “can’t upgrade
> piecemeal” — but a solution may allow your use-case too.
>
> C.
>
> --
> 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/AEC8D4F2-E042-4A6B-9E9D-7D0584BB42B4%40gmail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABD5YeEVhj2T0Yq0q%3DESvKjEHfXddiTNtgo_M%2B%2BxDvSKs5xRYw%40mail.gmail.com.

Re: Status of 3.1 release blockers.

[Carlton Gibson]

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 
> multiple servers with different versions of Django (3.0.x or 3.1). 
> 
> I think it might be related to an issue I reported - #31592 
> . Django 3.0 can't handle 
> sessions created by Django 3.1.

Yes, it’s related. Your issue was downgrading IIRC. This is “can’t upgrade 
piecemeal” — but a solution may allow your use-case too. 

C.

-- 
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/AEC8D4F2-E042-4A6B-9E9D-7D0584BB42B4%40gmail.com.

Re: Status of 3.1 release blockers.

[Raffaele Salmaso]

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 to sha1 usage and instruction how to upgrade
django 3.2
* set global setting set to sha256
django 4.0
* remove setting

-- 
| Raffaele Salmaso
| https://salmaso.org
| https://bitbucket.org/rsalmaso
| https://github.com/rsalmaso

-- 
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/CABgH4JtF%3DB2sX%3Dv%2B3twh0BMHpQcXGCvxnnNzuZFU7B%2BYSH5PVw%40mail.gmail.com.

Re: Status of 3.1 release blockers.

[Raffaele Salmaso]

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/ in all emails 😰

-- 
| Raffaele Salmaso
| https://salmaso.org
| https://bitbucket.org/rsalmaso
| https://github.com/rsalmaso

-- 
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/CABgH4JsQ23qQQUctCzVPkhfS-U2zWJHfrKBQ%2B59g1ivzj5ohcg%40mail.gmail.com.

Re: Status of 3.1 release blockers.

[Markus Holtermann]

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 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 just move the migration problem from 3.2 to 4.0. 
> What about the other way: add a migration setting set to new algorithm, 
> so who really need sha1 can opt-in to old algorithm?
> 
> -- 
> | Raffaele Salmaso
> | https://salmaso.org
> | https://bitbucket.org/rsalmaso
> | https://github.com/rsalmaso
> 
> -- 
> 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/CABgH4Jt0xXzXrFO8vAFFbF_zabF6xhFGnnTS1rJi_iWAT9fJRg%40mail.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1b35a40d-c3e3-4aab-a856-078f2efad7c4%40beta.fastmail.com.

Re: Status of 3.1 release blockers.

[Raffaele Salmaso]

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 instruction how to upgrade
django 4.0
* remove setting

-- 
| Raffaele Salmaso
| https://salmaso.org
| https://bitbucket.org/rsalmaso
| https://github.com/rsalmaso

-- 
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/CABgH4JtZhcQASb%3DPnaxr%3DzqvAn2XhJJAvNOu%2BQez7E%3DHyTCKWw%40mail.gmail.com.

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 be related to an issue I reported - #31592
. Django 3.0 can't handle
sessions created by Django 3.1.


אורי
u...@speedy.net

-- 
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/CABD5YeGYZGjH2k48Rr%3DT1NwbYzjq%2Bs94Bw-4uZ0H%3Dmw7bK-vQQ%40mail.gmail.com.

Re: Status of 3.1 release blockers.

[Carlton Gibson]

> 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 sounds better.

>

-- 
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/CAJwKpySb-cyEhQwJVETef_UJ2Kuagyty%2BYcLMAZrMK9xaOzHNg%40mail.gmail.com.

Re: Status of 3.1 release blockers.

[Raffaele Salmaso]

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 just move the migration problem from 3.2 to 4.0.
What about the other way: add a migration setting set to new algorithm, so
who really need sha1 can opt-in to old algorithm?

-- 
| Raffaele Salmaso
| https://salmaso.org
| https://bitbucket.org/rsalmaso
| https://github.com/rsalmaso

-- 
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/CABgH4Jt0xXzXrFO8vAFFbF_zabF6xhFGnnTS1rJi_iWAT9fJRg%40mail.gmail.com.

Re: Status of 3.1 release blockers.

[Carlton Gibson]

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 (so folks can opt-in
to the future.)
Remove setting, and change default to sha256, when 4.0?

Does that sound right? (Grrr.)

-- 
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/CAJwKpyTM41tJ3mO_rs4%2B9moBPmw_G-6vQmK%2Bx6JV4i0081VLRA%40mail.gmail.com.

Re: Status of 3.1 release blockers.

[Markus Holtermann]

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, or on huge 
deployments of the course of days or weeks, when a staged rollout occurs.

Cheers, Markus

On Fri, Jul 31, 2020, at 11:28 AM, Mariusz Felisiak 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). Signatures created on servers with Django 3.1 are not valid on 
> Django 3.0, it's not only about signing.loads()/dumps but also about 
> sessions etc. (see #27468 
> ). We have several 
> possible approaches:
>  * revert commits related with #27468,
>  * change the default hashing algorithm to SHA-1,
>  * add the new setting for the default hashing algorithm,
>  * add the "algorithm" parameter to signing.dumps()/loads() (PR13260 
> ) and ignore the rest of 
> the problem (it's probably not an option),
>  * add the new setting "MIN_DJANGO_VERSION" and change the default 
> hashing algorithm if it's 3.0 or less.
>  * ... (ideas are welcome)
> 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/2a3d706d-6f78-406e-b7a9-3bba3ea9b7e6n%40googlegroups.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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d8d56bc4-98a4-460b-ac8c-3b194b11daa4%40beta.fastmail.com.

Re: Status of 3.1 release blockers.

[Mariusz Felisiak]

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()/dumps but also about sessions etc. (see 
#27468 ). We have several 
possible approaches:

   - revert commits related with #27468,
   - change the default hashing algorithm to SHA-1,
   - add the new setting for the default hashing algorithm,
   - add the "algorithm" parameter to signing.dumps()/loads() (PR13260 
   ) and ignore the rest of 
   the problem (it's probably not an option),
   - add the new setting "MIN_DJANGO_VERSION" and change the default 
   hashing algorithm if it's 3.0 or less.
   - ... (ideas are welcome)
   
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/2a3d706d-6f78-406e-b7a9-3bba3ea9b7e6n%40googlegroups.com.