Bug#1079454: bookworm-pu: package python-django/3:3.2.19-1+deb12u2
Hi Chris, > > Thanks for the update, much appreciated. So yes this means we will > > have to defer updates to the later point releases (window for uploads > > is closing this weekend). Thanks for moving this forward! > I finally have an update here locally, fixing 22 (!) CVEs in total. Three > topics to raise at this point: > > 1. bookworm's Django is currently based on Django 3.2.19. However, we make >some of the changes cleaner if we base this update on 3.2.25 instead, >as this version includes 4 or 5 CVEs fixed without explicit Debian patches; >changes that aren't the nicest to backport. Any objections to this >version bump? Alas, upstream won't be releasing any more 3.2.x updates. That's perfectly fine. Let's follow upstream releases until they are end-of-life and after the final release we do cherrypicks. We're doing the same for other software as well (e.g. Wireshark or Samba). > 2. In #1126461, Moritz replied that they would prefer to fix Django in >trixie via a DSA instead. Shall we do that for bookworm as well — i.e. >not a pu after all? Yes, let's also fix this via a DSA. > 3. My candidate version causes the same regression in the > python-django-storages >testsuite previously observed. As Steve pointed out, though "there are >*already* changes in our version of django-storages that are clearly >expected to work with the fixes in django. But they're not.". I am >investigating this. Since you identified the, let's simply release a fixed version of python-django-storages via bookworm-security alongside. > 4. For completeness, my candidate version also causes some reverse-autopkgtest >failures in django-fsm-admin, django-markupfield, django-webpack-loader and >python-xapian-haystack (thanks, Debusine). However, these are not actually >regressions; the testsuite already/always fails for these packages. This >is mostly an FYI, but let me know if I need to do anything special for > those. Ok, noted! > § > > My current/candidate changelog entry is as follows: > > Source: python-django > Version: 3:3.2.25-1+deb12u1 Can you make that 3:3.2.25-0+deb12u1 please? And can you please send the full debdiff for review or alternatively push it to the bookworm branch for a full review? Cheers, Moritz
Bug#1079454: bookworm-pu: package python-django/3:3.2.19-1+deb12u2
Hey Chris, and well done for tracking this down! On Wed, Jan 28, 2026 at 03:28:29PM -0800, Chris Lamb wrote: >Chris Lamb wrote: > >> 3. My candidate version causes the same regression in the >> python-django-storages >>testsuite previously observed. As Steve pointed out, though "there are >>*already* changes in our version of django-storages that are clearly >>expected to work with the fixes in django. But they're not.". I am >>investigating this. > >This turned out NOT to be a test-only problem — the Dropbox backend >of django-storages will need to be updated or we might be breaking >user's web services. > >The changes in our version of django-storages were not complete; >or rather, long after those changes were committed, django-storages >upstream worked with Django upstream after they identified a >validation issue, leading to the very CVE (and changes in Django) >that cause this regression: > > https://github.com/jschneier/django-storages/issues/1430#issuecomment-2219310781 > >The subsequent change to django-storages is a bit confusing to parse, >as this took the form of reverting some removed code. But first, >observe that upstream entirely removed the "get_available_name" method here: > > > https://github.com/jschneier/django-storages/commit/a5319477473e5bab60b0d698e2a8127a8f750787#diff-ae567fb35986cceee2f0399f7be300078047a13c07299ef415971c7e2f786bbeL202-L207 > >... and when they reverted it, they did so *without* re-including >the call to self._full_path(name): > > > https://github.com/jschneier/django-storages/pull/1484/changes#diff-ae567fb35986cceee2f0399f7be300078047a13c07299ef415971c7e2f786bbeR195 > >Thus, the change required to django-storages is as follows: > > diff -urNad a/storages/backends/dropbox.py b/storages/backends/dropbox.py > --- a/storages/backends/dropbox.py 2026-01-28 15:16:12.506131883 -0800 > +++ b/storages/backends/dropbox.py 2026-01-28 15:16:30.469908898 -0800 > @@ -199,7 +199,6 @@ > > def get_available_name(self, name, max_length=None): > """Overwrite existing file with the same name.""" > -name = self._full_path(name) > if self.write_mode == 'overwrite': > return get_available_overwrite_name(name, max_length) > return super().get_available_name(name, max_length) > >This patch is for the version in bookworm. \o/ -- Steve McIntyre, Cambridge, [email protected] Welcome my son, welcome to the machine.
Bug#1079454: bookworm-pu: package python-django/3:3.2.19-1+deb12u2
Chris Lamb wrote: > 3. My candidate version causes the same regression in the > python-django-storages >testsuite previously observed. As Steve pointed out, though "there are >*already* changes in our version of django-storages that are clearly >expected to work with the fixes in django. But they're not.". I am >investigating this. This turned out NOT to be a test-only problem — the Dropbox backend of django-storages will need to be updated or we might be breaking user's web services. The changes in our version of django-storages were not complete; or rather, long after those changes were committed, django-storages upstream worked with Django upstream after they identified a validation issue, leading to the very CVE (and changes in Django) that cause this regression: https://github.com/jschneier/django-storages/issues/1430#issuecomment-2219310781 The subsequent change to django-storages is a bit confusing to parse, as this took the form of reverting some removed code. But first, observe that upstream entirely removed the "get_available_name" method here: https://github.com/jschneier/django-storages/commit/a5319477473e5bab60b0d698e2a8127a8f750787#diff-ae567fb35986cceee2f0399f7be300078047a13c07299ef415971c7e2f786bbeL202-L207 ... and when they reverted it, they did so *without* re-including the call to self._full_path(name): https://github.com/jschneier/django-storages/pull/1484/changes#diff-ae567fb35986cceee2f0399f7be300078047a13c07299ef415971c7e2f786bbeR195 Thus, the change required to django-storages is as follows: diff -urNad a/storages/backends/dropbox.py b/storages/backends/dropbox.py --- a/storages/backends/dropbox.py2026-01-28 15:16:12.506131883 -0800 +++ b/storages/backends/dropbox.py2026-01-28 15:16:30.469908898 -0800 @@ -199,7 +199,6 @@ def get_available_name(self, name, max_length=None): """Overwrite existing file with the same name.""" -name = self._full_path(name) if self.write_mode == 'overwrite': return get_available_overwrite_name(name, max_length) return super().get_available_name(name, max_length) This patch is for the version in bookworm. Regards, -- ,''`. : :' : Chris Lamb `. `'` [email protected] 🍥 chris-lamb.co.uk `-
Bug#1079454: bookworm-pu: package python-django/3:3.2.19-1+deb12u2
Hi all, > Thanks for the update, much appreciated. So yes this means we will > have to defer updates to the later point releases (window for uploads > is closing this weekend). I finally have an update here locally, fixing 22 (!) CVEs in total. Three topics to raise at this point: 1. bookworm's Django is currently based on Django 3.2.19. However, we make some of the changes cleaner if we base this update on 3.2.25 instead, as this version includes 4 or 5 CVEs fixed without explicit Debian patches; changes that aren't the nicest to backport. Any objections to this version bump? Alas, upstream won't be releasing any more 3.2.x updates. 2. In #1126461, Moritz replied that they would prefer to fix Django in trixie via a DSA instead. Shall we do that for bookworm as well — i.e. not a pu after all? 3. My candidate version causes the same regression in the python-django-storages testsuite previously observed. As Steve pointed out, though "there are *already* changes in our version of django-storages that are clearly expected to work with the fixes in django. But they're not.". I am investigating this. 4. For completeness, my candidate version also causes some reverse-autopkgtest failures in django-fsm-admin, django-markupfield, django-webpack-loader and python-xapian-haystack (thanks, Debusine). However, these are not actually regressions; the testsuite already/always fails for these packages. This is mostly an FYI, but let me know if I need to do anything special for those. § My current/candidate changelog entry is as follows: Source: python-django Version: 3:3.2.25-1+deb12u1 Distribution: bookworm-security Urgency: high Maintainer: Chris Lamb Timestamp: 1769541419 Date: Tue, 27 Jan 2026 11:16:59 -0800 Closes: 1051226 1099682 1113865 Changes: python-django (3:3.2.25-1+deb12u1) bookworm-security; urgency=high * Update to upstream's last 3.2 series release: - CVE-2023-41164: Potential denial of service vulnerability in django.utils.encoding.uri_to_iri(). This method was subject to potential denial of service attack via certain inputs with a very large number of Unicode characters. This fix was released in Django 3.2.21. (Closes: #1051226) - CVE-2023-43665: Address a denial-of-service possibility in django.utils.text.Truncator. Following the fix for CVE-2019-14232, the regular expressions used in the implementation of django.utils.text.Truncator’s chars() and words() methods (with html=True) were revised and improved. However, these regular expressions still exhibited linear backtracking complexity, so when given a very long, potentially malformed HTML input, the evaluation would still be slow, leading to a potential denial of service vulnerability. The chars() and words() methods are used to implement the truncatechars_html and truncatewords_html template filters, which were thus also vulnerable. The input processed by Truncator, when operating in HTML mode, has been limited to the first five million characters in order to avoid potential performance and memory issues. This fix was included in Django 3.2.22. - CVE-2024-24680: Potential denial-of-service in intcomma template filter. The intcomma template filter was subject to a potential denial-of-service attack when used with very long strings. This fix was included in Django 3.2.24. - CVE-2024-27351: Fix a potential regular expression denial-of-service (ReDoS) attack in django.utils.text.Truncator.words. This method (with html=True) and the truncatewords_html template filter were subject to a potential regular expression denial-of-service attack via a suitably crafted string. This is, in part, a follow up to CVE-2019-14232 and CVE-2023-43665, and was included in Django 3.2.25. * Drop debian/patches/CVE-2023-36053.patch now that we include the fix directly via 3.2.20. * CVE-2024-39329: Avoid a username enumeration vulnerability through timing difference for users with unusable password. The authenticate method of django.contrib.auth.backends.ModelBackend method allowed remote attackers to enumerate users via a timing attack involving login requests for users with unusable passwords. * CVE-2024-39330: Address a potential directory-traversal in django.core.files.storage.Storage.save. Derived classes of this method's base class which override generate_filename without replicating the file path validations existing in the parent class allowed for potential directory-traversal via certain inputs when calling save(). Built-in Storage sub-classes were not affected by this vulnerability. * CVE-2024-
Bug#1079454: bookworm-pu: package python-django/3:3.2.19-1+deb12u2
Hi Chris, On Fri, Jan 02, 2026 at 04:19:58PM -0800, Chris Lamb wrote: > Salvatore Bonaccorso wrote: > > > I do realize I'm late and we will miss the next point release, but > > what is the status of python-django for bookworm? In meanwhile we have > > several more CVEs which are added and should be included as well, and > > many of the new ones were covered by a DLA. > > Happy New Year, all. :) I had to pause working on it, but I plan to > get back to it next week (5/1). > Same to you! Thanks for the update, much appreciated. So yes this means we will have to defer updates to the later point releases (window for uploads is closing this weekend). Regards, Salvatore
Bug#1079454: bookworm-pu: package python-django/3:3.2.19-1+deb12u2
Salvatore Bonaccorso wrote: > I do realize I'm late and we will miss the next point release, but > what is the status of python-django for bookworm? In meanwhile we have > several more CVEs which are added and should be included as well, and > many of the new ones were covered by a DLA. Happy New Year, all. :) I had to pause working on it, but I plan to get back to it next week (5/1). Best wishes, -- ,''`. : :' : Chris Lamb `. `'` [email protected] 🍥 chris-lamb.co.uk `-
Bug#1079454: bookworm-pu: package python-django/3:3.2.19-1+deb12u2
Hi Chris, On Fri, May 09, 2025 at 01:03:21PM -0300, Santiago Ruano Rincón wrote: > El 08/05/25 a las 13:05, Chris Lamb escribió: > > Hi Santiago, > > Hi Chris, > > > > As a follow up of > > > https://lists.debian.org/debian-lts/2025/05/msg00023.html, > > > I forgot to check if a pu for python-django was in the queue. And I > > > would just like to point you out about the above questions from > > > Salvatore. > > > > > > Chris, the next point release window is closing this week-end. Do you > > > think you could help with that? > > > > Unfortunately, I'm really really slammed right now so I don't feel > > confident I can prepare a fully-tested pu for Django by this weekend. > > > > Salvatore's questions are indeed still outstanding and haven't been > > dropped — lot of stuff IRL recently so things have piled up. Slowly > > digging my way out of the hole, however. > > Thanks a lot for your answer. I hope all of that IRL stuff will get > solved soon. > > Don't hesitate to speak up if you would like/need help from other LTS > team fellows! I do realize I'm late and we will miss the next point release, but what is the status of python-django for bookworm? In meanwhile we have several more CVEs which are added and should be included as well, and many of the new ones were covered by a DLA. Thanks for working it time permitting, Regards, Salvatore
Bug#1079454: bookworm-pu: package python-django/3:3.2.19-1+deb12u2
El 08/05/25 a las 13:05, Chris Lamb escribió: > Hi Santiago, Hi Chris, > > As a follow up of https://lists.debian.org/debian-lts/2025/05/msg00023.html, > > I forgot to check if a pu for python-django was in the queue. And I > > would just like to point you out about the above questions from > > Salvatore. > > > > Chris, the next point release window is closing this week-end. Do you > > think you could help with that? > > Unfortunately, I'm really really slammed right now so I don't feel > confident I can prepare a fully-tested pu for Django by this weekend. > > Salvatore's questions are indeed still outstanding and haven't been > dropped — lot of stuff IRL recently so things have piled up. Slowly > digging my way out of the hole, however. Thanks a lot for your answer. I hope all of that IRL stuff will get solved soon. Don't hesitate to speak up if you would like/need help from other LTS team fellows! All the best, -- Santiago signature.asc Description: PGP signature
Bug#1079454: bookworm-pu: package python-django/3:3.2.19-1+deb12u2
Hi all, On 08-05-2025 22:05, Chris Lamb wrote: As a follow up of https://lists.debian.org/debian-lts/2025/05/msg00023.html, I forgot to check if a pu for python-django was in the queue. And I would just like to point you out about the above questions from Salvatore. Chris, the next point release window is closing this week-end. Do you think you could help with that? Unfortunately, I'm really really slammed right now so I don't feel confident I can prepare a fully-tested pu for Django by this weekend. Salvatore's questions are indeed still outstanding and haven't been dropped — lot of stuff IRL recently so things have piled up. Slowly digging my way out of the hole, however. And for avoidance of doubt, the people in this thread are aware of the regression that the current version of python-django in pu is causing in python-django-storages. I assume yes because of the cc list, but I wanted to spell it out. See https://release.debian.org/proposed-updates/stable.html Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1079454: bookworm-pu: package python-django/3:3.2.19-1+deb12u2
Hi Santiago, > As a follow up of https://lists.debian.org/debian-lts/2025/05/msg00023.html, > I forgot to check if a pu for python-django was in the queue. And I > would just like to point you out about the above questions from > Salvatore. > > Chris, the next point release window is closing this week-end. Do you > think you could help with that? Unfortunately, I'm really really slammed right now so I don't feel confident I can prepare a fully-tested pu for Django by this weekend. Salvatore's questions are indeed still outstanding and haven't been dropped — lot of stuff IRL recently so things have piled up. Slowly digging my way out of the hole, however. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` [email protected] 🍥 chris-lamb.co.uk `-
Bug#1079454: bookworm-pu: package python-django/3:3.2.19-1+deb12u2
Hi again Chris! El 19/04/25 a las 21:16, Salvatore Bonaccorso escribió: > Hi Chris, > > On Fri, Mar 14, 2025 at 06:38:56AM +0100, Salvatore Bonaccorso wrote: > > Hi, > > > > [including Chris in CC] > > > > On Sun, Oct 20, 2024 at 09:05:43AM +0200, Paul Gevers wrote: > > > Hi Steve, > > > > > > On 29-08-2024 17:05, Steve McIntyre wrote: > > > > I've already spent some time looking at this, and in fact there are > > > > *already* changes in our version of django-storages that are clearly > > > > expected to work with the fixes in django. But they're not. I'm > > > > digging in further to see whether it's something I've done or a wider > > > > bug. I don't*think* it's my fault, but stranger things have > > > > happened! > > > > > > > > At this point, I would say let's be safe and hang back on the django > > > > update this - it will wait for the next point release. > > > > > > As you are well aware, the next point release is around the corner: 9 > > > November. Did anything happen, or should python-django be skipped one more > > > time? > > > > We will miss the 12.10 point release with these changes. Chris can you > > help Steve here resolving the regressions and then include as well > > fixes for the new CVEs which appeared in meanwhile? > > Any updates here? The date for the 12.11 point release is not yet set, > but would be great to have the python-django CVEs currently known > fixed in the next point release. As a follow up of https://lists.debian.org/debian-lts/2025/05/msg00023.html, I forgot to check if a pu for python-django was in the queue. And I would just like to point you out about the above questions from Salvatore. Chris, the next point release window is closing this week-end. Do you think you could help with that? (WRT my debusine-related request, it doesn't matter of course if python-django is updated via a point release instead of a security update.) Cheers! -- Santiago signature.asc Description: PGP signature
Bug#1079454: bookworm-pu: package python-django/3:3.2.19-1+deb12u2
Hi Chris, On Fri, Mar 14, 2025 at 06:38:56AM +0100, Salvatore Bonaccorso wrote: > Hi, > > [including Chris in CC] > > On Sun, Oct 20, 2024 at 09:05:43AM +0200, Paul Gevers wrote: > > Hi Steve, > > > > On 29-08-2024 17:05, Steve McIntyre wrote: > > > I've already spent some time looking at this, and in fact there are > > > *already* changes in our version of django-storages that are clearly > > > expected to work with the fixes in django. But they're not. I'm > > > digging in further to see whether it's something I've done or a wider > > > bug. I don't*think* it's my fault, but stranger things have > > > happened! > > > > > > At this point, I would say let's be safe and hang back on the django > > > update this - it will wait for the next point release. > > > > As you are well aware, the next point release is around the corner: 9 > > November. Did anything happen, or should python-django be skipped one more > > time? > > We will miss the 12.10 point release with these changes. Chris can you > help Steve here resolving the regressions and then include as well > fixes for the new CVEs which appeared in meanwhile? Any updates here? The date for the 12.11 point release is not yet set, but would be great to have the python-django CVEs currently known fixed in the next point release. Regards, Salvatore
Bug#1079454: bookworm-pu: package python-django/3:3.2.19-1+deb12u2
Hi, [including Chris in CC] On Sun, Oct 20, 2024 at 09:05:43AM +0200, Paul Gevers wrote: > Hi Steve, > > On 29-08-2024 17:05, Steve McIntyre wrote: > > I've already spent some time looking at this, and in fact there are > > *already* changes in our version of django-storages that are clearly > > expected to work with the fixes in django. But they're not. I'm > > digging in further to see whether it's something I've done or a wider > > bug. I don't*think* it's my fault, but stranger things have > > happened! > > > > At this point, I would say let's be safe and hang back on the django > > update this - it will wait for the next point release. > > As you are well aware, the next point release is around the corner: 9 > November. Did anything happen, or should python-django be skipped one more > time? We will miss the 12.10 point release with these changes. Chris can you help Steve here resolving the regressions and then include as well fixes for the new CVEs which appeared in meanwhile? Regards, Salvatore
Bug#1079454: bookworm-pu: package python-django/3:3.2.19-1+deb12u2
Hi Steve, On 29-08-2024 17:05, Steve McIntyre wrote: I've already spent some time looking at this, and in fact there are *already* changes in our version of django-storages that are clearly expected to work with the fixes in django. But they're not. I'm digging in further to see whether it's something I've done or a wider bug. I don't*think* it's my fault, but stranger things have happened! At this point, I would say let's be safe and hang back on the django update this - it will wait for the next point release. As you are well aware, the next point release is around the corner: 9 November. Did anything happen, or should python-django be skipped one more time? Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1079454: bookworm-pu: package python-django/3:3.2.19-1+deb12u2
On Thu, 2024-08-29 at 16:05 +0100, Steve McIntyre wrote: > At this point, I would say let's be safe and hang back on the django > update this - it will wait for the next point release. Thanks; added to the list for Saturday. Regards, Adam
Bug#1079454: bookworm-pu: package python-django/3:3.2.19-1+deb12u2
On Thu, Aug 29, 2024 at 01:51:27PM +0200, Paul Gevers wrote: >On 28-08-2024 13:58, Steve McIntyre wrote: > >> That does very much look like a test with broken assumptions, I'll be >> honest. Ah, I see... >> >> I can see that Josh Schneier (the upstream for django-storages) is the >> person responsible for the CVE against django in the first place - he >> spotted the issue and reported it. In >> >> >> https://github.com/jschneier/django-storages/commit/330966293a74f2dabda18fa2e4a221952bf010a9 >> >> there's a fix on his side to cope with the django change. It looks >> like we'll want that change backporting into python-django-storages. I >> can try to do that too if you like, but I appreciate we're getting >> very tight on time before the weekend. :-/ > >I'm not SRM, just trying to help out with the autopkgtest infrastructure and >results. I'm predicting that SRM might not want a fixed >python-django-storages this late, so I think it would help if you can advise >the SRM: do you think the regression is less bad than leaving the CVE's >unfixed or the other way around? I.e. accept the regression, or keep the >fixed python-django out until the next point release (with a fixed >python-django-storages). I've already spent some time looking at this, and in fact there are *already* changes in our version of django-storages that are clearly expected to work with the fixes in django. But they're not. I'm digging in further to see whether it's something I've done or a wider bug. I don't *think* it's my fault, but stranger things have happened! At this point, I would say let's be safe and hang back on the django update this - it will wait for the next point release. -- Steve McIntyre, Cambridge, [email protected] "The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary." -- James D. Nicoll
Bug#1079454: bookworm-pu: package python-django/3:3.2.19-1+deb12u2
Hi, On 28-08-2024 13:58, Steve McIntyre wrote: Apologies for the delayed response - busy weekend here... Totally understood. :) But the autopkgtest of python-django-storages fails [1]. This *appears* to me as a test problem we can accept, but maybe you or the python-django-storages maintainers can confirm? That does very much look like a test with broken assumptions, I'll be honest. Ah, I see... I can see that Josh Schneier (the upstream for django-storages) is the person responsible for the CVE against django in the first place - he spotted the issue and reported it. In https://github.com/jschneier/django-storages/commit/330966293a74f2dabda18fa2e4a221952bf010a9 there's a fix on his side to cope with the django change. It looks like we'll want that change backporting into python-django-storages. I can try to do that too if you like, but I appreciate we're getting very tight on time before the weekend. :-/ I'm not SRM, just trying to help out with the autopkgtest infrastructure and results. I'm predicting that SRM might not want a fixed python-django-storages this late, so I think it would help if you can advise the SRM: do you think the regression is less bad than leaving the CVE's unfixed or the other way around? I.e. accept the regression, or keep the fixed python-django out until the next point release (with a fixed python-django-storages). Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1079454: bookworm-pu: package python-django/3:3.2.19-1+deb12u2
Hey Paul! Apologies for the delayed response - busy weekend here... On Sun, Aug 25, 2024 at 09:38:47AM +0200, Paul Gevers wrote: >Hi Steve and python-django-storages maintainers, > >On 23-08-2024 13:24, Steve McIntyre wrote: >> I've backported a lump of upstream CVE fixes for django to the version >> in bookworm. Chris Lamb has reviewed and approved the changes as one >> of the existing maintainers. >> >> The standard test suite all passes as expected. > >But the autopkgtest of python-django-storages fails [1]. This *appears* to me >as a test problem we can accept, but maybe you or the python-django-storages >maintainers can confirm? That does very much look like a test with broken assumptions, I'll be honest. Ah, I see... I can see that Josh Schneier (the upstream for django-storages) is the person responsible for the CVE against django in the first place - he spotted the issue and reported it. In https://github.com/jschneier/django-storages/commit/330966293a74f2dabda18fa2e4a221952bf010a9 there's a fix on his side to cope with the django change. It looks like we'll want that change backporting into python-django-storages. I can try to do that too if you like, but I appreciate we're getting very tight on time before the weekend. :-/ -- Steve McIntyre, Cambridge, [email protected] "War does not determine who is right - only who is left." -- Bertrand Russell
Bug#1079454: bookworm-pu: package python-django/3:3.2.19-1+deb12u2
Hi Steve and python-django-storages maintainers, On 23-08-2024 13:24, Steve McIntyre wrote: I've backported a lump of upstream CVE fixes for django to the version in bookworm. Chris Lamb has reviewed and approved the changes as one of the existing maintainers. The standard test suite all passes as expected. But the autopkgtest of python-django-storages fails [1]. This *appears* to me as a test problem we can accept, but maybe you or the python-django-storages maintainers can confirm? Paul [1] https://release.debian.org/proposed-updates/stable.html OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1079454: bookworm-pu: package python-django/3:3.2.19-1+deb12u2
Package: release.debian.org Severity: normal Tags: bookworm User: [email protected] Usertags: pu X-Debbugs-Cc: [email protected], [email protected] Control: affects -1 + src:python-django Hi! I've backported a lump of upstream CVE fixes for django to the version in bookworm. Chris Lamb has reviewed and approved the changes as one of the existing maintainers. The standard test suite all passes as expected. I've already uploaded to p-u Here's the changelog; debdiff attached. python-django (3:3.2.19-1+deb12u2) bookworm; urgency=high * Rename CVE-2023-36053.patch to 0014-CVE-2023-36053.patch * Backport upstream fixes in 3:4.2.14-1: * Closes: #1076069 * CVE-2024-39329: Standardize timing of verify_password() when checking unusable passwords. * CVE-2024-39330: Add extra file name validation in Storage's save method. * CVE-2024-39614: Mitigate potential DoS in get_supported_language_variant. * The patch for CVE-2024-38875 won't sensibly backport. * Backport upstream fixes in 3:4.2.15-1: * Closes: #1078074 * CVE-2024-41989: Prevent excessive memory consumption in floatformat. * CVE-2024-41991: Prevente potential ReDoS in django.utils.html.urlize() and AdminURLFieldWidget. * CVE-2024-42005: Mitigate QuerySet.values() SQL injection attacks against JSON fields Backport and tweak the upstream fix series to fit into 3.2. * The patch for CVE-2024-41990 won't sensibly backport. -- Steve McIntyre <[email protected]> Wed, 21 Aug 2024 12:08:24 +0100 diff -Nru python-django-3.2.19/debian/changelog python-django-3.2.19/debian/changelog --- python-django-3.2.19/debian/changelog 2023-07-28 14:24:04.0 +0100 +++ python-django-3.2.19/debian/changelog 2024-08-21 12:08:24.0 +0100 @@ -1,3 +1,26 @@ +python-django (3:3.2.19-1+deb12u2) bookworm; urgency=high + + * Rename CVE-2023-36053.patch to 0014-CVE-2023-36053.patch + * Backport upstream fixes in 3:4.2.14-1: +* Closes: #1076069 +* CVE-2024-39329: Standardize timing of verify_password() when + checking unusable passwords. +* CVE-2024-39330: Add extra file name validation in Storage's save + method. +* CVE-2024-39614: Mitigate potential DoS in + get_supported_language_variant. +* The patch for CVE-2024-38875 won't sensibly backport. + * Backport upstream fixes in 3:4.2.15-1: +* Closes: #1078074 +* CVE-2024-41989: Prevent excessive memory consumption in floatformat. +* CVE-2024-41991: Prevente potential ReDoS in django.utils.html.urlize() + and AdminURLFieldWidget. +* CVE-2024-42005: Mitigate QuerySet.values() SQL injection attacks against JSON fields + Backport and tweak the upstream fix series to fit into 3.2. +* The patch for CVE-2024-41990 won't sensibly backport. + + -- Steve McIntyre <[email protected]> Wed, 21 Aug 2024 12:08:24 +0100 + python-django (3:3.2.19-1+deb12u1) bookworm-security; urgency=high * CVE-2023-36053: Potential regular expression denial of service diff -Nru python-django-3.2.19/debian/patches/0014-CVE-2023-36053.patch python-django-3.2.19/debian/patches/0014-CVE-2023-36053.patch --- python-django-3.2.19/debian/patches/0014-CVE-2023-36053.patch 1970-01-01 01:00:00.0 +0100 +++ python-django-3.2.19/debian/patches/0014-CVE-2023-36053.patch 2024-08-07 16:56:53.0 +0100 @@ -0,0 +1,242 @@ +From: Mariusz Felisiak +Date: Wed, 14 Jun 2023 12:23:06 +0200 +Subject: [PATCH] [3.2.x] Fixed CVE-2023-36053 -- Prevented potential ReDoS in + EmailValidator and URLValidator. + +Thanks Seokchan Yoon for reports. +--- + django/core/validators.py| 7 +-- + django/forms/fields.py | 3 +++ + docs/ref/forms/fields.txt| 7 ++- + docs/ref/validators.txt | 25 +++- + tests/forms_tests/field_tests/test_emailfield.py | 5 - + tests/forms_tests/tests/test_forms.py| 19 -- + tests/validators/tests.py| 11 +++ + 7 files changed, 66 insertions(+), 11 deletions(-) + +diff --git a/django/core/validators.py b/django/core/validators.py +index 6b28eef08dd2..52ebddac6345 100644 +--- a/django/core/validators.py b/django/core/validators.py +@@ -93,6 +93,7 @@ class URLValidator(RegexValidator): + message = _('Enter a valid URL.') + schemes = ['http', 'https', 'ftp', 'ftps'] + unsafe_chars = frozenset('\t\r\n') ++max_length = 2048 + + def __init__(self, schemes=None, **kwargs): + super().__init__(**kwargs) +@@ -100,7 +101,7 @@ class URLValidator(RegexValidator): + self.schemes = schemes + + def __call__(self, value): +-if not isinstance(value, str): ++if not isinstance(value, str) or len(value) > self.max_length: + raise ValidationError(self.message, code=self.code, params={'valu
