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

[James Bennett]

While I think Adam's right that adding one or two new settings
wouldn't be a problem, I do worry about the ongoing proliferation, and
it's a thing that I keep wanting to try to find the time to work on
but never actually succeed at.

Separate from the suggestion of a generic way to add headers on every
response, I've been leaning for a while toward the idea of
consolidating the security-header settings the way we've already
consolidated database and template settings. We can paint the bikeshed
whatever color, but suppose for sake of an example name we add a
SECURITY_HEADERS setting, with each one configured under its own key.
That would allow X-Frame-Options, content sniffing, HSTS,
Referrer-Policy, opener policy, and future stuff like CSP, built-in
CORS, etc. to all be defined in a single place that doesn't
proliferate a huge number of new settings, or require adding and
supporting a new setting every time a new one comes along (which, with
security headers, is about twice a week these days).

For now I think the best thing would be to accept the opener-policy
work as-is, then get consensus around a proposal for how future
security headers should be handled.

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

Re: Django default input validation accepts special caracters

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

> Backwards compatibility is the bigger concern here.

I understand that, I believe there is always a way, because prior to 2008 when 
I switched to Django, I was commiter on a PHP library group that not only had 
the best code quality: but COMMITS to maintaining BC. Code that I have made 
prior to 2008 still works today with the last releases. Since then, I've been 
upgrading a lot of code, maintaining django packages with millions of downloads 
from Python 2 and Django 1 to nowadays and contribute the same to many 
libraries as much as I can, often proud to be the first to offer a patch, as 
such, I most definitely understand the cost of not maintaining BC.

I love BC, I think maintaining it is a challenge that always deserves as much 
time and effort as possible.

But, since Django broke BC for on_delete, which I accept to be "for the greater 
good", I just wanted to at least discuss how this could be done to improve the 
results of security audits for all Django users, and not just me and my 20 yrs 
of pro xp, I'm too 1337 to need it for myself, I thought it was worth 
discussing about it for others.

On a more emotional note, which I hope you will understand as **I've just been 
fired by one of the developers that I have admired most for more than a decade 
now, just for following OWASP recommandations**, no matter that I'm mentionning 
that my competitors do at least the same:

THANK YOU Rene,

For not completely discarding everything I offer for debate, it's been a while 
since django-developers make me feel like "just a craze", despite that I do 
actually maintain both governmental and financial websites in production which 
I develop and manage tech teams of, as part of different customers, and a lot 
of the money I make I actually throw away to other developers on R&D and other 
cool stuff which I wish I could be working on full time.

To others: keep up the great work, Django is a fantastic project and I love it, 
last year I took a few months to assess all other more recent languages and 
frameworks I could find, with the purpose of deciding what my stack would be 
for the next decade and guess what: it's still Django ;)

<3

-- 
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/TrcSP2vCQe456Y-cKDkXK0HQMTiB-EsVd9ctmfkG5ZPDdqznDehSt8m-wjt6mHo51mAjoAk_9Kg5RcJrKDjBAqywkOpcfPDZ5aNFgtpsnKg%3D%40protonmail.com.

Re: Django default input validation accepts special caracters

[René Fleschenberg]

Hi,

But when you are making a governmental website for example: you need 
actual identity.


Django makes it possible (I'd even say easy) to setup your forms / 
models to enforce stricter requirements if you have to. We don't have to 
treat these cases as the default. Backwards compatibility is the bigger 
concern here.


Regards,
René

--
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/19bea9a3-2006-8120-4657-63ff0116b5e8%40fleschenberg.net.

Re: Django default input validation accepts special caracters

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

> This may be true - not all people have first_name & last_name or want to use 
> them online. But it's also convenient to be able to call a person by their 
> first name, and also allow them to use their full name on the website.

I completely agree with you, for example on dating sites like speedy or things 
like that.

But when you are making a governmental website for example: you need actual 
identity.

Same goes when you're manipulating money: most countries require you to partake 
in the fight against money laundering and they will not allow you to take/pay 
people without a valid identity (KYC/KYB).

If you want to access a governmental or banking service online with a fake 
identity or forged documents you might just end up in jail.

-- 
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/Q-dp6hMqMJx8yM0IrpnkIvOwpEetC2GJ_gxbGPgH77e9X4-sFQSerBIucvObkh61PEah37kpqZGI0soiurj9IpLKflLdaCX_mzdxspDgmWg%3D%40protonmail.com.

Re: Django default input validation accepts special caracters

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

Opened an issue on the OWASP project, reporting the reasoning of the consensus 
made on this mailing list as best as I could:

https://github.com/OWASP/CheatSheetSeries/issues/472

Please feel free to comment or request changes on the issue.

-- 
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/dEwdPhKAegZD-Mp640uZ_nXcyYFvvFRyJeTs5iO1TBZaPgnvv6B24ANMYf9Z7kOTRNb69BtcbZpoJ0gNGVV6vSAHXeMGQgxCz_Hv_V6V0t4%3D%40protonmail.com.

Re: Django default input validation accepts special caracters

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

> Input validation is performed to ensure only properly formed data is entering 
> the workflow in an information system, preventing malformed data from 
> persisting in the database and triggering malfunction of various downstream 
> components. Input validation should happen as early as possible in the data 
> flow, preferably as soon as the data is received from the external party.
>
> Data from all potentially untrusted sources should be subject to input 
> validation, including not only Internet-facing web clients but also backend 
> feeds over extranets, from [suppliers, partners, vendors or 
> regulators](https://badcyber.com/several-polish-banks-hacked-information-stolen-by-unknown-attackers/),
>  each of which may be compromised on their own and start sending malformed 
> data.
>
> Input Validation should not be used as the primary method of preventing 
> [XSS](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html),
>  [SQL 
> Injection](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html)
>  and other attacks which are covered in respective [cheat 
> sheets](https://cheatsheetseries.owasp.org/) but can significantly contribute 
> to reducing their impact if implemented properly.

https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html

-- 
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/UGSjWB0yN5mSHouGwK5tTmvXmJ0kuJmESgGaRdTh8Q4MKH4lvv6US_mn0t_rTdMV6U8ehA7yyeGDEdYieUPvnO3qCNDBY7u3JXVCOcQ3W6k%3D%40protonmail.com.

Re: include_block template tag

[Carlton Gibson]

Hey Sam. 

(“I” is a placeholder in what follows…)

What I’m missing here, personally, having read this thread, and the old-one is 
motivating examples where I go "wow, yeah, that would really make my life 
easier”.  

I read it and think yeah maybe. I see a couple of positive comments from people 
who’s judgement I would trust. But I STILL don’t really see what I’d gain. (I 
could spend hours thinking over it but it’s not clear I have that time.) 

Then I see Curtis, who’s judgement I do trust, saying “I have this (or similar) 
working in my package over here”. I then think, well let’s push forward with 
that, and I’ll put it on the list to check out next time I need something in 
this ballpark. (Not a placeholder: I think I recall Curtis showing me this 
package in Florence a few years ago, but I have to admit to forgetting about it 
until this thread came up.) 

I suspect it’s not really that pressing: after all this time, maybe a custom 
tag is good/easy enough…? — the recent survey showed that people aren’t 
abandoning the DTL on mass: the lack of this feature doesn’t seem to be enough 
to make people jump ship. 

Maybe this is the missing feature, but can be show WHY it would be so good? 

I think compelling use-cases gain converts. The advantage of the third-party 
package is it allows that to be worked out, outside the main development cycle, 
which is so slow, and had such strong backwards compatibility constraints that 
we simply can’t take things which are fully worked out… — it has to be right, 
or there about when we first take it. 

C. 




> On 19 Aug 2020, at 15:34, Sam Willis  wrote:
> 
> Hi Carlton, 
> 
> Thanks for chipping in.
> 
> As a long time user of Django (I first stated with it back in 2006) from my 
> experience where is excels is in providing a full toolbox for building things 
> for the web. The most successful “third party” apps and library’s tend to be 
> very large editions of functionality rather than small functions and template 
> tags. I personally stay away from small libraries as I have been bitten 
> before when they are no longer maintained.
> 
> One of the criticisms of Node.js and from personal experience reasons why 
> people prefer Django and similar “everything included” frameworks is the 
> fragmentation of tools and large number of dependancies.
> 
> For this reason I don’t think there will ever be a successful “third party” 
> implementation of this particular idea. It’s not a big enough tool for people 
> to justify adding to their dependancies. (People are more likely to swap to 
> Jinja which has Macros and are “sort of” similar if you squint at them)
> 
> Also, last year I had a quick look at my old implementation again and I think 
> I came to the conclusion that it would require some small changes to core in 
> order to work. I don’t remember what they are now though.
> 
> I understand completely that the barrier for adding new functionality to 
> Django should be high. It important to maintain its “maintainability” and 
> stop feature creep, but I also think that there is a risk of not developing 
> new ideas and attracting new developers and users if it is only “maintained”.
> 
> (Obviously there are new things happing like the incredible and exciting work 
> going into async!)
> 
> Anyway, to summarise, I think this needs to be in core to get traction and 
> for people to discover it. For some ideas going the external route to prove 
> it certainly makes sense but for others (like this) I think it should be 
> developed though consensus in the core framework.
> 
> Reusable template components are still an unsolved problem that would be 
> lovely to solve.
> 
> Thanks!
> Sam
> On Wednesday, August 19, 2020 at 1:05:15 PM UTC+1 jure.er...@gmail.com 
>  wrote:
> It definitely does. Thanks. 
> 
> Jure 
> 
> On 19/08/2020 14:03, Carlton Gibson wrote: 
> > From the thread, I’d suggest collaboration with Curtis if the ideas are 
> > similar enough. 
> > 
> > Also from the thread: the idea seems to fit between include as we have it 
> > now, and a custom tag. 
> > Maybe that gap hasn’t been wide enough to grasp sufficient interest? 
> > 
> > I think the standard path for inclusion into core goes more or less: 
> > 
> > * Here’s an idea 
> > * Here’s a third-party implementation. 
> > * Everyone[*] is using it, and the troubles have been ironed-out 
> > * let’s merge it. 
> > 
> > [*]: Everyone ≈ a good number. 
> > 
> > For a third-party lib, there’s no need for it ever get to the last step. 
> > (It could but it doesn’t have to.) 
> > Everything we can keep somewhere else makes Django more maintainable, so 
> > there’s a general preference for NOT including things if possible. 
> > 
> > Hopefully that makes sense. 
> > 
> > Kind Regards, 
> > 
> > Carlton 
> > 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group

Re: Django default input validation accepts special caracters

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

And I'm sorry if I offended Mister alert("pwnd") :)

-- 
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/pgzhWU0l240Rjq8dO-yUh0TVOMNTGqXfoQi8-cU1XIJ6r3bhOMmnQ6SWXS6EmErgpNtQ0HIH4Q0TBF_IY-MKIohSQnyte_QiUym_m99xa_U%3D%40protonmail.com.

Re: Django default input validation accepts special caracters

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

Thanks for the comment Florian, it's just basic hygiene really, don't leave 
open ports you don't need, never trust user inputs for characters they don't 
need, and so on.

-- 
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/0neKwVz0CQQwuCPoAPpu_FszKel8xGFohA1OF1mtwxeGsxI6_aYyuZ9P7qOqFnkHSOkD3Vaf8yHdAAZQ-kRyJ8-A8jwiNyPIeb8GaCtib0g%3D%40protonmail.com.

Re: include_block template tag

[Sam Willis]

Hi Carlton, 

Thanks for chipping in.

As a long time user of Django (I first stated with it back in 2006) from my 
experience where is excels is in providing a full toolbox for building 
things for the web. The most successful “third party” apps and library’s 
tend to be very large editions of functionality rather than small functions 
and template tags. I personally stay away from small libraries as I have 
been bitten before when they are no longer maintained.

One of the criticisms of Node.js and from personal experience reasons why 
people prefer Django and similar “everything included” frameworks is the 
fragmentation of tools and large number of dependancies.

For this reason I don’t think there will ever be a successful “third party” 
implementation of this particular idea. It’s not a big enough tool for 
people to justify adding to their dependancies. (People are more likely to 
swap to Jinja which has Macros and are “sort of” similar if you squint at 
them)

Also, last year I had a quick look at my old implementation again and I 
think I came to the conclusion that it would require some small changes to 
core in order to work. I don’t remember what they are now though.

I understand completely that the barrier for adding new functionality to 
Django should be high. It important to maintain its “maintainability” and 
stop feature creep, but I also think that there is a risk of not developing 
new ideas and attracting new developers and users if it is only 
“maintained”.

(Obviously there are new things happing like the incredible and exciting 
work going into async!)

Anyway, to summarise, I think this needs to be in core to get traction and 
for people to discover it. For some ideas going the external route to prove 
it certainly makes sense but for others (like this) I think it should be 
developed though consensus in the core framework.

Reusable template components are still an unsolved problem that would be 
lovely to solve.
Thanks!
Sam
On Wednesday, August 19, 2020 at 1:05:15 PM UTC+1 jure.er...@gmail.com 
wrote:

> It definitely does. Thanks.
>
> Jure
>
> On 19/08/2020 14:03, Carlton Gibson wrote:
> > From the thread, I’d suggest collaboration with Curtis if the ideas are 
> similar enough.
> >
> > Also from the thread: the idea seems to fit between include as we have 
> it now, and a custom tag.
> > Maybe that gap hasn’t been wide enough to grasp sufficient interest?
> >
> > I think the standard path for inclusion into core goes more or less:
> >
> > * Here’s an idea
> > * Here’s a third-party implementation.
> > * Everyone[*] is using it, and the troubles have been ironed-out
> > * let’s merge it.
> >
> > [*]: Everyone ≈ a good number.
> >
> > For a third-party lib, there’s no need for it ever get to the last step. 
> (It could but it doesn’t have to.)
> > Everything we can keep somewhere else makes Django more maintainable, so 
> there’s a general preference for NOT including things if possible.
> >
> > Hopefully that makes sense.
> >
> > Kind Regards,
> >
> > Carlton
> >
>

-- 
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/4b1a3f96-9fa4-4ab3-9213-b00911a57750n%40googlegroups.com.

Re: include_block template tag

[Jure Erznožnik]

It definitely does. Thanks.

Jure

On 19/08/2020 14:03, Carlton Gibson wrote:

 From the thread, I’d suggest collaboration with Curtis if the ideas are 
similar enough.

Also from the thread: the idea seems to fit between include as we have it now, 
and a custom tag.
Maybe that gap hasn’t been wide enough to grasp sufficient interest?

I think the standard path for inclusion into core goes more or less:

* Here’s an idea
* Here’s a third-party implementation.
* Everyone[*] is using it, and the troubles have been ironed-out
* let’s merge it.

[*]: Everyone ≈ a good number.

For a third-party lib, there’s no need for it ever get to the last step. (It 
could but it doesn’t have to.)
Everything we can keep somewhere else makes Django more maintainable, so 
there’s a general preference for NOT including things if possible.

Hopefully that makes sense.

Kind Regards,

Carlton



--
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/52b88e00-c2f7-1d10-f4e1-76d24294ba90%40gmail.com.

Re: include_block template tag

[Carlton Gibson]

>From the thread, I’d suggest collaboration with Curtis if the ideas are 
>similar enough. 

Also from the thread: the idea seems to fit between include as we have it now, 
and a custom tag. 
Maybe that gap hasn’t been wide enough to grasp sufficient interest? 

I think the standard path for inclusion into core goes more or less:

* Here’s an idea
* Here’s a third-party implementation. 
* Everyone[*] is using it, and the troubles have been ironed-out
* let’s merge it. 

[*]: Everyone ≈ a good number. 

For a third-party lib, there’s no need for it ever get to the last step. (It 
could but it doesn’t have to.)
Everything we can keep somewhere else makes Django more maintainable, so 
there’s a general preference for NOT including things if possible. 

Hopefully that makes sense. 

Kind Regards,

Carlton

-- 
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/8D0FCDDA-AA5B-443F-9C10-FCC5D9F64C6C%40gmail.com.

Re: include_block template tag

[Jure Erznožnik]

Hi Sam,

It seems that even your complete proposal with working code did not 
receive any attention from the core developers at the time. It would 
seem from that thread that Jonathan Slenders also made a similar 
proposal / solution and it too was rejected. Well, his was at least 
rejected - judging by his post.


Gathering such proposals in external projects like sniplates (proposed 
by Curtis) seems like a good approach as long as the target library has 
such enhancements in its scope. It would seem Curtis has issues 
implementing stuff like that though: he proposed the same to you as 
well, you allowed it, but it's not in his library.


Given the evidence, it seems there is no interest in core team to do 
something like this. I am yet to figure out how decisions on feature set 
are made: I have not found any document stating missions for various 
django parts. Something like that could be very helpful in determining 
whether to propose something to this list at all. It is difficult to 
determine whether something would benefit from being in core django vs 
in a separate library.


LP,

Jure

On 18/08/2020 17:57, Sam Willis wrote:

Hi Jure,

I think this would be a great addition to Django!

I also proposed something a few years ago which was almost identical 
(https://groups.google.com/d/msg/django-developers/-75sOjhJuRU/ax_TZJgRmPQJ) 
and had a basic implementation (it probably won't work anymore without 
some tweaks). However from my experience then it will be difficult to 
get this into core without the championing from a core developer.


If there was enough interest I would certainly be happy to contribute 
to the feature!


Sam

On Monday, August 17, 2020 at 10:05:29 AM UTC+1, Jure Erznožnik wrote:

While rendering templates we often come into situations where data
remains the same, but sometimes we want to render it one way,
other times - another.

Examples:

a library supporting various CSS frameworks. You would always
render panel

title and panel body, but bootstrap does it using one HTML,
material uses another.

you may decide to render a piece of data in a panel, input, table
cell, etc.

analysis:

There's a huge note with include tag

clarifying how include tag is NOT used for purposes listed above.
This leads me to believe (but I have not researched it thoroughly)
that the question has been asked many times before.

proposal:

implement support for passing HTML renders into an included template.

I see two possible approaches for this:

Approach 1 template example:

{% includeblock template with ... %}
    {% subblock block1 %}
 HTML code
    {% endsubblock %}
    {% subblock block2 %}
 HTML code
    {% endsubblock %}
{% endincludeblock %}

block1 and block2 would be blocks defined in template using
existing block syntax. I'm not sure if recycling existing block
tag would be possible in this context, but I would certainly
prefer to avoid new template tag syntax. Basically what this tag
would do is first evaluate the subblocks, then override the blocks
defined in the template, then render the template.

Approach 2 template example:

{% block block1 as block1_var %}
   HTML code
{% endblock %}
{% subblock block2 %}
   HTML code
{% endsubblock %}
{% include template with block1=block1_var block2=block2_var %}

This approach is a bit less structured than the first one, but it
requires a lot less modification. Basically it would only add the
with parameter to store block render in a variable instead of
actually rendering it to output. Possible problem with block
inheritance within the template.


Would either of the above be interesting to include in Django
templating code?

Thanks for your consideration,
Jure

--
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/bb721678-2220-41ae-8624-29661df353f2o%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...@googlegr

Fellow Reports -- August 2020

[Carlton Gibson]

Hi all. 


Calendar Week 32 -- ending 09 August.


Triaged:

https://code.djangoproject.com/ticket/31864 -- Session data cannot be 
decoded during the transition to Django 3.1. (Accepted)
https://code.djangoproject.com/ticket/31862 -- Add ArrayField for all 
supported databases - not only postgres (invalid)
https://code.djangoproject.com/ticket/31858 -- space outside of parameters 
are not allowed in path() routes (Accepted)
https://code.djangoproject.com/ticket/31860 -- "__date" in F 
expression not working, have to use Func() (Duplicate of #31639)
https://code.djangoproject.com/ticket/31861 -- Model field for enumeration 
types (Duplicate of #24342)
https://code.djangoproject.com/ticket/19040 -- Allow declaring a model 
Manager class inside the model class (wontfix)
https://github.com/django/asgiref/issues/186 -- Migration from wsgi to asgi 
questions #186 (invalid)
https://code.djangoproject.com/ticket/31856 -- Add block to customize nav_ 
sidebar style and script. (invalid)
https://code.djangoproject.com/ticket/31855 -- Flag for Initial Database 
Engine (wontfix)
https://code.djangoproject.com/ticket/31854 -- Long model names are not 
wrapped in the navigation sidebar. (Accepted)
https://code.djangoproject.com/ticket/31853 -- In some languages, such as 
Chinese, the Add button text of the navigation bar is wrapped (Accepted)
https://code.djangoproject.com/ticket/31852 -- Support async generators in 
StreamingHttpResponse (needsinfo)
https://code.djangoproject.com/ticket/31845 -- CSRF check fails when 
browsing with FQDN with trailing dot (wontfix)
https://code.djangoproject.com/ticket/31847 -- Adding table prefix 
stripping to inspectdb (wontfix)
https://code.djangoproject.com/ticket/31846 -- inspectdb doesn't 
handle tables with "id" field and without primary key (worksforme)
https://code.djangoproject.com/ticket/31844 -- When running migrations, the 
origional starting migrations should be shown. (wontfix)



Reviewed:

https://github.com/django/django/pull/13282 -- Refs #31864 -- Doc'd 
that DEFAULT_HASHING_ALGORITHM requires 3.1.1+ in release notes.
https://github.com/django/django/pull/13256 -- Added README link to DSF 
fundraising page.~
https://github.com/django/django/pull/13173 -- Fixed #25513 -- Extracted 
admin pagination to Paginator.get_elided_page_range().
https://github.com/django/django/pull/13272 -- Added Hypercorn to ASGI 
deployment guide.
https://github.com/django/django/pull/13276 -- Fixed #31856 -- Add block to 
customize nav_sidebar
https://github.com/django/django/pull/13247 -- Fixed #29336 -- Doc'd 
circular template inheritance
https://github.com/django/django/pull/13275 -- Fixed #31854 -- Fixed 
wrapping long model names in admin's sidebar.
https://github.com/django/django/pull/13274 -- Fixed #31853 -- Fixed 
wrapping of translated action labels in admin sidebar.
https://github.com/django/django/pull/13224 -- Fixed #31811 -- Add optional 
timing outputs to the test runner
https://github.com/django/djangoproject.com/pull/1014 -- Updated 
docs-related model fixtures for 3.1 release.
https://github.com/django/djangoproject.com/pull/1012 -- Updated download 
page for 3.1 release.
https://github.com/django/djangoproject.com/pull/1013 -- Updated 
robots.docs.txt for Django 3.1.
https://github.com/django/code.djangoproject.com/pull/104 -- Updated 
default ticket version to 3.1.
https://github.com/django/django/pull/13262 -- Fixed #31842 -- Added 
DEFAULT_HASHING_ALGORITHM transitional setting.
https://github.com/django/django/pull/13268 -- Moved note about features 
deprecated in Django 3.1 above their descriptions.







Calendar Week 33 -- ending 16 August.


Triaged:

https://code.djangoproject.com/ticket/31879 -- Changing a model 
formset's queryset has no effect when self.forms is accessed (Invalid)
https://code.djangoproject.com/ticket/31867 -- Inconsistency rendering 
hidden fields with view-only permissions in admin (Accepted)
https://code.djangoproject.com/ticket/31846 -- MySQL inspectdb doesn't 
handle composite keys (Accepted)
https://code.djangoproject.com/ticket/31865 -- Missing variable in admin 
template (Accepted)



Reviewed:

https://github.com/django/django/pull/13281 -- Fixed #31863 -- Prevented 
mutating model state by copies of model instances.
https://github.com/django/django/pull/13224 -- Fixed #31811 -- Add optional 
timing outputs to the test runner
https://github.com/django/django/pull/13299 -- Fixed #31867 -- Fixed admin 
inline display of hidden fields with view-only permissions.
https://github.com/django/django/pull/13299 -- Fixed #31867 -- Fixed admin 
inline display of hidden fields with view-only permissions.
https://github.com/django/django/pull/12387 -- Fixed #31216 -- Added 
support for colorama terminal colors on Windows.
https://github.com/django/djangoproject.com/pull/1015 -- Updated 
"Other ways to give" fundraising info.
https://github.com/django/djangoproject.com/pull/1017 -- Update isort, 
Python, and PostgreSQL.
https://github.com/django/