Re: Fellow Reports - January 2021
Week ending January 17, 2021 *Triaged:* https://code.djangoproject.com/ticket/32341 - forms.ModelMultipleChoiceField raises TypeError with empty_label argument. (invalid) https://code.djangoproject.com/ticket/32342 - Enable supports_index_column_ordering on MySQL 8.0.1+ (created) https://code.djangoproject.com/ticket/32338 - Accessibility issues with Django forms RadioSelect and CheckboxSelectMultiple (accepted) https://code.djangoproject.com/ticket/32336 - Allow functions in ModelAdmin.readonly_fields. (wontfix) https://code.djangoproject.com/ticket/32348 - Deleting "extra" inlines in admin should not be possible. (accepted) https://code.djangoproject.com/ticket/32352 - Django tests uses SRIDs which gives different results by default on different versions of proj4 (duplicate) https://code.djangoproject.com/ticket/32353 - Add support for PROJ 7.X. (created) https://code.djangoproject.com/ticket/32355 - Drop support for Python 3.6 & 3.7. (created) https://code.djangoproject.com/ticket/12794 - Interaction between sessions and django.views.i18n.set_language causes caching errors (invalid) https://code.djangoproject.com/ticket/32356 - Add url argument to translate tag (invalid) https://code.djangoproject.com/ticket/32354 - HTML in verbose_name (invalid) https://code.djangoproject.com/ticket/32357 - Drop support for PostgreSQL 9.6 and PostGIS 2.3. (created) https://code.djangoproject.com/ticket/32349 - unable to obtain auth template password_reset_done when using namespaced urls (invalid) https://code.djangoproject.com/ticket/32351 - AlterField migration on ForeignKey column fails on fresh DB when referenced model has been subsequently modified (invalid) *Reviewed/committed:* https://github.com/django/django/pull/13856 - Refs #31791 -- Improved performance of URLResolver.resolve(). https://github.com/django/django/pull/13834 - Fixed #32313 -- Corrected QuerySet.in_bulk() signature. https://github.com/django/django/pull/13857 - Refs #32018 -- Used --header-link-color for header links in admin. https://github.com/django/django/pull/13876 - Refs #32018 -- Corrected color variables for paginator and header links in admin. https://github.com/django/django/pull/13668 - Added SpatialFeatures.empty_intersection_returns_none. https://github.com/django/django/pull/11929 - Fixed #26167 -- Added support for functional indexes. https://github.com/django/django/pull/12553 - Fixed #31358 -- Increased salt entropy of password hashers. https://github.com/django/django/pull/13886 - Fixed #32321 -- Added system checks for invalid model field names in functional indexes. https://github.com/django/django/pull/13895 - [3.2.x] Updated source translation catalogs. *Reviewed:* https://github.com/django/django/pull/13892 - Updates for branching stable/3.2.x. *Authored:* https://github.com/django/django/pull/13875 - Fixed #32342 -- Added index order introspection on MySQL 8.0.1+. https://github.com/django/django/pull/13845 - Bootstrapped Django 4.0. https://github.com/django/django/pull/13894 - Fixed #32357 -- Dropped support for PostgreSQL 9.6 and PostGIS 2.3. 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/01b0dfb2-7f4f-4296-bb92-b0c733a611fcn%40googlegroups.com.
Re: Rethink (?) how we handle security headers.
The proposal seems to be a setting of the form:
SECURITY_HEADERS = {
'Strict-Transport-Security': 'max-age=60; includeSubDomains; preload',
...
}
Currently we have system checks to suggest
setting SECURE_HSTS_SECONDS, SECURE_HSTS_PRELOAD, etc. Do you envision
trying to keep these checks? It seems it'll be more complicated to parse
and validate arbitrary string values instead of individual settings.
It seems some headers may still need special handling in
SecurityMiddleware. For example, 'Strict-Transport-Security' is only set if
request.is_secure().
On Friday, August 21, 2020 at 12:53:33 PM UTC-4 Adam Johnson wrote:
> A single SECURITY_HEADERS (or perhaps SECURITY) setting sounds good. Would
> love to get CORS into core too.
>
> The Opener-Policy ticket has been marked as someday/maybe because the
> header is still not widely supported.
>
> On Thu, 20 Aug 2020 at 00:02, James Bennett wrote:
>
>> 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-develop...@googlegroups.com.
>>
> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CAL13Cg8Uf3FdNtK6kbEdZ9Ja7sa5jhg4ptnUGotpzO8hj9B49g%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/26f74d84-4a8a-41a7-8824-e016e3e15dcfn%40googlegroups.com.
