Bug#1075775: please package new upstream release 2.6.0 or greater to possibly support many new transit providers
Source: railway-gtk Version: 2.4.0-4 Severity: wishlist Hi friends, New versions of Railway appear to have added support for not only new transit routes, but also new services to discover transit routes. The current packaged version is geared towards rail travel in Europe, but it appears that the new version should be capable of public transportation more broadly, especially in the United States. Given that Google Maps alternatives such as OpenStreetMap are already uncommon in the US, I think this new upstream release could be a giant leap forward in breaking up the monoculture. At least for the large American bus network around me, it doesn't seem like there's any practical way to navigate it using free software. There are plans to change it, but for now public transit support in GNOME Maps is basically a patchwork that (I think) only covers a single US city. Thus I think that letting users get their feet wet with possibilities will also motivate discussions for the rest of the ecosystem to improve. I'm a Debian Maintainer for unrelated packages and have made small merge requests to GNOME packages before, so although it would be ambitious, please let me know if you'd like me to try this. Thanks -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unreleased'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.8.12-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, TAINT_FIRMWARE_WORKAROUND 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 -- no debconf information signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature
Bug#1042913: freecad: TechDraw workbench: part corner vertices and circle centers not showing up, unable to attach for draw dimensions
Package: freecad Version: 0.20.2+dfsg1-4 Followup-For: Bug #1042913 X-Debbugs-Cc: larri...@inbox.lv Dear Maintainer, I see this problem exactly as described. I downloaded/ran FreeCAD_0.20.2-2022-12-27-conda-Linux-x86_64-py310.AppImage and the problem does not appear to exist in upstream. I am eagerly awaiting the efforts of the smarter people. Regards, Scott. -- System Information: Debian Release: 12.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-22-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 freecad depends on: ii freecad-python3 0.20.2+dfsg1-4 Versions of packages freecad recommends: ii calculix-ccx 2.20-1 ii graphviz 2.42.2-7+b3 Versions of packages freecad suggests: pn povray -- no debconf information
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#1074497: wiki.debian.org: NVIDIA Optimus: Still necessary to avoid the intel Xorg driver?
Package: wiki.debian.org Severity: minor X-Debbugs-Cc: larri...@inbox.lv Dear Maintainer, '.. Also make sure that the outdated xserver-xorg-video-intel package is not installed. The "modesetting" xorg driver has superseded it and will be used in this configuration.' I have Debian 12.5 (i.e. current as of June 2024) but I have the intel driver installed. When I try to use apt to install the modesetting driver, I get a redirect to xserver-xorg-core and the result that everything is already up-to-date. Has the modesetting driver been withdrawn and superseded by the original drivers? Does the wiki need an update? Regards, Scott.
Bug#1074429: xml-security-c: CVE-2024-34580
TL;DR, This is not a vulnerability, it's a default that people don't like that required a minor update to change, and that wasn't going to happen. The code has been formally retired at Apache and forked for the Shibboleth Project's use, and there will be some form of official indication of that at some point later this summer. > The following vulnerability was published for xml-security-c. It is not a vulnerability, and should never have been published as one. It's a default that people don't like. I don't like a lot of defaults in lots of software but that doesn't make them vulnerabilities. > NOTE: the supplier disputes this CVE Record on the grounds > that they are | implementing the specification "correctly" > and are not "at fault." Yes, because those are the facts. The scare quotes are unnecessary, as is the entire CVE. > Not sure what to make out of this? It seems the use of xml >-security-sec within Shibboleth continues to be supported, > but otherwise the library is deemed deprecated, so maybe > this should at least be made explicit in the package > description? The mess around this invalid CVE led to my finally putting my foot down and demanding that we either retire the code or somebody else show up to help maintain it. Nobody did, so the Apache project retired that version of the library. The Shbboleth Project has forked the codebase for its own use since we were the only maintainers. It is effectively in the same state in terms of support as the xmltooling and opensaml libraries: they're for the Shibboleth SP's use and any other uses are not relevant to the maintainers of the code and bugs or requests that do not impact the SP will not be prioritized. Our needs are far less general than the original library's, so taking it over allows us to potentially do new releases that strip out a lot of code and attack surface, and to make different decisions in regard to API compatibility than could be made when it was a general-purpose tool. The code was only recently converted to git and we are still in the process of getting it in place and deciding what to do with it. I have no idea how the retirement is going to be managed from the Apache side. Something needs to be done with the wiki, etc., but none of that has been determined. Once the code is fully in place, I was planning to drop a note to the Debian packaging list for Shibboleth to note the change, as if the packaging continues, it should likely pull from our copy rather than the old one. I don't have an opinion really about what to do with the package. I'm not about to rename it because that's more work for me, not less. I could understand the feeling on the Debian side being different about the need to delineate the transition and retire the original package since it's unmaintained. -- Scott
Bug#1074146: Confirmation that Poppler's CVE-2024-6239 affects Buster and all subsequent releases
Control: found -1 poppler/0.71.0-5+deb10u3 Control: found -1 poppler/20.09.0-3.1+deb11u1 Control: found -1 poppler/22.12.0-2 Control: found -1 poppler/24.06.0-2 Since I couldn't find detailed information from upstream, I'd like to confirm that I was able to reproduce the crash on Buster, Bullseye, Bookworm, and experimental, and so the Security Tracker information is accurate. I am therefore updating the bug to indicate this as a courtesy to BTS users. Please note that the vulnerable code and its fix are exclusive to the pdfinfo utility in the poppler-utils binary package; the library is not affected. It might would be helpful if this bug were assigned to that binary package, but it's not my place to make that determination. I don't maintain this package, but do pitch in occasionally and keep a close eye on it. Thanks and please let me know if I can be of any assistance. -- Homepage https://johnscott.me 着 Contact info • as a vCard: https://johnscott.me/me/me.vcf • as an LDAP directory entry: ldap://johnscott.me/CN=John%20Scott,DC=johnscott,DC=me signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature
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#635834: Revisiting inclusion of AcroTeX/eForms in TeX Live in light of advancements in libre PDF readers
Hello, I must disclaim that I've not used these packages yet and would welcome being informed if I'm mistaken. It looks like both TeX Live and Debian have had reservations about shipping AcroTeX and eForms because at the time it was considered, the only PDF readers that appeared to support the features were proprietary ones. However, it seems that free PDF viewers have made great strides in the past several years especially in supporting these advanced features, so I think their inclusion in the standard distribution should be reconsidered. Free PDF viewers, especially Okular with the Poppler backend, have gained support for many of the features that have been standardized, including non-XFA forms, digital/cryptographic signature support, and JavaScript, all things that eForms appears to assist in making. There are probably still some things that AcroTeX and eForms can do that only proprietary readers support, but unless software patents muddy the waters, it seems like this can improve in client software at any time. Frankly I'm itching to use this functionality in my documents, but as a strong advocate for free software as well, I'd like to be informed if there are any freedom or distribution issues remaining. Thanks, John P.S. I'm having trouble subscribing, so please CC me on replies. -- Homepage: https://johnscott.me Contact info: as a vCard: https://johnscott.me/me/me.vcf or as an LDAP directory entry: ldap://johnscott.me/CN=John%20Scott,DC=johnscott,DC=me signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature
Bug#1071548: nmu: libwx-perl_1:0.9932-8+b7
Control: reopen -1 On Tue, 21 May 2024, Emilio Pozuelo Monfort wrote: On 21/05/2024 01:21, Scott Talbert wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: libwx-p...@packages.debian.org Control: affects -1 + src:libwx-perl User: release.debian@packages.debian.org Usertags: binnmu nmu libwx-perl_1:0.9932-8+b7 . ANY . unstable . -m "Rebuild with wxwidgets3.2 (3.2.5+dfsg-1)" (Please schedule this to rebuild after the corresponding libalien-wxwidgets-perl binNMU.) Scheduled. This one needs another binNMU also, depwaited on libalien-wxwidgets-perl 0.69+dfsg-6+b9. Thanks, Scott
Bug#1071547: nmu: libalien-wxwidgets-perl_0.69+dfsg-6+b7
Control: reopen -1 On Tue, 21 May 2024, Emilio Pozuelo Monfort wrote: On 21/05/2024 01:20, Scott Talbert wrote: Package: release.debian.org Severity: normal X-Debbugs-Cc: libalien-wxwidgets-p...@packages.debian.org Control: affects -1 + src:libalien-wxwidgets-perl User: release.debian@packages.debian.org Usertags: binnmu nmu libalien-wxwidgets-perl_0.69+dfsg-6+b7 . ANY . unstable . -m "Rebuild for wxwidgets3.2 (3.2.5+dfsg-1)" (Please schedule this to rebuild with wxwidgets3.2 (3.2.5+dfsg-1)) Scheduled. Hello, Unfortunately, it seems this was scheduled to execute immediately, rather than wait for wxwidgets3.2 (3.2.5+dfsg-1). So we're going to need another binNMU now that wx has been uploaded. Regards, Scott
Bug#1071548: nmu: libwx-perl_1:0.9932-8+b7
Package: release.debian.org Severity: normal X-Debbugs-Cc: libwx-p...@packages.debian.org Control: affects -1 + src:libwx-perl User: release.debian@packages.debian.org Usertags: binnmu nmu libwx-perl_1:0.9932-8+b7 . ANY . unstable . -m "Rebuild with wxwidgets3.2 (3.2.5+dfsg-1)" (Please schedule this to rebuild after the corresponding libalien-wxwidgets-perl binNMU.)
Bug#1071547: nmu: libalien-wxwidgets-perl_0.69+dfsg-6+b7
Package: release.debian.org Severity: normal X-Debbugs-Cc: libalien-wxwidgets-p...@packages.debian.org Control: affects -1 + src:libalien-wxwidgets-perl User: release.debian@packages.debian.org Usertags: binnmu nmu libalien-wxwidgets-perl_0.69+dfsg-6+b7 . ANY . unstable . -m "Rebuild for wxwidgets3.2 (3.2.5+dfsg-1)" (Please schedule this to rebuild with wxwidgets3.2 (3.2.5+dfsg-1))
Bug#1071488: udisks2: Syslog filled with "Error probing device: Error sending ATA command IDENTIFY DEVICE to '/dev/sdx': Unexpected sense data returned:"
Package: udisks2 Version: 2.9.4-4 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- 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-21-amd64 (SMP w/2 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 udisks2 depends on: ii dbus 1.14.10-1~deb12u1 ii libacl12.3.1-3 ii libatasmart4 0.19-5 ii libblockdev-fs22.28-2 ii libblockdev-loop2 2.28-2 ii libblockdev-part2 2.28-2 ii libblockdev-swap2 2.28-2 ii libblockdev-utils2 2.28-2 ii libblockdev2 2.28-2 ii libc6 2.36-9+deb12u7 ii libglib2.0-0 2.74.6-2+deb12u2 ii libgudev-1.0-0 237-2 ii libmount1 2.38.1-5+deb12u1 ii libpolkit-agent-1-0122-3 ii libpolkit-gobject-1-0 122-3 ii libsystemd0252.22-1~deb12u1 ii libudisks2-0 2.9.4-4 ii libuuid1 2.38.1-5+deb12u1 ii parted 3.5-3 ii udev 252.22-1~deb12u1 Versions of packages udisks2 recommends: ii dosfstools 4.2-1 ii e2fsprogs1.47.0-2 ii eject2.38.1-5+deb12u1 ii exfatprogs 1.2.0-1+deb12u1 ii libblockdev-crypto2 2.28-2 ii libpam-systemd 252.22-1~deb12u1 ii ntfs-3g 1:2022.10.3-1+b1 ii polkitd 122-3 Versions of packages udisks2 suggests: pn btrfs-progs pn f2fs-tools pn libblockdev-mdraid2 ii mdadm4.2-5 ii nilfs-tools 2.2.9-1 pn reiserfsprogs pn udftools pn udisks2-bcache pn udisks2-btrfs pn udisks2-lvm2 pn udisks2-zram pn xfsprogs -- no debconf information This started happening after I upgraded from Debian 11 to Debian 12. This copy of Debian is running as a VM under VMWare ESXi and I have a number of USB hard drives connected to it. This message is coming from two of them, one a Western Digital and one an older Buffalo. I've seen this bug reported in other venues (i.e. other distributions) but it never seems to get fixed, although in one report it looks like a maintainer said they were simply going to supress the message, which would be good. The message appears at about 6 minute intervals and is several individual lines which makes filtering it out with grep difficult. Here is an example of the message: May 20 01:00:50 lhNAS udisksd[65284]: Error probing device: Error sending ATA command IDENTIFY DEVICE to '/dev/sdm': Unexpected sense data returned: : f0 00 01 00 50 00 01 0a 80 00 00 00 00 1d 00 00P... 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 (g-io-error-quark, 0) Reports in other venues say the issue is most common with Western Digital drives. I've tried changing the loglevel in /etc/udisks2/udisks2.conf but that doesn't stop the messages even when set to the "Alert" level. Functionality isn't affected, but if you have a number of hard drives causing this message to be put out every 6 minutes it gets very difficult to find anything else in the log, especially since you have to use multiple filters to get rid of them all. This message should be eliminated or set to notice level and the loglevel directive in the config file then needs to be fixed to actaully affect messages going into the syslog.
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#1070130: python3-pycurl: SSL path issues - upstream bug
On Tue, 30 Apr 2024, i...@fernandolucas.info wrote: Package: python3-pycurl Version: 7.45.3-2 Severity: grave Tags: upstream Justification: renders package unusable Dear Maintainer, Please consider https://github.com/pycurl/pycurl/issues/834 pycurl 7.45.3 wheel not working for https in debian/ubuntu systems I confirm that the debian package for 7.45.3 fails sometimes to handle SSL connections, meanwhile 7.45.2 works properly always. Mabye it can be manually patched, or skip version 7.45.3 for debian. Are you having problems with the Debian packaged version of pycurl, or with the pycurl wheel from upstream? If the you're having problems with the packaged version of pycurl, can you please explain how to reproduce the problem? Thanks, Scott
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#1068868: ITP: python3-pyzmq -- Python bindings for 0MQ
Package: wnpp Severity: wishlist Owner: Cody Scott X-Debbugs-Cc: debian-de...@lists.debian.org, cody.sc...@giatec.ca * Package name: python3-pyzmq Version : 25.1.2 Upstream Contact: ZeroMQ * URL : https://pyzmq.readthedocs.io/en/latest/ * License : BSD Programming Lang: Python Description : Python bindings for 0MQ This will be used by Python applications that use ZeroMQ. There doesn't appear to be any other Python bindings for ZeroMQ. I plan to maintain it and I'm looking for a sponsor.
Bug#1068863: ITP: python3-atcom -- A tool which makes AT communication easier.
Package: wnpp Severity: wishlist Owner: Cody Scott X-Debbugs-Cc: debian-de...@lists.debian.org, cody.sc...@giatec.ca * Package name: python3-atcom Version : 0.4.3 Upstream Contact: Sixfab * URL : https://pypi.org/project/atcom/ * License : Apache Version 2.0 Programming Lang: Python Description : A tool which makes AT communication easier. This is a Python package that provides utilities to use cellular modems. I am using it in a travelling device. There appears to be an alternative that I haven't used. https://pypi.org/project/atcom/ I plan to maintain it.
Bug#1068517: kate: request to backport patch for upstream bug 476307
Package: kate Version: 4:22.12.3-1 Severity: normal Dear Maintainer, Upstream bug https://bugs.kde.org/show_bug.cgi?id=476307 has been reported resolved by MR https://invent.kde.org/utilities/kate/-/merge_requests/1441 It would be extremely helpful if you were able to pull the patch back to bookworm, or at least ensure the fix is included in the next stable, as the bug causes me pain every day. -- System Information: Debian Release: 12.5 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kate depends on: ii kate5-data 4:22.12.3-1 ii kio 5.103.0-1 ii ktexteditor-katepart 5.103.0-1.1 ii libc62.36-9+deb12u4 ii libkf5activities55.103.0-1 ii libkf5bookmarks5 5.103.0-1 ii libkf5completion55.103.0-1 ii libkf5configcore55.103.0-2 ii libkf5configgui5 5.103.0-2 ii libkf5configwidgets5 5.103.0-1 ii libkf5coreaddons55.103.0-1 ii libkf5crash5 5.103.0-1 ii libkf5dbusaddons55.103.0-1 ii libkf5guiaddons5 5.103.0-1 ii libkf5i18n5 5.103.0-1 ii libkf5iconthemes55.103.0-1 ii libkf5jobwidgets55.103.0-1 ii libkf5kiocore5 5.103.0-1 ii libkf5kiofilewidgets55.103.0-1 ii libkf5kiogui55.103.0-1 ii libkf5kiowidgets55.103.0-1 ii libkf5newstuff5 5.103.0-1 ii libkf5newstuffcore5 5.103.0-1 ii libkf5newstuffwidgets5 5.103.0-1 ii libkf5parts5 5.103.0-1 ii libkf5service-bin5.103.0-1 ii libkf5service5 5.103.0-1 ii libkf5syntaxhighlighting55.103.0-3 ii libkf5texteditor55.103.0-1.1 ii libkf5textwidgets5 5.103.0-1 ii libkf5wallet-bin 5.103.0-1 ii libkf5wallet55.103.0-1 ii libkf5widgetsaddons5 5.103.0-1 ii libkf5windowsystem5 5.103.0-1 ii libkf5xmlgui55.103.0-1 ii libkuserfeedbackcore11.2.0-2 ii libkuserfeedbackwidgets1 1.2.0-2 ii libqt5concurrent55.15.8+dfsg-11 ii libqt5core5a 5.15.8+dfsg-11 ii libqt5dbus5 5.15.8+dfsg-11 ii libqt5gui5 5.15.8+dfsg-11 ii libqt5network5 5.15.8+dfsg-11 ii libqt5sql5 5.15.8+dfsg-11 ii libqt5widgets5 5.15.8+dfsg-11 ii libqt5xml5 5.15.8+dfsg-11 ii libstdc++6 12.2.0-14 ii plasma-framework 5.103.0-1+deb12u1 ii qml-module-org-kde-kquickcontrolsaddons 5.103.0-1 ii qml-module-qtquick-layouts 5.15.8+dfsg-3 ii qml-module-qtquick2 5.15.8+dfsg-3 Versions of packages kate recommends: ii sonnet-plugins 5.103.0-1 Versions of packages kate suggests: pn darcs pn exuberant-ctags ii git 1:2.39.2-1.1 ii khelpcenter 4:22.12.3-1 ii konsole-kpart4:22.12.3-1 ii mercurial6.3.2-1 pn subversion -- no debconf information
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#1066962: wxwidgets3.2: 1 testsuite failed on loong64
On Sat, 16 Mar 2024 15:21:57 +0800 zhangdandan wrote: > Source: wxwidgets3.2 > Version: 3.2.4+dfsg-3.1 > Severity: serious > Tags: help > User: debian-loonga...@lists.debian.org > Usertags: loong64 > > Dear maintainers, > > The following test failed on the loongarch64 architecture, compiled 20 > hours ago (March 16th). > ``` > - -- > URLTestCase > GetInputStream > - -- > ./uris/url.cpp:37 > ... > > ./uris/url.cpp:89: FAILED: > REQUIRE( in_stream ) > with expansion: > 0 > > === > test cases: 312 | 311 passed | 1 failed > assertions: 1230238 | 1230237 passed | 1 failed > > make[1]: *** [debian/rules:89: override_dh_auto_test] Error 1 > make[1]: Leaving directory '/<>' > make: *** [debian/rules:22: binary-arch] Error 2 > dpkg-buildpackage: error: debian/rules binary-arch subprocess returned > exit status 2 > ``` > The full build log can be found at > https://buildd.debian.org/status/package.php?p=wxwidgets3.2=sid. > > I have reproduced the above testsuite issues on my local loong64 rootfs > environment. > After analyzing, I don't think this error has anything to do with > architecture. > So please focus on this test case failure. > > thanks, > Dandan Zhang Hello, This particular test is supposed to be skipped if the build host doesn't have network connectivity. Does the loong64 buildd have network connectivity (unlike the other buildd's)? Unfortunately, there doesn't appear to be a loong64 porterbox, so I'm unable to look into why this is failing. Regards, Scott
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
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: post...@packages.debian.org Control: affects -1 + src:postfix [ Reason ] Usual postfix maintenance update. Note that this is the final planned update for postfix 3.5. [ Impact ] Users continue to have the bugs that this update fixes. [ Tests ] The package has an autopkgtest, which passes. Additionally, I have it installed on one server and have tested that it works. [ Risks ] Risk is very low. Upstream has an excellent record for post-release updates and the changes are small. [ 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 ] - 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. - Cleanup: Postfix 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. [ Other info ] Changes are already in Unstable in 3.8.6 and uploaded pending SRM review for bookworm (3.7.9). Scott K diff -Nru postfix-3.5.24/debian/changelog postfix-3.5.25/debian/changelog --- postfix-3.5.24/debian/changelog 2024-01-27 10:21:04.0 -0500 +++ postfix-3.5.25/debian/changelog 2024-03-09 10:38:51.0 -0500 @@ -1,3 +1,66 @@ +postfix (3.5.25-0+deb11u1) bullseye; urgency=medium + + [Wietse Venema] + + * 3.5.25 +- 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. +- Cleanup: Po
Bug#1065562: bookworm-pu: package postfix/3.7.10-0+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: post...@packages.debian.org Control: affects -1 + src:postfix [ Reason ] Standard postfix post-release update [ Impact ] They will still have the bugs that are fixed by this update. [ Tests ] There is an autopkgtest, which passes locally. I also have the package in production on one server and it is running fine. [ Risks ] Risk is low. Changes are relatively minor and are as released by upstream, which has an excellent track record for such things. [ 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.7.11 - 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. - Cleanup: Postfix 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. [ Other info ] N/A Scott K diff -Nru postfix-3.7.10/debian/changelog postfix-3.7.11/debian/changelog --- postfix-3.7.10/debian/changelog 2024-01-26 18:44:58.0 -0500 +++ postfix-3.7.11/debian/changelog 2024-03-06 10:10:14.0 -0500 @@ -1,3 +1,66 @@ +postfix (3.7.11-0+deb12u1) bookworm; urgency=medium + + [Wietse Venema] + + * 3.7.11 +- 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. +- Cleanup: Postfix SMTP server response with an empty + authentication failure reason. File: smtpd/smtpd_sasl_glue.c. +
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#1065007: pycurl: Please reconsider SSL choice (OpenSSL instead of GnuTLS)
On Wed, 28 Feb 2024, Boyuan Yang wrote: Source: pycurl Version: 7.45.2-7 Severity: normal X-Debbugs-CC: s...@techie.net Dear Debian pycurl maintainer, I was made aware of issues encountered by multiple users due to pycurl using GnuTLS instead of OpenSSL. Reviewing https://bugs.debian.org/515200 , it looks like the only reason of not using OpenSSL is the old OpenSSL licensing issue in the past. With OpenSSL 3.0 and later, linking against OpenSSL is obviously no longer problematic due to license switching to Apache-2.0. As a result, I am once again requesting using OpenSSL for SSL implementation for pycurl or at least adding an option for users to select. Currently I believe several options exist: 1) Switch the default package python3-pycurl to use OpenSSL. 2) Add a new binary package python3-pycurl-openssl, which is linked to OpenSSL. 3) Add binary packages python3-pycurl-openssl and python3-pycurl-gnutls, and let python3-pycurl to be an empty dependency package that may default to a certain implementation of your choice. In any case, the binary packages providing the same files and the same functionalities shall mutually conflict with each other. If you need patches for any of the choices, please let me know. Please also let me know if you have any comments. If needed, I can make package uploads via Team upload. Thanks! Thanks for CC'ing me on the bug report. I don't have any objections to rebuilding pycurl with openssl. I don't see a lot of value in having the added complexity of building both versions, so I'm fine with just switching to openssl. I'm in the middle of a new upstream release right now, but I'll plan to switch it after that. Scott
Bug#1064284: [pcp] Bug#1064284: pcp: NMU diff for 64-bit time_t transition
Hi Steve, On Tue, Feb 20, 2024 at 3:11 PM Steve Langasek wrote: > [...] > To ensure that inconsistent combinations of libraries with their > reverse-dependencies are never installed together, it is necessary to > have a library transition, which is most easily done by renaming the > runtime library package. > > Since turning on 64-bit time_t is being handled centrally through a change > to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is > important that libraries affected by this ABI change all be uploaded close > together in time. Therefore I have prepared a 0-day NMU for pcp > which will initially be uploaded to experimental if possible, then to > unstable after packages have cleared binary NEW. > > Please find the patch for this NMU attached. > > If you have any concerns about this patch, please reach out ASAP. Thanks for preparing the patch, sorry for not getting back to you sooner (I've been away). I have discussed with other PCP maintainers and we'd prefer an approach where we simply exclude PCP from the few remaining 32 bit platforms, from the next major release onward. This is consistent with the approach taken with other distributions and avoids the package name mangling and general user confusion that will result for our packages. > [...] if information > becomes available that your package should not be included in the transition, > there is time for us to amend the planned uploads. cheers. -- Nathan
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#1063462: pycurl: FTBFS during tests: GnuTLS recv error (-110): The TLS connection was non-properly terminated
Control: reassign -1 src:curl 8.6.0-1 Control: affects -1 src:pycurl On Thu, 8 Feb 2024, Emanuele Rocca wrote: Source: pycurl Version: 7.45.2-7 Severity: serious Justification: fails to build from source (but built successfully in the past) Tags: sid trixie ftbfs Dear Maintainer, pycurl currently fails to build from source on amd64 and arm64 with the following error: === FAILURES === __ CertinfoTest.test_request_without_certinfo __ self = @util.min_libcurl(7, 19, 1) @util.only_ssl def test_request_without_certinfo(self): self.curl.setopt(pycurl.URL, 'https://localhost:8383/success') sio = util.BytesIO() self.curl.setopt(pycurl.WRITEFUNCTION, sio.write) # self signed certificate self.curl.setopt(pycurl.SSL_VERIFYPEER, 0) self.curl.perform() E pycurl.error: (56, 'GnuTLS recv error (-110): The TLS connection was non-properly terminated.') tests/certinfo_test.py:34: error === warnings summary === ../../../usr/lib/python3/dist-packages/bottle.py:38 /usr/lib/python3/dist-packages/bottle.py:38: DeprecationWarning: 'cgi' is deprecated and slated for removal in Python 3.13 import base64, cgi, email.utils, functools, hmac, itertools, mimetypes,\ -- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html ===Flaky Test Report=== === short test summary info FAILED tests/certinfo_test.py::CertinfoTest::test_request_without_certinfo - ... = 1 failed, 404 passed, 19 skipped, 5 deselected, 1 warning in 15.80s == This is a regression in curl 8.6.0. It has already been fixed/reverted upstream: https://github.com/curl/curl/commit/ed09a99af57200643d5ae001e815eeab9ffe3f84 Cherry-picking that commit should fix the issue. Regards, Scott
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#1063321: libwxgtk3.2-1t64 has an undeclared file conflict
On Fri, 9 Feb 2024, Scott Talbert wrote: On Tue, 6 Feb 2024, Helmut Grohne wrote: Package: libwxgtk3.2-1t64 Version: 3.2.4+dfsg-3.1~exp1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + libwxgtk-gl3.2-1 libwxgtk-gl3.2-1t64 libwxgtk-media3.2-1 libwxgtk-media3.2-1t64 libwxgtk-webview3.2-1 libwxgtk-webview3.2-1t64 X-Debbugs-Cc: vor...@debian.org libwxgtk3.2-1t64 has an undeclared file conflict. This may result in an unpack error from dpkg. Hello Steve, Are you planning on fixing this, or would you like me to? If the latter, how would you like the fix submitted before this is uploaded to unstable? Sending to your vor...@dodds.net as your mail server rejected the mail sent through debian.org with some sort of SPF error. Probably something the debian server is doing? Scott
Bug#1063321: libwxgtk3.2-1t64 has an undeclared file conflict
On Tue, 6 Feb 2024, Helmut Grohne wrote: Package: libwxgtk3.2-1t64 Version: 3.2.4+dfsg-3.1~exp1 Severity: serious User: debian...@lists.debian.org Usertags: fileconflict Control: affects -1 + libwxgtk-gl3.2-1 libwxgtk-gl3.2-1t64 libwxgtk-media3.2-1 libwxgtk-media3.2-1t64 libwxgtk-webview3.2-1 libwxgtk-webview3.2-1t64 X-Debbugs-Cc: vor...@debian.org libwxgtk3.2-1t64 has an undeclared file conflict. This may result in an unpack error from dpkg. Hello Steve, Are you planning on fixing this, or would you like me to? If the latter, how would you like the fix submitted before this is uploaded to unstable? Regards, Scott
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#1041754: [pcp] Bug#1041754: pcp: ships empty directory /usr/lib/pkgconfig
https://github.com/performancecopilot/pcp/pull/1874
Bug#1041754: pcp: ships empty directory /usr/lib/pkgconfig
On Mon, Jan 1, 2024 at 1:47 AM Chris Hofstaedtler wrote: > [..] > > I see you've uploaded two new upstream versions since this bug was > filed. Is there anything blocking inclusion of Helmut's patch? > Thank you for the reminder and thanks for the patch Helmut. I'll get this into the next update (pcp-6.2.0 expected late next week). cheers. -- Nathan
Bug#1052866: python-plaster: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
On Sun, 28 Jan 2024, Andreas Tille wrote: Hi, I upgraded python-plaster to latest upstream - but this did not changed the test suite error. I suspect the issue is because dh-python is clobbering the *.egg-info directories in the tests directory during the 'clean' target. While this is helpful in a lot of cases, it would be nice if there was a way to opt out of this behavior. Scott
Bug#1042325: python-miio: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13
On Sat, 27 Jan 2024, Andreas Tille wrote: Control: tags -1 help Hi, I upgraded python-miio in Git. Unfortunately there are some test suite errors[1] Any help would be welcome Andreas. Fixed.
Bug#1061625: bullseye-pu: package postfix/3.5.23-0+deb11u1
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu [ Reason ] This is the next in our normal postfix maintenance releases. It consists soley of updates to the SMTP Smuggling processing that were released near the end of December. I think it would be better to get this in now for the next point release so that the fixes that most of our users see are the final form. [ Impact ] Users will have the older version of the SMTP Smuggling fixes which mean they are unable to sanitize outbound mail and then will have to consider the inbound processing changes later instead of all at once. [ Tests ] The package has a reasonably extensive autopkgtest, although it does not have specific tests for SMTP Smuggling, it does ensure the changes do not cause regressions. The tests pass when run locally. Additionally, I have installed the package on one of my servers to verified it is still working as expected. [ Risks ] Risk is negligible. No changes from the upstream release and upstream is known to be very careful. The risk is primarily on not updating as there are changes (backward compatible, so there's no issue if someone already dealt with SMTP Smuggling based on the December release) in how some of the related controls work. If we don't update, then behavior on Debian will differ from user expectations. The alternative would be to hold this until the next point release, which I don't think would be a good idea. [ 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 ] - 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. - 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, global/mail_params.h, global/smtp_stream.c, global/smtp_stream.h, smtpd/smtpd.c, smtpd/smtpd_check.[hc]. [ Other info ] I do not think an SUA is required for this update. The capability provided by the December SUA is sufficient until the next point release. Scott K diff -Nru postfix-3.5.23/debian/changelog postfix-3.5.24/debian/changelog --- postfix-3.5.23/debian/changelog 2023-12-26 16:07:38.0 -0500 +++ postfix-3.5.24/debian/changelog 2024-01-27 10:21:04.0 -0500 @@ -1,3 +1,36 @@ +postfix (3.5.24-0+deb11u1) bullseye; urgency=medium + + [Wietse Venema] + + * 3.5.24 +- 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. + - 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 compati
Bug#1061624: bookworm-pu: package postfix/3.7.9-0+deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu [ Reason ] This is the next in our normal postfix maintenance releases. It consists soley of updates to the SMTP Smuggling processing that were released near the end of December. I think it would be better to get this in now for the next point release so that the fixes that most of our users see are the final form. [ Impact ] Users will have the older version of the SMTP Smuggling fixes which mean they are unable to sanitize outbound mail and then will have to consider the inbound processing changes later instead of all at once. [ Tests ] The package has a reasonably extensive autopkgtest, although it does not have specific tests for SMTP Smuggling, it does ensure the changes do not cause regressions. The tests pass when run locally. Additionally, I have installed the package on one of my servers to verified it is still working as expected. [ Risks ] Risk is negligible. No changes from the upstream release and upstream is known to be very careful. The risk is primarily on not updating as there are changes (backward compatible, so there's no issue if someone already dealt with SMTP Smuggling based on the December release) in how some of the related controls work. If we don't update, then behavior on Debian will differ from user expectations. The alternative would be to hold this until the next point release, which I don't think would be a good idea. [ 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 ] - 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. - 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, global/mail_params.h, global/smtp_stream.c, global/smtp_stream.h, smtpd/smtpd.c, smtpd/smtpd_check.[hc]. [ Other info ] I do not think an SUA is required for this update. The capability provided by the December SUA is sufficient until the next point release. Scott K diff -Nru postfix-3.7.9/debian/changelog postfix-3.7.10/debian/changelog --- postfix-3.7.9/debian/changelog 2023-12-24 12:33:24.0 -0500 +++ postfix-3.7.10/debian/changelog 2024-01-26 18:44:58.0 -0500 @@ -1,3 +1,36 @@ +postfix (3.7.10-0+deb12u1) bookworm; urgency=medium + + [Wietse Venema] + + * 3.7.10 +- 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. +- 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 client
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#1060711: python3-wxgtk4.0: Library dependency too lenient
On Mon, 22 Jan 2024, Matthias Urlichs wrote: On 17.01.24 15:01, Scott Talbert wrote: On Wed, 17 Jan 2024, Matthias Urlichs wrote: On 16.01.24 23:58, Scott Talbert wrote: Do I understand correctly that you installed the python3-wxgtk4.0 4.2.1+dfsg-3 binary package from Debian Testing into a Debian 12 system and that's how you encountered this error? Yes. So? Mix+match from stable+testing is rather common when you're developing stuff, and Policy 3.5 doesn't say "umm well that only applies for dependencies from the same release". Sorry, but that's not generally supported, at least for wxWidgets related packages. Sometimes we change compile options and other things that change the ABI. I noticed … However, perhaps you misunderstood. I'm not asking for "support mix and match of wx*-related packages". I'm asking for "support mix+match between releases; if and when that doesn't work, please set the dependencies so that the user can't install a mix-and-match system in the first place". I didn't misunderstand - you're asking for mis+match of wx-related (to include wxWidgets and wxPython) packages between releases, which isn't supported. wxPython is a Python wrapper for wxWidgets, so it is by necessity tightly coupled with wxWidgets. I'll try to find a way to tighten wxPython's dependency on be >= the wxWidgets it was compiled with. See also: https://lists.debian.org/debian-devel/2024/01/msg00266.html — NB, please disregard my snarky "go away" pseudo-quote there. That was not intended to reflect your reply here. Yes, I saw that. Scott
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#1060708: python3-wxgtk4.0: Package doesn't import
On Sat, 13 Jan 2024, Matthias Urlichs wrote: Package: python3-wxgtk4.0 Version: 4.2.0+dfsg-3 Severity: important X-Debbugs-Cc: sm...@smurf.noris.de /usr/lib/python3/dist-packages/wx/__init__.py contains: from wx.core import * del core del wx This doesn't work on my system. "wx.core" does *not* export a symbol named "core", thus the "del core" fails. Deleting the "del core" part fixes the problem. -- System Information: Debian Release: 12.4 APT prefers stable APT policy: (750, 'stable'), (700, 'testing'), (650, 'oldstable'), (600, 'oldoldstable'), (500, 'stable-security'), (500, 'oldstable-security'), (500, 'unstable'), (300, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.1.0-10-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 python3-wxgtk4.0 depends on: ii libc62.36-9+deb12u3 ii libgcc-s112.2.0-14 ii libstdc++6 13.2.0-9 ii libwxbase3.2-1 3.2.4+dfsg-1 ii libwxgtk-gl3.2-1 3.2.4+dfsg-1 ii libwxgtk3.2-13.2.2+dfsg-2 ii python3 [python3-supported-min] 3.11.2-1+b1 ii python3-numpy1:1.24.2-1 ii python3-pil 9.4.0-1.1+b1 ii python3-six 1.16.0-4 Can you provide any additional details that may be relevant to reproducing this problem? I'm going to assume this is probably related to your other bug where you seem to be mixing and matching packages from testing and bookworm? Scott
Bug#1060711: python3-wxgtk4.0: Library dependency too lenient
On Sat, 13 Jan 2024, Matthias Urlichs wrote: Package: python3-wxgtk4.0 Version: 4.2.1+dfsg-3 Severity: normal X-Debbugs-Cc: sm...@smurf.noris.de Installing the version from Testing says import wx.core Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/wx/__init__.py", line 17, in from wx.core import * File "/usr/lib/python3/dist-packages/wx/core.py", line 12, in from ._core import * ImportError: /usr/lib/python3/dist-packages/wx/_core.cpython-311-x86_64-linux-gnu.so: undefined symbol: _ZN13wxRadioButtonD2Ev, version WXU_3.2 due to its dependency on libwxgtk3.2-1, which apparently needs to be >= 3.2.4 instead of 3.2.2. Semantic versioning appears to be overrated. :-( Hello Matthias, Do I understand correctly that you installed the python3-wxgtk4.0 4.2.1+dfsg-3 binary package from Debian Testing into a Debian 12 system and that's how you encountered this error? Scott
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#1060814: inetutils-ftpd: No inetd dependency
Package: inetutils-ftpd Version: 2:2.0-1+deb11u Severity: minor Dear Maintainer, * What led up to the situation? installed package, then attempted to open connection, received no reply from ftpd service * What exactly did you do (or not do) that was effective (or ineffective)? determined no inetd installed selected ftpd-ssl package which depends on openbsd-inetd * What was the outcome of this action? received reply from ftpd service -- System Information: Debian Release: 11.8 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-20-amd64 (SMP w/4 CPU threads) 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 inetutils-ftpd depends on: ii libc6 2.31-13+deb11u7 ii libcrypt1 1:4.4.18-4 ii libpam0g 1.4.0-9+deb11u1 ii libwrap0 7.6.q-31 ii netbase 6.3 ii rsyslog [system-log-daemon] 8.2102.0-2+deb11u1 inetutils-ftpd recommends no packages. inetutils-ftpd suggests no packages.
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#1057852: haskell-pandoc: please upgrade to at least v3.1.2
On Sat, 09 Dec 2023 17:16:41 +0100 Jonas Smedegaard wrote: > Source: haskell-pandoc > Version: 3.0.1-3 > Severity: normal > Tags: upstream > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Pandoc 3.0.1 is almost a year old. > > It seems that upgrading to 3.1.2 involves no upgrades to any of its > dependencies, and upgrading further involves only few dependencies: > > * upgrade to 3.1.2 > * upgrade to 3.1.3 > when needed Haskell libraries are in Debian: > + typst >= 0.1 && < 0.2 > * upgrade to 3.1.4 > when needed Haskell libraries are in Debian: > + crypton-connection >= 0.3.1 && < 0.4 > * upgrade to 3.1.6.2 > when needed Haskell libraries are in Debian: > + typst >= 0.3.2.0 && < 0.3.3 Replying here as per your request. Unfortunately, updating to haskell-pandoc 3.1.2 does not involve updating no dependencies - it requires an update to pandoc-lua-engine, which requires adding two new packages, isocline and hslua-repl. I went ahead and added these packages, as well as typst, so we should be able to update to 3.1.3 soon. Adding crypton-connection is going to be a bit more challenging as it requires an update to tls, which is used by several other packages, so I'm not sure if that's going to be easy. BTW, you didn't really address my question about updating the version of src:haskell-pandoc in relation to the version of src:pandoc (having nothing to do with the dependencies of src:haskell-pandoc). Just the version number. Scott
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
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,
tls/tls_proxy.h, tlsproxy/tlsproxy.c.
- Cleanup: reverted cosmetic-only changes to minimize the
patch footprint for OpenSSL INI file support; updated daemon
manpages with the new tls_config_file and tls_config_name
configuration parameters. Files: smtp/smtp.c, smtpd/smtpd.c,
tls/tls_client.c, tls/tls.h, tls/tls_server.c, tlsproxy/tlsproxy.c,
- Cleanup: made OpenSSL 'default' INI file support error
handling consistent with OpenSSL default behavior. Viktor
Dukhovni. Files: proto/postconf.proto, tls/tls_misc.c.
- Backwards compatibility for stable releases that originally
had no OpenSSL INI support. Skip the new OpenSSL INI support
code, unless the Postfix configuration actually specifies
non-default tls_config_xxx settings. File: tls/tls_misc.c.
- Cleanup: added a multiple initialization guard in the
tls_library_init() function, and made an initialization
error sticky. File: tls/tls_misc.c.
- Security: new parameter smtpd_forbid_unauth_pipelining
(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.
* 3.5.21
- 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.
- 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.
* 3.5.22
- 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.5.23 (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,
[ Other info ]
The bulk of the diff is dcoumentation updates related to the documented
code changes. The actual code changes start ~ line 2100 in the diff.
The CVE fix requires a configuration change, which is not set be default
as it would likely break some configuratins. We should be sure to
mention that in the SUA.
Scott K
