Django security releases issued: 4.0.7 and 3.2.15.
Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2022/aug/03/security-releases/ -- 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/CAJwKpyRZNynRNTqRnE7HCUpNk0Yh1DRg8UUyDZ%2BzFc0pzpcg9g%40mail.gmail.com.
Re: timesince and timeuntil - should we use python-dateutil?
I'd suggest the docs are updated with a warning relating to what's Uri's
found as it could be extremely important to someone and not highlighting it
would be misleading .
On Tuesday, 2 August 2022 at 16:31:33 UTC+1 Uri wrote:
> Hi,
>
> I created my own utility function:
>
>
>
> *from dateutil.relativedelta import relativedelta*
>
> *from django.utils.timesince import TIME_STRINGS as
> timesince_time_strings**from
> django.utils.html import avoid_wrapping*
> *from django.utils.translation import gettext, get_language*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *def timesince(d, now):delta = relativedelta(now, d)years =
> delta.yearsmonths = delta.monthsweeks = delta.days // 7days =
> delta.days - weeks * 7timesince_counts = [(years, "year"), (months,
> "month")]if (years == 0):timesince_counts.append((weeks,
> "week"))if (months == 0):timesince_counts.append((days,
> "day"))result = []for (count, name) in timesince_counts:if
> (count > 0):
> result.append(avoid_wrapping(value=timesince_time_strings[name] % {"num":
> count}))return gettext(", ").join(result)*
>
> I don't need depth>2, I don't need hours and minutes and by definition my
> function returns "" if both dates are the same. now must be bigger than d
> or else I don't know what will happen... I think you just get "" otherwise.
>
>
> https://github.com/speedy-net/speedy-net/blob/master/speedy/core/base/utils.py
>
>
> אורי
> u...@speedy.net
>
>
> On Tue, Aug 2, 2022 at 10:54 AM Carlton Gibson
> wrote:
>
>> Hey Uri.
>>
>> Historically, taking on extra dependencies isn't something we've done
>> lightly.
>> The packaging situation is a lot better these days than it was in
>> earlier years, but with the concerns about supply chain security I think
>> maintaining that position is worthwhile.
>> If we were to take on python-dateutil as a required dependency there
>> would be folks needing to go through an additional security audit in order
>> to get permission to upgrade Django. I wouldn't think two template tags
>> justifies that.
>>
>> So then, it would need to be optional.
>> But then it could just live in a third-party package.
>> (I don't think we really document it, but one could shadow/override the
>> built-in tags with the improved versions if your app was installed, I
>> guess...)
>>
>> Or that would be my initial thought. 🤔
>>
>> Kind Regards,
>>
>> Carlton
>>
>>
>> On Tue, 2 Aug 2022 at 03:27, אורי wrote:
>>
>>> Hi,
>>>
>>> Lately I discovered some inaccuracy bugs in timesince (and timeuntil),
>>> and I created a ticket (#33879
>>> ). In short, the problems
>>> are when calculating a year minus one week, 2 weeks, one day etc. and also
>>> 2 years minus one or 2 days. In all such cases, Django's implementation
>>> of timesince is inaccurate, in some cases resulting in "1 year, 12
>>> months" (for 2 years minus one or 2 days) or adding a week (for a year
>>> minus one or 2 weeks). I read the code of Django's timesince implementation
>>> and it's quite long, and I searched and found that python-dateutil already
>>> have such methods, which is possible to calculate exactly the number of
>>> days between two dates like this:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *from dateutil.relativedelta import relativedeltadiff =
>>> relativedelta(date2, date1)years = diff.yearsmonths = diff.monthsweeks =
>>> diff.days // 7days = diff.days - weeks * 7 # ("**diff.days % 7" will
>>> also work here)*
>>>
>>> This calculates exactly the number of years, months, weeks and days and
>>> not an approximation like Django's implementation. And python-dateutil is
>>> stable and I think exists even before Django. I recently started using
>>> Django's timesince function in my own website, and I like the way it's
>>> translated (currently only to English and Hebrew). Do you think it's worth
>>> using python-dateutil in the Django implementation of timesince and
>>> timeuntil?
>>>
>>> Of course, I can also implement my own version of timesince which
>>> uses python-dateutil and doesn't use Django. But since timesince and
>>> timeuntil are built-in tags in Django, I guess many websites are using
>>> them. Isn't it better to use a more precise implementation and avoid
>>> something like "1 year, 12 months"?
>>>
>>> Thanks,
>>> Uri Rodberg, Speedy Net
>>> אורי
>>> u...@speedy.net
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django developers (Contributions to Django itself)" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-develop...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/CABD5YeEC_o%2BwQVF8pj3Kat57MXfX071LT0rZAq2XipFFCK%3DFBQ%40mail.gmail.com
>>>
>>>
Django 4.1 released
Details are available on the Django project weblog: https://www.djangoproject.com/weblog/2022/aug/03/django-41-released/ -- 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/CAJwKpyR3GRReA1qdshq-eNERRTQUHMHznCiLeBntVNoLZ6_kiQ%40mail.gmail.com.
Re: Fellow Reports - July 2022
Week ending July 31, 2022 *Triaged: * https://code.djangoproject.com/ticket/33866 - Support Path instances in GDALRaster constructor (accepted) https://code.djangoproject.com/ticket/33867 - Automatic detection of timezone in django admin using javascript (duplicate) https://code.djangoproject.com/ticket/33869 - Self Reference Inlines is not working form me (invalid) https://code.djangoproject.com/ticket/33870 - Add a SHORT_TIME_FORMAT to settings.py (wontfix) https://code.djangoproject.com/ticket/33871 - JSONField with default is not detected as changed when invalidated in inlines. (accepted) https://code.djangoproject.com/ticket/33872 - Deprecate CICharField, CIEmailField, CITextField. (created) https://code.djangoproject.com/ticket/33873 - Unstyled admin logout button. (invalid) https://code.djangoproject.com/ticket/33874 - BooleanField validate function should use ‘value is not None’ instead of 'not value' (invalid) https://code.djangoproject.com/ticket/33875 - Inserting new record into partitioned table with triggers fails on returned values. (invalid) https://code.djangoproject.com/ticket/33877 - Add accurate port validation to the URLValidator. (wontfix) *Reviewed/committed: * https://github.com/django/django/pull/15876 - Removed obsolete note in management.get_commands() docstring. https://github.com/django/django/pull/15873 - Fixes #33863 -- Fixed JavaScriptCatalog with more than 1 level of fallback translations. https://github.com/django/django/pull/14333 - Simplified various built-in templates. https://github.com/django/django/pull/15879 - Fixed #33866 -- Added pathlib.Path support to GDALRaster constructor. https://github.com/django/django/pull/15880 - Fixed BasicExtractorTests.test_makemessages_find_files() test. https://github.com/django/django/pull/15886 - Refs #32948 -- Made django.utils.tree.Node cleanups. https://github.com/django/django/pull/14677 - Fixed #32948 -- Optimized django.utils.tree.Node and its subclasses. https://github.com/django/django/pull/15892 - Fixed #33442 -- Allowed GeoIP2 to use DB-IP Lite datasets. https://github.com/django/djangoproject.com/pull/1190 - Updated Akismet paramaters in ContactForm. *Reviewed: * https://github.com/django/djangoproject.com/pull/1187 - Updated Supported Versions tables for Django 4.1. https://github.com/django/djangoproject.com/pull/1188 - Updated docs-related model fixtures for 4.1 release. https://github.com/django/djangoproject.com/pull/1189 - Updated robots.docs.txt for Django 4.1. *Authored: * https://github.com/django/django/pull/15861 - Refs #27236 -- Reverted AlterIndexTogether deprecation. https://github.com/django/django/pull/15883 - Fixed #33820 -- Doc'd and tested "true"/"false"/"null" caveat for JSONField key transforms on SQLite. https://github.com/django/django/pull/15887 - Fixed collation tests on MySQL 8.0.30+. https://github.com/django/django/pull/15891 - Fixed #33872 -- Deprecated django.contrib.postgres.fields.CIText/CICharField/CIEmailField/CITextField. https://github.com/django/django/pull/15895 - Fixed warnings per flake8 5.0.0. 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/cc690243-65c3-4cc4-b413-e6341beaa0dcn%40googlegroups.com.
Named Groups for Enumeration Types
Hello all,
In my project I recently wanted to group choices, and have gotten used to
the Enumeration Types Django provides. I noticed Django currently does not
support named groups for these.
So, I've implemented them in two ways:
Option A) Ugly, but simple changes to Django
class Media(models.TextChoices):
_named_group1 = "Audio"
VINYL = "vinyl"
CD = "cd", "CD"
_named_group2 = "Video"
VHS_TAPE = "vhs", "VHS Tape"
DVD = "dvd", _("DVD")
_named_group3 = None
UNKNOWN = "unknown"
Option B) Pretty, but complex changes to Django
class Media(models.TextChoices):
class Audio(models.TextChoices):
VINYL = "vinyl"
CD = "cd", "CD"
class Video(models.TextChoices):
VHS_TAPE = "vhs", "VHS Tape"
DVD = "dvd", _("DVD")
UNKNOWN = "unknown"
Does anyone have better ideas to implement named groups here? Would one of
these implementations be useful for Django?
Below are links to personal pull requests to see potential patches. The
pull requests include tests and documentation.
GitHub links:
* https://github.com/shjohnson-pi/django/pull/1 (Pretty, complex)
* https://github.com/shjohnson-pi/django/pull/2 (Ugly, simple)
Relevant docs:
*
https://docs.djangoproject.com/en/4.1/ref/models/fields/#field-choices-named-groups
* https://docs.djangoproject.com/en/4.1/ref/models/fields/#enumeration-types
Thank you,
Steven H Johnson
--
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/7d66f6a9-4056-4e2e-ade2-8175994ebd20n%40googlegroups.com.
Re: Should SECRET_KEY be allowed to be bytes?
Years later, sorry. But this is still broken and SECRET_KEY management is a mess! Even though you can now use bytes, this line here will blow up if you attempt to use bytes as a secret key: https://github.com/django/django/blob/3.2.14/django/core/checks/security/base.py#L202 Basically, we are unable to use bytes in the secret key (and we want bytes so we can use a short string for other HMAC/signing operations). This means that our "str" keys will be twice as big (if encoded as hex) and will also always end up hashed because a 64 bytes secret will be a 128 string hex, which is over HMAC-SHA256 block size. El Wednesday, December 28, 2016 a la(s) 6:45:50 AM UTC-3, Aymeric Augustin escribió: > I’m happy with that. > > -- > Aymeric. > > On 27 Dec 2016, at 19:49, Tim Graham wrote: > > Thanks Aymeric. How about this documentation addition: > > Uses of the key shouldn't assume that it's text or bytes. Every use should > go > through :func:`~django.utils.encoding.force_text` or > :func:`~django.utils.encoding.force_bytes` to convert it to the desired > type. > > https://github.com/django/django/pull/7750 > > Adam created https://code.djangoproject.com/ticket/27635 about the "use > secrets" idea. > > On Saturday, December 24, 2016 at 4:52:38 PM UTC-5, Aymeric Augustin wrote: >> >> Hello Andres, >> >> We both seem to agree with the status quo — supporting both text and >> bytes. >> >> >> On 24 Dec 2016, at 00:36, 'Andres Mejia' via Django developers >> (Contributions to Django itself) wrote: >> >> On 12/22/2016 05:15 PM, Aymeric Augustin wrote: >> >> export SECRET_KEY=… # generated with pwgen -s 50 >> >> What do you think is ultimately being used in the pwgen program? I'm >> going to guess, at least on POSIX systems, it is /dev/urandom or >> /dev/random, both of which return random bytes. >> >> >> I understand this, but it doesn’t change my argument. I’m saying that the >> format of SECRET_KEY doesn’t matter, as long as it contain enough entropy, >> since it will be injected in hashing algorithms designed to extract the >> entropy. I think we can agree on this. >> >> We have different preferences for that format. You like keeping the >> original raw binary data SECRET_KEY. I find it more convenient to convert >> it to an ASCII-safe format, for example with pwgen. I really think this >> boils down to taste. I don’t think we can conclusively determine that one >> approach is superior to the other. I think my technique is more beginner >> friendly; while not applicable to you, it’s a concern for Django in general. >> >> The only cost of supporting both options is that every use must go either >> through force_text or force_bytes to convert to a known type. >> >> - “I think it's fair to assume devs using the SECRET_KEY know it must be >> used as bytes.” — well that doesn't include me or any Django dev I ever >> talked to about this topic >> >> (..) >> >> >> Oops, I misunderstood “used as bytes” to mean “defined as bytes”. Sorry. >> I withdraw this. >> >> >> And since I’ve been waving my hands about the types Django expects in a >> previous email, here’s the full audit. Below, *text* means unicode on >> Python 2 and str on Python 3. *ASCII-safe bytes* means bytes containing >> only ASCII-characters, so they can be used transparently as if they were >> text on Python 2, because it will call decode() implicitly. >> >> - django/conf/global_settings.py >> >> Sets the default to an empty *text* string (note the unicode_literals >> import at the top for Python 2). >> >> - django/conf/settings.py-tpl >> >> Sets the generated value to *ASCII-safe bytes* on Python 2 and *text* on >> Python 3 (no unicode_literals there). >> >> - django/core/signing.py: >> >> Calls force_bytes to support *bytes* and *text* in get_cookie_signer. >> >> - django/utils/crypto.py: >> >> Calls force_bytes to support *bytes* and *text* in salted_hmac. >> >> *Assumes SECRET_KEY contains text* in the `if not using_sysrandom` >> branch of `get_random_string`. This is the bug I hinted to in a previous >> email. It must have appeared when adding the unicode_literals import to >> that file. No one complained since June 2012. It only affects people >> setting their SECRET_KEY to bytes on Python 3 or ASCII-unsafe bytes on >> Python 2 on Unix-like systems that don’t provide /dev/urandom. This sounds >> uncommon. >> >> While we’re there, we should use >> https://docs.python.org/3/library/secrets.html#module-secrets on Python >> >= 3.6. >> >> >> Best regards, >> >> -- >> Aymeric. >> >> > -- > 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 post to this group, send email to django-d...@googlegroups.com. > > > Visit this group at https://groups.google.com/group/django-developers. > > To view this discuss
