Bug#704528: Please include new resolvconf hook script which handles multiple postfix instances
On Tue, 23 May 2017 01:39:54 -0400 Scott Kitterman wrote: > On Tue, 2 Apr 2013 15:32:44 +0200 Thomas Hood wrote: > > Package: postfix > > Version: 2.9.6-2 > > Severity: wishlist > > Tags: patch > > > > Attached is a new resolvconf update hook script > > (/etc/resolvconf/update-libc.d/postfix) which handles multiple postfix > > instances. Please include it instead of the existing script. > > > > Thanks to Patrik Båt for writing this. > > I think that as of 3.1.4-5, this is not needed any longer when using the > default init system. Please check and let us know if you think differently. > > Scott K I think 7 years is long enough to wait, so closing. If this is still an issue, please file a new bug with current information. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1074759: O: aiodns -- Asynchronous DNS resolver library for Python 3
Package: wnpp Severity: normal X-Debbugs-Cc: aio...@packages.debian.org, debian-pyt...@lists.debian.org Control: affects -1 + src:aiodns I intend to orphan the aiodns package. The package description is: aiodns provides a simple way for doing asynchronous DNS resolutions with a synchronous looking interface, using pycares. I am no longer interested in maintaining this package and the other theorectical uploader is long inactive. Scott K
Bug#1074758: O: pycares -- Python interface for c-ares (common documentation)
Package: wnpp Severity: normal X-Debbugs-Cc: pyca...@packages.debian.org, debian-pyt...@lists.debian.org Control: affects -1 + src:pycares I intend to orphan the pycares package. The package description is: pycares is a Python 3 module which provides an interface to c-ares. c-ares is a C library that performs DNS requests and name resolutions asynchronously. I no longer have interest in maintaining it and the other theorectical uploader is long inactive. Scott K
Bug#1073869: RM: python-zxcvbn -- ROM; Unmaintained, depends on obsolete libs
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: python-zxc...@packages.debian.org, team-pyt...@tracker.debian.org Control: affects -1 + src:python-zxcvbn This depends on pypdf2 which has been removed from Testing and will be removed from the archive. It appears unmaintained both in Debian and upstream. Scott K
Bug#1070718: ITP: python-gfloat -- Python module of generic floating point encode/decode logic
Package: wnpp
Severity: wishlist
Owner: Scott Kitterman
X-Debbugs-Cc: debian-de...@lists.debian.org
* Package name: python-gfloat
Version : 0.1
Upstream Contact: Andrew Fitzgibbon
* URL : https://github.com/graphcore-research/gfloat
* License : Expat
Programming Lang: Python
Description : Python module of generic floating point encode/decode logic
An implementation of generic floating point encode/decode logic, handling
various current and proposed floating point types:
.
- IEEE 754: Binary16, Binary32
- OCP Float8: E5M2, E4M3
- IEEE WG P3109: P{p} for p in 1..7
- OCP MX Formats: E2M1, M2M3, E3M2, E8M0, INT8, and the MX block formats.
.
The library favours readability and extensibility over speed - for fast
implementations of these datatypes see, for example, ml_dtypes, bitstring, MX
PyTorch Emulation Library.
I intend to maintain this as part of the Debian Python Team. It's
needed to run tests for the newest version of python-bitstring.
Scott K
Bug#1070638: kde-spectacle: Build-depends on NBS libkcolorpicker-dev
On Mon, 06 May 2024 10:33:54 -0400 Scott Kitterman wrote: > Source: kde-spectacle > Version: 22.12.3-1 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) > > Once kcolorpicker is decrufted, this package will FTBFS. Please update > your build-depends. Also libkimageannotator-dev needs updating. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1070638: kde-spectacle: Build-depends on NBS libkcolorpicker-dev
Source: kde-spectacle Version: 22.12.3-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Once kcolorpicker is decrufted, this package will FTBFS. Please update your build-depends. Scott K
Bug#1070116: python-zeep: Build-depends on NBS libraries libxmlsec1 and libxmlsec1-openssl
Source: python-zeep Version: 4.2.1-1 Severity: serious Tags: ftbfs Justification: fails to build from source Once xmlsec1 is decrufted, python-zeep will FTBFS. The build-depends need to be updated to libxmlsec1t64 and libxmlsec1t64-openssl. Scott K
Bug#1070062: waylandpp: Missing build-depends libwayland-egl1-mesa
Source: waylandpp Version: 1.0.0-4 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) The libwayland-egl1-mesa package was a transitional package for libegl1 and libwayland-egl1 and has been removed. You will need to update your build-depends appropriately. Scott K
Bug#1069986: dublin-traceroute: Manual build-depends on NBS package libtins4.0
Source: dublin-traceroute Version: 0.4.2-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) The package has a manual build-depends on libtins4.0, which is NBS. It has been renamed libtins4.5. Once it is decrufted, this package will FTBFS. Scott K
Bug#1069985: python-cobra: Manual build-depends on NBS package libsbml5
Source: python-cobra Version: 0.26.2-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) The package build-depends on the NBS package libsbml5. It has been renamed libsbml5t64. Once the package is decrufted, this one will FTBFS. Please update your build-depends. Scott K
Bug#1069984: alire: Build-depends on NBS package libgnatcoll21-dev
Source: alire Version: 1.2.1-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) The package libgnatcoll21-dev has been renamed to libgnatcoll-dev. Once libgnatcoll21-dev is decfufted, it will FTBFS. Please update your build depends. Scott K
Bug#1069983: dwarf-fortress: Manual build-depends on NBS package libgtk2.0-0
Source: dwarf-fortress Version: 0.47.04+dfsg1-1 Severity: serious Tags: ftbfs Justification: fails to build from source The package has a manual build-depends on libgtk2.0-0, which has been replaced by libgtk2.0-0t64. Once it has been decrufted, the package will no longer build. Scott K
Bug#1069982: theli: Manual build-depends on NBS package libcurl4
Source: theli Version: 3.1.4-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Once libcurl4 is decrufted, the package will no longer build. The libcurl4 package has been replaced by libcurl4t64. Scott K
Bug#1069963: python-nbxmpp: Build-depends on NBS package libglib2.0-0
Source: python-nbxmpp Version: 4.5.4-1 Severity: serious Tags: ftbfs Justification: fails to build from source This package has a hard coded build-depends on libglib2.0-0, which is NBS and the package will FTBFS once it is decrufted. It was renamed libglib2.0-0t64 as part of the 64 bit time transition. Please update your build-depends. Scott K
Bug#1069004: casacore-data-services: Hard coded build-depends on decrufted lib libcasa-meas7
Package: casacore-data-services Version: 2-4 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Will now FTBFS due to missing build-depends. Scott K
Bug#1065623: reverse dependencies
On Mon, 25 Mar 2024 18:48:44 + (UTC) Thorsten Alteholz wrote: > Control: tags -1 + moreinfo > > Hi, > > there are reverse dependencies that need to be taken care of: > > > Checking reverse dependencies... > # Broken Depends: > baresip: baresip-x11 > > # Broken Build-Depends: > baresip: libomxil-bellagio-dev > kodi: libomxil-bellagio-dev > vlc: libomxil-bellagio-dev > > > In case they matter, this needs to be addressed first. Please remove the > moreinfo tag once that is done. > >Thorsten Baresip is not resolved in Unstable. Please don't remove the moreinfo tag again until ALL the rdepends are taken care of. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1063772: postfix-mysql upgrade add map in dynamicmaps.cf after postfix restart
The next postfix upload to unstable should address this by using a trigger to restart postfix any time one of the map type packages is configured. Scott K
Bug#1029735: pypdf2 is deprecated, please move from python3-pypdf2 to python3-pypdf
On Sun, 21 Jan 2024 12:09:30 -0500 Scott Kitterman wrote: > As we approach the first anniversary for this bug, an update: > > I've recently adopted pypdf and pypdf2 into the Debian Python Team in response > to an RFA for both packages. As these are somewhat security sensitive > packages (among my first acts after adopting the packages was to upload > proposed updates for both to address minor security issues in Bookworm in the > next point release - same bug in both), I do not think we should release > pypdf2 in Trixie and have filed an RC bug to that effect. > > If you want this package to be in Trixie, you will need to use pypdf instead > of pypdf2. Now that pypdf2 has been removed from Trixie, bumping to serious. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1029738: pypdf2 is deprecated, please move from python3-pypdf2 to python3-pypdf
On Sun, 21 Jan 2024 12:19:23 -0500 Scott Kitterman wrote: > As we approach the first anniversary for this bug, an update: > > I've recently adopted pypdf and pypdf2 into the Debian Python Team in response > to an RFA for both packages. As these are somewhat security sensitive > packages (among my first acts after adopting the packages was to upload > proposed updates for both to address minor security issues in Bookworm in the > next point release - same bug in both), I do not think we should release > pypdf2 in Trixie and have filed an RC bug to that effect. > > If you want this package to be in Trixie, you will need to use pypdf instead > of pypdf2. Now that pypdf2 is removed from Trixie, bumping to serious. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1061261: odoo: Uses deprecated/to be removed PyPDF2
On Sun, 21 Jan 2024 12:17:53 -0500 Scott Kitterman wrote: > I've recently adopted pypdf and pypdf2 into the Debian Python Team in response to an RFA for both packages. As these are somewhat security sensitive packages (among my first acts after adopting the packages was to upload proposed updates for both to address minor security issues in Bookworm in the next point release - same bug in both), I do not think we should release pypdf2 in Trixie and have filed an RC bug to that effect. > > If you want this package to be in Trixie, you will need to use pypdf instead of pypdf2. Now that pypdf2 is removed from Trixie, updating to serious. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1029734: pypdf2 is deprecated, please move from python3-pypdf2 to python3-pypdf
On Sun, 21 Jan 2024 12:08:35 -0500 Scott Kitterman wrote: > As we approach the first anniversary for this bug, an update: > > I've recently adopted pypdf and pypdf2 into the Debian Python Team in response > to an RFA for both packages. As these are somewhat security sensitive > packages (among my first acts after adopting the packages was to upload > proposed updates for both to address minor security issues in Bookworm in the > next point release - same bug in both), I do not think we should release > pypdf2 in Trixie and have filed an RC bug to that effect. > > If you want this package to be in Trixie, you will need to use pypdf instead > of pypdf2. Now that pypdf2 has been removed from Trixie, bumping to serious. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1029733: pypdf2 is deprecated, please move from python3-pypdf2 to python3-pypdf
On Sun, 21 Jan 2024 12:07:19 -0500 Scott Kitterman wrote: > As we approach the first anniversary for this bug, an update: > > I've recently adopted pypdf and pypdf2 into the Debian Python Team in response > to an RFA for both packages. As these are somewhat security sensitive > packages (among my first acts after adopting the packages was to upload > proposed updates for both to address minor security issues in Bookworm in the > next point release - same bug in both), I do not think we should release > pypdf2 in Trixie and have filed an RC bug to that effect. > > If you want this package to be in Trixie, you will need to use pypdf instead > of pypdf2. Now that pypdf2 is removed from Trixie, bumping to serious. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1061264: ocrmypdf: Uses deprecated/to be removed pypdf2 in autopkgtest
On Sun, 21 Jan 2024 13:14:34 -0500 Scott Kitterman wrote: > Source: ocrmypdf > Version: 15.2.0+dfsg1-1 > Severity: wishlist > > I've recently adopted pypdf and pypdf2 into the Debian Python Team in response to an RFA for both packages. As these are somewhat security sensitive packages (among my first acts after adopting the packages was to upload proposed updates for both to address minor security issues in Bookworm in the next point release - same bug in both), I do not think we should release pypdf2 in Trixie and have filed an RC bug to that effect. > > ocrmypdf uses the package in debian/tests/control. Please update to use > python3-pypdf insteadm. Pypdf2 has been removed from testing, so this is now serious. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1067051: python3-fs: Switch from appdirs to platformdirs
Package: python3-fs Version: 2.4.16-2 Severity: important Python3-fs uses python3-appdirs, which is dead upstream. It is being replaced by python3-platformdirs. As a maintainer of appdirs, I would prefer that we do not release Trixie with appdirs. As far as I can tell, python3-fs is the only critical package that uses it, so if python3-fs were ported to platformdirs, it could be removed. I investigated and it's more than just s/appdirs/platformdirs// for some reason (mostly that is all that's needed to port to platformdirs). Upstream for fs looks pretty dead, so it may be a long wait for an upstream solution. Scott K
Bug#1066838: hplip: Files remain after purge
Package: hplip Version: 3.22.10+dfsg0-2 Severity: important After removing and then purging hplip, the __pycache__ directories remain. # apt purge hplip Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages will be REMOVED: hplip* 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. After this operation, 0 B of additional disk space will be used. Do you want to continue? [Y/n] y (Reading database ... 358577 files and directories currently installed.) Purging configuration files for hplip (3.22.10+dfsg0-2) ... Processing triggers for dbus (1.14.10-1~deb12u1) ... # ls -R /usr/share/hplip/ /usr/share/hplip/: base copier fax installer pcard prnt __pycache__ scan ui5 /usr/share/hplip/base: pexpect __pycache__ /usr/share/hplip/base/pexpect: __pycache__ /usr/share/hplip/base/pexpect/__pycache__: /usr/share/hplip/base/__pycache__: /usr/share/hplip/copier: __pycache__ /usr/share/hplip/copier/__pycache__: /usr/share/hplip/fax: __pycache__ /usr/share/hplip/fax/__pycache__: /usr/share/hplip/installer: __pycache__ /usr/share/hplip/installer/__pycache__: /usr/share/hplip/pcard: __pycache__ /usr/share/hplip/pcard/__pycache__: /usr/share/hplip/prnt: __pycache__ /usr/share/hplip/prnt/__pycache__: /usr/share/hplip/__pycache__: /usr/share/hplip/scan: __pycache__ /usr/share/hplip/scan/__pycache__: /usr/share/hplip/ui5: __pycache__ /usr/share/hplip/ui5/__pycache__: Scott K -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages hplip depends on: ii adduser3.134 ii cups 2.4.2-3+deb12u5 pn hplip-data ii libc6 2.36-9+deb12u4 ii libcups2 2.4.2-3+deb12u5 ii libdbus-1-31.14.10-1~deb12u1 ii libhpmud0 3.22.10+dfsg0-2 ii libpython3.11 3.11.2-6 pn libsane-hpaio ii libsane1 1.2.1-2 ii lsb-base 11.6 ii printer-driver-hpcups 3.22.10+dfsg0-2 ii python33.11.2-1+b1 ii python3-dbus 1.3.2-4+b1 ii python3-gi 3.42.2-3+b1 pn python3-pexpect ii python3-pil9.4.0-1.1+b1 pn python3-reportlab ii sysvinit-utils [lsb-base] 3.06-4 ii wget 1.21.3-1+b2 ii xz-utils 5.4.1-0.2 Versions of packages hplip recommends: ii avahi-daemon 0.8-10 ii policykit-1 122-3 ii printer-driver-postscript-hp 3.22.10+dfsg0-2 ii sane-utils1.2.1-2 Versions of packages hplip suggests: pn hplip-doc pn hplip-gui ii python3-notify20.3-5 ii system-config-printer 1.5.18-1
Bug#1063771: Also needed for aioquic
This is starting to affect a lot of things. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1065312: RM: deborphan -- ROM; missing too many dpkg features, thus broken and unreliable
On March 10, 2024 3:23:32 PM UTC, "Martin-Éric Racine" wrote: >On Sat, 2 Mar 2024 18:40:13 +0100 Chris Hofstaedtler wrote: >> * Christoph Biedl [240302 17:02]: >> > Chris Hofstaedtler wrote... >> > >> > > please remove deborphan. It is stuck, featurewise, in a very old time >> > > and does not support many currently available dpkg features properly >> > > (multi-arch, versioned provides, etc). >> > >> > FWIW, deborphan is part of my regular workflow, and while you claim >> > it has defects, it works for me pretty well. >> >> It works "well" if you use it in very limited usecases, yes (like I >> did). It doesn't seem to work well for a lot of people using more of >> the "features" it has. > >Just because it doesn't work for everyone is not a remotely good >enough reason to ask for its removal. It works for most people. don't >break it for them. > >> The t64 transition will apparently make deborphan mostly useless in >> trixie. >> >> > [..] >> > So: What are the alternatives? How do they work? Are they a drop-in >> > replacment or do they introduce new dependencies? Are there feature that >> > will be no longer supported? >> >> release-notes recommends: >> https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#removing-non-debian-packages > >Which has nothing to do with what was asked. > >> Some people seem to recommend debfoster. > >Which really doesn't provide similar functionality. > >> > Leaving users in the void about this is just bad style. > >I totally agree. Not wanting to maintain it is a shitty reason for >asking for its removal. If you don't wanna maintain is, just orphan >it. It's really a maintainer call if that's appropriate. So far no one has jumped up to ask if they can take over the package. Scott K
Bug#1065158: postfix: FTBFS: missing build-dep on libnsl-dev
On Fri, 01 Mar 2024 11:33:37 +0100 Aurelien Jarno wrote: > Source: postfix > Version: 3.8.5-1 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) > User: debian-gl...@lists.debian.org > Usertags: libnsl-dev > > Dear maintainer, > > Starting with glibc 2.31, support for NIS (libnsl library) has been > moved to a separate libnsl2 package. In order to allow a smooth > transition, a libnsl-dev has been added to the libc6-dev package. > > This dependency has been temporarily dropped in the 2.37-15.1 NMU, as > part of the 64-bit time_t transition. This causes postfix to FTBFS in > sid with: > > | gcc -fPIC -I. -I../../include -DDEBIAN -DHAS_PCRE=2 -DHAS_LDAP - DUSE_LDAP_SASL -DHAS_SQLITE -DMYORIGIN_FROM_FILE -DHAS_CDB -DHAS_LMDB - DHAS_MYSQL -I/usr/include/mysql -DHAS_PGSQL -I/usr/include/postgresql - DHAS_SQLITE -DHAS_SSL -I/usr/include/openssl -DUSE_SASL_AUTH -I/usr/include/ sasl -DUSE_CYRUS_SASL -DUSE_TLS -DHAS_DEV_URANDOM -DDEF_DAEMON_DIR=\"/usr/lib/ postfix/sbin\" -DDEF_HTML_DIR=\"/usr/share/doc/postfix/html\" - DDEF_MANPAGE_DIR=\"/usr/share/man\" -DDEF_README_DIR=\"/usr/share/doc/postfix\" -DUSE_DYNAMIC_LIBS -DUSE_DYNAMIC_MAPS -Wmissing-prototypes -Wformat -Wno- comment -fno-common -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 -U_FORTIFY_SOURCE - D_FORTIFY_SOURCE=3 -g -O2 -ffile-prefix-map=/<>=. -flto=auto -ffat- lto-objects -fstack-protector-strong -fstack-clash-protection -Wformat - Werror=format-security -fcf-protection -flto=auto -ffat-lto-objects -Wl,-z,relro -Wl,-z,now -I. -DLINUX6 -c dict_nis.c > | dict_nis.c:42:10: fatal error: rpcsvc/ypclnt.h: No such file or directory > |42 | #include > | | ^ > | compilation terminated. > | make: *** [Makefile:220: dict_nis.o] Error 1 > | make: *** Waiting for unfinished jobs > | make: Leaving directory '/<>/src/util' > | make[2]: *** [Makefile:114: update] Error 1 > | make[2]: Leaving directory '/<>' > | dh_auto_build: error: make -j3 "INSTALL=install --strip-program=true" returned exit code 2 > | make[1]: *** [debian/rules:90: override_dh_auto_build] Error 25 > | make[1]: Leaving directory '/<>' > | make: *** [debian/rules:63: binary] Error 2 > > This could be fixed by adding an explicit Build-Depends on libnsl-dev. > The glibc change will likely be reverted in the short term, but given > its a change we want to do for Trixie, this will only lower the severity > of the bug. This doesn't currently cause a FTBFS in Testing and it's fixed in Unstable, so lowering severity to important. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1065743: bullseye-pu: package postfix/3.5.24-0+deb11u1
stfix SMTP server response with an empty + authentication failure reason. File: smtpd/smtpd_sasl_glue.c. +- Bugfix (defect introduced: Postfix 3.1, date: 20151128): + "postqueue -j" produced broken JSON when escaping a control + character as \u. Found during code maintenance. File: + postqueue/showq_json.c. +- Cleanup: posttls-finger certificate match expectations for + all TLS security levels, including warnings for levels that + don't implement certificate matching. Viktor Dukhovni. + File: posttls-finger.c. +- Bugfix (defect introduced: Postfix 2.3): after prepending + a message header with a Postfix access table PREPEND action, + a Milter request to delete or update an existing header + could have no effect, or it could target the wrong instance + of an existing header. Root cause: the fix dated 20141018 + for the Postfix Milter client was incomplete. The client + did correctly hide the first, Postfix-generated, Received: + header when sending message header information to a Milter + with the smfi_header() application callback function, but + it was still hiding the first header (instead of the first + Received: header) when handling requests from a Milter to + delete or update an existing header. Problem report by + Carlos Velasco. This change was verified to have no effect + on requests from a Milter to add or insert a header. File: + cleanup/cleanup_milter.c. +- Workaround: tlsmgr logfile spam. Some OS lies under load: + it says that a socket is readable, then it says that the + socket has unread data, and then it says that read returns + EOF, causing Postfix to spam the log with a warning message. + File: tlsmgr/tlsmgr.c. +- Bugfix (defect introduced: Postfix 3.4): the SMTP server's + BDAT command handler could be tricked to read $message_size_limit + bytes into memory. Found during code maintenance. File: + smtpd/smtpd.c. +- Performance: eliminate worst-case behavior where the queue + manager defers delivery to all destinations over a specific + delivery transport, after only a single delivery agent + failure. The scheduler now throttles one destination, and + allows deliveries to other destinations to keep making + progress. Files: *qmgr/qmgr_deliver.c. +- Safety: drop and log over-size DNS responses resulting in + more than 100 records. This 20x larger than the number of + server addresses that the Postfix SMTP client is willing + to consider when delivering mail, and is well below the + number of records that could cause a tail recursion crash + in dns_rr_append() as reported by Toshifumi Sakaguchi. This + also limits the number of DNS requests from check_*_*_access + restrictions. Files: dns/dns.h, dns/dns_lookup.c, dns/dns_rr.c, + dns/test_dns_lookup.c, posttls-finger/posttls-finger.c, + smtp/smtp_addr.c, smtpd/smtpd_check.c. + + -- Scott Kitterman Sat, 09 Mar 2024 10:38:51 -0500 + postfix (3.5.24-0+deb11u1) bullseye; urgency=medium [Wietse Venema] diff -Nru postfix-3.5.24/HISTORY postfix-3.5.25/HISTORY --- postfix-3.5.24/HISTORY 2024-01-19 14:16:32.0 -0500 +++ postfix-3.5.25/HISTORY 2024-02-27 15:58:22.0 -0500 @@ -25433,3 +25433,83 @@ Files: mantools/postlink, proto/postconf.proto, global/mail_params.h, global/smtp_stream.c, global/smtp_stream.h, smtpd/smtpd.c, smtpd/smtpd_check.[hc]. + +20231102 + + Bugfix (defect introduced: Postfix 2.3, date 20051222): the + Dovecot auth client did not reset the 'reason' from a + previous Dovecot auth service response, before parsing the + next Dovecot auth server response in the same SMTP session. + Reported by Stephan Bosch, File: xsasl/xsasl_dovecot_server.c. + +20231105 + + Cleanup: Postfix SMTP server response with an empty + authentication failure reason. File: smtpd/smtpd_sasl_glue.c. + +20231208 + + Bugfix (defect introduced: Postfix 3.1, date: 20151128): + "postqueue -j" produced broken JSON when escaping a control + character as \u. Found during code maintenance. File: + postqueue/showq_json.c. + +20231211 + + Cleanup: posttls-finger certificate match expectations for + all TLS security levels, including warnings for levels that + don't implement certificate matching. Viktor Dukhovni. + File: posttls-finger.c. + +20231213 + + Bugfix (defect introduced: Postfix 2.3): after prepending + a message header with a Postfix access table PREPEND action, + a Milter request to delete or update an existing header + could have no effect, or it could target the wrong instance + of an existing header. Root cause: the fix dated 20141018 + for the Postfix Milter client was incomplete. The client + did correctly hid
Bug#1065562: bookworm-pu: package postfix/3.7.10-0+deb12u1
- Bugfix (defect introduced: Postfix 3.1, date: 20151128): + "postqueue -j" produced broken JSON when escaping a control + character as \u. Found during code maintenance. File: + postqueue/showq_json.c. +- Cleanup: posttls-finger certificate match expectations for + all TLS security levels, including warnings for levels that + don't implement certificate matching. Viktor Dukhovni. + File: posttls-finger.c. +- Bugfix (defect introduced: Postfix 2.3): after prepending + a message header with a Postfix access table PREPEND action, + a Milter request to delete or update an existing header + could have no effect, or it could target the wrong instance + of an existing header. Root cause: the fix dated 20141018 + for the Postfix Milter client was incomplete. The client + did correctly hide the first, Postfix-generated, Received: + header when sending message header information to a Milter + with the smfi_header() application callback function, but + it was still hiding the first header (instead of the first + Received: header) when handling requests from a Milter to + delete or update an existing header. Problem report by + Carlos Velasco. This change was verified to have no effect + on requests from a Milter to add or insert a header. File: + cleanup/cleanup_milter.c. +- Workaround: tlsmgr logfile spam. Some OS lies under load: + it says that a socket is readable, then it says that the + socket has unread data, and then it says that read returns + EOF, causing Postfix to spam the log with a warning message. + File: tlsmgr/tlsmgr.c. +- Bugfix (defect introduced: Postfix 3.4): the SMTP server's + BDAT command handler could be tricked to read $message_size_limit + bytes into memory. Found during code maintenance. File: + smtpd/smtpd.c. +- Performance: eliminate worst-case behavior where the queue + manager defers delivery to all destinations over a specific + delivery transport, after only a single delivery agent + failure. The scheduler now throttles one destination, and + allows deliveries to other destinations to keep making + progress. Files: *qmgr/qmgr_deliver.c. +- Safety: drop and log over-size DNS responses resulting in + more than 100 records. This 20x larger than the number of + server addresses that the Postfix SMTP client is willing + to consider when delivering mail, and is well below the + number of records that could cause a tail recursion crash + in dns_rr_append() as reported by Toshifumi Sakaguchi. This + also limits the number of DNS requests from check_*_*_access + restrictions. Files: dns/dns.h, dns/dns_lookup.c, dns/dns_rr.c, + dns/test_dns_lookup.c, posttls-finger/posttls-finger.c, + smtp/smtp_addr.c, smtpd/smtpd_check.c. + + -- Scott Kitterman Wed, 06 Mar 2024 10:10:14 -0500 + postfix (3.7.10-0+deb12u1) bookworm; urgency=medium [Wietse Venema] diff -Nru postfix-3.7.10/HISTORY postfix-3.7.11/HISTORY --- postfix-3.7.10/HISTORY 2024-01-19 11:52:30.0 -0500 +++ postfix-3.7.11/HISTORY 2024-02-27 15:58:54.0 -0500 @@ -26681,3 +26681,83 @@ Files: mantools/postlink, proto/postconf.proto, global/mail_params.h, global/smtp_stream.c, global/smtp_stream.h, smtpd/smtpd.c, smtpd/smtpd_check.[hc]. + +20231102 + + Bugfix (defect introduced: Postfix 2.3, date 20051222): the + Dovecot auth client did not reset the 'reason' from a + previous Dovecot auth service response, before parsing the + next Dovecot auth server response in the same SMTP session. + Reported by Stephan Bosch, File: xsasl/xsasl_dovecot_server.c. + +20231105 + + Cleanup: Postfix SMTP server response with an empty + authentication failure reason. File: smtpd/smtpd_sasl_glue.c. + +20231208 + + Bugfix (defect introduced: Postfix 3.1, date: 20151128): + "postqueue -j" produced broken JSON when escaping a control + character as \u. Found during code maintenance. File: + postqueue/showq_json.c. + +20231211 + + Cleanup: posttls-finger certificate match expectations for + all TLS security levels, including warnings for levels that + don't implement certificate matching. Viktor Dukhovni. + File: posttls-finger.c. + +20231213 + + Bugfix (defect introduced: Postfix 2.3): after prepending + a message header with a Postfix access table PREPEND action, + a Milter request to delete or update an existing header + could have no effect, or it could target the wrong instance + of an existing header. Root cause: the fix dated 20141018 + for the Postfix Milter client was incomplete. The client + did correctly hide the first, Postfix-generated, Received: + header when sending message header information to a Milte
Bug#1065312: RM: deborphan -- ROM; missing too many dpkg features, thus broken and unreliable
Generally in the FTP Team we trust maintainer's judgement when it comes to deciding if a package should be removed rather than orphaned and left to rot. I looked and it's been about 5 years since anyone other than Chris has uploaded the package and he's the only human maintainer. It is both a feature and a bug that in Debian, we're all volunteers and can choose how we volunteer. I don't see anyone volunteering to step up and take over, so in the end, the maintainer's judgement is what has to control. Scott K
Bug#1063476: the sanesecurity configuration is not suitable for a release
On Fri, 16 Feb 2024 09:17:40 -0500 Scott Kitterman wrote: > On Thu, 8 Feb 2024 19:35:50 +0100 Marco d'Itri wrote: > > Source: fangfrisch > > Version: 1.7.0-1 > > Severity: grave > > Tags: upstream > > > > Control: forwarded -1 https://github.com/rseichter/fangfrisch/issues/30 > > > > The sanesecurity section of default configuration, if enabled, relies on > > an unofficial HTTP mirror which is seriously overloaded and probably > > seriously expensive for their operators, since it is located in > > Australia. > > The only other known HTTP mirror is mentioned on > > https://wiki.gentoo.org/wiki/ClamAV_Unofficial_Signatures, with a vague > > note about it being available to the public. > > > > Until fangfrisch will implement rsync support, I do not think that it is > > safe to include fangfrisch in a Debian release due to the possible > > effect on unsuspecting third party mirrors. > > > > This has also been discussed upstream: > > https://github.com/rseichter/fangfrisch/issues/30 > > I don't know that I'd call this fixed upstream, since the package is not > directly using rsync, but the fact that he's now rsyncing from sanesecurity > and running his own mirror is progress (that only person he can DoS is > himself) is progress. > > If we update to 1.8.0, I don't think we should mark this bug done, but it > might be reasonable to change the severity to Important. What do you think? Upon further reflection, I'm going to mark this as done in 1.8.0. The specific issue raised in the bug is resolved. Direct support for rsync would be better, but I think we've cleared this particular hurdle for releasability. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1063771: Please update to version 42, needed for new dnspython
On Tue, 13 Feb 2024 18:30:42 -0500 Scott Kitterman wrote: > On Tue, 13 Feb 2024 10:16:23 +0100 Jérémy Lal wrote: > > Will do, but right now there are a bunch of rust dependencies that need to > > be upgraded. > > Thanks, I got a one release reprieve from the dnspython upstream, so I'm good with version 41, for now, but will definitely need 42 for the next release, which is nominally in a few months. Appreciate your work on the package. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1063771: Please update to version 42, needed for new dnspython
On Tue, 13 Feb 2024 10:16:23 +0100 Jérémy Lal wrote: > Will do, but right now there are a bunch of rust dependencies that need to > be upgraded. Thanks, Scott K signature.asc Description: This is a digitally signed message part.
Bug#1063821: bullseye-pu: package python-dnslib/0.9.14-1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
Address no-dsa CVE. CVE-2022-22846
[ Impact ]
Continued vulnerability to minor issue.
[ Tests ]
Package has tests which are run via autopkgtest and during the build.
Both pass locally with the added patch.
[ Risks ]
Risk is minimal. Patch is from upstream and has been around for awhile
without known issues. Change is trivial.
[ Checklist ]
[X] *all* changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in (old)stable
[X] the issue is verified as fixed in unstable
[ Changes ]
Add verify that the ID value in a DNS reply matches an ID value in a query.
[ Other info ]
I've only ever used this for running local tests to mock DNS responses,
which is not a case that's at risk for this issue, but it did occur to
me others may use it differently, so probably better to fix it.
Scott K
diff -Nru python-dnslib-0.9.14/debian/changelog
python-dnslib-0.9.14/debian/changelog
--- python-dnslib-0.9.14/debian/changelog 2020-06-10 00:51:44.0
-0400
+++ python-dnslib-0.9.14/debian/changelog 2024-02-12 19:43:55.0
-0500
@@ -1,3 +1,9 @@
+python-dnslib (0.9.14-1+deb11u1) bullseye; urgency=medium
+
+ * Add d/p/0002-Validate-TXID-in-client.py.patch to address CVE-2022-22846
+
+ -- Scott Kitterman Mon, 12 Feb 2024 19:43:55 -0500
+
python-dnslib (0.9.14-1) unstable; urgency=medium
* New upstream release
diff -Nru
python-dnslib-0.9.14/debian/patches/0002-Validate-TXID-in-client.py.patch
python-dnslib-0.9.14/debian/patches/0002-Validate-TXID-in-client.py.patch
--- python-dnslib-0.9.14/debian/patches/0002-Validate-TXID-in-client.py.patch
1969-12-31 19:00:00.0 -0500
+++ python-dnslib-0.9.14/debian/patches/0002-Validate-TXID-in-client.py.patch
2024-02-12 19:42:50.0 -0500
@@ -0,0 +1,24 @@
+From: Scott Kitterman
+Date: Sat, 12 Feb 2024 19:41:26 -0500
+Subject: Validate TXID in client.py
+Fixes CVE-2022-22846
+Origin: backport,
https://github.com/paulc/dnslib/commit/76e8677699ed098387d502c57980f58da642aeba
+
+---
+ dnslib/client.py | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/dnslib/client.py b/dnslib/client.py
+index 628ea81..09572b6 100644
+--- a/dnslib/client.py
b/dnslib/client.py
+@@ -76,6 +76,9 @@ if __name__ == '__main__':
+ a_pkt = q.send(address,port,tcp=args.tcp)
+ a = DNSRecord.parse(a_pkt)
+
++if q.header.id != a.header.id:
++raise DNSError('Response transaction id does not match query
transaction id')
++
+ if a.header.tc and args.noretry == False:
+ # Truncated - retry in TCP mode
+ a_pkt = q.send(address,port,tcp=True)
diff -Nru python-dnslib-0.9.14/debian/patches/series
python-dnslib-0.9.14/debian/patches/series
--- python-dnslib-0.9.14/debian/patches/series 2020-06-10 00:50:31.0
-0400
+++ python-dnslib-0.9.14/debian/patches/series 2024-02-12 19:43:55.0
-0500
@@ -1 +1,2 @@
0001-Only-run-tests-for-python3.patch
+0002-Validate-TXID-in-client.py.patch
Bug#1063771: python-cryptography: Please update to version 42, needed for new dnspython
Source: python-cryptography Version: 41.0.7-3 Severity: wishlist There is a new dnspython release candidate out, 2.6.0~rc1. Typically, final releases follow in a few weeks. It has a hard requirement for version 42 to continue to support dnssec, which is important. It would be great if you could update the package so we can update dnspython without losing dnssec support. Thanks, Scott K
Bug#1063752: custodian: Inappriate maintainer address
Source: custodian Version: 2024.1.9-2 Severity: serious Justification: Policy 3.3 Policy 3.3 says that maintainer addresses must accept mail from Debian role accounts. This one, apparently, does not: From: debichem-devel-ow...@alioth-lists.debian.net To: ftpmas...@ftp-master.debian.org Sender: Debichem-devel List-Id:Debichem development list Date: 2/11/24 10:10 PM Spam Status:Spamassassin  You are not allowed to post to this mailing list From: a domain which publishes a DMARC policy of reject or quarantine, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at debichem-devel-ow...@alioth-lists.debian.net. Scott K
Bug#1063723: bullseye-pu: package pypdf2/1.26.0-4
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
Fixes two no-DSA CVE issues.
[ Impact ]
Continued low level security risk.
[ Tests ]
None that are run in the Debian package or autopkgtest.
[ Risks ]
Risk is low. Code changes are relatively simple and were provided by
upstream. These same two patches were previously released for LTS with
no known issues.
[ Checklist ]
[X] *all* changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in (old)stable
[X] the issue is verified as fixed in unstable
[ Changes ]
* Forward-port CVE fixes by LTS team
- CVE-2023-36810: Quadratic runtime with malformed PDF missing xref marker.
- Fix CVE-2022-24859:
Sebastian Krause discovered that manipulated inline images can force
PyPDF2, a pure Python PDF library, into an infinite loop, if a
maliciously crafted PDF file is processed.
[ Other info ]
This may show up as an NMU (lintian things so), but I'm the maintainer
now for Testing/Unstable. I chose not to update the maintainer fields
in this update to keep it minimal to address the issues.
Scott K
diff -Nru pypdf2-1.26.0/debian/changelog pypdf2-1.26.0/debian/changelog
--- pypdf2-1.26.0/debian/changelog 2020-01-19 03:08:58.0 -0500
+++ pypdf2-1.26.0/debian/changelog 2024-02-11 13:50:22.0 -0500
@@ -1,3 +1,14 @@
+pypdf2 (1.26.0-4+deb11u1) bullseye; urgency=medium
+
+ * Forward-port CVE fixes by LTS team
+- CVE-2023-36810: Quadratic runtime with malformed PDF missing xref marker.
+- Fix CVE-2022-24859:
+Sebastian Krause discovered that manipulated inline images can force
+PyPDF2, a pure Python PDF library, into an infinite loop, if a
+maliciously crafted PDF file is processed.
+
+ -- Scott Kitterman Sun, 11 Feb 2024 13:50:22 -0500
+
pypdf2 (1.26.0-4) unstable; urgency=medium
* Remove Python 2 from build dependencies (closes: #937505).
diff -Nru
pypdf2-1.26.0/debian/patches/0001-MAINT-Quadratic-runtime-while-parsing-reduced-to-lin.patch
pypdf2-1.26.0/debian/patches/0001-MAINT-Quadratic-runtime-while-parsing-reduced-to-lin.patch
---
pypdf2-1.26.0/debian/patches/0001-MAINT-Quadratic-runtime-while-parsing-reduced-to-lin.patch
1969-12-31 19:00:00.0 -0500
+++
pypdf2-1.26.0/debian/patches/0001-MAINT-Quadratic-runtime-while-parsing-reduced-to-lin.patch
2024-02-11 13:49:50.0 -0500
@@ -0,0 +1,50 @@
+From 82ee233ea82a40c626e95a191fe2d52c745db870 Mon Sep 17 00:00:00 2001
+From: dsk7
+Date: Sat, 23 Apr 2022 19:12:13 +0200
+Subject: MAINT: Quadratic runtime while parsing reduced to linear (#808)
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+When the PdfFileReader tries to find the xref marker, the readNextEndLine
methods builds a so called line by reading byte-for-byte. Every time a new byte
is read, it is concatenated with the currently read line. This leads to
quadratic runtime O(n²) behavior as Python strings (also byte-strings) are
immutable and have to be copied where n is the size of the file.
+For files where the xref marker can not be found at the end this takes a
enormous amount of time:
+
+* 1mb of zeros at the end: 45.54 seconds
+* 2mb of zeros at the end: 357.04 seconds
+(measured on a laptop made in 2015)
+
+This pull request changes the relevant section of the code to become linear
runtime O(n), leading to a run time of less then a second for both cases
mentioned above. Furthermore this PR adds a regression test.
+---
+ PyPDF2/pdf.py | 8
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/PyPDF2/pdf.py b/PyPDF2/pdf.py
+index 9979414..8b355e0 100644
+--- a/PyPDF2/pdf.py
b/PyPDF2/pdf.py
+@@ -1930,7 +1930,7 @@ class PdfFileReader(object):
+ def readNextEndLine(self, stream):
+ debug = False
+ if debug: print(">>readNextEndLine")
+-line = b_("")
++line_parts = []
+ while True:
+ # Prevent infinite loops in malformed PDFs
+ if stream.tell() == 0:
+@@ -1957,10 +1957,10 @@ class PdfFileReader(object):
+ break
+ else:
+ if debug: print(" x is neither")
+-line = x + line
+-if debug: print((" RNEL line:", line))
++line_parts.append(x)
+ if debug: print("leaving RNEL")
+-return line
++line_parts.reverse()
++return b"".join(line_parts)
+
+ def decrypt(self, password):
+ """
+--
+2.30.2
+
diff -Nru pypdf2-1.26.0/debian/patches/CVE-2022-24859.patch
pypdf2-1.26.0/debian/patches/CVE-2022-24859.patch
--- pypdf2-1.26.0/debian/patches/CVE-2022-24859.patch 1969-12-31
19:00:00.0 -0500
+++ pypdf2-1.26.0/debian/patches/C
Bug#1060934: pycountry: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.12 3.11" returned exit code 13
It's been a couple of weeks and no action upstream. I'll plan on uploading
this unless you'd rather I hold off for some reason.
Scott K
On Wed, 24 Jan 2024 16:56:30 -0500 Scott Kitterman
wrote:
> On Tue, 16 Jan 2024 20:41:58 +0100 Lucas Nussbaum wrote:
> > Source: pycountry
> > Version: 23.12.11+ds1-1
> > Severity: serious
> > Justification: FTBFS
> > Tags: trixie sid ftbfs
> > User: lu...@debian.org
> > Usertags: ftbfs-20240115 ftbfs-trixie
> >
> > Hi,
> >
> > During a rebuild of all packages in sid, your package failed to build
> > on amd64.
>
> This is due to changes in the recent iso-codes upload. the patch below fixes
> it so it should work with either version:
>
> --- pycountry-23.12.11+ds1.orig/src/pycountry/__init__.py
> +++ pycountry-23.12.11+ds1/src/pycountry/__init__.py
> @@ -169,7 +169,8 @@ class SubdivisionHierarchy(pycountry.db.
> kw["parent_code"] = None
> super().__init__(**kw)
> self.country_code = self.code.split("-")[0]
> -if self.parent_code is not None:
> +if (self.parent_code is not None and
> +self.country_code != self.parent_code.split("-")[0]):
> self.parent_code = f"{self.country_code}-{self.parent_code}"
>
> @property
>
> Please let me know if you don't want an NMU. This will eventually cause
> xml2rfc to be removed, so I'll NMU at some point unless you want to take
care
> of it first (thanks if you do).
>
> Scott K
=<2567281.9CzbHMAgVU@zini-1880>
signature.asc
Description: This is a digitally signed message part.
Bug#1063348: O: pdfkit
Package: wnpp Severity: normal X-Debbugs-Cc: debian-pyt...@lists.debian.org Control: affects -1 src:pdfkit I am no longer interested in this package and no else in the Debian Python Team expressed interest it taking it over, so orphaning. The package itself is in reasonable shape. Upstream includes the following warning in the Git version of the package README: This library has been deprecated to match the wkhtmltopdf project status. Scott K
Bug#1063317: O: django-anymail
Package: wnpp Severity: normal X-Debbugs-Cc: debian-pyt...@lists.debian.org Control: affects -1 src:django-anymail I'm no longer interested in the package and no one from the Debian Python Team expressed interest in it, so orphaning. I've updated the package to the current upstream and updated for the switch to hatchling, so that package is in good shape for now. Upstream is moderately active. Scott K
Bug#1063171: O: python-sparkpost
Package: wnpp Severity: normal X-Debbugs-Cc: debian-pyt...@lists.debian.org Control: affects -1 src:python-sparkpost I'm no longer interested in the package (it was only packaged to support django-anymail, which is also about to be orphaned). This is an interface to a proprietary mail service. The company was acquired in 2021 and nothing has happened with the package upstream since then. The package itself is in reasonably good condition. There is one Python 3.12 related issue that will be addressed in the upload that orphans the package. Scott K
Bug#1063033: O: django-wkhtmltopdf
Package: wnpp Severity: normal X-Debbugs-Cc: debian-pyt...@lists.debian.org Control: affects -1 src:django-wkhtmltopdf I no longer use this package and no one in the Debian Python Team expressed any interest in it, so orphaning. At this time, the package is in reasonably good shape and does not generally require a lot of attention. It's not clear if upstream is dead or moving slowly. Scott K
Bug#1062938: RM: clamav-unofficial-sigs -- ROM; Unmaintained and obsolete, replaced by fangfrisch
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: pkg-clamav-de...@lists.alioth.debian.org Long dead upstream and only minimally maintained in Debian. Not working well, if at all, anymore. The fangfrisch package is a maintained alternative that is now it the archive. Request coordinated with pabs via IRC. Scott K
Bug#1061625: bullseye-pu: package postfix/3.5.23-0+deb11u1
bility, local clients are excluded by + default with "smtpd_forbid_bare_newline_exclusions = + $mynetworks". + Files: mantools/postlink, proto/postconf.proto, + global/mail_params.h, global/smtp_stream.c, global/smtp_stream.h, + smtpd/smtpd.c, smtpd/smtpd_check.[hc]. + + -- Scott Kitterman Sat, 27 Jan 2024 10:21:04 -0500 + postfix (3.5.23-0+deb11u1) bullseye; urgency=medium [Wietse Venema] diff -Nru postfix-3.5.23/HISTORY postfix-3.5.24/HISTORY --- postfix-3.5.23/HISTORY 2023-12-22 13:55:36.0 -0500 +++ postfix-3.5.24/HISTORY 2024-01-19 14:16:32.0 -0500 @@ -25400,16 +25400,36 @@ a configured recipient delimiter value. Reported by Tod A. Sandman. Files: proto/postconf.proto, local/local_expand.c. -20231221 +20240109 - Security: with "smtpd_forbid_bare_newline = yes" (default - "no" for Postfix < 3.9), reply with "Error: bare - received" and disconnect when an SMTP client sends a line - ending in , violating the RFC 5321 requirement that - lines must end in . This prevents SMTP smuggling - attacks that target a recipient at a Postfix server. For - backwards compatibility, local clients are excluded by + Security (outbound SMTP smuggling): with the default setting + "cleanup_replace_stray_cr_lf = yes" Postfix will replace + stray or characters in message content with a + space character. This prevents Postfix from enabling + outbound (remote) SMTP smuggling, and it also makes evaluation + of Postfix-added DKIM etc. signatures independent from how + a remote mail server handles stray or characters. + Files: global/mail_params.h, cleanup/cleanup.c, + cleanup/cleanup_message.c, mantools/postlink, proto/postconf.proto. + +20240112 + + Security (inbound SMTP smuggling): with "smtpd_forbid_bare_newline + = normalize" (default "no" for Postfix < 3.9), the Postfix + SMTP server requires the standard End-of-DATA sequence + ., and otherwise allows command or message + content lines ending in the non-standard , processing + them as if the client sent the standard . + + The alternative setting, "smtpd_forbid_bare_newline = reject" + will reject any command or message that contains a bare + , and is more likely to cause problems with legitimate + clients. + + For backwards compatibility, local clients are excluded by default with "smtpd_forbid_bare_newline_exclusions = - $mynetworks". Files: mantools/postlink, proto/postconf.proto, + $mynetworks". + + Files: mantools/postlink, proto/postconf.proto, global/mail_params.h, global/smtp_stream.c, global/smtp_stream.h, - smtpd/smtpd.c. + smtpd/smtpd.c, smtpd/smtpd_check.[hc]. diff -Nru postfix-3.5.23/html/cleanup.8.html postfix-3.5.24/html/cleanup.8.html --- postfix-3.5.23/html/cleanup.8.html 2019-11-09 19:00:16.0 -0500 +++ postfix-3.5.24/html/cleanup.8.html 2024-01-19 14:27:01.0 -0500 @@ -146,6 +146,16 @@ The set of characters that Postfix will remove from message con- tent. + Available in Postfix version 3.9, 3.8.5, 3.7.10, 3.6.14, 3.5.24, and + later: + + cleanup_replace_stray_cr_lf (yes) + Replace each stray CR or LF character in message content + with a space character, to prevent outbound SMTP smuggling, and + to make the evaluation of Postfix-added DKIM or other signatures + independent from how a remote mail server handles such charac- + ters. + BEFORE QUEUE MILTER CONTROLS As of version 2.3, Postfix supports the Sendmail version 8 Milter (mail filter) protocol. When mail is not received via the smtpd(8) server, diff -Nru postfix-3.5.23/html/postconf.5.html postfix-3.5.24/html/postconf.5.html --- postfix-3.5.23/html/postconf.5.html 2023-12-22 13:58:15.0 -0500 +++ postfix-3.5.24/html/postconf.5.html 2024-01-21 17:27:31.0 -0500 @@ -1444,6 +1444,40 @@ +cleanup_replace_stray_cr_lf +(default: yes) + + Replace each stray CR or LF character in message +content with a space character, to prevent outbound SMTP smuggling, +and to make the evaluation of Postfix-added DKIM or other signatures +independent from how a remote mail server handles such characters. + + + SMTP does not allow such characters unless they are part of a +CRLF sequence, and different mail systems handle +such stray characters in an implementation-dependent manner. Stray +CR or LF characters could be used for outbound +SMTP smuggling, where an attacker uses a Postfix server to send +message content with a non-standard End-of-DATA sequence that +triggers inbound SMTP smuggling at a remote SMTP server. + + The replacement happens before all other conten
Bug#1061624: bookworm-pu: package postfix/3.7.9-0+deb12u1
s are excluded by + default with "smtpd_forbid_bare_newline_exclusions = + $mynetworks". + Files: mantools/postlink, proto/postconf.proto, + global/mail_params.h, global/smtp_stream.c, global/smtp_stream.h, + smtpd/smtpd.c, smtpd/smtpd_check.[hc]. + + -- Scott Kitterman Fri, 26 Jan 2024 18:44:58 -0500 + postfix (3.7.9-0+deb12u1) bookworm; urgency=medium [Wietse Venema] diff -Nru postfix-3.7.9/HISTORY postfix-3.7.10/HISTORY --- postfix-3.7.9/HISTORY 2023-12-21 21:01:13.0 -0500 +++ postfix-3.7.10/HISTORY 2024-01-19 11:52:30.0 -0500 @@ -26648,16 +26648,36 @@ a configured recipient delimiter value. Reported by Tod A. Sandman. Files: proto/postconf.proto, local/local_expand.c. -20231221 +20240109 - Security: with "smtpd_forbid_bare_newline = yes" (default - "no" for Postfix < 3.9), reply with "Error: bare - received" and disconnect when an SMTP client sends a line - ending in , violating the RFC 5321 requirement that - lines must end in . This prevents SMTP smuggling - attacks that target a recipient at a Postfix server. For - backwards compatibility, local clients are excluded by + Security (outbound SMTP smuggling): with the default setting + "cleanup_replace_stray_cr_lf = yes" Postfix will replace + stray or characters in message content with a + space character. This prevents Postfix from enabling + outbound (remote) SMTP smuggling, and it also makes evaluation + of Postfix-added DKIM etc. signatures independent from how + a remote mail server handles stray or characters. + Files: global/mail_params.h, cleanup/cleanup.c, + cleanup/cleanup_message.c, mantools/postlink, proto/postconf.proto. + +20240112 + + Security (inbound SMTP smuggling): with "smtpd_forbid_bare_newline + = normalize" (default "no" for Postfix < 3.9), the Postfix + SMTP server requires the standard End-of-DATA sequence + ., and otherwise allows command or message + content lines ending in the non-standard , processing + them as if the client sent the standard . + + The alternative setting, "smtpd_forbid_bare_newline = reject" + will reject any command or message that contains a bare + , and is more likely to cause problems with legitimate + clients. + + For backwards compatibility, local clients are excluded by default with "smtpd_forbid_bare_newline_exclusions = - $mynetworks". Files: mantools/postlink, proto/postconf.proto, + $mynetworks". + + Files: mantools/postlink, proto/postconf.proto, global/mail_params.h, global/smtp_stream.c, global/smtp_stream.h, - smtpd/smtpd.c. + smtpd/smtpd.c, smtpd/smtpd_check.[hc]. diff -Nru postfix-3.7.9/html/cleanup.8.html postfix-3.7.10/html/cleanup.8.html --- postfix-3.7.9/html/cleanup.8.html 2021-12-23 17:24:55.0 -0500 +++ postfix-3.7.10/html/cleanup.8.html 2024-01-19 12:18:33.0 -0500 @@ -159,6 +159,16 @@ The set of characters that Postfix will remove from message con- tent. + Available in Postfix version 3.9, 3.8.5, 3.7.10, 3.6.14, 3.5.24, and + later: + + cleanup_replace_stray_cr_lf (yes) + Replace each stray CR or LF character in message content + with a space character, to prevent outbound SMTP smuggling, and + to make the evaluation of Postfix-added DKIM or other signatures + independent from how a remote mail server handles such charac- + ters. + BEFORE QUEUE MILTER CONTROLS As of version 2.3, Postfix supports the Sendmail version 8 Milter (mail filter) protocol. When mail is not received via the smtpd(8) server, diff -Nru postfix-3.7.9/html/postconf.5.html postfix-3.7.10/html/postconf.5.html --- postfix-3.7.9/html/postconf.5.html 2023-12-22 12:06:57.0 -0500 +++ postfix-3.7.10/html/postconf.5.html 2024-01-21 17:26:25.0 -0500 @@ -1453,6 +1453,40 @@ +cleanup_replace_stray_cr_lf +(default: yes) + + Replace each stray CR or LF character in message +content with a space character, to prevent outbound SMTP smuggling, +and to make the evaluation of Postfix-added DKIM or other signatures +independent from how a remote mail server handles such characters. + + + SMTP does not allow such characters unless they are part of a +CRLF sequence, and different mail systems handle +such stray characters in an implementation-dependent manner. Stray +CR or LF characters could be used for outbound +SMTP smuggling, where an attacker uses a Postfix server to send +message content with a non-standard End-of-DATA sequence that +triggers inbound SMTP smuggling at a remote SMTP server. + + The replacement happens before all other content management, +and before P
Bug#1060934: pycountry: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p "3.12 3.11" returned exit code 13
On Tue, 16 Jan 2024 20:41:58 +0100 Lucas Nussbaum wrote:
> Source: pycountry
> Version: 23.12.11+ds1-1
> Severity: serious
> Justification: FTBFS
> Tags: trixie sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20240115 ftbfs-trixie
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
This is due to changes in the recent iso-codes upload. the patch below fixes
it so it should work with either version:
--- pycountry-23.12.11+ds1.orig/src/pycountry/__init__.py
+++ pycountry-23.12.11+ds1/src/pycountry/__init__.py
@@ -169,7 +169,8 @@ class SubdivisionHierarchy(pycountry.db.
kw["parent_code"] = None
super().__init__(**kw)
self.country_code = self.code.split("-")[0]
-if self.parent_code is not None:
+if (self.parent_code is not None and
+self.country_code != self.parent_code.split("-")[0]):
self.parent_code = f"{self.country_code}-{self.parent_code}"
@property
Please let me know if you don't want an NMU. This will eventually cause
xml2rfc to be removed, so I'll NMU at some point unless you want to take care
of it first (thanks if you do).
Scott K
signature.asc
Description: This is a digitally signed message part.
Bug#1061447: O: django-maintenancemode
Package: wnpp Severity: normal X-Debbugs-Cc: debian-pyt...@lists.debian.org Control: affects -1 src:django-maintenancemode Orphaning the package on behalf of the Debian Python Team as the sole uploader (no one else on the team expressed interest in taking over and I no longer use the package). The package itself is in reasonable shape. Upstream is mostly dean, so if you take over this package, expect to have to do more than just package new upstream releases. Scott K
Bug#1061324: lmdb: Move doxygen to B-D-I
Source: lmdb Version: 0.9.31-1 Severity: normal It looks like doxygen is only needed for building the arch all lmdb-doc package, so it could be moved from Build-Depends to Build-Depends-Indep. While this is a pretty minor issue, I think it would be better and it would at least allow lmdb to be built on archs which don't have doxygen (currently only hurd-amd64, but it's been others in the past). Scott K
Bug#1061265: rst2pdf: Uses deprecated/to be removed pypdf2
On January 22, 2024 10:11:50 AM UTC, Rob Allen wrote: >Hi, > >I’m the one of the leads on rst2pdf itself. > >Is there anything you want me to do related to this? > >Regards, > >Rob Thank you for being interested in its status in Debian. No. My understanding is that all this needs is for the maintainer in Debian to update the package to the most current release. The next Debian release is likely at least a year and a half from now, so there's plenty of time. Scott K
Bug#1061265: rst2pdf: Uses deprecated/to be removed pypdf2
Source: rst2pdf Version: 0.99-1 Severity: wishlist rst2pdf declares a requirement for python3-pypdf2 in Build-Depends-Indep. I've recently adopted pypdf and pypdf2 into the Debian Python Team in response to an RFA for both packages. As these are somewhat security sensitive packages (among my first acts after adopting the packages was to upload proposed updates for both to address minor security issues in Bookworm in the next point release - same bug in both), I do not think we should release pypdf2 in Trixie and have filed an RC bug to that effect. It looks like the current upstream release has already been ported to use python3-pypdf (which is really pypdf3). Please update your package. Scott K
Bug#1061264: ocrmypdf: Uses deprecated/to be removed pypdf2 in autopkgtest
Source: ocrmypdf Version: 15.2.0+dfsg1-1 Severity: wishlist I've recently adopted pypdf and pypdf2 into the Debian Python Team in response to an RFA for both packages. As these are somewhat security sensitive packages (among my first acts after adopting the packages was to upload proposed updates for both to address minor security issues in Bookworm in the next point release - same bug in both), I do not think we should release pypdf2 in Trixie and have filed an RC bug to that effect. ocrmypdf uses the package in debian/tests/control. Please update to use python3-pypdf insteadm.
Bug#1029740: pypdf2 is deprecated, please move from python3-pypdf2 to python3-pypdf
On Fri, 27 Jan 2023 00:26:31 +0100 Mathias Behrle wrote: > tag -1 pending > > API changes were already considered in > https://foss.heptapod.net/tryton/tryton/-/merge_requests/25 > https://foss.heptapod.net/tryton/tryton/-/merge_requests/27 > and Tryton packages should be fit for any version 1, 2, 3 of pypdf. > > We are waiting for backports of the fixes to 6.0. We will anyway include them > for bookworm. As we are maintaining backports for bullseye and buster we will > stick for now with python3-pypdf2, until python3-pypdf will be available as > backport in the targeted Debian releases. As we approach the first anniversary for this bug, an update: I've recently adopted pypdf and pypdf2 into the Debian Python Team in response to an RFA for both packages. As these are somewhat security sensitive packages (among my first acts after adopting the packages was to upload proposed updates for both to address minor security issues in Bookworm in the next point release - same bug in both), I do not think we should release pypdf2 in Trixie and have filed an RC bug to that effect. If you want this package to be in Trixie, you will need to use pypdf instead of pypdf2. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1029739: pypdf2 is deprecated, please move from python3-pypdf2 to python3-pypdf
On Thu, 26 Jan 2023 16:39:39 -0500 Daniel Kahn Gillmor wrote: > As noted in https://bugs.debian.org/1028559, upstream for the PyPDF2 > Python module has moved to the "pypdf" namespace. > > Correspondingly, there is a new python3-pypdf package in debian > unstable. > > The packages listed above all currently depend on (or recommend) PyPDF2, > but probably should move to the updated version. When all these bug > reports are closed, we can consider removing the pypdf2 source package > and python3-pypdf2 from debian. > > The migration should be relatively straightforward; much of the API > remains the same, just under the "pypdf" module name instead of the > "PyPDF2" module name. Where the API differs, the version of PyPDF2 > currently in debian testing/unstable (2.12.1-3) emits a > PendingDeprecationWarning wherever a piece of the API will break. > > For example: > >foo.py:76: PendingDeprecationWarning: getObject is deprecated and will be removed in PyPDF2 3.0.0. Use get_object instead. > > (PyPDF2 version 3.x is basically a terminal version of PyPDF2, and pypdf > takes over from 3.1.x onward; PyPDF2 version 3.x will not enter debian, > as it is an API break from 2.x, and pypdf 3.x supercedes it) As we approach the first anniversary for this bug, an update: I've recently adopted pypdf and pypdf2 into the Debian Python Team in response to an RFA for both packages. As these are somewhat security sensitive packages (among my first acts after adopting the packages was to upload proposed updates for both to address minor security issues in Bookworm in the next point release - same bug in both), I do not think we should release pypdf2 in Trixie and have filed an RC bug to that effect. If you want this package to be in Trixie, you will need to use pypdf instead of pypdf2. There is a new upstream release that supports this transition, but packaging it will be non-trivial. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1029735: pypdf2 is deprecated, please move from python3-pypdf2 to python3-pypdf
On Thu, 26 Jan 2023 16:39:39 -0500 Daniel Kahn Gillmor wrote: > As noted in https://bugs.debian.org/1028559, upstream for the PyPDF2 > Python module has moved to the "pypdf" namespace. > > Correspondingly, there is a new python3-pypdf package in debian > unstable. > > The packages listed above all currently depend on (or recommend) PyPDF2, > but probably should move to the updated version. When all these bug > reports are closed, we can consider removing the pypdf2 source package > and python3-pypdf2 from debian. > > The migration should be relatively straightforward; much of the API > remains the same, just under the "pypdf" module name instead of the > "PyPDF2" module name. Where the API differs, the version of PyPDF2 > currently in debian testing/unstable (2.12.1-3) emits a > PendingDeprecationWarning wherever a piece of the API will break. > > For example: > >foo.py:76: PendingDeprecationWarning: getObject is deprecated and will be removed in PyPDF2 3.0.0. Use get_object instead. > > (PyPDF2 version 3.x is basically a terminal version of PyPDF2, and pypdf > takes over from 3.1.x onward; PyPDF2 version 3.x will not enter debian, > as it is an API break from 2.x, and pypdf 3.x supercedes it) > > To transition a given package: > > - run tests with as complete coverage as possible and note the >PendingDeprecation warnings > > - for each warning, patch the upstream line as recommended > > - ensure that the tests pass without PendingDeprecationWarnings > > - convert from "PyPDF2" to "pypdf" on any import or scoped reference in >python > > - update dependency indicators in upstream metadata annotations >(e.g. pyproject.toml, setup.cfg, etc) > > - update dependency indicators in debian packaging (from python3-pypdf2 >to python3-pypdf). > > - run the tests again As we approach the first anniversary for this bug, an update: I've recently adopted pypdf and pypdf2 into the Debian Python Team in response to an RFA for both packages. As these are somewhat security sensitive packages (among my first acts after adopting the packages was to upload proposed updates for both to address minor security issues in Bookworm in the next point release - same bug in both), I do not think we should release pypdf2 in Trixie and have filed an RC bug to that effect. If you want this package to be in Trixie, you will need to use pypdf instead of pypdf2. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1029738: pypdf2 is deprecated, please move from python3-pypdf2 to python3-pypdf
On Thu, 26 Jan 2023 16:39:39 -0500 Daniel Kahn Gillmor wrote: > As noted in https://bugs.debian.org/1028559, upstream for the PyPDF2 > Python module has moved to the "pypdf" namespace. > > Correspondingly, there is a new python3-pypdf package in debian > unstable. > > The packages listed above all currently depend on (or recommend) PyPDF2, > but probably should move to the updated version. When all these bug > reports are closed, we can consider removing the pypdf2 source package > and python3-pypdf2 from debian. > > The migration should be relatively straightforward; much of the API > remains the same, just under the "pypdf" module name instead of the > "PyPDF2" module name. Where the API differs, the version of PyPDF2 > currently in debian testing/unstable (2.12.1-3) emits a > PendingDeprecationWarning wherever a piece of the API will break. > > For example: > >foo.py:76: PendingDeprecationWarning: getObject is deprecated and will be removed in PyPDF2 3.0.0. Use get_object instead. > > (PyPDF2 version 3.x is basically a terminal version of PyPDF2, and pypdf > takes over from 3.1.x onward; PyPDF2 version 3.x will not enter debian, > as it is an API break from 2.x, and pypdf 3.x supercedes it) > > To transition a given package: > > - run tests with as complete coverage as possible and note the >PendingDeprecation warnings > > - for each warning, patch the upstream line as recommended > > - ensure that the tests pass without PendingDeprecationWarnings > > - convert from "PyPDF2" to "pypdf" on any import or scoped reference in >python > > - update dependency indicators in upstream metadata annotations >(e.g. pyproject.toml, setup.cfg, etc) > > - update dependency indicators in debian packaging (from python3-pypdf2 >to python3-pypdf). > > - run the tests again As we approach the first anniversary for this bug, an update: I've recently adopted pypdf and pypdf2 into the Debian Python Team in response to an RFA for both packages. As these are somewhat security sensitive packages (among my first acts after adopting the packages was to upload proposed updates for both to address minor security issues in Bookworm in the next point release - same bug in both), I do not think we should release pypdf2 in Trixie and have filed an RC bug to that effect. If you want this package to be in Trixie, you will need to use pypdf instead of pypdf2. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1029733: pypdf2 is deprecated, please move from python3-pypdf2 to python3-pypdf
On Thu, 26 Jan 2023 16:39:39 -0500 Daniel Kahn Gillmor wrote: > As noted in https://bugs.debian.org/1028559, upstream for the PyPDF2 > Python module has moved to the "pypdf" namespace. > > Correspondingly, there is a new python3-pypdf package in debian > unstable. > > The packages listed above all currently depend on (or recommend) PyPDF2, > but probably should move to the updated version. When all these bug > reports are closed, we can consider removing the pypdf2 source package > and python3-pypdf2 from debian. > > The migration should be relatively straightforward; much of the API > remains the same, just under the "pypdf" module name instead of the > "PyPDF2" module name. Where the API differs, the version of PyPDF2 > currently in debian testing/unstable (2.12.1-3) emits a > PendingDeprecationWarning wherever a piece of the API will break. > > For example: > >foo.py:76: PendingDeprecationWarning: getObject is deprecated and will be removed in PyPDF2 3.0.0. Use get_object instead. > > (PyPDF2 version 3.x is basically a terminal version of PyPDF2, and pypdf > takes over from 3.1.x onward; PyPDF2 version 3.x will not enter debian, > as it is an API break from 2.x, and pypdf 3.x supercedes it) > > To transition a given package: > > - run tests with as complete coverage as possible and note the >PendingDeprecation warnings > > - for each warning, patch the upstream line as recommended > > - ensure that the tests pass without PendingDeprecationWarnings > > - convert from "PyPDF2" to "pypdf" on any import or scoped reference in >python > > - update dependency indicators in upstream metadata annotations >(e.g. pyproject.toml, setup.cfg, etc) > > - update dependency indicators in debian packaging (from python3-pypdf2 >to python3-pypdf). > > - run the tests again As we approach the first anniversary for this bug, an update: I've recently adopted pypdf and pypdf2 into the Debian Python Team in response to an RFA for both packages. As these are somewhat security sensitive packages (among my first acts after adopting the packages was to upload proposed updates for both to address minor security issues in Bookworm in the next point release - same bug in both), I do not think we should release pypdf2 in Trixie and have filed an RC bug to that effect. If you want this package to be in Trixie, you will need to use pypdf instead of pypdf2. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1029734: pypdf2 is deprecated, please move from python3-pypdf2 to python3-pypdf
On Thu, 26 Jan 2023 16:39:39 -0500 Daniel Kahn Gillmor wrote: > As noted in https://bugs.debian.org/1028559, upstream for the PyPDF2 > Python module has moved to the "pypdf" namespace. > > Correspondingly, there is a new python3-pypdf package in debian > unstable. > > The packages listed above all currently depend on (or recommend) PyPDF2, > but probably should move to the updated version. When all these bug > reports are closed, we can consider removing the pypdf2 source package > and python3-pypdf2 from debian. > > The migration should be relatively straightforward; much of the API > remains the same, just under the "pypdf" module name instead of the > "PyPDF2" module name. Where the API differs, the version of PyPDF2 > currently in debian testing/unstable (2.12.1-3) emits a > PendingDeprecationWarning wherever a piece of the API will break. > > For example: > >foo.py:76: PendingDeprecationWarning: getObject is deprecated and will be removed in PyPDF2 3.0.0. Use get_object instead. > > (PyPDF2 version 3.x is basically a terminal version of PyPDF2, and pypdf > takes over from 3.1.x onward; PyPDF2 version 3.x will not enter debian, > as it is an API break from 2.x, and pypdf 3.x supercedes it) > > To transition a given package: > > - run tests with as complete coverage as possible and note the >PendingDeprecation warnings > > - for each warning, patch the upstream line as recommended > > - ensure that the tests pass without PendingDeprecationWarnings > > - convert from "PyPDF2" to "pypdf" on any import or scoped reference in >python > > - update dependency indicators in upstream metadata annotations >(e.g. pyproject.toml, setup.cfg, etc) > > - update dependency indicators in debian packaging (from python3-pypdf2 >to python3-pypdf). > > - run the tests again As we approach the first anniversary for this bug, an update: I've recently adopted pypdf and pypdf2 into the Debian Python Team in response to an RFA for both packages. As these are somewhat security sensitive packages (among my first acts after adopting the packages was to upload proposed updates for both to address minor security issues in Bookworm in the next point release - same bug in both), I do not think we should release pypdf2 in Trixie and have filed an RC bug to that effect. If you want this package to be in Trixie, you will need to use pypdf instead of pypdf2. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1061261: odoo: Uses deprecated/to be removed PyPDF2
Source: odoo Version: 16.0.0+dfsg.2-2 Severity: wishlist The odoo package has recently added a dependency on python3-pypdf2. Last January the following bug was filed against all packages using python3-pypdf2: As noted in https://bugs.debian.org/1028559, upstream for the PyPDF2 Python module has moved to the "pypdf" namespace. Correspondingly, there is a new python3-pypdf package in debian unstable. The packages listed above all currently depend on (or recommend) PyPDF2, but probably should move to the updated version. When all these bug reports are closed, we can consider removing the pypdf2 source package and python3-pypdf2 from debian. The migration should be relatively straightforward; much of the API remains the same, just under the "pypdf" module name instead of the "PyPDF2" module name. Where the API differs, the version of PyPDF2 currently in debian testing/unstable (2.12.1-3) emits a PendingDeprecationWarning wherever a piece of the API will break. For example: foo.py:76: PendingDeprecationWarning: getObject is deprecated and will be removed in PyPDF2 3.0.0. Use get_object instead. (PyPDF2 version 3.x is basically a terminal version of PyPDF2, and pypdf takes over from 3.1.x onward; PyPDF2 version 3.x will not enter debian, as it is an API break from 2.x, and pypdf 3.x supercedes it) To transition a given package: - run tests with as complete coverage as possible and note the PendingDeprecation warnings - for each warning, patch the upstream line as recommended - ensure that the tests pass without PendingDeprecationWarnings - convert from "PyPDF2" to "pypdf" on any import or scoped reference in python - update dependency indicators in upstream metadata annotations (e.g. pyproject.toml, setup.cfg, etc) - update dependency indicators in debian packaging (from python3-pypdf2 to python3-pypdf). - run the tests again I'm currently in the process of updating all these bugs with: As we approach the first anniversary for this bug, an update: I've recently adopted pypdf and pypdf2 into the Debian Python Team in response to an RFA for both packages. As these are somewhat security sensitive packages (among my first acts after adopting the packages was to upload proposed updates for both to address minor security issues in Bookworm in the next point release - same bug in both), I do not think we should release pypdf2 in Trixie and have filed an RC bug to that effect. If you want this package to be in Trixie, you will need to use pypdf instead of pypdf2. Scott K
Bug#1060917: postfix-mysql broken in 3.7.9, results in unsupported dictionary type
On Wed, 17 Jan 2024 09:05:47 -0500 Scott Kitterman wrote: > On Wednesday, January 17, 2024 9:03:29 AM EST Richard Rosner wrote: > > I've updated all mariadb packages to 10.11.6 and all postfix packages. > > Everything still working. > > > Excellent news. Thanks for testing. Postfix packages in bookworm-proposed-updates have been rebuilt against the new mariadb, so I think this can be closed now. If anyone runs into this problem with the packages from bookworm-updates/stable-updates, install the rebuilt version from bookworm/stable-proposed-updates. After the next point release, this will be entirely OBE. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1061162: pypdf2: Do not release with Trixie
Source: pypdf2 Version: 2.12.1-4 Severity: serious Tags: upstream Justification: Maintainer opinion PyPDF2 has been replaced by pypdf upstream. We should not release this package with Trixie. Rdepends should be either ported or removed. Scott K
Bug#1061161: bookworm-pu: package pypdf2/2.12.1-3
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu [ Reason ] CVE fix. [ Impact ] Users still vulernable to security issue. [ Tests ] Upstream has an extensive test suite, although we don't include a test specifically for this issue. All tests pass on bookworm locally. [ Risks ] Risk is negligible. Code is trivial. Fix has been available for 8 months upstream. The same code is in pypdf and there have been no issues reported with it (stable update for it is pending as well). [ Checklist ] [X] *all* changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in (old)stable [X] the issue is verified as fixed in unstable [ Changes ] Add a patch to apply the upstream fix for the issue. [ Other info ] This looks like an NMU in bookworm, but I just adopted the package. I did not include the maintainer changes in the stble-update since that seemed to get beyone a minimal fix. Scott K diff -Nru pypdf2-2.12.1/debian/changelog pypdf2-2.12.1/debian/changelog --- pypdf2-2.12.1/debian/changelog 2023-01-13 16:38:55.0 -0500 +++ pypdf2-2.12.1/debian/changelog 2024-01-19 17:32:34.0 -0500 @@ -1,3 +1,12 @@ +pypdf2 (2.12.1-3+deb12u1) bookworm; urgency=medium + + * Prevent infinite loop when no character follows after a comment (Closes: +#1040339) +- Addresses CVE-2023-36464 +- Add d/p/0003-Prevent-infinite-loop-when-no-character-follows-afte.patch + + -- Scott Kitterman Fri, 19 Jan 2024 17:32:34 -0500 + pypdf2 (2.12.1-3) unstable; urgency=medium * disable two more network tests diff -Nru pypdf2-2.12.1/debian/patches/0003-Prevent-infinite-loop-when-no-character-follows-afte.patch pypdf2-2.12.1/debian/patches/0003-Prevent-infinite-loop-when-no-character-follows-afte.patch --- pypdf2-2.12.1/debian/patches/0003-Prevent-infinite-loop-when-no-character-follows-afte.patch 1969-12-31 19:00:00.0 -0500 +++ pypdf2-2.12.1/debian/patches/0003-Prevent-infinite-loop-when-no-character-follows-afte.patch 2024-01-19 17:30:16.0 -0500 @@ -0,0 +1,21 @@ +From: Scott Kitterman +Date: Mon, 15 Jan 2024 11:34:11 -0500 +Subject: Prevent infinite loop when no character follows after a comment +https://security-tracker.debian.org/tracker/CVE-2023-36464 +--- + PyPDF2/generic/_data_structures.py | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +Index: pypdf/PyPDF2/generic/_data_structures.py +=== +--- pypdf.orig/PyPDF2/generic/_data_structures.py pypdf/PyPDF2/generic/_data_structures.py +@@ -733,7 +733,7 @@ class ContentStream(DecodedStreamObject) + # encountering a comment -- but read_object assumes that + # following the comment must be the object we're trying to + # read. In this case, it could be an operator instead. +-while peek not in (b"\r", b"\n"): ++while peek not in (b"\r", b"\n", b""): + peek = stream.read(1) + else: + operands.append(read_object(stream, None, self.forced_encoding)) diff -Nru pypdf2-2.12.1/debian/patches/series pypdf2-2.12.1/debian/patches/series --- pypdf2-2.12.1/debian/patches/series 2023-01-13 16:38:30.0 -0500 +++ pypdf2-2.12.1/debian/patches/series 2024-01-19 17:30:16.0 -0500 @@ -1 +1,2 @@ disable-network-tests.patch +0003-Prevent-infinite-loop-when-no-character-follows-afte.patch
Bug#1060851: bookworm-pu: package pypdf/3.4.1-1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu (Please provide enough information to help the release team to judge the request efficiently. E.g. by filling in the sections below.) [ Reason ] This upload adds a patch to address CVE-2023-36464. It was assessed by the security team as no-dsa, so I think we ought to fix it in a stable update. [ Impact ] Users remain vulnerable to the DoS attack described in the CVE. [ Tests ] There is a pypdf test suite that runs during package build and autopkgtest. Upstream did add a test for this issue, but since it requires test assets not available in Debian, I did not include it in the patch. [ Risks ] Code is trivial and the risk of regression is negligible. This is the exact fix upstream used. The fix has been in the wild for 8 months, so I think if it was going to cause a problem, we'd know by now. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] Added the upstream change to fix the CVE (only the change to pypdf/generic/_data_structures.py is relevant): https://github.com/py-pdf/pypdf/commit/b0e5c689df689ab173df84dacd77b6fc3c161932 Updated gbp.conf to point at the bookworm branch [ Other info ] This will look like an NMU in tools that look at stable. I just adopted the package due to the original maintainer's RFA and have uploaded to unstable (including this fix). I elected not to change the maintainer in this upload since that didn't fit with a minimal change in stable. Scott K diff -Nru pypdf-3.4.1/debian/changelog pypdf-3.4.1/debian/changelog --- pypdf-3.4.1/debian/changelog2023-02-14 16:58:00.0 -0500 +++ pypdf-3.4.1/debian/changelog2024-01-15 11:28:43.0 -0500 @@ -1,3 +1,13 @@ +pypdf (3.4.1-1+deb12u1) bookworm; urgency=medium + + * Update debian/gbp.conf to point at bookworm branch + * Prevent infinite loop when no character follows after a comment (Closes: +#1040338) +- Addresses CVE-2023-36464 +- Add d/p/0003-Prevent-infinite-loop-when-no-character-follows-afte.patch + + -- Scott Kitterman Mon, 15 Jan 2024 11:28:43 -0500 + pypdf (3.4.1-1) unstable; urgency=medium * New upstream version 3.4.1 diff -Nru pypdf-3.4.1/debian/gbp.conf pypdf-3.4.1/debian/gbp.conf --- pypdf-3.4.1/debian/gbp.conf 2023-02-14 16:58:00.0 -0500 +++ pypdf-3.4.1/debian/gbp.conf 2024-01-15 11:28:20.0 -0500 @@ -1,3 +1,3 @@ [DEFAULT] -debian-branch = debian/unstable +debian-branch = debian/bookworm pristine-tar = True diff -Nru pypdf-3.4.1/debian/patches/0003-Prevent-infinite-loop-when-no-character-follows-afte.patch pypdf-3.4.1/debian/patches/0003-Prevent-infinite-loop-when-no-character-follows-afte.patch --- pypdf-3.4.1/debian/patches/0003-Prevent-infinite-loop-when-no-character-follows-afte.patch 1969-12-31 19:00:00.0 -0500 +++ pypdf-3.4.1/debian/patches/0003-Prevent-infinite-loop-when-no-character-follows-afte.patch 2024-01-15 11:28:43.0 -0500 @@ -0,0 +1,21 @@ +From: Scott Kitterman +Date: Mon, 15 Jan 2024 11:34:11 -0500 +Subject: Prevent infinite loop when no character follows after a comment +https://security-tracker.debian.org/tracker/CVE-2023-36464 +--- + pypdf/generic/_data_structures.py | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/pypdf/generic/_data_structures.py b/pypdf/generic/_data_structures.py +index bb2e028..524d4e0 100644 +--- a/pypdf/generic/_data_structures.py b/pypdf/generic/_data_structures.py +@@ -979,7 +979,7 @@ class ContentStream(DecodedStreamObject): + # encountering a comment -- but read_object assumes that + # following the comment must be the object we're trying to + # read. In this case, it could be an operator instead. +-while peek not in (b"\r", b"\n"): ++while peek not in (b"\r", b"\n", b""): + peek = stream.read(1) + else: + operands.append(read_object(stream, None, self.forced_encoding)) diff -Nru pypdf-3.4.1/debian/patches/series pypdf-3.4.1/debian/patches/series --- pypdf-3.4.1/debian/patches/series 2023-02-14 16:58:00.0 -0500 +++ pypdf-3.4.1/debian/patches/series 2024-01-15 11:28:43.0 -0500 @@ -1,2 +1,3 @@ 0001-Use-formal-Cryptodome-namespace.patch 0002-mark-new-external-tests-appropriately.patch +0003-Prevent-infinite-loop-when-no-character-follows-afte.patch
Bug#1060463: O: django-impersonate -- Django module for superusers to impersonate accounts
Package: wnpp Severity: normal X-Debbugs-Cc: debian-pyt...@lists.debian.org Control: affects -1 src:django-impersonate Orphaning the package on behalf of the Debian Python Team as the sole uploader (no one else on the team expressed interest in taking over and I no longer use the package). Currently the package is in good shape. There is a new upstream release available, which I will include in the upload that changes the maintainer to Debian QA Group. Scott K
Bug#1060427: python3-appdirs: Do not release with trixie
Package: python3-appdirs Version: 1.4.4-4 Severity: serious Justification: maintainer determination This is dead upstream and easily replacable with platformdirs. Rather than release trixie with appdirs, remaining users should port to platformdirs instead. Scott K
Bug#1060406: O: django-organizations -- Django groups and multi-user account management module
Package: wnpp Severity: normal X-Debbugs-Cc: debian-pyt...@lists.debian.org Control: affects -1 src:django-organizations Orphaning the package on behalf of the Debian Python Team as the sole uploader (no one else on the team expressed interest in taking over and I no longer use the package). Currently the package is in good shape. There is a new upstream release available, which I will probably include in the upload that changes the maintainer to Debian QA Group. Scott K
Bug#1059230: Stable Updates Available
Updated packages are available from stable/oldstable-updates. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1059230: Proposed Postfix SUA Text
Looks good to me. Thanks, Scott K On December 29, 2023 11:29:21 AM UTC, Jonathan Wiltshire wrote: >On Thu, Dec 28, 2023 at 03:31:55PM -0500, Scott Kitterman wrote: >> Postfix is a High-performance mail transport agent. >> >> Upstream published versions 3.5.23 and 3.7.9. >> >> These are bug-fix releases. The changes are not currently required for >> operation, but upstream strongly recommends that users update. >> >> Changes since 3.5.18 and 3.7.6 currently in bullseye and bookworm include >> fixes >> for multiple implementation defects identified since these packages were >> last >> updated, see debian/changelog for details. Of particular note is a new >> optional feature to prevent 'SMTP Smuggling' attacks. It is disabled by >> default. A configuration change is required to enable this protection [1]. >> >> If you use postfix, we recommend that you install this update. >> >> [1] https://www.postfix.org/smtp-smuggling.html > >The important part is the CVE fix with config change requirement, no? How >about this, rephrasing to shift the emphasis: > >| Postfix is a high-performance mail transport agent. >| >| This update consists of recommended upstream bug fixes since the versions >| in bullseye and bookworm. In particular, a fix for CVE-2023-51764 (SMTP >| smuggling) requires a configuration change to take full effect. >| >| The configuration change is not done automatically to avoid causing >| issues with existing installations. Users should consult the relevant >| Postfix documentation [1] before setting "smtpd_forbid_bare_newline = yes" >| in the main.cf file. >| >| 1: https://www.postfix.org/smtp-smuggling.html > >If you are able to comment before 13:00 UTC I can get it out this >afternoon. > >Thanks, > >
Bug#1059230: Proposed Postfix SUA Text
Postfix is a High-performance mail transport agent. Upstream published versions 3.5.23 and 3.7.9. These are bug-fix releases. The changes are not currently required for operation, but upstream strongly recommends that users update. Changes since 3.5.18 and 3.7.6 currently in bullseye and bookworm include fixes for multiple implementation defects identified since these packages were last updated, see debian/changelog for details. Of particular note is a new optional feature to prevent 'SMTP Smuggling' attacks. It is disabled by default. A configuration change is required to enable this protection [1]. If you use postfix, we recommend that you install this update. [1] https://www.postfix.org/smtp-smuggling.html signature.asc Description: This is a digitally signed message part.
Bug#1059500: bullseye-pu: package postfix/3.5.18-0+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
This is another of the regular postfix maintenance updates. It
encompasses five upstream updates (3.5.19 - 3.5.23) because
life intervened and I got behind. This one is of particular importance/
urgency since it includes a new setting to address CVE-2023-51764.
[ Impact ]
Bugs remain unfixed, CVE-2023-51764 unresolved.
[ Tests ]
There is a high level autopkgtest.
[ Risks ]
Risks are low. These have all been released as part of upstream
maintenance and no regressions have been reported. There are no changes
in Debian packaging.
[ Checklist ]
[X] *all* changes are documented in the d/changelog
[X] I reviewed all changes and I approve them
[X] attach debdiff against the package in (old)stable
[X] the issue is verified as fixed in unstable
[ Changes ]
* 3.5.19
- Portability: the EVP_get_digestbyname change broke OpenSSL
1.0.2 support. File: tls/tls.h.
- Bugfix (introduced: Postfix 3.4): the posttls-finger command
failed to detect that a connection was resumed in the case
that a server did not return a certificate. Viktor Dukhovni.
File: posttls-finger/posttls-finger.c.
- Workaround: OpenSSL 3.x EVP_get_cipherbyname() can return
lazily-bound handles. Postfix now checks that the expected
functionality will be available instead of failing later.
Fix by Viktor Dukhovni. File: tls/tls_server.c.
- Bugfix (introduced: Postfix 3.5): check_ccert_access did
not parse inline map specifications. Report and fix by Sean
Gallagher. File: global/map_search.c.
- Safety: the long form "{ name = value }" in import_environment
or export_environment is not documented, but accepted, and
it was stored in the process environment as the invalid
form "name = value", thus not setting or overriding an entry
for "name". This form is now stored as the expected
"name=value". Found during code maintenance. Also refined
the "missing attribute name" detection. Files: clean_env.c,
split_nameval.c.
- Bugfix (introduced: Postfix 3.2): the MySQL client could
return "not found" instead of "error" during the time that
all MySQL server connections were turned down after error.
Found during code maintenance. File: global/dict_mysql.c.
* 3.5.20
- Bugfix (defect introduced: Postfix 1.0): the command "postconf
.. name=v1 .. name=v2 .." (multiple instances of the same
parameter name) created multiple name=value entries with
the same parameter name. It now logs a warning and skips
the earlier update. Found during code maintenance. File:
postconf/postconf_edit.c
- Bugfix (defect introduced: Postfix 3.3): the command "postconf
-M name1/type1='name2 type2 ...'" died with a segmentation
violation when the request matched multiple master.cf
entries. The master.cf file was not damaged. Problem reported
by SATOH Fumiyasu. File: postconf/postconf_master.c.
- Bugfix (defect introduced: Postfix 2.11): the command
"postconf -M name1/type1='name2 type2 ...'" could add a
service definition to master.cf that conflicted with an
already existing service definition. It now replaces all
existing service definitions that match the service pattern
'name1/type1' or the service name and type in 'name2 type2
...' with a single service definition 'name2 type2 ...'.
Problem reported by SATOH Fumiyasu. File: postconf/postconf_edit.c.
- Bitrot: preliminary support for OpenSSL configuration files,
primarily OpenSSL 1.1.1b and later. This introduces new
parameters "tls_config_file" and "tls_config_name", which
can be used to limit collateral damage from OS distributions
that crank up security to 11, increasing the number of
plaintext email deliveries. Details are in the postconf(5)
manpage under "tls_config_file" and "tls_config_name".
Viktor Dukhovni. Files: mantools/postlink, proto/postconf.proto,
global/mail_params.h, posttls-finger/posttls-finger.c,
smtp/smtp.c, smtp/smtp_proto.c, tls/tls_client.c, tls/tls.h,
tls/tls_misc.c, tls/tls_proxy_client_print.c,
tls/tls_proxy_client_scan.c, tls/tls_proxy.h, tls/tls_server.c,
tlsproxy/tlsproxy.c.
- Cleanup: use TLS_CLIENT_PARAMS to pass the OpensSSL 'init'
configurations. This information is independent from the
client or server TLS context, and therefore does not belong
in tls_*_init() or tls_*_start() calls. The tlsproxy(8)
server uses TLS_CLIENT_PARAMS to report differences between
its own global TLS settings, and those from its clients.
Files: posttls-finger/posttls-finger.c, smtp/smtp.c,
smtp/smtp_proto.c, tls/tls.h, tls/tls_proxy_client_misc.c,
tls/tls_proxy_client_print.c, tls/tls_proxy_client_scan.c,
Bug#1059402: bookworm-pu: package postfix/3.7.6-0+deb12u2
class/type value
+*.one.example IN CNAME *.other.example
+*.other.example IN A 10.0.0.1
+*.other.example IN TLSA ..certificate info...
+ Such syntax is blesed in RFC 1034 section 4.3.3.
+ This problem was reported first in the context of TLSA
+ record lookups. Files: util/valid_hostname.[hc],
+ * 3.7.8
+- Bugfix (defect introduced Postfix 2.5, 20080104): the Postfix
+ SMTP server was waiting for a client command instead of
+ replying immediately, after a client certificate verification
+ error in TLS wrappermode. Reported by Andreas Kinzler. File:
+ smtpd/smtpd.c.
+- Usability: the Postfix SMTP server now attempts to log the
+ SASL username after authentication failure. In Postfix
+ logging, this appends ", sasl_username=xxx" after the reason
+ for SASL authentication failure. The logging replaces an
+ unavailable reason with "(reason unavailable)", and replaces
+ an unavailable sasl_username with "(unavailable)". Based
+ on code by Jozsef Kadlecsik. Files: xsasl/xsasl_server.c,
+ xsasl/xsasl_cyrus_server.c, smtpd/smtpd_sasl_glue.c.
+- Bugfix (defect introduced: Postfix 2.11): in forward_path,
+ the expression ${recipient_delimiter} would expand to an
+ empty string when a recipient address had no recipient
+ delimiter. Fixed by restoring Postfix 2.10 behavior to use
+ a configured recipient delimiter value. Reported by Tod
+ A. Sandman. Files: proto/postconf.proto, local/local_expand.c.
+ * 3.7.9 (Closes: #1059230)
+- Addresses CVE-2023-51764, requires configuration change
+- Security: with "smtpd_forbid_bare_newline = yes" (default
+ "no" for Postfix < 3.9), reply with "Error: bare
+ received" and disconnect when an SMTP client sends a line
+ ending in , violating the RFC 5321 requirement that
+ lines must end in . This prevents SMTP smuggling
+ attacks that target a recipient at a Postfix server. For
+ backwards compatibility, local clients are excluded by
+ default with "smtpd_forbid_bare_newline_exclusions =
+ $mynetworks". Files: mantools/postlink, proto/postconf.proto,
+ global/mail_params.h, global/smtp_stream.c, global/smtp_stream.h,
+
+ -- Scott Kitterman Sun, 24 Dec 2023 12:33:24 -0500
+
postfix (3.7.6-0+deb12u2) bookworm; urgency=medium
* Correct regression that caused postfix set-permissions to fail (Closes:
diff -Nru postfix-3.7.6/HISTORY postfix-3.7.9/HISTORY
--- postfix-3.7.6/HISTORY 2023-06-05 15:59:49.0 -0400
+++ postfix-3.7.9/HISTORY 2023-12-21 21:01:13.0 -0500
@@ -26594,3 +26594,70 @@
(default: no) to disconnect remote SMTP clients that violate
RFC 2920 (or 5321) command pipelining constraints. Files:
global/mail_params.h, smtpd/smtpd.c, proto/postconf.proto.
+
+20230815
+
+ Bugfix (bug introduced: 20140218): when opportunistic TLS fails
+ during or after the handshake, don't require that a probe
+ message spent a minimum time-in-queue before falling back to
+ plaintext. Problem reported by Serg. File: smtp/smtp.h.
+
+20230819
+
+ Bugfix (defect introduced: 19980207): the valid_hostname()
+ check in the Postfix DNS client library was blocking unusual
+ but legitimate wildcard names (*.name) in some DNS lookup
+ results and lookup requests. Examples:
+
+name class/type value
+*.one.example IN CNAME *.other.example
+*.other.example IN A 10.0.0.1
+*.other.example IN TLSA ..certificate info...
+
+ Such syntax is blesed in RFC 1034 section 4.3.3.
+
+ This problem was reported first in the context of TLSA
+ record lookups. Files: util/valid_hostname.[hc],
+ dns/dns_lookup.c.
+
+20230929
+
+ Bugfix (defect introduced Postfix 2.5, 20080104): the Postfix
+ SMTP server was waiting for a client command instead of
+ replying immediately, after a client certificate verification
+ error in TLS wrappermode. Reported by Andreas Kinzler. File:
+ smtpd/smtpd.c.
+
+20231006
+
+ Usability: the Postfix SMTP server now attempts to log the
+ SASL username after authentication failure. In Postfix
+ logging, this appends ", sasl_username=xxx" after the reason
+ for SASL authentication failure. The logging replaces an
+ unavailable reason with "(reason unavailable)", and replaces
+ an unavailable sasl_username with "(unavailable)". Based
+ on code by Jozsef Kadlecsik. Files: xsasl/xsasl_server.c,
+ xsasl/xsasl_cyrus_server.c, smtpd/smtpd_sasl_glue.c.
+
+20231026
+
+ Bugfix (defect introduced: Postfix 2.11): in forward_path,
+ the expression ${recipient_delimiter} would expand to an
+ empty string when a recipient address had no recipient
+
Bug#1054485: postfix: diff for NMU version 3.8.2-1.1
On Monday, December 18, 2023 7:31:47 PM EST Chris Hofstaedtler wrote: > Control: tags 1054485 + patch > Control: tags 1054485 + pending > > Dear maintainer, > > I've prepared an NMU for postfix (versioned as 3.8.2-1.1) and > uploaded it to DELAYED/7. Please feel free to tell me if I > should delay it longer. Better, upload yourself in the meantime. > > Best, > Chris Thank you for preparing this. I've just done a maintainer upload with this change as well as a new upstream release. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1059230: postfix: SMTP Smuggling attack
On Thursday, December 21, 2023 11:57:21 AM EST Salvatore Bonaccorso wrote: > Source: postfix > Version: 3.8.2-1 > Severity: important > Tags: security upstream > Forwarded: > https://www.mail-archive.com/postfix-users@postfix.org/msg100901.html > X-Debbugs-Cc: car...@debian.org, Debian Security Team > Control: found -1 3.7.6-0+deb12u2 > Control: found -1 3.5.18-0+deb11u1 > Control: found -1 3.4.23-0+deb10u1 > > Hi > > There was a SMTP smuggling vulerability reported, for which in some > Postfix versions at least already exists short term mitiations in form > of "smtpd_forbid_unauth_pipelining = yes". > > Details via: > > https://www.mail-archive.com/postfix-users@postfix.org/msg100901.html > https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwid > e/ See https://www.postfix.org/smtp-smuggling.html for the most recent information. The mitigation is available for stable, but not yet oldstable. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1053215: ITP: needrestart-gui -- web interface for needrestart
On September 29, 2023 11:57:52 AM UTC, Thomas Goirand wrote: >Package: wnpp >Severity: wishlist >Owner: Thomas Goirand >X-Debbugs-Cc: debian-de...@lists.debian.org > >* Package name: needrestart-gui > Version : 0.0.1 > Upstream Contact: Axel Jacquet >* URL : >https://salsa.debian.org/openstack-team/third-party/needrestart-gui >* License : most-permissive > Programming Lang: Python > Description : web interface for needrestart > > This package provides a Python implementation to monitor services and provides > a GUI to show their status and package versions. It uses in the background the > needrestart package. > Is this for any service that needs restart or just for Openstack services? If it's the latter (and glancing at the code, it seems it might be) then that ought to be in the package description. Scott K
Bug#1050053: xml2rfc: recommends empty package fonts-noto-unhinted
On September 15, 2023 5:37:23 AM UTC, Jonas Smedegaard wrote: >Scott Kitterman wrote: >>> Please change the dependency to the appropriate package instead. >>> Thank you. >> Which one is that? I can't find any indication in the package what >> replaced it. > >The binary package fonts-noto-unhinted is currently empty because it >contained only fonts lacking hinting, and currently all fonts provided >from same source package are available with hinting. > >So I would turn the question around: Do xml2rfc require fonts without >hinting, or does it require certain specific fonts which formerly >existed only without hinting? Unhinted is what the upstream documentation specifies: https://salsa.debian.org/debian/pkg-xml2rfc/-/blob/debian/sid/README.md Scott K
Bug#1050683: pep517: Should not be released with Trixie
Source: pep517 Severity: serious Justification: Maintainer opinion This package has been replace by python-pyproject-hooks and should not be in Trixie. Scott K
Bug#1049372: RM: gio-sharp -- RoQA; depends on gtk2; dead upstream; low popcon
On Sat, 26 Aug 2023 09:21:21 +0200 Bastian Germann wrote: > Control: tags -1 - moreinfo > > Am 26.08.23 um 01:18 schrieb Scott Kitterman: > > Checking reverse dependencies... > > # Broken Depends: > > smuxi: smuxi-frontend-gnome > > > > Dependency problem found. > > That package is gone now. Thanks. I don't know why, but this one didn't show up before (or I missed it): Checking reverse dependencies... # Broken Build-Depends: golang-github-twstrike-gotk3adapter: libgio-cil Dependency problem found. This also needs to be addressed. Once again, please remove the moreinfo tag once it's resolved. Scott K
Bug#1050491: Bug#1049876: Bug#1050491: RM: bbhash [armel armhf i386 mipsel powerpc Buildd exposure stats hurd-i386 hppa sh4] -- ROM; Does not build on 32bit architectures
On August 25, 2023 10:58:03 AM UTC, Andreas Tille wrote: >Am Fri, Aug 25, 2023 at 09:46:43AM + schrieb Graham Inggs: >> >> Andreas, what 32-bit builds? bbhash has never built on 32-bit architectures. > >Good question - I was not properly looking at the build matrix. >Sorry for the noise > >> Emanuele, since when is this RC? > >I'm tempted to close this bug since its at best wishlist but there >is no point at all to provide this package for 32bit. If you want to keep it, reassign it back to the package. As a rm bug it should definitely be closed. Scott K
Bug#1043002: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends
On Friday, August 18, 2023 9:33:48 AM EDT Andreas Tille wrote: > Hi Scott, > > Am Fri, Aug 18, 2023 at 01:15:18PM + schrieb Scott Kitterman: > > On August 18, 2023 1:04:26 PM UTC, Andreas Tille wrote: > > >> In Debian terms, it's not the preferred form for modification, so it's > > >> not source. In this regard DFSG goes farther than some software > > >> licenses.> > > > >I think the point Jeroen wanted to make is that these are actually > > >source file archives which "by chance" are featuring a .whl extension > > >rather than a .zip extension. > > > > A wheel is not the preferred form for modification. They're not wheels by > > chance at all. > Yes, thanks to Jeroen's hint I realised this as well and I agree that > this is a nasty way to hide the fact that the files are actually source > archives. They aren't. > However, you confirmed yourself that future_fstrings is an exception and > comes with source and thus does not violate DFSG. The only difference > I personally can see is that the archives are just hiding what they are. > We could simply add do some >for whl in *.whl ; do ln -s $whl $(basename .whl).zip ; done > and we have source archives that are obviously what they are. > > > From a DFSG perspective, > > Hmmm, the only thing where I can draw a violation of the DFSG is that > there are no d/copyright entries for the source code that is hidden > inside these *.whl files. Otherwise its "just" duplicated code (in most > cases) which is definitely not nice but IMHO not a violation of DFSG. > The disagreement here is that Python wheels aren't source. DFSG #2 requires the source be present and these aren't it. If you look at the WAF entry in the FTP team reject FAQ, this is similar. The FTP team view has long been that DFSG #2 means the actual preferred form for modification. > > the most straightforward approach is to build-depend on the relevant > > Debian packages and build any needed wheels from that. > Do avoid source code duplication I'm willing to do that. Yes, I > perfectly agree that its pretty ugly (I'm just a bit unsure about > the DFSG violation). I'm wondering whether a simple > >zip whl.zip /path/to/python/files ; mv whl.zip whl.whl > > will be something that can replace the current packages. I think > we also need to patch the tests to fit the version numbers (if > we do not want to cheat and simply use the version numbers of the > original whl files to avoid patching). Perhaps, but there are nuances to the wheel format. Please use Wheel to generate them. > > It won't necessarily get you the same version as upstream uses, but it's > > definitely DFSG compliant. > We also might symlink our resulting whl files with the version number > pdm upstream might expect in their tests. The question is, whether all > this effort might break the tests in some way and we might end up with > endless patching by at the same time loosing the chance to discuss with > upstream. But it might be time to discuss the issue with upstream > anyway. Perhaps. If it were me, what I'd do is locate the missing tarballs and stash them in debian/missing-sources/ and worry about more complex solutions later. Once you're done that, you've met DSFG #2 and there's no need to strip the wheels from the binary. It's not super maintainable, but it will allow you to focos on getting the tests working as upstream ships them without any Debian customizations that might cause Debian specific failures. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1043002: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends
On August 18, 2023 1:04:26 PM UTC, Andreas Tille wrote: >Hi Scott, > >Am Tue, Aug 15, 2023 at 02:18:35PM + schrieb Scott Kitterman: >> >They are zip files containing python source code. It is possible to include >> >compiled C extensions in wheels, but I checked and these wheels are all pure >> >python, so no binary blobs are included. >> >> In Debian terms, it's not the preferred form for modification, so it's not >> source. In this regard DFSG goes farther than some software licenses. > >I think the point Jeroen wanted to make is that these are actually >source file archives which "by chance" are featuring a .whl extension >rather than a .zip extension. A wheel is not the preferred form for modification. They're not wheels by chance at all. From a DFSG perspective, the most straightforward approach is to build-depend on the relevant Debian packages and build any needed wheels from that. It won't necessarily get you the same version as upstream uses, but it's definitely DFSG compliant. Scott K
Bug#1043002: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends
pdm is the last remaining blocker for pep517 removal. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1043002: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends
On August 15, 2023 1:51:54 PM UTC, Jeroen Dekkers wrote: >On Tue, 15 Aug 2023 15:08:11 +0200, >Scott Kitterman wrote: >> >> On Tuesday, August 15, 2023 3:53:07 AM EDT Andreas Tille wrote: >> > Hi Scott, >> > >> > Am Mon, Aug 14, 2023 at 02:06:42PM + schrieb Scott Kitterman: >> > >> > > those are all binary without source. That's a problem. >> > >> > Given your role as ftpmaster you definitely have more experience than I >> > in this field. I personally was thinking more in the line of binary >> > data we can not avoid in some cases. This is a bit in the line with >> > Rdata decision[1] where those binary data files are documented in >> > debian/README.source. >> > >> > My point is just: If we remove those data files (which are IMHO harmless >> > since these are not executd but used as input in tests - please correct >> > me if I'm wrong) we can not test the package. Removing the files >> > prevents testing and thus we can not know whether the package we deliver >> > will work. I've actually shown that not all tests are working but >> > stopped investigating this further. >> >> Even if they are used as data (I didn't check), they are, in fact, binary >> blobs of code by our definition and that requires the corresponding source. > >They are zip files containing python source code. It is possible to include >compiled C extensions in wheels, but I checked and these wheels are all pure >python, so no binary blobs are included. In Debian terms, it's not the preferred form for modification, so it's not source. In this regard DFSG goes farther than some software licenses. Scott K
Bug#1043002: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends
On Tuesday, August 15, 2023 3:53:07 AM EDT Andreas Tille wrote: > Hi Scott, > > Am Mon, Aug 14, 2023 at 02:06:42PM + schrieb Scott Kitterman: > > >Before I upload I'd like to ask for reviewing this patch and opinions > > >about the test suite errors. While these possibly occure in previous > > >versions (which I did not tested) we might consider ignoring just the > > >failing tests. I need to admit that I did not went through the list of > > >single failures - may be there is a chance of easy fixes for some of > > >them. I simply wanted to discuss the reintroduction of the artifacts > > >and my patch first. > > > > With the exception of future_fstrings > > I think there is also the souce for demo included. > > > those are all binary without source. That's a problem. > > Given your role as ftpmaster you definitely have more experience than I > in this field. I personally was thinking more in the line of binary > data we can not avoid in some cases. This is a bit in the line with > Rdata decision[1] where those binary data files are documented in > debian/README.source. > > My point is just: If we remove those data files (which are IMHO harmless > since these are not executd but used as input in tests - please correct > me if I'm wrong) we can not test the package. Removing the files > prevents testing and thus we can not know whether the package we deliver > will work. I've actually shown that not all tests are working but > stopped investigating this further. Even if they are used as data (I didn't check), they are, in fact, binary blobs of code by our definition and that requires the corresponding source. > > It's probably okay if you add the corresponding source somewhere in the > > package. > We probably have some source packages inside Debian - may be in > different versions. I need to admit that I intended to do a "quick fix > of a simple bug that affects some Debian Med packages" but realised that > I'm possibly opening a can of worms. The simplest solution to fulfill > my needs would be probably to revert my change to run the tests and be > done. However, I'm not sure whetherr this is in the interest of the > users of this package. I'm absolutely not able time-wise to povide > sources and reconstruct all those *.whl files *and* in addition track > down the test suite errors. This is a team package and if the team > decides we should go without testing I can do an according upload. > However, my prefered path would to document the issue of some binary > data properly an test what upstream expects to be tested. i think this is definitely more complicated than you want to take on casually. I don't think it's required to actually rebuild the wheels. If you provide the source, the DFSG is happy. You have to be able to rebuild it, but you aren't required to do it. It might, however, be simpler in the long run to just depend on those packages and build wheels from those (a Debian binary package has enough in it generally to build a wheel from it). I agree it'd be better in the long run to run the tests, but that may be more than you want to take on right now. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1043002: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends
On August 14, 2023 12:28:30 PM UTC, Andreas Tille wrote: >Control: tags -1 pending > >Hi, > >I've fixed the issue reported in this bug[1]. > >In addition I've took the chance to upload pdm to its latest upstream >version. When doing so I realised that build time tests are basically >ignored. This was mainly due to the removal of artefacts that are used >for testing. I admit I do not see any reason to remove those data >files - in Debian R team this kind of data files which is just used for >testing is accepted. Thus I took the freedom to re-introduce these >files and was running the tests in d/rules. Unfortunately there is >quite a number of tests failing > > 54 failed, 620 passed, 1 xfailed, 3 rerun in 228.94s (0:03:48) > > >(see Salsa CI[2]) > >I'd like to stress that to run those tests at all I needed a patch[3] >since BaseProvider can't be simply imported from findpython. > >Before I upload I'd like to ask for reviewing this patch and opinions >about the test suite errors. While these possibly occure in previous >versions (which I did not tested) we might consider ignoring just the >failing tests. I need to admit that I did not went through the list of >single failures - may be there is a chance of easy fixes for some of >them. I simply wanted to discuss the reintroduction of the artifacts >and my patch first. > With the exception of future_fstrings those are all binary without source. That's a problem. It's probably okay if you add the corresponding source somewhere in the package. I do think it's odd that pdm would need poetry-core in its test suit. Scott K
Bug#1023512: Naming of python binary packages
On Friday, August 11, 2023 10:49:00 AM EDT Stefano Rivera wrote: > My vote would be strongly towards maintaining the status quo of the > policy-defined names. > > I don't see any strong argument for changing this. Fully agreed. In addition to the reasons you listed, renaming a lot of packages would require a trip through New. I think we have enough backlog there without renaming a bunch of packages for a not very good reason. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1043002: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends
On Thu, 03 Aug 2023 23:52:10 -0400 Scott Kitterman wrote: > Source: pdm > Version: 2.2.1+ds1-1 > Severity: important > > The python3-pep517 package has been replaced by python3-pyproject-hooks. > Please update your package depends and build-depends (this may required > a new upstream release - I did check and the current upstream release > supports using pyproject-hooks). > > Once I request removal, I'll raise the severity of this to serious. I > expect that by next week we'll be down to only two or three packages > left that use pep517, so I'll probably request it then. If you need > more time to update this package, I can wait, please let me know. RM has been requested (See #1043255). Bumping to serious. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1042965: py7zr: Remove unneeded build-depends on deprecate pep517
On Thu, 03 Aug 2023 08:02:16 -0400 Scott Kitterman wrote: > Source: py7zr > Version: 0.11.3+dfsg-5 > Severity: important > Tags: patch > > The pep517 package has been superceded by python-pyproject-hooks. It > looks like this package added a build-depends on python3-pep517 > relatively early in our fielding of the ability to build Debian packages > based on pyproject.toml. This build dependency is no longer needed and > can be simply removed. > > I did test that the package built without it. See the attached patch. > I am happy to address this as a team upload if you would prefer. I will > soon be requesting removal of the pep517 package and I intend to bump > the severity of this when I do if it's not resolved by then. RM has been requested (See #1043255). Bumping to serious. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1042869: sniffles: Please update to newer version without python3-pep517 requirement
On Tue, 01 Aug 2023 22:36:34 -0400 Scott Kitterman wrote: > Source: sniffles > Version: 2.0.7-1 > Severity: important > > Currently sniffles build-depends on python3-pep517. This package has > been replaced upstream by python3-pyproject-hooks, which is now in > Debian. As a result, python3-pep517 will be removed soon. > > There appears to be a newer version of sniffles that does not use > python3-pep517 (I did not check if the current version acutally requires > it of the the build-depend is unneeded). Please upgrade to the newer > version or otherwise remove the build-depends on python3-pep517. > > Once I file the rm bug for it, I'll increase this to serious, so please > address it now. RM has been requested (See #1043255). Bumping to serious. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1043255: RM: pep517 -- ROM; Obsolete, replaced by python-pyproject-hooks
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: debian-pyt...@lists.debian.org Python-pyproject-hooks has replaced pep517, so it should be removed once there are no more reverse Build-Depends. Most packages have been updated and bugs have been filed for the three remaining. Scott K
Bug#1030290: Should have been RC
Bumped severity to serious as the package is not working at all. Although fixed in Unstable, it still affects Stable and should be fixed there as well. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1030835: ITP: ruff -- linter for Python, written in Rust
On Wed, 08 Feb 2023 01:00:19 + James Addison wrote: > Package: wnpp > Severity: wishlist > Owner: James Addison > X-Debbugs-Cc: debian-de...@lists.debian.org > > * Package name: ruff > Version : 0.0.243 > Upstream Contact: Charlie Marsh > * URL : https://github.com/charliermarsh/ruff/ > * License : MIT > Programming Lang: Rust > Description : linter for Python, written in Rust > > Ruff is a linter for Python that includes implementations of many common > checks implemented by flake8, flake8 plugins, and pylint. It appears the original reporter is no longer active in Debian (Salsa account deactivated), so converting to RFP. It would be nice to see this, but I do not intend to package it. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1043002: pdm: Please replace python3-pep517 with python3-pyproject-hooks in Depends/Build-Depends
Source: pdm Version: 2.2.1+ds1-1 Severity: important The python3-pep517 package has been replaced by python3-pyproject-hooks. Please update your package depends and build-depends (this may required a new upstream release - I did check and the current upstream release supports using pyproject-hooks). Once I request removal, I'll raise the severity of this to serious. I expect that by next week we'll be down to only two or three packages left that use pep517, so I'll probably request it then. If you need more time to update this package, I can wait, please let me know. Scott K
Bug#1042965: py7zr: Remove unneeded build-depends on deprecate pep517
Source: py7zr Version: 0.11.3+dfsg-5 Severity: important Tags: patch The pep517 package has been superceded by python-pyproject-hooks. It looks like this package added a build-depends on python3-pep517 relatively early in our fielding of the ability to build Debian packages based on pyproject.toml. This build dependency is no longer needed and can be simply removed. I did test that the package built without it. See the attached patch. I am happy to address this as a team upload if you would prefer. I will soon be requesting removal of the pep517 package and I intend to bump the severity of this when I do if it's not resolved by then. Scott K diff -Nru py7zr-0.11.3+dfsg/debian/changelog py7zr-0.11.3+dfsg/debian/changelog --- py7zr-0.11.3+dfsg/debian/changelog 2023-03-25 18:50:07.0 -0400 +++ py7zr-0.11.3+dfsg/debian/changelog 2023-08-02 10:11:34.0 -0400 @@ -1,3 +1,10 @@ +py7zr (0.11.3+dfsg-6) unstable; urgency=medium + + * Team upload. + * Drop build-depends on python3-pep517, deprecated, no longer needed + + -- Scott Kitterman Wed, 02 Aug 2023 10:11:34 -0400 + py7zr (0.11.3+dfsg-5) unstable; urgency=medium [ YOKOTA Hiroshi ] diff -Nru py7zr-0.11.3+dfsg/debian/control py7zr-0.11.3+dfsg/debian/control --- py7zr-0.11.3+dfsg/debian/control2023-03-25 18:50:07.0 -0400 +++ py7zr-0.11.3+dfsg/debian/control2023-08-02 10:06:35.0 -0400 @@ -6,7 +6,6 @@ Build-Depends: debhelper-compat (= 13), pybuild-plugin-pyproject, python3-all-dev, - python3-pep517, python3-pyannotate , python3-pycryptodome , python3-pytest ,
Bug#1042869: sniffles: Please update to newer version without python3-pep517 requirement
Source: sniffles Version: 2.0.7-1 Severity: important Currently sniffles build-depends on python3-pep517. This package has been replaced upstream by python3-pyproject-hooks, which is now in Debian. As a result, python3-pep517 will be removed soon. There appears to be a newer version of sniffles that does not use python3-pep517 (I did not check if the current version acutally requires it of the the build-depend is unneeded). Please upgrade to the newer version or otherwise remove the build-depends on python3-pep517. Once I file the rm bug for it, I'll increase this to serious, so please address it now. Thanks, Scott K
Bug#1042541: ITP: libmozilla-publicsuffix-perl -- Perl interface to the Mozilla Public Suffix List
On July 31, 2023 2:30:33 PM UTC, gregor herrmann wrote: >On Sun, 30 Jul 2023 14:47:28 +0200, gregor herrmann wrote: > >> So in the end I guess we need to patch lib/Mozilla/PublicSuffix.pm to >> read /usr/share/publicsuffix/effective_tld_names.dat dynamically … > >Done (in git) now. > >Thanks again for pointing me in the right direction :) > Sounds great. Approximately all language environments have or will soon have an interface to the PSL. Many of the issues are common across the different language implementations. Glad I could help. Scott K
Bug#1042541: ITP: libmozilla-publicsuffix-perl -- Perl interface to the Mozilla Public Suffix List
On July 30, 2023 2:30:29 AM UTC, gregor herrmann wrote: >On Sun, 30 Jul 2023 02:06:03 +0000, Scott Kitterman wrote: > >> Debian provides a system PSL in the publicsuffix package. Please >> depend on and use that rather than the bundled copy or the facility >> the package provides for downloading a newer version. > >Thanks for the pointer. > >I'm now build-depending on publicsuffix and copying effective_tld_names.dat >from the publicsuffix package over the shipped version in >override_dh_auto_configure. >(The perl bindings in /usr/share/perl5/Mozilla/PublicSuffix.pm are >generated from effective_tld_names.dat at configure time.) The publicsuffix package is often updated. If you do it that way, you won't get the new version without rebuilding the package. I'd suggest using Depends and installing a symlink to the file it provides, so you always get the current version's data. Scott K
Bug#1042541: ITP: libmozilla-publicsuffix-perl -- Perl interface to the Mozilla Public Suffix List
Debian provides a system PSL in the publicsuffix package. Please depend on and use that rather than the bundled copy or the facility the package provides for downloading a newer version. Scott K
Bug#1041538: dh-python: Unhelpful inclusion of optional packages in Depends
On Friday, July 28, 2023 3:42:50 PM EDT Emmanuel Arias wrote: > Control: reassign -1 poetry-core > > Hi, > > Sorry for this delay. Yes as you mentioned Scott, you need to add the > optional dependency in the extras section, not only marked it as > optional=true. > > Poetry documentation[0] is not very explicit with that. > > There's an issue open [1]. I can work in a patch to at least raise an > exception o message when a dependency is marked as optional and is not > added to extras. But I agree that mark a deps as optional and then is > not optional is confusing. > > [0] https://python-poetry.org/docs/pyproject/#extras > [1] https://github.com/python-poetry/poetry/issues/2357 Thanks, For this particular package I pointed this out to upstream and it's fixed in their latest bug fix update. They were quite surprised that marking a dependency optional didn't actually do anything, so I think it would be good to get poetry to handle this better. Scott K signature.asc Description: This is a digitally signed message part.
Bug#1042465: python3-hypercorn: Aioquic now in the archive, so please update Recommends/Suggests
Package: python3-hypercorn Version: 0.14.4-1 Severity: normal As of today, aioquic (python3-aioquic) is in the archive, so it might be good to update either the package Recommends or Suggests to take advantage of this. I seen it's already mentioned in the package description. Scott K
