Re: Django for beginners

[Larbi Gharib]

Hi Adam and Elisabetta,

Adam is right my bad.

Larbi

Le sam. 25 avr. 2020 à 13:45, Adam Johnson  a écrit :

> Larbi, that is the roadmap for Django CMS, a separate project that is an
> extension to Django.
>
> Elisabetta, yes this is more of a support question. If you’re looking for
> learning materials, check out the awesome Django list: as a start:
> https://github.com/wsvincent/awesome-django
>
> On Sat, 25 Apr 2020 at 14:33, Larbi Gharib  wrote:
>
>> Hi Elisabetta,
>>
>> If You age looking for a simplified roadmap of Django as a project and
>> how it will evolve in the future there is a link
>> https://www.django-cms.org/en/roadmap
>>
>> Am I answering your question?
>>
>> Larbi
>>
>> On Sat., Apr. 25, 2020, 9:24 a.m. elisabetta fierro, <
>> fierroelisabe...@gmail.com> wrote:
>>
>>> Is it available a Django roadmap for beginners?
>>>
>>> --
>>> 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/2be20c62-c0e2-4abd-8964-78c44b016d40%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/CAJpH8VeU8TqnEt_ViYG-J9WN-YmbzbPdApXYuZ4FZ2OD_k665g%40mail.gmail.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/CAMyDDM1t2kPysAezHpFG8m1%3Dr%3DtLSirrR5s9Pn6pYb6b%3D2THTw%40mail.gmail.com
> 
> .
>


-- 
GHARIB  Larbi
Diplômé en Génie Électrique à l'Université Laval

418-265-2508
http://www.larbigharib.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/CAJpH8VeX5d_DXev%3D%2Bh6LhOntygronF1_pAdFWmNhKPWS1ioMvA%40mail.gmail.com.

Re: Generate JWTs with Django

[James Bennett]

I understand that this will probably get shouted down due to the
popularity of JWTs, but: I don't think Django should include any type
of JWT support in the core framework.

JWTs are an absolute security nightmare. Some of the Django security
team have heard me rant on this topic already, but: there is no such
thing as a safe JWT implementation, because there are fundamental
flaws in the design of JWT that cannot be remedied by just writing
better implementations. Supporting them in Django, even to the minimal
extent in the current PR, would encourage users of Django to adopt
them, which goes against our historical trend of pushing best
practices when it comes to application security, and would
significantly add to the security team's burden because of the
increased attack surface JWT support would open up.

If Django does end up shipping some type of JWT support, I'd lobby
very strongly for declaring it out of scope for our security process,
and labeling it "use at your own risk".

-- 
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/CAL13Cg8Csr1ageZCEKm9bd12Tb_vosx_xLSV%2B8WfvoWi01%2BfPA%40mail.gmail.com.

Re: Generate JWTs with Django

[Ryan Hiebert]

On Sun, Apr 26, 2020 at 8:29 AM James Bennett  wrote:

> JWTs are an absolute security nightmare. Some of the Django security
> team have heard me rant on this topic already, but: there is no such
> thing as a safe JWT implementation, because there are fundamental
> flaws in the design of JWT that cannot be remedied by just writing
> better implementations.
>

Given this thesis, your conclusion makes sense. I use JWTs in my
application, because my domain is particularly suited to it IMO, and while
I can't speak for everyone on this list, I'd be interested to hear your
complaints about the design of JWTs. For my own thinking, I find that the
inclusion of the standardized algorithm field was a design mistake. It can
be papered over by a good library implementation, but that so many
libraries got it wrong is evidence of a flaw in the protocol design, IMO.

However, I'm not aware of any other standard payload-signing mechanism that
has the well-defined capabilities that JWTs have, without that issue.
That's fairly likely to be ignorance on my part, and if a more suitable
standard were available to me, I'd happily switch my application to using
it. Obviously JWTs are indeed popular, and I don't particularly find that
the issue I mentioned above to be a total showstopper (although obviously
very unfortunate).

Perhaps in email or a blog post or just a list of links, would you be
willing to share your complaints? Are there better designs for a similar
protocol that overcome your objections?

Ryan

-- 
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/CABpHFHQ6M6ODzjX9aXxY-nbZRu5hFHq-nUcviGvzdX8U_NwePw%40mail.gmail.com.

Re: Remove automatic date-naming of migrations (00XX_auto_YYYMMDD)

[Adam Johnson]

Since this proposal seems to be broadly supported, I've created a
corresponding ticket and pull request:
https://code.djangoproject.com/ticket/31516 and
https://github.com/django/django/pull/12799 .

Thanks all.

On Sat, 25 Apr 2020 at 19:08, Tom Forbes  wrote:

> I would be in favour of Adam’s proposed changes. Adding more context to
> them and stripping the appended timestamp would make them more user
> friendly.
>
> > As a developer I would like to know who generated the code. If a
> migration is auto-generated, I would like to know that. I checked and
> auto-generated migrations in my project have a comment such as "# Generated
> by Django 2.1.15 on 2020-01-21 15:31".
>
> A couple of things:
> 1. Your VCS will tell you who generated the code
> 2. The name of the file including “auto” in it doesn’t mean that it wasn’t
> completely edited by a developer afterwards, making the “auto” useless in
> knowing who generated the code
>
> A common operation when looking at a list of migrations is to try and find
> a specific one. I think this is a much more common occurrence than looking
> at the list of migrations to know how many have been (possibly) generates
> by Django.
>
> This would make the common case more convenient and simpler, which is good.
>
> Tom
>
> On 25 Apr 2020, at 17:45, אורי  wrote:
>
> 
>
>
> On Sat, Apr 25, 2020 at 5:48 PM Adam Johnson  wrote:
>
>> Re: Uri:
>>
>>> If the file name is not like ‘auto’ name with the current date + time,
>>> it looks like a migration which was written by a developer.
>>>
>>
>> I think making a distinction between "auto generated" and "hand written"
>> migrations is a bad idea. Django's makemigrations is a code generator, but
>> as a developer you're still responsible for the code. The autodetector
>> isn't perfect, and perhaps never can be. Even "simple" cases like adding a
>> through table to a ManyToManyField are autodetected "incorrectly" ( a real
>> migration needs SeparateDatabaseAndState
>> https://docs.djangoproject.com/en/3.0/howto/writing-migrations/#changing-a-manytomanyfield-to-use-a-through-model
>> ).
>>
>> I fear marking "auto generated" migrations differently would just
>> encourage (more) lax use of migrations files without reading their content,
>> which invites more risk for data loss and anger with Django for not being
>> perfect.
>>
> As a developer I would like to know who generated the code. If a migration
> is auto-generated, I would like to know that. I checked and auto-generated
> migrations in my project have a comment such as "# Generated by Django
> 2.1.15 on 2020-01-21 15:31". In most cases auto-generated migrations are
> good and don't need to be edited by a developer. So, I would prefer the
> migration file names to be auto-generated too (‘auto’ name with the current
> date + time).
>
> --
> 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/CABD5YeFvWJSotjqhB_L%3Dt9i%3Dx3%3DRt%2Bh-S_gYCAgTV3C8RFMjwg%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/CC4B31C7-EC63-4531-BF69-3672B9909133%40tomforb.es
> 
> .
>


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

Re: Generate JWTs with Django

[Adam Johnson]

James, I too would like to know your criticisms! I've always understood
that they aren't much different to signed cookies, but I haven't looked too
deeply at them.

On Sun, 26 Apr 2020 at 16:00, Ryan Hiebert  wrote:

>
>
> On Sun, Apr 26, 2020 at 8:29 AM James Bennett 
> wrote:
>
>> JWTs are an absolute security nightmare. Some of the Django security
>> team have heard me rant on this topic already, but: there is no such
>> thing as a safe JWT implementation, because there are fundamental
>> flaws in the design of JWT that cannot be remedied by just writing
>> better implementations.
>>
>
> Given this thesis, your conclusion makes sense. I use JWTs in my
> application, because my domain is particularly suited to it IMO, and while
> I can't speak for everyone on this list, I'd be interested to hear your
> complaints about the design of JWTs. For my own thinking, I find that the
> inclusion of the standardized algorithm field was a design mistake. It can
> be papered over by a good library implementation, but that so many
> libraries got it wrong is evidence of a flaw in the protocol design, IMO.
>
> However, I'm not aware of any other standard payload-signing mechanism
> that has the well-defined capabilities that JWTs have, without that issue.
> That's fairly likely to be ignorance on my part, and if a more suitable
> standard were available to me, I'd happily switch my application to using
> it. Obviously JWTs are indeed popular, and I don't particularly find that
> the issue I mentioned above to be a total showstopper (although obviously
> very unfortunate).
>
> Perhaps in email or a blog post or just a list of links, would you be
> willing to share your complaints? Are there better designs for a similar
> protocol that overcome your objections?
>
> Ryan
>
> --
> 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/CABpHFHQ6M6ODzjX9aXxY-nbZRu5hFHq-nUcviGvzdX8U_NwePw%40mail.gmail.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/CAMyDDM10C8CrXNCj7tsUgvJ-xBRG8LixMT1djwntpt4%2BZZ_fkQ%40mail.gmail.com.

Google Groups contingency plan

[Tom Forbes]

Hello,
Given the recent worldwide situation I’ve found myself thinking a lot about 
contingency plans recently. I wanted to raise a question about our reliance on 
Google Groups and if we had any contingency plans if this service was shut down?

To put it politely, it's pretty obvious that Google Groups is in “maintenance 
mode” and there is little, if any, active development. Alongside this:
1. Google has apparently broken core functionality like advanced searching, and 
left it broken for years at a time 
(https://en.wikipedia.org/wiki/Google_Groups#Google_Groups 
)
2. Google itself has shut down down maintenance-mode services before even if 
they have an active user base (see Google Reader)
3. Google Groups clearly doesn’t bring any revenue to Google at all, and is 
probably a legal liability.

Given this, if we have not already we should maybe consider what we would do if 
it was announced tomorrow that Google Groups was shutting down in 3 to 6 months?

Perhaps we’ve already considered this but I couldn’t find any discussions about 
this (and it’s hard to search for threads that reference “Google Groups” as 
every thread contains that string!). Some food for thought: the Python 
development mailing lists (i.e 
https://mail.python.org/archives/list/python-...@python.org/ 
) are browsable 
through a service called HyperKitty (https://gitlab.com/mailman/hyperkitty 
), which is built with Django. We could 
potentially ask for a mailing list on the python.org  mail 
server or we could host HyperKitty and MailMan ourselves?

-- 
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/2715F232-322F-4C3D-BEE7-9C63C2B0ECFB%40tomforb.es.


signature.asc
Description: Message signed with OpenPGP

Re: Google Groups contingency plan

[אורי]

On Sun, Apr 26, 2020 at 7:14 PM Tom Forbes  wrote:

> Hello,
> Given the recent worldwide situation I’ve found myself thinking a lot
> about contingency plans recently. I wanted to raise a question about our
> reliance on Google Groups and if we had any contingency plans if this
> service was shut down?
>
> To put it politely, it's pretty obvious that Google Groups is in
> “maintenance mode” and there is little, if any, active development.
> Alongside this:
> 1. Google has apparently broken core functionality like advanced
> searching, and left it broken for years at a time (
> https://en.wikipedia.org/wiki/Google_Groups#Google_Groups)
> 2. Google itself has shut down down maintenance-mode services before even
> if they have an active user base (see Google Reader)
> 3. Google Groups clearly doesn’t bring any revenue to Google at all, and
> is probably a legal liability.
>
> Given this, if we have not already we should maybe consider what we would
> do if it was announced tomorrow that Google Groups was shutting down in 3
> to 6 months?
>
> Perhaps we’ve already considered this but I couldn’t find any discussions
> about this (and it’s hard to search for threads that reference “Google
> Groups” as every thread contains that string!). Some food for thought: the
> Python development mailing lists (i.e
> https://mail.python.org/archives/list/python-...@python.org/) are
> browsable through a service called HyperKitty (
> https://gitlab.com/mailman/hyperkitty), which is built with Django. We
> could potentially ask for a mailing list on the python.org mail server or
> we could host HyperKitty and MailMan ourselves?
>
>
>
I think python.org and Django are managed by different (legal) entities so
it doesn't make sense for Django mailing lists to use the domain name
python.org. Actually as far as I see it, we only need mailing lists and
don't need any web interface features we get from Google Groups. Personally
my email is powered by Google which is like Gmail and I assign labels per
mailing list, so if I want to search I can just type text and the label
name and I can see any messages since I joined the mailing lists (I never
delete messages). I think if, if Google will close Google Groups they will
give us at least a few months notice and then we can discuss it, why do we
have to worry about it now? But just in case, I think running a (free
software & open source) mailing list software on a specific server will do,
something similar to what python.org is doing but not using their domain
name (unless Django becomes parts of the python.org legal entity).

By the way, is Django a commercial entity? Why does it use the .com domain
suffix? Python uses .org, but doesn't Django use .org too? From reading the
website I see that the Django Software Foundation is non-profit.

-- 
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/CABD5YeHLNhJXTGbaM%2BrYcoM9emvbHwhKxabQ0OoVTBPJyypt%2BA%40mail.gmail.com.

Re: Google Groups contingency plan

[אורי]

‪On Sun, Apr 26, 2020 at 7:34 PM ‫אורי‬‎  wrote:‬

>
> By the way, is Django a commercial entity? Why does it use the .com domain
> suffix? Python uses .org, but doesn't Django use .org too? From reading the
> website I see that the Django Software Foundation is non-profit.
>

Sorry, I meant:  Python uses .org, why doesn't Django use .org too?

-- 
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/CABD5YeHOzoPCrXSztBrUzTAJO6O1dVGO3Zq2wbenKL5rxhk%2BDA%40mail.gmail.com.

Re: Google Groups contingency plan

[Tom Forbes]

> I think python.org  and Django are managed by different 
> (legal) entities so it doesn't make sense for Django mailing lists to use the 
> domain name python.org 
That’s a good point, it was just an idea. However running mailserver can be 
annoying and there are economies of scale when it comes to security, spam 
filtering and ease of administration. We could potentially have a django.com 
mailing list address that points at a mailsever managed by python.org 
, and other projects like scikit have their mailing lists 
hosted by them.

> Actually as far as I see it, we only need mailing lists and don't need any 
> web interface features we get from Google Groups

We certainly do need it, if only for historic searching. User management and 
other niceties are great to have as well.

> why do we have to worry about it now

I mean, it’s a contingency plan. More of a contingency discussion actually. The 
point is to discuss future events before they happen. If the result is “it’s 
not worth thinking about now, let's decide when/if we get there” then that’s 
valid outcome.

> On 26 Apr 2020, at 17:34, ⁨אורי⁩ <⁨u...@speedy.net⁩> wrote:
> 
> 
> On Sun, Apr 26, 2020 at 7:14 PM Tom Forbes  > wrote:
> Hello,
> Given the recent worldwide situation I’ve found myself thinking a lot about 
> contingency plans recently. I wanted to raise a question about our reliance 
> on Google Groups and if we had any contingency plans if this service was shut 
> down?
> 
> To put it politely, it's pretty obvious that Google Groups is in “maintenance 
> mode” and there is little, if any, active development. Alongside this:
> 1. Google has apparently broken core functionality like advanced searching, 
> and left it broken for years at a time 
> (https://en.wikipedia.org/wiki/Google_Groups#Google_Groups 
> )
> 2. Google itself has shut down down maintenance-mode services before even if 
> they have an active user base (see Google Reader)
> 3. Google Groups clearly doesn’t bring any revenue to Google at all, and is 
> probably a legal liability.
> 
> Given this, if we have not already we should maybe consider what we would do 
> if it was announced tomorrow that Google Groups was shutting down in 3 to 6 
> months?
> 
> Perhaps we’ve already considered this but I couldn’t find any discussions 
> about this (and it’s hard to search for threads that reference “Google 
> Groups” as every thread contains that string!). Some food for thought: the 
> Python development mailing lists (i.e 
> https://mail.python.org/archives/list/python-...@python.org/ 
> ) are browsable 
> through a service called HyperKitty (https://gitlab.com/mailman/hyperkitty 
> ), which is built with Django. We 
> could potentially ask for a mailing list on the python.org 
>  mail server or we could host HyperKitty and MailMan 
> ourselves?
> 
> 
> 
> I think python.org  and Django are managed by different 
> (legal) entities so it doesn't make sense for Django mailing lists to use the 
> domain name python.org . Actually as far as I see it, we 
> only need mailing lists and don't need any web interface features we get from 
> Google Groups. Personally my email is powered by Google which is like Gmail 
> and I assign labels per mailing list, so if I want to search I can just type 
> text and the label name and I can see any messages since I joined the mailing 
> lists (I never delete messages). I think if, if Google will close Google 
> Groups they will give us at least a few months notice and then we can discuss 
> it, why do we have to worry about it now? But just in case, I think running a 
> (free software & open source) mailing list software on a specific server will 
> do, something similar to what python.org  is doing but 
> not using their domain name (unless Django becomes parts of the python.org 
>  legal entity).
> 
> By the way, is Django a commercial entity? Why does it use the .com domain 
> suffix? Python uses .org, but doesn't Django use .org too? From reading the 
> website I see that the Django Software Foundation is non-profit.
> 
> --
> 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/CABD5YeHLNhJXTGbaM%2BrYcoM9emvbHwhKxabQ0OoVTBPJyypt%2BA%40mail.gmail.com
>  
> 

Re: Google Groups contingency plan

[Abayomi Oloko]

Hello Tom,

I must commend your great foresight as we may be robbed of not only the rich 
content of our email communication history, our mailing list may also not be 
available. 

My suggestion will be for us to look in the direction of something open source 
as a stop gap between the time that we may agree to move and the time we have 
completed deliberations, business case analysis and decisions on the way 
forward.



Sent from my iPhone

> On Apr 26, 2020, at 12:13 PM, Tom Forbes  wrote:
> 
> Hello,
> Given the recent worldwide situation I’ve found myself thinking a lot about 
> contingency plans recently. I wanted to raise a question about our reliance 
> on Google Groups and if we had any contingency plans if this service was shut 
> down?
> 
> To put it politely, it's pretty obvious that Google Groups is in “maintenance 
> mode” and there is little, if any, active development. Alongside this:
> 1. Google has apparently broken core functionality like advanced searching, 
> and left it broken for years at a time 
> (https://en.wikipedia.org/wiki/Google_Groups#Google_Groups)
> 2. Google itself has shut down down maintenance-mode services before even if 
> they have an active user base (see Google Reader)
> 3. Google Groups clearly doesn’t bring any revenue to Google at all, and is 
> probably a legal liability.
> 
> Given this, if we have not already we should maybe consider what we would do 
> if it was announced tomorrow that Google Groups was shutting down in 3 to 6 
> months?
> 
> Perhaps we’ve already considered this but I couldn’t find any discussions 
> about this (and it’s hard to search for threads that reference “Google 
> Groups” as every thread contains that string!). Some food for thought: the 
> Python development mailing lists (i.e 
> https://mail.python.org/archives/list/python-...@python.org/) are browsable 
> through a service called HyperKitty (https://gitlab.com/mailman/hyperkitty), 
> which is built with Django. We could potentially ask for a mailing list on 
> the python.org mail server or we could host HyperKitty and MailMan ourselves?
> -- 
> 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/2715F232-322F-4C3D-BEE7-9C63C2B0ECFB%40tomforb.es.

-- 
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/00FED57B-A543-43B3-BEF0-94490DF79B44%40gmail.com.

Re: Google Groups contingency plan

[Adam Johnson]

>
>  I think python.org and Django are managed by different (legal) entities
> so it doesn't make sense for Django mailing lists to use the domain name
> python.org


I think it's fine to share with them, if possible.  As Tom, says other
projects like scikit do.


Tom - you didn't mention backing up the archives. I had a search and it
seems there's no official tool, but there is a script here:
https://geek.co.il/2018/05/16/migrating-google-groups-archives-between-accounts
. I think having a trial run ofthis would be a good first step to knowing
where we're at with preserving the data.


On Sun, 26 Apr 2020 at 17:45, Tom Forbes  wrote:

> I think python.org and Django are managed by different (legal) entities
> so it doesn't make sense for Django mailing lists to use the domain name
> python.org
>
>
> That’s a good point, it was just an idea. However running mailserver can
> be annoying and there are economies of scale when it comes to security,
> spam filtering and ease of administration. We could potentially have a
> django.com mailing list address that points at a mailsever managed by
> python.org, and other projects like scikit have their mailing lists
> hosted by them.
>
> Actually as far as I see it, we only need mailing lists and don't need any
> web interface features we get from Google Groups
>
>
> We certainly do need it, if only for historic searching. User management
> and other niceties are great to have as well.
>
> why do we have to worry about it now
>
>
> I mean, it’s a contingency plan. More of a contingency discussion
> actually. The point is to discuss future events before they happen. If the
> result is “it’s not worth thinking about now, let's decide when/if we get
> there” then that’s valid outcome.
>
> On 26 Apr 2020, at 17:34, ⁨אורי⁩ <⁨u...@speedy.net⁩> wrote:
>
>
> On Sun, Apr 26, 2020 at 7:14 PM Tom Forbes  wrote:
>
>> Hello,
>> Given the recent worldwide situation I’ve found myself thinking a lot
>> about contingency plans recently. I wanted to raise a question about our
>> reliance on Google Groups and if we had any contingency plans if this
>> service was shut down?
>>
>> To put it politely, it's pretty obvious that Google Groups is in
>> “maintenance mode” and there is little, if any, active development.
>> Alongside this:
>> 1. Google has apparently broken core functionality like advanced
>> searching, and left it broken for years at a time (
>> https://en.wikipedia.org/wiki/Google_Groups#Google_Groups)
>> 2. Google itself has shut down down maintenance-mode services before even
>> if they have an active user base (see Google Reader)
>> 3. Google Groups clearly doesn’t bring any revenue to Google at all, and
>> is probably a legal liability.
>>
>> Given this, if we have not already we should maybe consider what we would
>> do if it was announced tomorrow that Google Groups was shutting down in 3
>> to 6 months?
>>
>> Perhaps we’ve already considered this but I couldn’t find any discussions
>> about this (and it’s hard to search for threads that reference “Google
>> Groups” as every thread contains that string!). Some food for thought: the
>> Python development mailing lists (i.e
>> https://mail.python.org/archives/list/python-...@python.org/) are
>> browsable through a service called HyperKitty (
>> https://gitlab.com/mailman/hyperkitty), which is built with Django. We
>> could potentially ask for a mailing list on the python.org mail server
>> or we could host HyperKitty and MailMan ourselves?
>>
>>
>>
> I think python.org and Django are managed by different (legal) entities
> so it doesn't make sense for Django mailing lists to use the domain name
> python.org. Actually as far as I see it, we only need mailing lists and
> don't need any web interface features we get from Google Groups. Personally
> my email is powered by Google which is like Gmail and I assign labels per
> mailing list, so if I want to search I can just type text and the label
> name and I can see any messages since I joined the mailing lists (I never
> delete messages). I think if, if Google will close Google Groups they will
> give us at least a few months notice and then we can discuss it, why do we
> have to worry about it now? But just in case, I think running a (free
> software & open source) mailing list software on a specific server will do,
> something similar to what python.org is doing but not using their domain
> name (unless Django becomes parts of the python.org legal entity).
>
> By the way, is Django a commercial entity? Why does it use the .com domain
> suffix? Python uses .org, but doesn't Django use .org too? From reading the
> website I see that the Django Software Foundation is non-profit.
>
> --
> 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 discuss

Re: Google Groups contingency plan

[Tom Forbes]

Actually, after taking a look I found that there is actually a new version of 
Groups that is in beta 
(https://support.google.com/a/answer/9687393?hl=en&ref_topic=14869 
). It seems 
they are more tightly integrating it with G-Suite, and targeting it towards 
schools and businesses rather than public mailing lists/usenet archives.

Some features are potentially being deprecated 
(https://support.google.com/a/answer/9687393?hl=en&ref_topic=14869#deprecated 
),
 but I don’t think we use any of those.

I’m glad that Groups isn’t going to die, and I guess perhaps it makes this 
thread redundant, but the lack of an easy export is troubling and unexpected. 
Perhaps with the new release it might be possible without resorting to 
screen-scraping the public index pages?

Tom

> On 26 Apr 2020, at 21:14, Adam Johnson  wrote:
> 
>  I think python.org  and Django are managed by different 
> (legal) entities so it doesn't make sense for Django mailing lists to use the 
> domain name python.org 
> 
> I think it's fine to share with them, if possible.  As Tom, says other 
> projects like scikit do.
> 
> 
> Tom - you didn't mention backing up the archives. I had a search and it seems 
> there's no official tool, but there is a script here: 
> https://geek.co.il/2018/05/16/migrating-google-groups-archives-between-accounts
>  
> 
>  . I think having a trial run ofthis would be a good first step to knowing 
> where we're at with preserving the data.
> 
> 
> On Sun, 26 Apr 2020 at 17:45, Tom Forbes  > wrote:
>> I think python.org  and Django are managed by different 
>> (legal) entities so it doesn't make sense for Django mailing lists to use 
>> the domain name python.org 
> That’s a good point, it was just an idea. However running mailserver can be 
> annoying and there are economies of scale when it comes to security, spam 
> filtering and ease of administration. We could potentially have a django.com 
>  mailing list address that points at a mailsever managed 
> by python.org , and other projects like scikit have their 
> mailing lists hosted by them.
> 
>> Actually as far as I see it, we only need mailing lists and don't need any 
>> web interface features we get from Google Groups
> 
> We certainly do need it, if only for historic searching. User management and 
> other niceties are great to have as well.
> 
>> why do we have to worry about it now
> 
> I mean, it’s a contingency plan. More of a contingency discussion actually. 
> The point is to discuss future events before they happen. If the result is 
> “it’s not worth thinking about now, let's decide when/if we get there” then 
> that’s valid outcome.
> 
>> On 26 Apr 2020, at 17:34, ⁨אורי⁩ <⁨u...@speedy.net 
>> ⁩> wrote:
>> 
>> 
>> On Sun, Apr 26, 2020 at 7:14 PM Tom Forbes > > wrote:
>> Hello,
>> Given the recent worldwide situation I’ve found myself thinking a lot about 
>> contingency plans recently. I wanted to raise a question about our reliance 
>> on Google Groups and if we had any contingency plans if this service was 
>> shut down?
>> 
>> To put it politely, it's pretty obvious that Google Groups is in 
>> “maintenance mode” and there is little, if any, active development. 
>> Alongside this:
>> 1. Google has apparently broken core functionality like advanced searching, 
>> and left it broken for years at a time 
>> (https://en.wikipedia.org/wiki/Google_Groups#Google_Groups 
>> )
>> 2. Google itself has shut down down maintenance-mode services before even if 
>> they have an active user base (see Google Reader)
>> 3. Google Groups clearly doesn’t bring any revenue to Google at all, and is 
>> probably a legal liability.
>> 
>> Given this, if we have not already we should maybe consider what we would do 
>> if it was announced tomorrow that Google Groups was shutting down in 3 to 6 
>> months?
>> 
>> Perhaps we’ve already considered this but I couldn’t find any discussions 
>> about this (and it’s hard to search for threads that reference “Google 
>> Groups” as every thread contains that string!). Some food for thought: the 
>> Python development mailing lists (i.e 
>> https://mail.python.org/archives/list/python-...@python.org/ 
>> ) are 
>> browsable through a service called HyperKitty 
>> (https://gitlab.com/mailman/hyperkitty 
>> ), which is built with Django. We 
>> could potentially ask for a mailing list on the python.org 
>>  mail server or we could host HyperKit

Re: Google Groups contingency plan

[Abayomi Oloko]

I think it’s premature to posit that Groups isn’t going to die. To be honest, I 
have been thinking along the line of your original post and wondering what 
would happen should Google adopt a policy change towards groups. Moreover, one 
cannot be certain that Groups will be perpetual. I will advise we stay on the 
course of a plan B just in case.

Sent from my iPhone

> On Apr 26, 2020, at 4:45 PM, Tom Forbes  wrote:
> 
> Actually, after taking a look I found that there is actually a new version of 
> Groups that is in beta 
> (https://support.google.com/a/answer/9687393?hl=en&ref_topic=14869). It seems 
> they are more tightly integrating it with G-Suite, and targeting it towards 
> schools and businesses rather than public mailing lists/usenet archives. 
> 
> Some features are potentially being deprecated 
> (https://support.google.com/a/answer/9687393?hl=en&ref_topic=14869#deprecated),
>  but I don’t think we use any of those.
> 
> I’m glad that Groups isn’t going to die, and I guess perhaps it makes this 
> thread redundant, but the lack of an easy export is troubling and unexpected. 
> Perhaps with the new release it might be possible without resorting to 
> screen-scraping the public index pages?
> 
> Tom
> 
>>> On 26 Apr 2020, at 21:14, Adam Johnson  wrote:
>>> 
>>>  I think python.org and Django are managed by different (legal) entities so 
>>> it doesn't make sense for Django mailing lists to use the domain name 
>>> python.org
>> 
>> I think it's fine to share with them, if possible.  As Tom, says other 
>> projects like scikit do.
>> 
>> 
>> Tom - you didn't mention backing up the archives. I had a search and it 
>> seems there's no official tool, but there is a script here: 
>> https://geek.co.il/2018/05/16/migrating-google-groups-archives-between-accounts
>>  . I think having a trial run ofthis would be a good first step to knowing 
>> where we're at with preserving the data.
>> 
>> 
>> On Sun, 26 Apr 2020 at 17:45, Tom Forbes  wrote:
 I think python.org and Django are managed by different (legal) entities so 
 it doesn't make sense for Django mailing lists to use the domain name 
 python.org
>>> 
>>> That’s a good point, it was just an idea. However running mailserver can be 
>>> annoying and there are economies of scale when it comes to security, spam 
>>> filtering and ease of administration. We could potentially have a 
>>> django.com mailing list address that points at a mailsever managed by 
>>> python.org, and other projects like scikit have their mailing lists hosted 
>>> by them. 
>>> 
 Actually as far as I see it, we only need mailing lists and don't need any 
 web interface features we get from Google Groups
>>> 
>>> We certainly do need it, if only for historic searching. User management 
>>> and other niceties are great to have as well.
>>> 
 why do we have to worry about it now
>>> 
>>> I mean, it’s a contingency plan. More of a contingency discussion actually. 
>>> The point is to discuss future events before they happen. If the result is 
>>> “it’s not worth thinking about now, let's decide when/if we get there” then 
>>> that’s valid outcome.
>>> 
 On 26 Apr 2020, at 17:34, ⁨אורי⁩ <⁨u...@speedy.net⁩> wrote:
 
 
> On Sun, Apr 26, 2020 at 7:14 PM Tom Forbes  wrote:
> Hello,
> Given the recent worldwide situation I’ve found myself thinking a lot 
> about contingency plans recently. I wanted to raise a question about our 
> reliance on Google Groups and if we had any contingency plans if this 
> service was shut down?
> 
> To put it politely, it's pretty obvious that Google Groups is in 
> “maintenance mode” and there is little, if any, active development. 
> Alongside this:
> 1. Google has apparently broken core functionality like advanced 
> searching, and left it broken for years at a time 
> (https://en.wikipedia.org/wiki/Google_Groups#Google_Groups)
> 2. Google itself has shut down down maintenance-mode services before even 
> if they have an active user base (see Google Reader)
> 3. Google Groups clearly doesn’t bring any revenue to Google at all, and 
> is probably a legal liability.
> 
> Given this, if we have not already we should maybe consider what we would 
> do if it was announced tomorrow that Google Groups was shutting down in 3 
> to 6 months?
> 
> Perhaps we’ve already considered this but I couldn’t find any discussions 
> about this (and it’s hard to search for threads that reference “Google 
> Groups” as every thread contains that string!). Some food for thought: 
> the Python development mailing lists (i.e 
> https://mail.python.org/archives/list/python-...@python.org/) are 
> browsable through a service called HyperKitty 
> (https://gitlab.com/mailman/hyperkitty), which is built with Django. We 
> could potentially ask for a mailing list on the python.org mail server or 
> we could host HyperKitty and M

Re: Google Groups contingency plan

[Alex Krupp]

If someone has all of the email messages going back to the beginning of the
group in a Gmail account, it would be very easy to export them that way and
then either re-host them elsewhere on the web or else put them into a long
term preservation format so that people can download them and use them
locally. Here is a good report on the current state of email archiving, in
terms of options for preserving them for local use:
https://www.clir.org/pubs/reports/pub175/

In terms of re-hosting them, my software (www.fwdeveryone.com) could
process all of the raw email messages to make them suitable for display on
the web, and then they could be re-hosted wherever. They come out looking like
this  by default, but the
API response serving the processed threads is the main thing of value,
using that the actual display can be re-styled to look like whatever. (If
you don't get what I mean by processing, compare the API response for that
thread with what you see when you do "show original" in Gmail.)

Alex

On Sun, Apr 26, 2020 at 8:11 PM Abayomi Oloko 
wrote:

> I think it’s premature to posit that Groups isn’t going to die. To be
> honest, I have been thinking along the line of your original post and
> wondering what would happen should Google adopt a policy change towards
> groups. Moreover, one cannot be certain that Groups will be perpetual. I
> will advise we stay on the course of a plan B just in case.
>
> Sent from my iPhone
>
> On Apr 26, 2020, at 4:45 PM, Tom Forbes  wrote:
>
> Actually, after taking a look I found that there is actually a new version
> of Groups that is in beta (
> https://support.google.com/a/answer/9687393?hl=en&ref_topic=14869). It
> seems they are more tightly integrating it with G-Suite, and targeting it
> towards schools and businesses rather than public mailing lists/usenet
> archives.
>
> Some features are potentially being deprecated (
> https://support.google.com/a/answer/9687393?hl=en&ref_topic=14869#deprecated),
> but I don’t think we use any of those.
>
> I’m glad that Groups isn’t going to die, and I guess perhaps it makes this
> thread redundant, but the lack of an easy export is troubling and
> unexpected. Perhaps with the new release it might be possible without
> resorting to screen-scraping the public index pages?
>
> Tom
>
> On 26 Apr 2020, at 21:14, Adam Johnson  wrote:
>
>  I think python.org and Django are managed by different (legal) entities
>> so it doesn't make sense for Django mailing lists to use the domain name
>> python.org
>
>
> I think it's fine to share with them, if possible.  As Tom, says other
> projects like scikit do.
>
>
> Tom - you didn't mention backing up the archives. I had a search and it
> seems there's no official tool, but there is a script here:
> https://geek.co.il/2018/05/16/migrating-google-groups-archives-between-accounts
> . I think having a trial run ofthis would be a good first step to knowing
> where we're at with preserving the data.
>
>
> On Sun, 26 Apr 2020 at 17:45, Tom Forbes  wrote:
>
>> I think python.org and Django are managed by different (legal) entities
>> so it doesn't make sense for Django mailing lists to use the domain name
>> python.org
>>
>>
>> That’s a good point, it was just an idea. However running mailserver can
>> be annoying and there are economies of scale when it comes to security,
>> spam filtering and ease of administration. We could potentially have a
>> django.com mailing list address that points at a mailsever managed by
>> python.org, and other projects like scikit have their mailing lists
>> hosted by them.
>>
>> Actually as far as I see it, we only need mailing lists and don't need
>> any web interface features we get from Google Groups
>>
>>
>> We certainly do need it, if only for historic searching. User management
>> and other niceties are great to have as well.
>>
>> why do we have to worry about it now
>>
>>
>> I mean, it’s a contingency plan. More of a contingency discussion
>> actually. The point is to discuss future events before they happen. If the
>> result is “it’s not worth thinking about now, let's decide when/if we get
>> there” then that’s valid outcome.
>>
>> On 26 Apr 2020, at 17:34, ⁨אורי⁩ <⁨u...@speedy.net⁩> wrote:
>>
>>
>> On Sun, Apr 26, 2020 at 7:14 PM Tom Forbes  wrote:
>>
>>> Hello,
>>> Given the recent worldwide situation I’ve found myself thinking a lot
>>> about contingency plans recently. I wanted to raise a question about our
>>> reliance on Google Groups and if we had any contingency plans if this
>>> service was shut down?
>>>
>>> To put it politely, it's pretty obvious that Google Groups is in
>>> “maintenance mode” and there is little, if any, active development.
>>> Alongside this:
>>> 1. Google has apparently broken core functionality like advanced
>>> searching, and left it broken for years at a time (
>>> https://en.wikipedia.org/wiki/Google_Groups#Google_Groups)
>>> 2. Google itself has shut down down maintenance-mode se

Re: Generate JWTs with Django

[James Bennett]

On Sun, Apr 26, 2020 at 8:46 AM Adam Johnson  wrote:
>
> James, I too would like to know your criticisms! I've always understood that 
> they aren't much different to signed cookies, but I haven't looked too deeply 
> at them.

Well, people asked. So.

The short summary is: JWT is over-complex, puts too much power in the
attacker's hands, has too many configuration knobs, and makes poor
cryptographic choices. This is why we see vulnerabilities in JWT
libraries and JWT-using systems again and again and again.

And even if you get every single bit of it right, in the ideal perfect
world with the ideal perfect implementation, the payoff is you've put
in a ton of work to get something that already existed: signed
cookies, for the use case of session identification, or any of several
better token or token-like systems -- everything from PASETO to just
timestamped HMAC'd values -- for the use case of inter-service
communication.

The longer version goes more like this...

JWT is a more complex thing than many people appreciate. In fact, it's
at least *five* things, each specified in its own RFC, plus some more
you have to know about and implement if you want any hope of getting
the actually-sorta-secure version. And right off the bat, that's
worrying: the more different things you have to implement, and the
more places you have to look to find out what and how to implement,
the more opportunities there are to make mistakes.

This complexity comes from the sheer number of different options JWT
tries to support, which in turn is an anti-pattern. JWTs may be
signed, or they may not. They may be encrypted, or they may not. There
are multiple different options for how to sign, how to encrypt, how to
manage and specify keys... in a well-designed system there would be
far fewer options. Ideally, there'd be only one option, and the
solution for a vulnerability being found in it would be to increment
the version of the underlying spec, and change to something
better.

Anyway. In JWT, signature and encryption schemes are effectively
negotiable, which is yet another anti-pattern: you are putting
enormous power in the hands of attackers to negotiate you down to a
bad, or nonexistent, cipher/algorithm for encryption or signing. TLS/SSL
learned this lesson the hard way; JWT has chosen not to learn it at
all. Worse, JWT embeds the negotiation about how to handle the token
into the token itself. This is just asking for trouble, and in fact
trouble has routinely occurred. As a somewhat sarcastic author of my
acquaintance put it:

> It is extraordinarily easy to screw up JWT. JWT is a JSON format
> where you have to parse and interpret a JSON document to figure out
> how to decrypt and authenticate a JSON document. It has revived bugs
> we thought long dead, like “repurposing asymmetric public keys as
> symmetric private keys”.

(from: https://latacora.micro.blog/a-childs-garden/)

More succinctly: JWTs inherently and unavoidably violate the
Cryptographic Doom Principle
(https://moxie.org/blog/the-cryptographic-doom-principle/). Worse,
JWTs put full control of the violation in the hands of the attacker,
who -- thanks to the high level of configurability JWT offers -- is
free to find the set of options most likely to compromise you, and
foist them on you.

That quoted line above about revived long-dead bugs is no joke,
incidentally. Here's one from a few years back:

https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/

Five different libraries, written in three different languages, all
had the same bug. I once had the misfortune of arguing with someone
who attributed this to the libraries being built by bad programmers,
or in bad languages. But I personally tend to agree with a line from
this talk:

https://www.okta.com/video/oktane19-cryptographic-wrong-answers/

> Now you can say look those are all implementation vulnerabilities,
> it's not actually JWTs fault, I disagree. If I can find the same
> vulnerability in five popular libraries, then maybe the spec did a
> bad job of making sure people avoided that vulnerability.

So to completely head off the "it's just bad implementations"
argument, let's turn to the specs themselves: RFCs 7515, 7516, 7517,
7518, and 7519 are the core specifications that make up with is
commonly called "JWT" (and in RFC-land is more properly called "JOSE"
-- "JSON Object Signing and Encryption", of which the token format is
but one part).

The JOSE RFCs make a number of choices regarding default sets of
standardized cryptographic options. For example, RFC 7518 standardizes
thirteen signature algorithm options, seventeen encryption key
management options, and six different encryption cipher options.

This is already a problem -- that's an absolutely gigantic
combinatorial space of options! But then it gets worse.

Let's look just at the first table of options in that RFC, which is
for signing algorithms. It categorizes them as "Required",
"Recommended+", "Recommended", or "Opti

Re: Generate JWTs with Django

[Ryan Hiebert]

On Sun, Apr 26, 2020 at 9:53 PM James Bennett  wrote:

> On Sun, Apr 26, 2020 at 8:46 AM Adam Johnson  wrote:
>
> The short summary is: JWT is over-complex, puts too much power in the
> attacker's hands, has too many configuration knobs, and makes poor
> cryptographic choices. This is why we see vulnerabilities in JWT
> libraries and JWT-using systems again and again and again.
>
> And even if you get every single bit of it right, in the ideal perfect
> world with the ideal perfect implementation, the payoff is you've put
> in a ton of work to get something that already existed: signed
> cookies, for the use case of session identification, or any of several
> better token or token-like systems -- everything from PASETO to just
> timestamped HMAC'd values -- for the use case of inter-service
> communication.
>

Thank you very much for this write-up. The mention of PASETO was
particularly helpful to me. I was aware of the big all-library issue due to
algorithm negotiation and public/symmetric forgery, but not the others you
mentioned.

For my use-case, I need a signed payload that is server-verified and
client-readable. It sounds like PASETO is what you might recommend that I
use, instead of JWTs, IIUC.

Would you think that the motivation that started this thread might be well
served with having that as PASETO, or would it be better in your estimation
to avoid either JWT or PASETO in Django at this time? I can imagine that
Django using PASETO could give it a signal boost, but of course if there
were discovered some design flaw there, it would also entrench it more as
well as making it a security issue that Django has to address.

Either way, I really appreciate you taking the time to let us hear your
thoughts.

Ryan

-- 
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/CABpHFHTTYkQ3FsK4LOj%2B_kc-ZMyicdBSFTqFd1e370EnFHoPXA%40mail.gmail.com.