Bug#1070965: rtorrent: does not start due to soname update
Liam Stitt wrote: > libxmlrpc-core-c3t64 has bumped that soname to .4, so presumably a rebuild > will > fix this. A rebuild will indeed fix this, or at least rebuilding rtorrent locally fixes this for me. Can the maintainer therefore please request a binNMU? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1071063: screenkey: malformed debian/changelog
Package: screenkey Version: 1:1.5-4 Severity: serious User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Hi, This might not *strictly* be an RC bug, but the latest upload of screenkey has the following entry in debian/changelog: <<< screenkey (1:1.5-4) unstable; urgency=medium * fixed d/watch * bumped Standards-Version: 4.7.0 * removed the stance X-Python-Version -- >>> Note in particular the missing date. This doesn't break dak, otherwise it would not have been accepted by the archive, but it breaks many other tools (eg. gbp-buildpackage, etc.) as well as other things. For example, the package is not reproducible because SOURCE_DATE_EPOCH cannot be extracted from the debian/changelog. When building the package you should have seen warnings by, for instance, dh_installchangelogs, dpkg-gencontrol, dpkg-genchanges, etc. :) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#1070416: src:diffoscope: unsatisfied build dependency in testing: aapt
Paul Gevers wrote: > Dose [1] is reporting a build issue with your package, it's missing a > build dependency. Obviously your build dependencies shouldn't be > removed from testing, but unfortunately there are multiple scenarios > where that can happen nevertheless. Looks like this happened due to these RC bugs: https://bugs.debian.org/1062206 https://bugs.debian.org/1062110 https://bugs.debian.org/1062209 i.e. it wasn't that aapt was removed or barred from testing for some reason specific to aapt's code or license, etc. It is, as I understand it, not impossible that it might return to testing without further intervention on our part..? Otherwise, we can very cleanly remove this build dependency, even keeping the .arsc file support in diffoscope itself. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined
Alberto Bertogli wrote: > If you know of a functional official image that I can use to try to > reproduce the problem, or recently-tested steps I can follow to get > a working qemu install, please let me know. Alas, I can't actually be helpful here. There are no official images as far as I know… and somewhat annoyingly I (ie. a Debian Developer) actually have access to some machines set aside for this purpose. I call this "annoying" because I naturally can't then give you direct SSH access transitively — but I can proxy ideas, of course. Hm, googling the actual error message a little, I think this might be a bigger issue... or perhaps more accurately, at least one that has potentially been also solved elsewhere: * Same think in lightdm: <https://bugs.debian.org/1067561> * Some kind of "_FILE_OFFSET_BITS"-related patch for v4l-utils <https://www.spinics.net/lists/linux-media/msg230147.html> etc. Does this spark anything worth trying? :-) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined
Alberto Bertogli wrote:
> I'll try to get a debian install to boot for armhf, but it'll take me a
> bit because it's not straightforward (to put it mildly :).
Oh, yeah. :/ Perhaps qemu might be better option here. There might
even be pre-built disk images flying around.
> How urgent/important is this issue?
Medium? As it is technically a regression (as in, armhf used to build
before), this was filed with a severity of "serious". What this means
in practical terms is that newer versions of libfiu we upload will not
migrate to the staging area for the next release of Debian.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org chris-lamb.co.uk
`-
Bug#1066938: Fwd: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error: symbol `open64' is already defined
Dear Alberto,
Hope this finds you well. Any quick/immediate ideas on what might be
behind this build failure? Note that this is on ARM architectures
rather than amd64 — I often misread and conflate them at speed. :) Oh,
and I can't reproduce this on amd64 locally, at least, so I don't think
it is, say, due to some *general* update to the GLIBC build toolchain.
Best wishes,
Chris
- Original message -
From: Sebastian Ramacher
To: Debian Bug Tracking System
Subject: Bug#1066938: libfiu: FTBFS on arm{el,hf}: /tmp/cc54dEva.s:726: Error:
symbol `open64' is already defined
Date: Friday, 15 March 2024 6:50 PM
Source: libfiu
Version: 1.2-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org
https://buildd.debian.org/status/fetch.php?pkg=libfiu=armhf=1.2-2=1710292712=0
cc -D_XOPEN_SOURCE=600 -fPIC -DFIU_ENABLE=1 -D_LARGEFILE64_SOURCE=1 -I.
-I../../libfiu/ -g -O2 -Werror=implicit-function-declaration
-ffile-prefix-map=/<>=. -fstack-protector-strong
-fstack-clash-protection -Wformat -Werror=format-security -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2
-Wl,-z,relro -Wl,-z,now -D_GNU_SOURCE -c codegen.c -o codegen.o
/tmp/cc54dEva.s: Assembler messages:
/tmp/cc54dEva.s:726: Error: symbol `open64' is already defined
/tmp/cchEoHpC.s: Assembler messages:
/tmp/cchEoHpC.s:474: Error: symbol `mmap64' is already defined
make[4]: *** [Makefile:67: modules/posix.mm.mod.o] Error 1
make[4]: *** Waiting for unfinished jobs
make[4]: *** [Makefile:67: modules/posix.custom.o] Error 1
/tmp/cct4HXD3.s: Assembler messages:
/tmp/cct4HXD3.s:1810: Error: symbol `pread64' is already defined
/tmp/cct4HXD3.s:3995: Error: symbol `pwrite64' is already defined
/tmp/cct4HXD3.s:5803: Error: symbol `truncate64' is already defined
/tmp/cct4HXD3.s:6480: Error: symbol `ftruncate64' is already defined
/tmp/ccInAMjZ.s: Assembler messages:
/tmp/ccInAMjZ.s:437: Error: symbol `fopen64' is already defined
make[4]: *** [Makefile:67: modules/posix.io.mod.o] Error 1
/tmp/ccInAMjZ.s:1099: Error: symbol `freopen64' is already defined
/tmp/ccInAMjZ.s:3393: Error: symbol `tmpfile64' is already defined
/tmp/ccInAMjZ.s:5973: Error: symbol `ftello64' is already defined
/tmp/ccInAMjZ.s:7007: Error: symbol `fseeko64' is already defined
/tmp/ccInAMjZ.s:7699: Error: symbol `fsetpos64' is already defined
make[4]: *** [Makefile:67: modules/posix.stdio.mod.o] Error 1
Bug#1060316: redis: CVE-2023-41056
Package: redis Version: 5:6.0.16-1+deb11u2 X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerability was published for redis. CVE-2023-41056[0]: Buffer overflow in certain payloads may lead to remote code execution Info just unembargoed, so links may time some time to update. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-41056 https://www.cve.org/CVERecord?id=CVE-2023-41056 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#1054777: Fwd: Bug#1054777: libfiu: FTBFS: dh_auto_test: error: make -j8 test V=1 LC_ALL=C returned exit code 2
Dear Alberto, > I think this is likely a problem I already fixed back in February in > commit 5dcc6d4. Ah, cherry-picking that commit fixed it for me. I've gone ahead and uploaded that to Debian in order to close this RC bug, but please do feel free to also release a libfiu v1.2 as well. That would have the added advantage of "clearing out" the other patch we had to apply re. Link-Time Optimisation. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1054777: Fwd: Bug#1054777: libfiu: FTBFS: dh_auto_test: error: make -j8 test V=1 LC_ALL=C returned exit code 2
Hey Alberto,
Hope all is well with you. Just wondering if you received the below
re. a recently-filed bug report against libfiu. I can reproduce it
locally if that helps.
Best wishes,
Chris
- Original message -
From: Lucas Nussbaum
To: sub...@bugs.debian.org
Subject: Bug#1054777: libfiu: FTBFS: dh_auto_test: error: make -j8 test V=1
LC_ALL=C returned exit code 2
Date: Friday, 27 October 2023 8:31 PM
Source: libfiu
Version: 1.1-4
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20231027 ftbfs-trixie
Hi,
During a rebuild of all packages in sid, your package failed to build
on amd64.
Relevant part (hopefully):
> make[4]: Entering directory '/<>/tests/utils'
> mkdir -p libs/
> ln -f ../../preload/posix/fiu_posix_preload.so libs/
> ln -f ../../preload/run/fiu_run_preload.so libs/
> LD_LIBRARY_PATH=../../libfiu/ ./test-basic_ctrl.py >
> output-test-basic_ctrl.py.txt 2>&1
> LD_LIBRARY_PATH=../../libfiu/ ./test-basic_run.sh >
> output-test-basic_run.sh.txt 2>&1
> ./generate-test -c tests/fprintf.conf -o tests/fprintf.c
> ./generate-test -c tests/fread.conf -o tests/fread.c
> ./generate-test -c tests/kill.conf -o tests/kill.c
> ./generate-test -c tests/malloc.conf -o tests/malloc.c
> ./generate-test -c tests/mmap.conf -o tests/mmap.c
> cc -I../../libfiu/ -L../../libfiu/ -L./ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE
> -fPIC -DFIU_ENABLE=1 -g -O2 -ffile-prefix-map=/<>=.
> -fstack-protector-strong -fstack-clash-protection -Wformat
> -Werror=format-security -fcf-protection -std=c99 -pedantic -Wall -std=c99
> -pedantic -Wall -L. binary.c -lfiu -lcoltest -o binary
> ./generate-test -c tests/open.conf -o tests/open.c
> ln -f ../preload/posix/fiu_posix_preload.so libs/
> ln -f ../preload/run/fiu_run_preload.so libs/
> ./generate-test -c tests/open64.conf -o tests/open64.c
> ./generate-test -c tests/pread.conf -o tests/pread.c
> ./generate-test -c tests/pread64.conf -o tests/pread64.c
> ./generate-test -c tests/strdup.conf -o tests/strdup.c
> cc -I../libfiu/ -L../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC
> -DFIU_ENABLE=1 -g -O2 -ffile-prefix-map=/<>=.
> -fstack-protector-strong -fstack-clash-protection -Wformat
> -Werror=format-security -fcf-protection -std=c99 -pedantic -Wall \
> -rdynamic -fno-optimize-sibling-calls test-enable_stack.c -lfiu
> -lpthread -o test-enable_stack
> test-enable_stack.c: In function 'main':
> test-enable_stack.c:32:50: warning: ISO C forbids conversion of function
> pointer to object pointer type [-Wpedantic]
>32 | r = fiu_enable_stack("fp-1", 1, NULL, 0, (void *) , -1);
> | ^
> cc -I../libfiu/ -L../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC
> -DFIU_ENABLE=1 -g -O2 -ffile-prefix-map=/<>=.
> -fstack-protector-strong -fstack-clash-protection -Wformat
> -Werror=format-security -fcf-protection -std=c99 -pedantic -Wall \
> -rdynamic -fno-optimize-sibling-calls test-enable_stack_by_name.c -lfiu
> -lpthread -o test-enable_stack_by_name
> cc -I../../libfiu/ -L../../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC
> -DFIU_ENABLE=1 -g -O2 -ffile-prefix-map=/<>=.
> -fstack-protector-strong -fstack-clash-protection -Wformat
> -Werror=format-security -fcf-protection -std=c99 -pedantic -Wall -std=c99
> -pedantic -Wall tests/fopen.c -lfiu -o tests/fopen.bin
> LD_LIBRARY_PATH="./:../../libfiu/" ./binary
> make[4]: Leaving directory '/<>/tests/collisions'
> cc -I../libfiu/ -L../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC
> -DFIU_ENABLE=1 -g -O2 -ffile-prefix-map=/<>=.
> -fstack-protector-strong -fstack-clash-protection -Wformat
> -Werror=format-security -fcf-protection -std=c99 -pedantic -Wall
> test-ferror.c -lfiu -lpthread -o test-ferror
> cc -I../../libfiu/ -L../../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC
> -DFIU_ENABLE=1 -g -O2 -ffile-prefix-map=/<>=.
> -fstack-protector-strong -fstack-clash-protection -Wformat
> -Werror=format-security -fcf-protection -std=c99 -pedantic -Wall -std=c99
> -pedantic -Wall tests/fprintf.c -lfiu -o tests/fprintf.bin
> cc -I../../libfiu/ -L../../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC
> -DFIU_ENABLE=1 -g -O2 -ffile-prefix-map=/<>=.
> -fstack-protector-strong -fstack-clash-protection -Wformat
> -Werror=format-security -fcf-protection -std=c99 -pedantic -Wall -std=c99
> -pedantic -Wall tests/fread.c -lfiu -o tests/fread.bin
> cc -I../../libfiu/ -L../../libfiu/ -D_XOPEN_SOURCE=600 -D_GNU_SOURCE -fPIC
> -DFIU_ENABLE=1 -g -O2 -ffile-prefix-map=/<>=.
> -fstack-protector-strong -fstack-clash-protection -Wformat
> -Werror=format-security -fcf-protection -std=c99 -pedantic -Wall -std=c99
> -pedantic -Wall tests/kill.c -lfiu -o tests/kill.bin
> LD_LIBRARY_PATH=../libfiu/
> LD_PRELOAD=./libs/fiu_run_preload.so:./libs/fiu_posix_preload.so
> ./test-enable_stack
> ./wrap-python 3 ./test-basic.py
> Can't find python3 bindings, run make python3
> make[3]: *** [Makefile:96:
Bug#1051226: python-django: CVE-2023-41164
Package: python-django Version: 1:1.11.29-1+deb10u9 X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerability was published for python-django. CVE-2023-41164[0]: Potential denial of service vulnerability in django.utils.encoding.uri_to_iri(); this was subject to potential denial of service attack via certain inputs with a very large number of Unicode characters. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-41164 https://www.cve.org/CVERecord?id=CVE-2023-41164 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#1050973: lastpass-cli: Please update to 1.3.5 upstream to fix certificate error
tags 1050973 + pending thanks Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#1040225: python-django: CVE-2023-36053
Package: python-django Version: 1:1.10.7-2+deb9u17 X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerability was published for python-django. CVE-2023-36053[0]: | In Django 3.2 before 3.2.20, 4 before 4.1.10, and 4.2 before 4.2.3, | EmailValidator and URLValidator are subject to a potential ReDoS | (regular expression denial of service) attack via a very large | number of domain name labels of emails and URLs. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-36053 https://www.cve.org/CVERecord?id=CVE-2023-36053 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload
No, please go ahead and do both: my availability is spotty for the next 18 hours. :) (on mobile) Utkarsh Gupta wrote: > Hi Chris, > > On Wed, Jun 7, 2023 at 9:01 PM Chris Lamb wrote: >> I see your 2.5.5-3+deb10u6 update on the debian/buster branch which >> fixes the broken +deb10u5 upload, but I don't see it in the archive >> yet. >> >> Although you mentioned you were going to wait a bit more, I'm just >> 100%-checking you aren't waiting on anything from me to upload that? > > Oh yeah, I wanted to sneak in some fixes and enable the tests and fix > the failing ones with the last upload. So I'll take care of the upload > and the announcement unless you prefer doing that since you did the > original upload? > > > -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload
Utkarsh, > I had missed your comment in the bug but super, many thanks for > testing this out! I'll wait a bit more before I roll this out. I see your 2.5.5-3+deb10u6 update on the debian/buster branch which fixes the broken +deb10u5 upload, but I don't see it in the archive yet. Although you mentioned you were going to wait a bit more, I'm just 100%-checking you aren't waiting on anything from me to upload that? Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1035467: python-django: CVE-2023-31047
Package: python-django Version: 1:1.11.29-1+deb10u7 X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerability was published for python-django: CVE-2023-31047: Potential bypass of validation when uploading multiple files using one form field Uploading multiple files using one form field has never been supported by forms.FileField or forms.ImageField as only the last uploaded file was validated. Unfortunately, Uploading multiple files topic suggested otherwise. In order to avoid the vulnerability, ClearableFileInput and FileInput` form widgets now raise ValueError when the multiple HTML attribute is set on them. To prevent the exception and keep the old behavior, set allow_multiple_selected to True. For more details on using the new attribute and handling of multiple files through a single field, see Uploading multiple files. — <https://www.djangoproject.com/weblog/2023/may/03/security-releases/> Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#1034128: memcached breaks cachelib autopkgtest: TimeoutError
Paul Gevers wrote:
> With a recent upload of memcached the autopkgtest of cachelib fails in
> testing when that autopkgtest is run with the binary packages of
> memcached from unstable. It passes when run with only packages from
> testing. In tabular form:
>
> passfail
> memcached from testing1.6.19-1
> cachelib from testing0.9.0-1
> all others from testingfrom testing
[..]
> E TimeoutError: The provided start pattern server
> listening could not be matched within the specified
> time interval of 120 seconds
Not sure what is going on here. However, I am dumping some links that I
came across so far:
* memcached release notes:
https://github.com/memcached/memcached/wiki/ReleaseNotes1619
* cachelib release notes: https://cachelib.readthedocs.io/en/stable/changes/
* A similar-looking report on cachelib's Issue Page:
https://github.com/pallets-eco/cachelib/issues/39
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org chris-lamb.co.uk
`-
Bug#1030600: redis breaks python-fakeredis autopkgtest: Connection refused
Adrian Bunk wrote: > Control: affects -1 src:beaker […] > beaker has a FTBFS that looks similar, without fakeredis installed: > https://buildd.debian.org/status/logs.php?pkg=beaker=1.12.1-1 Putting aside the question of the beaker FTBFS for a second, this issue (ie. #1030600, ie. preventing redis from migrating…) is, as I now believe, caused by the python-fakeredis testsuite being flaky. I can reproduce this fairly easily: $ PYTHONPATH=. python3.11 -Wd -m pytest -v test/test_hypothesis.py::TestString::test […] test/test_hypothesis.py::TestString::test PASSED 1 passed in 6.20s = $ PYTHONPATH=. python3.11 -Wd -m pytest -v test/test_hypothesis.py::TestString::test […] test/test_hypothesis.py::TestString::test PASSED 1 passed in 6.20s = $ PYTHONPATH=. python3.11 -Wd -m pytest -v test/test_hypothesis.py::TestString::test […] test/test_hypothesis.py::TestString::test FAILED […] In fact, Hypothesis is actually detecting this flakiness: E hypothesis.errors.Flaky: Inconsistent data generation! Data generation behaved differently between different runs. Is your data generation depending on external state? There might be other issues with redis (eg. the beaker FTBFS perhaps), but given that the fakeredis testsuite is currently nondeterministic, it's difficult to have something solid to reason from. :) (For the avoidance of doubt, I don't maintain python-fakeredis.) Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1031290: python-django: CVE-2023-24580 (denial-of-service vulnerability in file uploads)
Package: python-django Version: 1:1.11.29-1+deb10u6 X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerability was published for python-django. CVE-2023-24580[0]: Potential denial-of-service vulnerability in file uploads Passing certain inputs to multipart forms could result in too many open files or memory exhaustion, and provided a potential vector for a denial-of-service attack. The number of files parts parsed is now limited via the new DATA_UPLOAD_MAX_NUMBER_FILES setting. <https://www.djangoproject.com/weblog/2023/feb/14/security-releases/> If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2023-24580 https://www.cve.org/CVERecord?id=CVE-2023-24580 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#1030600: redis breaks python-fakeredis autopkgtest: Connection refused
Paul Gevers wrote: > With a recent upload of redis the autopkgtest of python-fakeredis fails > in testing when that autopkgtest is run with the binary packages of > redis from unstable. It passes when run with only packages from testing. Just had a stab at this. Unfortunately, I tried updating the python-fakeredis package to the latest upstream version (hey, it worked before!), but I believe I get the same errors. Some thoughts: * I wonder if this is a compatibility issue with python3-redis; a few issues on upstream's Github project seem to suggest the two projects are more interconnected that one might initially believe. * Here are the release notes for Redis, showing the difference between 7.0.7 in testing and 7.0.8 in unstable: https://raw.githubusercontent.com/redis/redis/7.0/00-RELEASENOTES Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1030251: marked as pending in python-django
Control: tag -1 pending Hello, Bug #1030251 in python-django reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-django/-/commit/58abeb151957d5a6009686b6828ed0fb09506ce9 New upstream release. (Closes: #1030251) (this message was generated automatically) -- Greetings https://bugs.debian.org/1030251
Bug#1030251: python-django: CVE-2023-23969 Potential denial-of-service via Accept-Language headers
Package: python-django
Version: 1:1.11.29-1+deb10u5
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security
Hi,
The following vulnerability was published for python-django.
CVE-2023-23969: Potential denial-of-service via Accept-Language headers
The parsed values of Accept-Language headers are cached in
order to avoid repetitive parsing. This leads to a potential
denial-of-service vector via excessive memory usage if large header
values are sent.
In order to avoid this vulnerability, the Accept-Language header is
now parsed up to a maximum length.
Thanks to Mithril for the report.
This issue has severity "moderate" according to the Django security
policy.
If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
For further information see:
[0] https://security-tracker.debian.org/tracker/CVE-2023-23969
https://www.cve.org/CVERecord?id=CVE-2023-23969
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
Bug#1029066: diffoscope: FTBFS if no internet is available (using internet connection during build)
Hi all,
> […]
As Mattia writes on the Salsa bug [0], I now don't think this is a
network issue. In other words, the package FTBFS regardless of whether
you have network access or not.
To make debugging this easier, I've split out the inline Python code
in c341b63a [1], and simply running the new script results in:
$ ping -q -c1 google.com 2>&1 | grep packet
1 packets transmitted, 1 received, 0% packet loss, time 0ms
$ debian/tests/generate-recommends.py
ERROR: Could not find an activated virtualenv (required).
Traceback (most recent call last):
File
"/home/lamby/git/debian/reproducible-builds/diffoscope/debian/tests/generate-recommends.py",
line 7, in
dist = meta.load(".")
^^
File "/usr/lib/python3/dist-packages/pep517/meta.py", line 72, in load
path = Path(build_as_zip(builder))
^
File "/usr/lib/python3/dist-packages/pep517/meta.py", line 59, in
build_as_zip
builder(dest=out_dir)
File "/usr/lib/python3/dist-packages/pep517/meta.py", line 53, in build
env.pip_install(system['requires'])
File "/usr/lib/python3/dist-packages/pep517/envbuild.py", line 103, in
pip_install
check_call(
File "/usr/lib/python3.11/subprocess.py", line 413, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/usr/bin/python3', '-m',
'pip', 'install', '--ignore-installed', '--prefix',
'/tmp/pep517-build-env-jzvg739_', 'setuptools', 'wheel']' returned
non-zero exit status 3.
Regarding when this was introduced, I think a confounding factor is
that this behaviour is reliant on the behaviour of the python3-pep517
package. (Maybe this *was* a network-related issue in the past as
well… but this matters very little now.)
As to a solution, though, I think this is somewhat blocking on Mattia's
expertise in the generation of the Python test recommends. Are we, in
essence, trying to parse the following data in setup.py?
install_requires=[
"python-magic",
"libarchive-c",
],
extras_require={
"distro_detection": ["distro"],
"cmdline": ["argcomplete", "progressbar"],
"comparators": [
"androguard",
"binwalk",
"defusedxml",
"guestfs",
"jsondiff",
"python-debian",
"pypdf",
"pyxattr",
"rpm-python",
"tlsh",
],
},
If so, we don't necessarily have to wholesale move to pyproject.toml;
instead, we could rejig setup.py...?
Chris
[0]
https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/325#note_366185
[1]
https://salsa.debian.org/reproducible-builds/diffoscope/commit/c341b63a4c8cfe56be883b43b4e4faff71fc060e
Bug#1026520: reprotest: FTBFS: AttributeError: module 're' has no attribute 'sre_parse'
reassign 1026520 python-rstr merge 1026569 1026520 affects 1026520 diffoscope thanks Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build > on amd64. Quite so. However, I think the problem is elsewhere: >> File "/usr/lib/python3/dist-packages/rstr/xeger.py", line 63, in xeger >> parsed = re.sre_parse.parse(pattern) >> >> AttributeError: module 're' has no attribute 'sre_parse' I believe this is #1026569 in python-rstr.
Bug#999259: leave: please make the build reproducible
tags 777403 + pending patch
tags 967002 + pending patch
tags 999259 + pending patch
thanks
I've just uploaded leave 1.12-2.2 to DELAYED/10:
leave (1.12-2.2) unstable; urgency=medium
.
* Non-maintainer upload.
* Pass -n to gzip(1) to make the manual page and changelog reproducible, as
well as pass CFLAGS to the C compiler to ensure that, for instance,
-ffile-prefix-map is used. (Closes: #777403)
* Apply a patch by Helmut Grohne to correctly cross-build the leave binary.
(Closes: #967002)
* Add the missing required debian/rules targets, build-arch and build-indep.
(Closes: #999259)
* Remove a "debian/changelog~" editor backup file.
The full debdiff is attached.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
diffstat for leave_1.12-2.1 leave_1.12-2.2
debian/changelog~ | 88
leave-1.12/debian/changelog | 14 +++
leave-1.12/debian/rules | 17
3 files changed, 23 insertions(+), 96 deletions(-)
diff -u leave-1.12/debian/changelog leave-1.12/debian/changelog
--- leave-1.12/debian/changelog
+++ leave-1.12/debian/changelog
@@ -1,3 +1,17 @@
+leave (1.12-2.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Pass -n to gzip(1) to make the manual page and changelog reproducible, as
+well as pass CFLAGS to the C compiler to ensure that, for instance,
+-ffile-prefix-map is used. (Closes: #777403)
+ * Apply a patch by Helmut Grohne to correctly cross-build the leave binary.
+(Closes: #967002)
+ * Add the missing required debian/rules targets, build-arch and build-indep.
+(Closes: #999259)
+ * Remove a "debian/changelog~" editor backup file.
+
+ -- Chris Lamb Thu, 06 Oct 2022 10:59:51 -0700
+
leave (1.12-2.1) unstable; urgency=low
* Non-maintainer upload.
reverted:
--- leave-1.12/debian/changelog~
+++ leave-1.12.orig/debian/changelog~
@@ -1,88 +0,0 @@
-leave (1.12-2) unstable; urgency=low
-
- * Exited with 0 instead of 1 for binary-indep, just for people who obsess
-with pointless details, closes: #395734.
-
- -- Josip Rodin Sat, 28 Oct 2006 00:10:22 +0200
-
-leave (1.12-1) unstable; urgency=low
-
- * New upstream version.
- * Added an unportable glibc-only variable to get the program name,
-because the unportable NetBSD-only variable didn't work.
-
- -- Josip Rodin Fri, 15 Aug 2003 21:10:23 +0200
-
-leave (1.10-1) unstable; urgency=low
-
- * New upstream version, closes: #143720.
-Abolished our patches for handling 24-hour time formats, and used
-the upstream's. The behaviour is unchanged, AFAICT.
- * Updated for Policy 3.5.6. debian/rules in shell,
-removed the use of both debhelper and pmake -> no Build-Depends :)
-
- -- Josip Rodin Mon, 26 Aug 2002 14:40:30 +0200
-
-leave (1.8-2) unstable; urgency=low
-
- * Fixed those long standing bugs in the handling of 24h-clock
-arguments, by making leave not convert times to 12h clock, but check
-whether the time is between 1 and 12, and then interpret it according
-to a 12-hour clock. Let's hope it all works.
-Thanks to Sergio Gelato , who provided
-the patch both for the code and for the manual page.
-(closes #25150 #26000 #31250 #31872)
- * Updated for Policy 3.x. Removed the full text of the BSD license from
-the copyright file and referenced the /usr/share/common-licenses/BSD
-file.
-
- -- Josip Rodin Mon, 18 Oct 1999 23:13:16 +0200
-
-leave (1.8-1) unstable; urgency=low
-
- * New maintainer, new upstream source (with exactly two (2) new lines
-of code), new debian/* files.
-
- -- Josip Rodin Wed, 19 May 1999 18:13:22 +0200
-
-leave (1.6-2) unstable; urgency=low
-
- * debian/control (Maintainer): new address.
- * debian/copyright: ditto.
- * debian/control (Standards-Version): updated to 2.5.0.0.
- * debian/rules: replace $(package) with a string literal and other minor
-clean ups.
-
- -- James Troup Tue, 10 Nov 1998 15:46:23 +
-
-leave (1.6-1) unstable; urgency=low
-
- * New upstream version.
- * debian/rules: Use BSD make not GNU make to build.
- * debian/rules: Build with -g.
- * debian/rules: Call dpkg-gencontrol with -isp.
- * debian/rules: remove leave.cat1 on clean.
- * debian/rules: no more {,} usage.
- * debian/rules: chmod go=rX not g-ws.
- * debian/control: Standards-Version 2.3.0.1.
- * debian/control: section is really utils not misc.
- * debian/copyright: removed over-keen "famous" from description.
-
- -- James Troup Mon, 8 Dec 1997 21:03:01 +
-
-leave (1.4-3) unstable; urgency=low
-
- * Rebuilt libc6.
-
- -- James Troup Wed, 25 Jan 1997 18:30:06 +
-
-leave (1.4-2) unstable; urgency=low
-
- * New Maintainer.
- * Updated package to standards version 2.1.1.2.
-
- -- James Troup Wed, 22 Jan 1997 00:30:17 +
-
-Local variables:
-mode: debian-changelog
-End:
diff -u l
Bug#999219: xcolmix: reproducible-builds: Embedded build path in /usr/bin/xcolmix
tags 1020748 + pending patch tags 999219 + pending patch tags 988018 + pending patch thanks I've just uploaded xcolmix 1.07-10.1 to DELAYED/10: xcolmix (1.07-10.1) unstable; urgency=medium . * Non-maintainer upload. * Add missing required debian/rules targets build-arch and/or build-indep. (Closes: #999219) * Apply a patch by Helmut Grohne to correctly pass cross-building tools to Make. (Closes: #988018) * Make the build reproducible by adapting debian/rules to use CFLAGS from dpkg-buildflags(1), appending -ffile-prefix-map. (Closes: #1020748) The full debdiff is attached. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- diffstat for xcolmix-1.07 xcolmix-1.07 changelog | 12 rules |5 - 2 files changed, 16 insertions(+), 1 deletion(-) diff -Nru xcolmix-1.07/debian/changelog xcolmix-1.07/debian/changelog --- xcolmix-1.07/debian/changelog 2010-05-27 17:47:37.0 -0700 +++ xcolmix-1.07/debian/changelog 2022-10-06 09:41:37.0 -0700 @@ -1,3 +1,15 @@ +xcolmix (1.07-10.1) unstable; urgency=medium + + * Non-maintainer upload. + * Add missing required debian/rules targets build-arch and/or build-indep. +(Closes: #999219) + * Apply a patch by Helmut Grohne to correctly pass cross-building tools to +Make. (Closes: #988018) + * Make the build reproducible by adapting debian/rules to use CFLAGS from +dpkg-buildflags(1), appending -ffile-prefix-map. (Closes: #1020748) + + -- Chris Lamb Thu, 06 Oct 2022 09:41:37 -0700 + xcolmix (1.07-10) unstable; urgency=low * Rebuild against libforms2. diff -Nru xcolmix-1.07/debian/rules xcolmix-1.07/debian/rules --- xcolmix-1.07/debian/rules 2010-05-27 17:45:10.0 -0700 +++ xcolmix-1.07/debian/rules 2022-10-06 09:41:37.0 -0700 @@ -7,10 +7,13 @@ package=xcolmix +build-arch: build +build-indep: build + build: $(checkdir) - (cd src; make final STDLFLAGS="-L /usr/X11R6/lib" STDCFLAGS="-c -O2 -Wall $(XFINCDIR) -g") + dh_auto_build --sourcedirectory=src -- final STDLFLAGS="-L /usr/X11R6/lib" STDCFLAGS="$(XFINCDIR) $(shell dpkg-buildflags --get CFLAGS)" touch build clean:
Bug#998978: mailto: please make the build reproducible
tags 777413 + pending patch
thanks
I've just uploaded mailto 1.3.2-3.1 to DELAYED/10:
mailto (1.3.2-3.1) unstable; urgency=medium
.
* Non-maintainer upload.
* Implement the required build-arch and build-indep targets in debian/rules.
(Closes: #998978)
* Make the build reproducible by adding "-n" to the gzip(1) invocation.
(Closes: #777413)
The full debdiff is attached.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
diffstat for mailto_1.3.2-3 mailto_1.3.2-3.1
changelog | 10 ++
rules |5 -
2 files changed, 14 insertions(+), 1 deletion(-)
diff -u mailto-1.3.2/debian/changelog mailto-1.3.2/debian/changelog
--- mailto-1.3.2/debian/changelog
+++ mailto-1.3.2/debian/changelog
@@ -1,3 +1,13 @@
+mailto (1.3.2-3.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Implement the required build-arch and build-indep targets in debian/rules.
+(Closes: #998978)
+ * Make the build reproducible by adding "-n" to the gzip(1) invocation.
+(Closes: #777413)
+
+ -- Chris Lamb Thu, 06 Oct 2022 09:26:08 -0700
+
mailto (1.3.2-3) unstable; urgency=low
* Disable included version of getline() since it is unused and produce
diff -u mailto-1.3.2/debian/rules mailto-1.3.2/debian/rules
--- mailto-1.3.2/debian/rules
+++ mailto-1.3.2/debian/rules
@@ -37,6 +37,9 @@
installdoc= install -g root -o root -m 644
installscript = install -g root -o root -m 755
+build-arch: build
+build-indep: build
+
build:
$(MAKE) CFLAGS="$(CFLAGS)"
touch stamp-build
@@ -66,7 +69,7 @@
#
$(installdoc) debian/changes
debian/tmp/usr/share/doc/$(package)/changelog
$(installdoc) debian/{readme,usage}.txt
debian/tmp/usr/share/doc/$(package)
- gzip -9f
debian/tmp/usr/share/doc/$(package)/{changelog{,.Debian},{readme,usage}.txt}
+ gzip -9fn
debian/tmp/usr/share/doc/$(package)/{changelog{,.Debian},{readme,usage}.txt}
#
$(installdir) debian/tmp/etc
$(installdoc) debian/mailto.conf debian/tmp/etc
Bug#1017556: src:redis: fails to migrate to testing for too long: autopkgtest regressions
Paul Gevers wrote: > If you believe your package is unable to migrate to testing due to > issues beyond your control, don't hesitate to contact the Release Team. I think I've fixed the two underlying issues have been fixed: * python-fakeredis was fixed in #1014101 * python-redis was fixed in #1014102 Perhaps jobs just need to be resubmitted? I see that the version numbers on: https://qa.debian.org/excuses.php?package=redis ... refer to the unfixed versions; for example, python-fakeredis (version 1.6.1-1) was fixed in 1.7.1-1. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1017556: src:redis: fails to migrate to testing for too long: autopkgtest regressions
Hi Paul,
> I have prepared a new version of python-fakeredis which builds and
> passes its autopkgtest in unstable:
> https://salsa.debian.org/python-team/packages/python-fakeredis/-/merge_requests/1
> https://salsa.debian.org/python-team/packages/python-fakeredis/-/merge_requests/2
> https://salsa.debian.org/python-team/packages/python-fakeredis/-/merge_requests/3
Uploading now. :)
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org chris-lamb.co.uk
`-
Bug#1016090: python-django breaks lots of autopkgtests
Raphael Hertzog wrote: > As such, as much as I hate it, I think than only (a) is realistic. Yeah. :/ Okay, I'll upload 3.3.14 shortly. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1016090: python-django breaks lots of autopkgtests
Raphael Hertzog wrote: > I'm surprised that we uploaded an non-LTS release to unstable. > > Chris, why did you do that? Hmpf, this is deeply unfortunate. I was working under the incorrect belief that the 4.0.x series was now the LTS branch. A number of things encouraged this interpretation, including that the 4.0.x and 4.1.x were the release streams that were receiving security and targeted bugfix releases, and this was happening as a relatively consistent pair. (As in, not the 3.x stream.) Regardless of that though, I think we have two options: a) Revert back to the 3.2.14 LTS version in Debian unstable. b) Wait for the 4.x stream to become designated LTS. I believe this should happen with version 4.2, due for release in about 6 or 7 months: https://www.djangoproject.com/download/ Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1014541: python-django: CVE-2022-34265
Package: python-django Version: 1:1.10.7-2+deb9u17 X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerability was published for python-django. CVE-2022-34265 [0]: | An issue was discovered in Django 3.2 before 3.2.14 and 4.0 before | 4.0.6. The Trunc() and Extract() database functions are subject to SQL | injection if untrusted data is used as a kind/lookup_name value. | Applications that constrain the lookup name and kind choice to a known | safe list are unaffected. This affects: * stretch (1:1.10.7-2+deb9u17) * buster (1:1.11.29-1~deb10u1) * bookworm (2:3.2.13-1) sid was already fixed in 2:4.0.6-1 and jessie is unaffected as Trunc(...) and Extract(...) support was added later. Let me know if you'd like me to prepare updates for any of stretch, buster & bookworm. [0] https://security-tracker.debian.org/tracker/CVE-2022-34265 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#1013615: hiredis: FTBFS: 2 TESTS FAILED ***
>> #54 Does not return a reply when the command times out: [0;31mFAILED[0;0m I suspect that the root cause here is that Redis 7.x is now in unstable (vs. 6.x). // Chris
Bug#1013348: test_elf.py fails with binutils in unstable
tags 1013348 + pending thanks > the test_elf.py test fails with binutils from the trunk: Thanks for the report. I've fixed this earlier today with this commit: https://salsa.debian.org/reproducible-builds/diffoscope/commit/280ff40115af104685932b96e83ccb79f78afabb It fixes it in our Salsa CI pipeline, and I'll upload it tomorrow. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#1013172: redis: Failed at step EXEC spawning /usr/bin/redis-server: Permission denied
Hi Christian,
> The cause seems to be the following systemd hardening options (when
> commented out redis starts successfully):
>
> NoExecPaths=/
> ExecPaths=/usr/bin/redis-server /usr/lib
>
> Probably cause is that /usr/bin/redis-server is a symlink to
> /usr/bin/redis-check-rdb.
Hm! That is an interesting hypothesis, but I can't seem to reproduce
this problem locally. I'm using systemd 251.2-5, you?
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org chris-lamb.co.uk
`-
Bug#1011187: redis: FTBFS: killed due to inactivity
Sebastian Ramacher wrote: > E: Build killed with signal TERM after 150 minutes of inactivity > [..] Hm, I requested a giveback using the automated service and it seems to build properly... this time. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1009677: python-django: CVE-2022-28346
Package: python-django Version: 1:1.10.7-2+deb9u15 X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerability was published for python-django. CVE-2022-28346[0]: | An issue was discovered in Django 2.2 before 2.2.28, 3.2 before | 3.2.13, and 4.0 before 4.0.4. QuerySet.annotate(), aggregate(), and | extra() methods are subject to SQL injection in column aliases via a | crafted dictionary (with dictionary expansion) as the passed **kwargs. There was another CVE as part of this release: https://www.djangoproject.com/weblog/2022/apr/11/security-releases/ However, the CVE in question (CVE-2022-28347), does not apply in buster, stretch or jessie; the .explain(...) functionality was added later versions. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2022-28346 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-28346 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#1006999: python-plac: Non-determinstically FTBFS on amd64/unstable due to timing in tests
Source: python-plac Version: 1.3.4-1 Severity: serious Justification: fails to build from source User: reproducible-bui...@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org Tags: fbtfs Dear maintainer, python-plac will randomly fail to build because the testsuite performs timing/benchmarking. This will vary on (for example) CPU and I/O load. test3 _ def test3(): t0 = time.time() plac.runp([gen(9), gen(9)]) > assert int(time.time() - t0) == 1 # it must take 1 second, not 2 E assert 2 == 1 E +2 E -1 /build/1st/python-plac-1.3.4/.pybuild/cpython3_3.9_plac/build/doc/test_runp.py:26: AssertionError === short test summary info FAILED doc/test_runp.py::test3 - assert 2 == 1 = 1 failed, 28 passed in 6.12s = […] The full build log is attached or can be viewed here: https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/python-plac_1.3.4-1.rbuild.log.gz Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `- python-plac.1.3.4-1.unstable.amd64.log.txt.gz Description: Binary data
Bug#1005787: redis: CVE-2022-0543
Package: redis Version: 5:5.0.14-1+deb10u1 X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, A vulnerability was published for redis as CVE-2022-0543[0]. This is the placeholder Debian bug which will be renamed and fleshed out later with more details once it has become unembargoed. [0] https://security-tracker.debian.org/tracker/CVE-2022-0543 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0543 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#1004752: python-django: CVE-2022-22818 CVE-2022-23833
Package: python-django
Version: 1:1.10.7-2+deb9u14
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security
Hi,
The following vulnerabilities were published for python-django:
* CVE-2022-22818: Possible XSS via {% debug %} template tag
The {% debug %} template tag didn't properly encode the current
context, posing an XSS attack vector.
In order to avoid this vulnerability, {% debug %} no longer outputs
information when the DEBUG setting is False, and it ensures all
context variables are correctly escaped when the DEBUG setting is
True.
* CVE-2022-23833: Denial-of-service possibility in file uploads
Passing certain inputs to multipart forms could result in an
infinite loop when parsing files.
This issue has severity "medium" according to the Django security policy.
If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
For further information see:
[0] https://security-tracker.debian.org/tracker/CVE-2022-22818
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22818
[1] https://security-tracker.debian.org/tracker/CVE-2022-23833
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23833
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
Bug#1004464: python-django FTBFS: FAIL: test_custom_fields (inspectdb.tests.InspectDBTestCase)
Hi, >> Just to point out that you specified the 'Version' here as 2:3.2.7, >> whilst the traceback you linked to: >> >> > https://buildd.debian.org/status/fetch.php?pkg=python-django=all=2%3A3.2.11-1=1641309500=0 >> >> ... refers to a different version: 2:3.2.11. [..] > That was intentional: > The package does FTBFS both on the buildds and in reproducible > in both unstable and experimental, and the version in testing > did also FTBFS for me in an unstable chroot. Ah, I see — thanks for checking so many versions. I've just uploaded a fix; it was a SQLite compatibility issue. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1004464: marked as pending in python-django
Control: tag -1 pending Hello, Bug #1004464 in python-django reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-django/-/commit/8080a59ae57921718fa53e4355ea112ba734be17 Fix compatibility with SQLite 3.37+. (Closes: #1004464) (this message was generated automatically) -- Greetings https://bugs.debian.org/1004464
Bug#1004464: marked as pending in python-django
Control: tag -1 pending Hello, Bug #1004464 in python-django reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-django/-/commit/875f902415bc77a246eb23fc8e9e9ad6eaad2762 Fix compatibility with SQLite 3.37+. (Closes: #1004464) (this message was generated automatically) -- Greetings https://bugs.debian.org/1004464
Bug#1004464: python-django FTBFS: FAIL: test_custom_fields (inspectdb.tests.InspectDBTestCase)
found 1004464 2:3.2.11-1 thanks Hi Adrian, > Version: 2:3.2.7-1 Just to point out that you specified the 'Version' here as 2:3.2.7, whilst the traceback you linked to: > https://buildd.debian.org/status/fetch.php?pkg=python-django=all=2%3A3.2.11-1=1641309500=0 ... refers to a different version: 2:3.2.11. It's not a problem at all — am only mentioning it explicitly in case you have a bug in a script (or similar) that might need updating. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1003113: python-django: CVE-2021-45115, CVE-2021-45116 & CVE-2021-45452
Hi Moritz, >> I was just looking at these CVEs for ELTS and LTS, but before I make >> a move there, I was just wondering if you were planning on (or would >> like) a DSA. > > Hi Chris, > these both seem rather harmless to me, I'd say we postpone them until > the next round of more serious Django issues? That works for me. I think I've reflected that in data/CVE/list in this commit: https://salsa.debian.org/security-tracker-team/security-tracker/commit/09807490bc5924c02b11adb4f85ed9467f50efcf Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1003113: python-django: CVE-2021-45115, CVE-2021-45116 & CVE-2021-45452
Hi Security Team, I was just looking at these CVEs for ELTS and LTS, but before I make a move there, I was just wondering if you were planning on (or would like) a DSA. — Chris > * CVE-2021-45115: Denial-of-service possibility in > UserAttributeSimilarityValidator [0] > > UserAttributeSimilarityValidator incurred significant overhead > evaluating submitted password that were artificially large in > relative to the comparison values. On the assumption that access > to user registration was unrestricted this provided a potential > vector for a denial-of-service attack. > > In order to mitigate this issue, relatively long values are now > ignored by UserAttributeSimilarityValidator. > > * CVE-2021-45116: Potential information disclosure in dictsort > template filter [1] > > Due to leveraging the Django Template Language's variable resolution > logic, the dictsort template filter was potentially vulnerable to > information disclosure or unintended method calls, if passed a > suitably crafted key. > > In order to avoid this possibility, dictsort now works with a > restricted resolution logic, that will not call methods, nor allow > indexing on dictionaries. > > * CVE-2021-45452: Potential directory-traversal via Storage.save() [2] > > Storage.save() allowed directory-traversal if directly passed > suitably crafted file names. -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#1003113: python-django: CVE-2021-45115, CVE-2021-45116 & CVE-2021-45452
Package: python-django Version: 1:1.10.7-2+deb9u14 X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerabilities were published for python-django: * CVE-2021-45115: Denial-of-service possibility in UserAttributeSimilarityValidator [0] UserAttributeSimilarityValidator incurred significant overhead evaluating submitted password that were artificially large in relative to the comparison values. On the assumption that access to user registration was unrestricted this provided a potential vector for a denial-of-service attack. In order to mitigate this issue, relatively long values are now ignored by UserAttributeSimilarityValidator. * CVE-2021-45116: Potential information disclosure in dictsort template filter [1] Due to leveraging the Django Template Language's variable resolution logic, the dictsort template filter was potentially vulnerable to information disclosure or unintended method calls, if passed a suitably crafted key. In order to avoid this possibility, dictsort now works with a restricted resolution logic, that will not call methods, nor allow indexing on dictionaries. * CVE-2021-45452: Potential directory-traversal via Storage.save() [2] Storage.save() allowed directory-traversal if directly passed suitably crafted file names. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-45115 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45115 [1] https://security-tracker.debian.org/tracker/CVE-2021-45116 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45116 [2] https://security-tracker.debian.org/tracker/CVE-2021-45452 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45452 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#996995: dh-python: Unable to parse debian/control
tags 996995 + patch
severity 996995 serious
thanks
Patch attached.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-
diff --git a/dhpython/debhelper.py b/dhpython/debhelper.py
index 7308bbe..55b91c0 100644
--- a/dhpython/debhelper.py
+++ b/dhpython/debhelper.py
@@ -80,6 +80,10 @@ class DebHelper:
except IOError:
raise Exception('cannot find debian/control file')
+# Strip any paragraphs that are entirely empty, which could be caused
+# by commented-out packages.
+paragraphs = [x for x in paragraphs if x]
+
if len(paragraphs) < 2:
raise Exception('Unable to parse debian/control, found less than '
'2 paragraphs')
Bug#993651: lintian: "Profile debian/main references unknown checks" when run from Debian package
Package: lintian Version: 2.104.0 Severity: serious Hi, Building the Debian package of Lintian from Git (5de96f0301) and then running it, for example, on itself results in the error below. Am assuming it's a dev/prod path issue, and had a glance at the code but couldn't quite work out why it couldn't find the checks in the import path. Profile debian/main references unknown checks: apache2 application-not-library appstream-metadata apt binaries build-systems/automake build-systems/autotools build-systems/autotools/libtool build-systems/cmake build-systems/waf changes-file conffiles continuous-integration/salsa control-files cron cruft deb-format debhelper debian/changelog debian/control debian/copyright debian/copyright/apache-notice debian/copyright/dep5 debian/debconf debian/desktop-entries debian/filenames debian/files debian/line-separators debian/lintian-overrides debian/lintian-overrides/comments debian/manual-pages debian/not-installed debian/patches debian/patches/count debian/patches/dep3 debian/patches/dpatch debian/patches/quilt debian/po-debconf debian/readme debian/rules debian/rules/dh-sequencer debian/source-dir debian/source/include-binaries debian/substvars debian/symbols debian/trailing-whitespace debian/upstream/metadata debian/upstream/signing-key debian/variables debian/version-substvars debian/watch debian/watch/standard desktop/dbus desktop/gnome desktop/gnome/gir desktop/icons desktop/x11 dh-make documentation documentation/doxygen documentation/examples documentation/manual documentation/texinfo emacs emacs/elpa examples fields/architecture fields/bugs fields/built-using fields/changed-by fields/checksums fields/deb822 fields/derivatives fields/description fields/distribution fields/dm-upload-allowed fields/empty fields/essential fields/format fields/homepage fields/installer-menu-item fields/length fields/mail-address fields/maintainer fields/maintainer/team fields/multi-arch fields/multi-line fields/origin fields/package fields/package-relations fields/package-type fields/priority fields/recommended fields/required fields/section fields/source fields/standards-version fields/style fields/subarchitecture fields/terminal-control fields/trimmed fields/unknown fields/uploaders fields/urgency fields/vcs fields/version filename-length files/architecture files/banned files/banned/compiled-help files/banned/lenna files/bugs files/build-path files/compressed files/compressed/bz2 files/compressed/gz files/compressed/lz files/compressed/lzma files/compressed/lzo files/compressed/xz files/compressed/zip files/config-scripts files/contents files/date files/debug files/debug-packages files/desktop files/devhelp files/duplicates files/empty-directories files/empty-package files/encoding files/hard-links files/hierarchy/links files/hierarchy/merged-usr files/hierarchy/path-segments files/hierarchy/standard files/ieee-data files/includes files/init files/ld-so files/licenses files/locales files/missing files/multi-arch files/names files/non-free files/obsolete-paths files/ownership files/p11-kit files/pam files/permissions files/permissions/usr-lib files/pkgconfig files/privacy-breach files/scripts files/sgml files/special files/symbolic-links files/symbolic-links/broken files/unwanted files/usr-merge files/vcs fonts fonts/opentype fonts/postscript/type1 fonts/truetype foreign-operating-systems games group-checks huge-usr-share images images/filenames images/thumbnails includes/config-h init-d languages/fortran/gfortran languages/java languages/java/bytecode languages/javascript/embedded languages/javascript/nodejs languages/ocaml languages/perl languages/perl/perl5 languages/perl/yapp languages/php languages/php/embedded languages/php/pear languages/php/pear/embedded languages/python languages/python/bogus-prerequisites languages/python/dist-overrides languages/python/feedparser languages/python/homepage languages/python/obsolete languages/python/scripts languages/r languages/r/architecture languages/r/site-library languages/ruby languages/rust libraries/shared/obsolete linda lintian mailcap maintainer-scripts/adduser maintainer-scripts/generated md5sums menu-format menus mimeinfo modprobe nmu obsolete-sites origtar pe scripts shared-libs systemd systemd/tmpfiles team/pkg-js/deprecated team/pkg-js/testsuite team/pkg-js/vcs team/pkg-perl/testsuite team/pkg-perl/vcs team/pkg-perl/xs-abi testsuite triggers udev upstream-signature usrmerge vim vim/addons at /usr/share/lintian/bin/../lib/Lintian/Profile.pm line 606. Lintian::Profile::read_profile(Lintian::Profile=HASH(0x564511daa230), undef) called at /usr/share/lintian/bin/../lib/Lintian/Profile.pm line 372 Lintian::Profile::load(Lintian::Profile=HASH(0x564511daa230), undef, ARRAY(0x5645120b1938), 1) called at /usr/bin/lintian line 502 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#982122: redis: experimental package OOMs s390x buildds
forwarded 982122 https://github.com/redis/redis/issues/9369 thanks Hi Julien, > https://people.debian.org/~jcristau/redis_6.2.5-2_s390x-2021-08-11T16:17:34Z This was very useful and, in conjunction with your suggestion of potentially reproducing it on a porterbox, I have been able to reproduce this on zelenka.debian.org... leading me to have enough info to file it upstream: https://github.com/redis/redis/issues/9369 As I mention there, it is currently unknown whether the changes in the rather suspect commit introduced the underlying problem or merely introducing a test that exposes it. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#982122: redis: experimental package OOMs s390x buildds
Hey Julian, > sorry about my tone yesterday, and thanks for working on this, that's > great to hear. Really, no worries at all... Still, I'm somewhat at a loss to debug this. In the first instance, can one of you throw over the s390x log for the latest upload? As alluded to in my previous mail, that should have some more debugging information and buildd.debian.org is telling me "no log" at the moment. Failing that, I would be happy to disable the testsuite for the time being, limiting this to s390x on the problematic experimental branch. Let me know your thoughts on this. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#982122: redis: experimental package OOMs s390x buildds
Julien Cristau wrote: > It'd be appreciated if you could make fixing this a priority, and > refrained from uploading further versions until then. Sure. Just to say though, your message was rather unfortunate to receive given this latest upload was, in part, an attempt to resolve this very issue. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#991451: redis breaks python-fakeredis autopkgtest: AssertionError
Jochen Sprickerhof wrote: > I have no idea about Redis/Fakeredis, adding Ondřej as he did all the > uploads, lately. Hey Ondřej, any input here? Otherwise, not sure what to suggest... Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#991476: redis: insane amount of memory used by the testsuite on s390x
Hey Aurelien,
> For what I have remarked is that the 2560 PiB is allocated from around
> the beginning of the testsuite, but the crash happened way later. It
> might just be that there is original issue (allocating insane amount of
> memory) that is there for some time, but that using many part of it in
> one of the tests is something new.
Thanks for the logs. As you imply, however, it doesn't seem to narrow
down which test (and thus which part of Redis itself) needs to be
adjusted. The fact that the testsuite is checking invalid input for
OOMing whilst the testsuite crashes is rather fishy... but I fear not
quite definitive enough to take to upstream.
Would you object if I uploaded the following change to experimental so
that we can track it down better? Otherwise, am not sure what to
suggest here:
https://salsa.debian.org/lamby/pkg-redis/commit/98b2cbd5085cd1d526ac9f30cb205ebcf8d8e38a
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org chris-lamb.co.uk
`-
Bug#991451: redis breaks python-fakeredis autopkgtest: AssertionError
Chris Lamb wrote: > Sure thing -- I've forwarded this upstream here: > > https://github.com/redis/redis/issues/9273 Okay, so the latest reply there suggests that this is (now) the expected and behaviour of Redis going forward. I still don't quite grasp what it is that fakeredis is testing though, so I can't state with any authority whether it definitely is fakeredis that needs to be addressed, but reverting this behavioural change in Redis does not seem the right way to go at all (!). Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#991451: redis breaks python-fakeredis autopkgtest: AssertionError
forwarded 991451 https://github.com/redis/redis/issues/9273 thanks Hi Jochen, > As far as I read https://redis.io/topics/data-types-intro this should be > allowed, but I don't really [know] Redis. Can you report this to upstream if > you agree? Sure thing -- I've forwarded this upstream here: https://github.com/redis/redis/issues/9273 As you can see, your testcase was very useful in putting together this bug report. Thanks! Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#991476: redis: insane amount of memory used by the testsuite on s390x
Hi Aurelien, > Version 5:6.2.4-1 built fine, so it's likely a regression introduced in > the new upstream version. Thanks for the report. I just have a few minutes to look into this right this second so (for my own convenience) I've attached the diff between these two particular upstream versions. There is this entry in the upstream changelog that might be worthy of further investigation: * Fix ziplist length updates on big-endian platforms (#2080) Do you happen to have the full log of this failing build though? I would suspect it's something in the testsuite that's exposing this issue, but being able to pin it down would be the ideal next step, especially as the testsuite is so large (and there were quite a few changes). Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-diff --git a/.github/workflows/daily.yml b/.github/workflows/daily.yml index 9e4630e2..432971a9 100644 --- a/.github/workflows/daily.yml +++ b/.github/workflows/daily.yml @@ -151,7 +151,7 @@ jobs: run: | sudo apt-get update sudo apt-get install tcl8.6 valgrind -y -./runtest --valgrind --verbose --clients 1 --dump-logs +./runtest --valgrind --verbose --clients 1 --tags -large-memory --dump-logs - name: module api test run: ./runtest-moduleapi --valgrind --no-latency --verbose --clients 1 - name: unittest @@ -171,7 +171,7 @@ jobs: run: | sudo apt-get update sudo apt-get install tcl8.6 valgrind -y -./runtest --valgrind --verbose --clients 1 --dump-logs +./runtest --valgrind --verbose --clients 1 --tags -large-memory --dump-logs - name: module api test run: ./runtest-moduleapi --valgrind --no-latency --verbose --clients 1 @@ -260,7 +260,7 @@ jobs: prepare: pkg install -y bash gmake lang/tcl86 run: > gmake && - ./runtest --accurate --verbose --no-latency --dump-logs && + ./runtest --accurate --verbose --no-latency --tags -large-memory --dump-logs && MAKE=gmake ./runtest-moduleapi --verbose && ./runtest-sentinel && ./runtest-cluster diff --git a/00-RELEASENOTES b/00-RELEASENOTES index 9411714e..a5fb897e 100644 --- a/00-RELEASENOTES +++ b/00-RELEASENOTES @@ -12,7 +12,54 @@ SECURITY: There are security fixes in the release. -Redis 6.2.4 Released Tue July 1 12:00:00 IST 2021 +Redis 6.2.5 Released Wed Jul 21 16:32:19 IDT 2021 + + +Upgrade urgency: SECURITY, contains fixes to security issues that affect +authenticated client connections on 32-bit versions. MODERATE otherwise. + +Fix integer overflow in BITFIELD on 32-bit versions (CVE-2021-32761). +An integer overflow bug in Redis version 2.2 or newer can be exploited using the +BITFIELD command to corrupt the heap and potentially result with remote code +execution. + +Bug fixes that involve behavior changes: +* Change reply type for ZPOPMAX/MIN with count in RESP3 to nested array (#8981). + Was using a flat array like in RESP2 instead of a nested array like ZRANGE does. +* Fix reply type for HRANDFIELD and ZRANDMEMBER when key is missing (#9178). + Was using a null array instead of an empty array. +* Fix reply type for ZRANGESTORE when source key is missing (#9089). + Was using an empty array like ZRANGE instead of 0 (used in the STORE variant). + +Bug fixes that are only applicable to previous releases of Redis 6.2: +* ZRANDMEMBER WITHSCORES with negative COUNT may return bad score (#9162) +* Fix crash after CLIENT UNPAUSE when threaded I/O config is enabled (#9041) +* Fix XTRIM or XADD with LIMIT may delete more entries than the limit (#9048) +* Fix build issue with OpenSSL 1.1.0 (#9233) + +Other bug fixes: +* Fail EXEC command in case a watched key is expired (#9194) +* Fix SMOVE not to invalidate dest key (WATCH and tracking) when member already exists (#9244) +* Fix SINTERSTORE not to delete dest key when getting a wrong type error (#9032) +* Fix overflows on 32-bit versions in GETBIT, SETBIT, BITCOUNT, BITPOS, and BITFIELD (#9191) +* Improve MEMORY USAGE on stream keys (#9164) +* Set TCP keepalive on inbound cluster bus connections (#9230) +* Fix diskless replica loading to recover from RDB short read on module AUX data (#9199) +* Fix race in client side tracking (#9116) +* Fix ziplist length updates on big-endian platforms (#2080) + +CLI tools: +* redis-cli cluster import command may issue wrong MIGRATE command, sending COPY instead of REPLACE (#8945) +* redis-cli --rdb fixes when using "-" to write to stdout (#9136, #9135) +* redis-cli support for RESP3 set type in CSV and RAW output (#7338) + +Modules: +*
Bug#991451: redis breaks python-fakeredis autopkgtest: AssertionError
Hi Paul, > > However, why the slight change to security-related overflow handling > > in bitfield fields *on i386 systems* should result in this failure > > eludes me... :/ > > The changelog mentions some other bug fixes, the first one looks > potentially related (new failure): > Fail EXEC command in case a watched key is expired (#9194) > and so does the third (WRONGTYPE error): > Fix SINTERSTORE not to delete dest key when getting a wrong type error > (#9032) Good news. I've tried reverting a bunch of commits from the changelog, and I can narrow it down to: https://github.com/redis/redis/pull/9032 As in, reverting the commit associated with this pull request: https://github.com/redis/redis/commit/1655576e23c41ea9c12a42699651d207656a0e83 ... results in the test passing again. § I'd be happy to report this to Redis upstream, but I have no evidence that this indicates an actual bug in Redis itself or any kind of "When I see X we see Y but we should see Z". I lack knowledge about what python-fakeredis is actually testing here (as well as how Hypothesis works!) to determine which package is buggy. Could the fakeredis maintainer chime in perhaps? Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#991451: redis breaks python-fakeredis autopkgtest: AssertionError
Paul Gevers wrote: > With a recent upload of redis the autopkgtest of python-fakeredis fails > in testing when that autopkgtest is run with the binary packages of > redis from unstable. It passes when run with only packages from testing. Just to confirm that I can reliably and locally reproduce the failure of the: test/test_hypothesis.py::TestJoint::test ... test in python-fakeredis when run against redis 5:6.0.15-1 on my amd64 machine, and it reliably succeeds against redis 5:6.0.14-1. (I wan't certain it was reliable as there are some known flaky tests in python-fakeredis.) However, why the slight change to security-related overflow handling in bitfield fields *on i386 systems* should result in this failure eludes me... :/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#991403: mtools: mcopy fails on arm*, breaks d-i builds
Paul Gevers wrote: > Can you please revert at least the latest upload? We're extremely close > to the release of bullseye, I don't want to see more trouble in d-i > land, we had enough of that this freeze. Sure, will do this tomorrow morning (BST). ACK the comment about new upstreams versions. Alas, this upload was an attempt to address a different regression (which shouldn't have been introduced/uploaded to begin with... ultimately, just underscoring the entire purpose of freezes.) Lesson learned. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#991375: redis: CVE-2021-32761
Package: redis Version: 5:5.0.3-4+deb10u2 X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerability was published for redis. CVE-2021-32761: Integer overflow issues with BITFIELD command on 32-bit systems If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-32761 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32761 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#989245: python3-django needs to depends on libjs-jquery, not only recommend this package
Hi Carsten, > I'd say there is a gap which is difficult to handle in the end by only > pointing and strictly using our more technically packaging policy in > contrary to make the system much as possible user friendly. But o.k., I > see your point and will respect the decision of the package maintainers. Firstly, I totally understand this sentiment. Whilst the close adherence to rules across a large distribution is a net welfare for all manner of reasons I won't belabour here, it would be a cliche to remark that there will always be scenarios where they should not apply. Indeed, I am sure you could fill a handsome book with famous quotes to this effect. > > This is all to say that given that your custom patchy2 package calls > > collectstatic during its own package configuration stage, would it not > > make more sense to specify libjs-query as a Depends on your package > > instead? > > Our application has no dependency on libjs-jquery so adding a direct > dependency to this package wouldn't be the correct thing to me. However, I don't believe this statement is entirely accurate. Your application calls "collectstatic" during it's postinst script in order to collate all of the assets for a kind of "web runtime", so in a certain sense then, your package *does* have a dependency on libjs-jquery that none of the Django-related packages in Debian has -- at the very least, none of them call "collectstatic". It us thus your package thus warrants the Depends-level relation, not any of the others. (Or alternatively, as you write, through your configuration management system.) I would gladly concede that this is a subjective judgement coached in technical language. Anyway, thanks for your reply and for closing the bug. And, circling back to my remarks above about not being overly wedded to rules, I am very happy to re-explore this in the future if it comes up repeatedly for others. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#989394: python-django: CVE-2021-33203 & CVE-2021-33571
Package: python-django Version: 1:1.11.29-1~deb10u1 X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerabilities were published for python-django. * CVE-2021-33203: Potential directory traversal via admindocs Staff members could use the admindocs TemplateDetailView view to check the existence of arbitrary files. Additionally, if (and only if) the default admindocs templates have been customized by the developers to also expose the file contents, then not only the existence but also the file contents would have been exposed. As a mitigation, path sanitation is now applied and only files within the template root directories can be loaded. This issue has low severity, according to the Django security policy. Thanks to Rasmus Lerchedahl Petersen and Rasmus Wriedt Larsen from the CodeQL Python team for the report. * CVE-2021-33571: Possible indeterminate SSRF, RFI, and LFI attacks since validators accepted leading zeros in IPv4 addresses URLValidator, validate_ipv4_address(), and validate_ipv46_address() didn't prohibit leading zeros in octal literals. If you used such values you could suffer from indeterminate SSRF, RFI, and LFI attacks. validate_ipv4_address() and validate_ipv46_address() validators were not affected on Python 3.9.5+. This issue has medium severity, according to the Django security policy. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: https://www.djangoproject.com/weblog/2021/jun/02/security-releases/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#989351: redis: CVE-2021-32625
Package: redis Version: 5:6.0.11-1 X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerability was published for redis. CVE-2021-32625 [0] If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-32625 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32625 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#989245: python3-django needs to depends on libjs-jquery, not only recommend this package
Hi Carsten,
> FileNotFoundError: [Errno 2] No such file or directory:
> '/usr/lib/python3/dist-packages/django/contrib/admin/static/admin/js/vendor/jquery/jquery.js'
[..]
> So looking around for the missing file indeed I see this isn't there.
> Looking at the python3-django package I can see that the package
> libjs-jquery isn't a hard dependency and only recommended.
So I'm pretty much just paraphrasing the definition of the Depends
field here (hence why there is no explicit note in the Django
packaging itself), but the libjs-jquery package is not required to
provide a significant amount of functionality in Django. Needless to
say, the python3-django package can be installed without libjs-jquery
being installed.
This is all to say that given that your custom patchy2 package calls
collectstatic during its own package configuration stage, would it not
make more sense to specify libjs-query as a Depends on your package
instead?
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org chris-lamb.co.uk
`-
Bug#988136: python-django: CVE-2021-32052
Package: python-django Version: 1:1.10.7-2+deb9u13 X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerability was published for python-django. CVE-2021-32052: Header injection possibility since URLValidator accepted newlines in input on Python 3.9.5+ On Python 3.9.5+, URLValidator didn't prohibit newlines and tabs. If you used values with newlines in HTTP response, you could suffer from header injection attacks. Django itself wasn't vulnerable because HttpResponse prohibits newlines in HTTP headers. Moreover, the URLField form field which uses URLValidator silently removes newlines and tabs on Python 3.9.5+, so the possibility of newlines entering your data only existed if you are using this validator outside of the form fields. This issue was introduced by the bpo-43882 fix. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: https://www.djangoproject.com/weblog/2021/may/06/security-releases/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#988053: python-django: CVE-2021-31542
Package: python-django Version: 1:1.10.7-2+deb9u12 X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerability was published for python-django. CVE-2021-31542[0][1]: Potential directory-traversal via uploaded files If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-31542 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-31542 [1] https://www.djangoproject.com/weblog/2021/may/04/security-releases/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#988045: redis: CVE-2021-29477 & CVE-2021-29478
Package: redis Version: 3:3.2.6-3+deb9u3 X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerabilities were published for redis. CVE-2021-29477[0]: Vulnerability in the STRALGO LCS command CVE-2021-29478[1]: Vulnerability in the COPY command for large intsets If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-29477 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-29477 [1] https://security-tracker.debian.org/tracker/CVE-2021-29478 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-29478 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#986447: python-django: CVE-2021-28658
Package: python-django Version: 1.7.11-1+deb8u11 X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerability was published for python-django. CVE-2021-28658[0][1]: MultiPartParser allowed directory-traversal via uploaded files with suitably crafted file names. Built-in upload handlers were not affected by this vulnerability. This affects all versions in Debian, including 1.7.11-1+deb8u11 in jessie ELTS. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-28658 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-28658 [1] https://www.djangoproject.com/weblog/2021/apr/06/security-releases/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#983090: python-django: CVE-2021-23336
Hi, > > ACK. Have filed #983526 for this purpose. > > Can you please add as well the fixes for the other open issues? This was done on Feb 26th: https://bugs.debian.org/983526#22 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#983446: redis: CVE-2021-21309
Hi Moritz, > given that this only affects 32 bit archs and only with an inherently insecure > setup (opening up the default bulk size to such high values might impact all > kinds of stability / availability I guess) I don't think this needs a DSA. > So s-p-u or piggybacking with the next DSA seems fine to me. Sure thing. I've filed this as #983527. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#983090: python-django: CVE-2021-23336
Sébastien Delafond wrote: > > > Django is vulnerable because it embeds parse_qsl: > > > > > > https://www.djangoproject.com/weblog/2021/feb/19/security-releases/ > > > > Security team, let me know if you would like an update for stable. […] > we think this should rather go via s-p-u. ACK. Have filed #983526 for this purpose. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#983446: redis: CVE-2021-21309
Chris Lamb wrote: > Package: redis > Version: 3:3.2.6-3+deb9u3 [..] > CVE-2021-21309: > https://groups.google.com/g/redis-db/c/fV7cI3GSgoQ/m/ocwV-MlzAgAJ Security team, would you like an upload to stretch-security or should this go via s-p-u? I mention that option specifically as the s-p-u route might permit us to go from 5.0.3 → 5.0.11, fixing a number of other fairly high priority bugs as well. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#983446: redis: CVE-2021-21309
Package: redis Version: 3:3.2.6-3+deb9u3 X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerability was published for redis. CVE-2021-21309: https://groups.google.com/g/redis-db/c/fV7cI3GSgoQ/m/ocwV-MlzAgAJ If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-21309 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-21309 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#983090: python-django: CVE-2021-23336
Chris Lamb wrote:
> The following vulnerability was published for python-django.
[…]
>
> Django is vulnerable because it embeds parse_qsl:
>
> https://www.djangoproject.com/weblog/2021/feb/19/security-releases/
Security team, let me know if you would like an update for stable.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org chris-lamb.co.uk
`-
Bug#983090: python-django: CVE-2021-23336
Package: python-django Version: 1:1.10.7-2+deb9u10 X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerability was published for python-django. CVE-2021-23336[0]: | The package python/cpython from 0 and before 3.6.13, from 3.7.0 and | before 3.7.10, from 3.8.0 and before 3.8.8, from 3.9.0 and before | 3.9.2 are vulnerable to Web Cache Poisoning via urllib.parse.parse_qsl | and urllib.parse.parse_qs by using a vector called parameter cloaking. | When the attacker can separate query parameters using a semicolon (;), | they can cause a difference in the interpretation of the request | between the proxy (running with default configuration) and the server. | This can result in malicious requests being cached as completely safe | ones, as the proxy would usually not see the semicolon as a separator, | and therefore would not include it in a cache key of an unkeyed | parameter. Django is vulnerable because it embeds parse_qsl: https://www.djangoproject.com/weblog/2021/feb/19/security-releases/ If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-23336 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-23336 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#982122: redis: experimental package OOMs s390x buildds
Hi Adam,
> Ah, indeed, the failure mode means that the log never made it to
> buildd.d.o.
Curious, not heard of that failure mode — is there someplace I can
learn about that? No worries if not.
> I've attached a copy of the log from zani.
Ah, thanks. Unfortunately, it does not point us straight to the
solution. I note that you titled this bug "package OOMs" — I point
this out because the "OOM" text the log is actually the name of the
test. As in, here is tests/integration/corrupt-dump.tcl:
447 test {corrupt payload: OOM in rdbGenericLoadStringObject} {
448 start_server [list overrides [list loglevel verbose use-exit-on-panic
yes crash-memcheck-enabled no] ] {
449 r config set sanitize-dump-payload no
450 catch { r RESTORE x 0 "\x0A\x81\x7F\xFF\xFF\xFF\xFF\xFF\xFF\xFF […]
451 assert_match "*Bad data format*" $err
452 r ping
453 }
454 }
Do we have confirmation somewhere that the build is actually OOMing,
rather than it just timing out on a test that was designed to test
*for* an OOM condition. This OOM-related bug *should* be fixed by
virtue of them adding the test to begin with (!) but if we can show
that it is still OOMing, I suspect that upstream will be able to
address it quickly.
If it helps, this test was added in this commit:
https://github.com/antirez/redis/commit/7ca00d694d44be13a3ff9ff1c96b49222ac9463b
... which was in:
$ git tag --contains 7ca00d694d44be13a3ff9ff1c96b49222ac9463b
6.2-rc1
6.2-rc2
6.2-rc3
Not sure if previous s390x builds were failing, which might be another
route to fixing this.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org chris-lamb.co.uk
`-
Bug#982122: redis: experimental package OOMs s390x buildds
Hi Adam, > Both s390x buildds hit OOM conditions while attempting to build redis > 6.2 in experimental. > > The log from zani ends with: > > [..] Thanks. I can't seem to find the full log anywhere thoug; can you help? I might need that before I can raise it with upstream. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#981562: python-django: CVE-2021-3281
Package: python-django Version: 1.7.11-1+deb8u10 X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerability was published for python-django: CVE-2021-3281[0] https://www.djangoproject.com/weblog/2021/feb/01/security-releases/ At a first glance, all of jessie, stretch, buster, bullseye, sid and experimental are vulnerable. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-3281 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3281 Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#979843: python-django: autopkgtest regression in testing: 'image/vnd.mozilla.apng' != 'image/png'
Hi Paul, > sorry, I missed the follow up somehow. Mea culpa Oh, not at all! Thank you for working on the autopkgtest stuff and handling all the replies from these RC bugs. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#979843: python-django: autopkgtest regression in testing: 'image/vnd.mozilla.apng' != 'image/png'
Hi Sandro,
> > This appears to be returning the correct result. Has another mimetype-
> > related package been updated recently? I can't seem to locate one.
>
> yup, it was fixed in
> https://packages.qa.debian.org/m/media-types/news/20210107T225251Z.html
Ah, thanks for the reference. Closing this bug...
Best wishes,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org chris-lamb.co.uk
`-
Bug#979843: python-django: autopkgtest regression in testing: 'image/vnd.mozilla.apng' != 'image/png'
Hi Paul et al.,
> With a recent in testing the autopkgtest of your package started to
> fail. I copied some of the output at the bottom of this report. Can you
> please investigate the situation and fix it?
Hm, I can't seem to reproduce this failing test:
$ dpkg-parsechangelog | grep Version
Version: 2:2.2.17-2
$ LC_ALL=C.UTF-8 PYTHONPATH=. python3 tests/runtests.py --verbosity 2
mail.tests.MailTests.test_attach_file
Testing against Django installed in
'/home/lamby/git/debian/python-team/modules/python-django/django' with up to 8
processes
Importing application mail
Skipping setup of unused database(s): default, other.
System check identified no issues (0 silenced).
test_attach_file (mail.tests.MailTests)
Test attaching a file against different mimetypes and make sure that ... ok
--
Ran 1 test in 0.017s
Still, we can dig in a bit more:
> AssertionError: 'image/vnd.mozilla.apng' != 'image/png'
> - image/vnd.mozilla.apng
> + image/png
ie. it is expecting "image/png" but gets "image/vnd.mozilla.apng" when
guessing the mimetype of a file called "image.png". A minimal testcase
of this is as follows, I think:
$ python3 -c "import mimetypes; print(mimetypes.guess_type('file.png'))"
('image/png', None)
This appears to be returning the correct result. Has another mimetype-
related package been updated recently? I can't seem to locate one.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org chris-lamb.co.uk
`-
Bug#978263: marked as pending in python-django
Control: tag -1 pending Hello, Bug #978263 in python-django reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-django/-/commit/f9148319aa6420126a6ed7883c5d40a04a56f949 Fix compatibility with xgettext 0.21. (Closes: #978263) (this message was generated automatically) -- Greetings https://bugs.debian.org/978263
Bug#975372: minidlna: "rm: cannot remove '/var/log/minidlna': Is a directory" on purge
Source: minidlna Version: 1.2.1+dfsg-2 Severity: serious Tags: patch Hi, Purging the package currently fails with the following error: Purging configuration files for minidlna (1.2.1+dfsg-2) ... rm: cannot remove '/var/log/minidlna': Is a directory dpkg: error processing package minidlna (--purge): installed minidlna package post-removal script subprocess returned error exit status 1 Errors were encountered while processing: minidlna E: Sub-process /usr/bin/dpkg returned an error code (1) Patch attached. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-diff --git a/debian/minidlna.postrm b/debian/minidlna.postrm index 0e9114d..5cde64c 100644 --- a/debian/minidlna.postrm +++ b/debian/minidlna.postrm @@ -5,8 +5,8 @@ set -e case "$1" in purge) - rm -rf /var/cache/minidlna -rm -f /var/log/minidlna.log* /var/log/minidlna + rm -rf /var/cache/minidlna /var/log/minidlna +rm -f /var/log/minidlna.log* ;; remove|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear)
Bug#972519: black and #972519
Hi Diane, > Think it would be reasonable for me to to push this patch and make a > new team release? Ah, I had not noticed it had dropped out of testing. Yes, please go ahead. Kind regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#972518: marked as pending in diffoscope
Control: tag -1 pending Hello, Bug #972518 in diffoscope reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/reproducible-builds/diffoscope/-/commit/0be160534f11500780beb32a7841c195fd95c92e Update tests to support 4.11.1. (Closes: #972518) (this message was generated automatically) -- Greetings https://bugs.debian.org/972518
Bug#971418: jhbuild: Missing dependency on python3-distuils
Hi Simon, > > Patch attached (although it might mean some Python substvar apparatus > > is not working as expected). > > I don't think it's expected to work automatically in this case: I think > hard-coding the dependency, as in your patch, is likely to be the only > solution. Sounds eminently reasonable — I should have added more of a "I have not checked this is the case at all, just throwing it out there just in case it rings a bell" spin to my comment. I would agree wholeheartedly with your later sentiments regarding the reliability of said mechanism. -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#971418: jhbuild: Missing dependency on python3-distuils
Package: jhbuild
Version: 3.38.0-1
Severity: serious
Tags: patch
Hi,
This package is missing a binary dependency on python3-distutils:
$ jhbuild
Traceback (most recent call last):
File "/usr/bin/jhbuild", line 29, in
import jhbuild.main
File "/usr/lib/python3/dist-packages/jhbuild/main.py", line 28, in
import jhbuild.config
File "/usr/lib/python3/dist-packages/jhbuild/config.py", line 31, in
from jhbuild.environment import setup_env, setup_env_defaults, addpath
File "/usr/lib/python3/dist-packages/jhbuild/environment.py", line 24, in
from distutils.sysconfig import get_python_lib
ModuleNotFoundError: No module named 'distutils.sysconfig'
Installing python3-distutils resolves this issue.
Patch attached (although it might mean some Python substvar apparatus
is not working as expected).
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-diff --git a/debian/control b/debian/control
index e7a8882..7d18b97 100644
--- a/debian/control
+++ b/debian/control
@@ -22,7 +22,8 @@ Package: jhbuild
Architecture: all
Depends: ${shlibs:Depends},
${misc:Depends},
- ${python3:Depends}
+ ${python3:Depends},
+python3-distuils,
Recommends: git-core,
patch,
wget | curl,
Bug#971131: diffoscope: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.8 returned exit code 13
forcemerge 970901 971131 affects 971131 diffoscope thanks > Source: diffoscope > Version: 160 > Severity: serious > Justification: FTBFS on amd64 […] > > File "", line 219, in > > _call_with_frames_removed > > File "/usr/lib/python3/dist-packages/black/__init__.py", line 65, in > > > > from _black_version import version as __version__ > > ModuleNotFoundError: No module named '_black_version' This is #970901 in black. I actually provided a patch for this issue a few days ago, but no response from the maintainer yet. -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#970901: black: cannot run, "ModuleNotFoundError: No module named '_black_version'"
tags 970901 + patch
thanks
Hi,
> black: cannot run, "ModuleNotFoundError: No module named '_black_version'"
The following patch works for me, but there is likely a cleaner
solution; seems like the Black package maintainers are doing special
things with the version handling and I am missing some nuance.
--- a/debian/rules
+++ b/debian/rules
@@ -16,6 +16,8 @@ export VERSION=$(shell dpkg-parsechangelog -S Version|cut
-d- -f1)
%:
echo "version = '$(VERSION)'" > _black_version.py
+ mkdir -p src
+ cp _black_version.py src/
dh $@ --with sphinxdoc,python3 --buildsystem=pybuild
override_dh_auto_build:
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org / chris-lamb.co.uk
`-diff --git a/debian/rules b/debian/rules
index 09908f4..1a70969 100755
--- a/debian/rules
+++ b/debian/rules
@@ -16,6 +16,8 @@ export VERSION=$(shell dpkg-parsechangelog -S Version|cut -d-
-f1)
%:
echo "version = '$(VERSION)'" > _black_version.py
+ mkdir -p src
+ cp _black_version.py src/
dh $@ --with sphinxdoc,python3 --buildsystem=pybuild
override_dh_auto_build:
Bug#969753: marked as pending in diffoscope
Control: tag -1 pending Hello, Bug #969753 in diffoscope reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/reproducible-builds/diffoscope/-/commit/4d60897d512e032a89e3bf4c25076454de6a2b17 Mark some PGP tests that they require pgpdump. Thanks to Gianfranco Costamagna (locutusofborg). (Closes: #969753) (this message was generated automatically) -- Greetings https://bugs.debian.org/969753
Bug#969753: diffoscope: autopkgtest failures
Hi Gianfranco,
> Hello, autopkgtests looks sad, pytest-with-recommends works, while
> pytest doesn't, because of missing pgpdump
>
> I did add some @skip_unless_tools_exist("pgpdump") around the failing
> tests (attached the diff), however I don't know
> if this is the right solution, or something better has to be
> implemented.
Thanks. Adding the decorator in test_pgp.py looks fine at a first
glance, but needing PGP support to diff two directories (!) is a
symptom of a deeper problem with pgpdump integration.
Will investigate.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org chris-lamb.co.uk
`-
Bug#969367: python-django: CVE-2020-24583 CVE-2020-24584
Package: python-django Version: 1:1.10.7-2+deb9u9 X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, The following vulnerabilities were published for python-django. CVE-2020-24583 CVE-2020-24584 If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2020-24583 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24583 [1] https://security-tracker.debian.org/tracker/CVE-2020-24584 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24584 [2] https://www.djangoproject.com/weblog/2020/sep/01/security-releases/ Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#922129: filemanager-actions: Incomplete debian/copyright?
Hi darkdragon, > > I just ACCEPTed filemanager-actions from NEW but noticed it was > > missing attribution in debian/copyright for at least Red Hat, Novell, > > etc. > > Can you please clarify the problem upstream in > https://gitlab.gnome.org/GNOME/filemanager-actions/-/issues/17 ? Two quick things: * You say: "filemanager-actions has been removed from Debian/Ubuntu because of incomplete license/copyright information". This is not really true. The package was removed for reasons listed in #961824 as far as I can tell; ie. it was unmaintained. * I filed this bug (#922129) due to an incomplete debian/copyright file. In other words, the file under the debian/ subdirectory, and not something that upstream could clarify. This might be why they are confused. I am no longer a member of the ftpmaster team, so I won't be able to help you any further. Good luck... Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#968124: diffoscope: FTBFS with fpc 3.2.0
tags 968124 + pending thanks Hi Graham, > As can be seen on reproducible builds [1], this package FTBFS since > the upload of fpc 3.2.0+dfsg-5 to unstable. Thanks, very useful bug report. I've fixed this in: https://salsa.debian.org/reproducible-builds/diffoscope/commit/d0f0b21559ab162164c25c4b76dcfdeac92b8487 … but also made a few related changes while I was in this rather unloved part of the code (eg. 8ce4515f1). Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#940017: crypto-policies: Incomplete debian/copyright?
Hi John Scott, > On Wednesday, September 11, 2019 4:03:59 AM EDT Chris Lamb wrote: > > > I just ACCEPTed minder from NEW but noticed it was missing attribution > > for at least Tomáš Mráz. > > This bug is against crypto-policies, but it appears you accepted minder too > the same day. Did you mean to file this against minder? It is possible, but it was so long ago now that I could not say either way. Please use your best judgement, and sorry I could not be of more help. Best wishes, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#962323: python-django: CVE-2020-13254 CVE-2020-13596
Hi Sébastien, > They look fine, please upload to security-master. Done. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#962158: lintian: New very problematic --fail-on default value
Chris Lamb wrote: > I'd like to perform another Lintian release but for various reasons > I'd prefer to have this issue addressed before doing another upload. Just to be 100% explicit here, I don't feel I can cut a new release until this bug is resolved. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
Bug#962323: python-django: CVE-2020-13254 CVE-2020-13596
Chris Lamb wrote: > The full debdiffs are attached. Can you especially check the > versioning scheme and distribution fields for me? I often get this > wrong and end up confusing myself. Really appreciated. They are now attached. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-diff --git a/debian/changelog b/debian/changelog index a84d1b261..f18eaf3ed 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,20 @@ +python-django (1:1.10.7-2+deb9u9) stretch-security; urgency=high + + * CVE-2020-13254: Potential a data leakage via malformed memcached keys. + +In cases where a memcached backend does not perform key validation, passing +malformed cache keys could result in a key collision, and potential data +leakage. In order to avoid this vulnerability, key validation is added to +the memcached cache backends. + + * CVE-2020-13596: Possible XSS via admin ForeignKeyRawIdWidget. + +Query parameters to the admin ForeignKeyRawIdWidget were not properly URL +encoded, posing an XSS attack vector. ForeignKeyRawIdWidget now ensures +query parameters are correctly URL encoded. + + -- Chris Lamb Sat, 13 Jun 2020 15:47:14 +0100 + python-django (1:1.10.7-2+deb9u8) stretch-security; urgency=high * CVE-2020-7471: Prevent a Potential SQL injection via StringAgg(delimiter). diff --git a/debian/patches/0027-CVE-2020-13254.patch b/debian/patches/0027-CVE-2020-13254.patch new file mode 100644 index 0..e2e03f982 --- /dev/null +++ b/debian/patches/0027-CVE-2020-13254.patch @@ -0,0 +1,177 @@ +From: Chris Lamb +Date: Sat, 13 Jun 2020 15:31:18 +0100 +Subject: CVE-2020-13254 + +--- + django/core/cache/__init__.py | 4 ++-- + django/core/cache/backends/base.py | 33 + + django/core/cache/backends/memcached.py | 24 ++-- + 3 files changed, 45 insertions(+), 16 deletions(-) + +diff --git a/django/core/cache/__init__.py b/django/core/cache/__init__.py +index 26897ff..dc377a9 100644 +--- a/django/core/cache/__init__.py b/django/core/cache/__init__.py +@@ -17,13 +17,13 @@ from threading import local + from django.conf import settings + from django.core import signals + from django.core.cache.backends.base import ( +-BaseCache, CacheKeyWarning, InvalidCacheBackendError, ++BaseCache, CacheKeyWarning, InvalidCacheBackendError, InvalidCacheKey, + ) + from django.utils.module_loading import import_string + + __all__ = [ + 'cache', 'DEFAULT_CACHE_ALIAS', 'InvalidCacheBackendError', +-'CacheKeyWarning', 'BaseCache', ++'CacheKeyWarning', 'BaseCache', 'InvalidCacheKey', + ] + + DEFAULT_CACHE_ALIAS = 'default' +diff --git a/django/core/cache/backends/base.py b/django/core/cache/backends/base.py +index a07a34e..688ffb8 100644 +--- a/django/core/cache/backends/base.py b/django/core/cache/backends/base.py +@@ -24,6 +24,10 @@ DEFAULT_TIMEOUT = object() + MEMCACHE_MAX_KEY_LENGTH = 250 + + ++class InvalidCacheKey(ValueError): ++pass ++ ++ + def default_key_func(key, key_prefix, version): + """ + Default function to generate keys. +@@ -233,18 +237,8 @@ class BaseCache(object): + backend. This encourages (but does not force) writing backend-portable + cache code. + """ +-if len(key) > MEMCACHE_MAX_KEY_LENGTH: +-warnings.warn( +-'Cache key will cause errors if used with memcached: %r ' +-'(longer than %s)' % (key, MEMCACHE_MAX_KEY_LENGTH), CacheKeyWarning +-) +-for char in key: +-if ord(char) < 33 or ord(char) == 127: +-warnings.warn( +-'Cache key contains characters that will cause errors if ' +-'used with memcached: %r' % key, CacheKeyWarning +-) +-break ++for warning in memcache_key_warnings(key): ++warnings.warn(warning, CacheKeyWarning) + + def incr_version(self, key, delta=1, version=None): + """Adds delta to the cache version for the supplied key. Returns the +@@ -270,3 +264,18 @@ class BaseCache(object): + def close(self, **kwargs): + """Close the cache connection""" + pass ++ ++ ++def memcache_key_warnings(key): ++if len(key) > MEMCACHE_MAX_KEY_LENGTH: ++yield ( ++'Cache key will cause errors if used with memcached: %r ' ++'(longer than %s)' % (key, MEMCACHE_MAX_KEY_LENGTH) ++) ++for char in key: ++if ord(char) < 33 or ord(char) == 127: ++yield ( ++'Cache key contains characters that will cause errors if ' ++'used with memcached: %r' % key, ++) ++break +diff --git a/django/core/cache/backends/memcached.py b/django/core/cache/backends/memcached.py
Bug#962323: python-django: CVE-2020-13254 CVE-2020-13596
Chris Lamb wrote:
> I will wait a few days to see what upstream says. I will also have to
> re-release for jessie LTS, alas.
Okay, this is now fixed in the following versions (without and with
the regression fix):
DistributionUpload with regressionUpload with regression fixed
jessie 1.7.11-1+deb8u9 1.7.11-1+deb8u10
stretch n/a 1:1.10.7-2+deb9u9 (pending)
buster n/a 1:1.11.29-1~deb10u1 (pending)
unstable2:2.2.13-12:2.2.13-2
experimental2:3.0.7-1 2:3.0.7-2
The two pending uploads (ie. needing your approval) to upload are:
python-django (1:1.10.7-2+deb9u9) stretch-security; urgency=high
* CVE-2020-13254: Potential a data leakage via malformed memcached keys.
In cases where a memcached backend does not perform key validation,
passing
malformed cache keys could result in a key collision, and potential data
leakage. In order to avoid this vulnerability, key validation is added to
the memcached cache backends.
* CVE-2020-13596: Possible XSS via admin ForeignKeyRawIdWidget.
Query parameters to the admin ForeignKeyRawIdWidget were not properly URL
encoded, posing an XSS attack vector. ForeignKeyRawIdWidget now ensures
query parameters are correctly URL encoded.
-- Chris Lamb Sat, 13 Jun 2020 15:47:14 +0100
and
python-django (1:1.11.29-1~deb10u1) buster-security; urgency=high
* New upstream security release (postponed from March 2020):
- CVE-2020-9402: Potential SQL injection via tolerance parameter in GIS
functions and aggregates on Oracle
Note that Django 1.11.x left upstream's extended security support on
April
1st 2020. For more information, please see:
https://www.djangoproject.com/download/
* This upload also fixes the following security issues:
- CVE-2020-13254: Potential a data leakage via malformed memcached keys.
In cases where a memcached backend does not perform key validation,
passing malformed cache keys could result in a key collision, and
potential data leakage. In order to avoid this vulnerability, key
validation is added to the memcached cache backends.
- CVE-2020-13596: Possible XSS via admin ForeignKeyRawIdWidget.
Query parameters to the admin ForeignKeyRawIdWidget were not properly
URL
encoded, posing an XSS attack vector. ForeignKeyRawIdWidget now
ensures
query parameters are correctly URL encoded.
-- Chris Lamb Sun, 14 Jun 2020 12:15:26 +0100
The full debdiffs are attached. Can you especially check the
versioning scheme and distribution fields for me? I often get this
wrong and end up confusing myself. Really appreciated.
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` la...@debian.org chris-lamb.co.uk
`-
Bug#962158: lintian: New very problematic --fail-on default value
Felix Lechner wrote: > It would also give me more time to understand the possibly > unreasonable burden on Lintian users across Debian and the derivative > ecosystem. Simon may receive feedback from Ubuntu, a significant > derivative. If there are real problems, I am happy to discuss a > solution that reverts the default to Lintian's old setting. Without rehashing the details here, if Ubuntu's CI would prefer a different exit code, it would seem more sensible to keep the default the same and ask Ubuntu to specify a different --fail-on=. That would appear to limit require one change (and potential "fallout") to one place, and indeed in a place that has the ability to be changed. > Now the best course of action, I think, is to downgrade the severity > again to Guillem's original setting of 'important'. That will allow > the change to remain in testing. It is, after all, what the testing > distribution is for. Ah, yeah, I had forgotten about autoremovals. Sigh. > At the same time, the change was widely released two weeks ago. Simon > Quigley from Ubuntu announced it on debian-devel on May 25 [1], while > I advertised the change repeatedly on IRC and added a note to DevNews. Just as an aside, it feels like a slight stretch to assume that every Lintian user reads debian-devel, lurks on IRC or can be expected to come across this in another way. In the event that this default change stays, using the NEWS mechanism might be appropriate to explain concisely and exactly what a user may need to change (eg. "if you were relying on X, you should do Y".) We should also consider bumping the major version number of Lintian itself if we are strictly following the semver.org versioning scheme. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org chris-lamb.co.uk `-
