Bug#992997: milter-greylist: segfault in libGeoIP
Sudip Mukherjee writes: > I just updated the package to latest 4.6.4, can you please try with that > and check if you still get the same problem. If you still the same problem > the a coredump or some way to reproduce the problem will be needed. Thanks. I've not seen the problem since I installed version 4.6.4-1 so you may close this bug as you find appropriate. Looking at the upstream changelog I noticted this entry under 4.6.3: .. Fix crash when GeoIP for IPv6 is not configured (Paul Howarth) And that could very well have been the issue. The server is dual-stack, but I only had geoipdb "/usr/share/GeoIP/GeoIP.dat" in /etc/milter-greylist/greylist.conf and no geoipv6db entry. Bjørn
Bug#993375: Bug#993378: RM: gtkpod -- RoQA; Upstream not active, orphaned & uses a vulnerable embedded library
Control: tags 993378 moreinfo On Tue, Aug 31, 2021 at 03:49:45PM +0100, Neil Williams wrote: > Package: ftp.debian.org > Severity: normal > > gtkpod upstream has moved but has not had any activity for over 5 years. > > When investigating the two CVEs against AtomicParsley, former maintainer > Matteo F. Vescovi reached > out to me to suggest removal of gtkpod. > > The use case for this package seems to be declining / absent and 4 crash bugs > are currently open. > > Fixes for these bugs and CVEs seem unlikely to appear, it would seem best to > remove gtkpod > from Debian at this point. As a user I am quite unhappy when a working package I am using is out of the void getting am RM bug. With software for older hardware it is normal that upstream becomes inactive, and anything other than declining usage would be a surprise. I am also dismayed at the CVEs. At first sight the "two CVEs" might be for the same bug, with the fix for the first CVE not fixing the bug. Does manually backporting the one-character change from CVE-2021-37232 fix everything, even without the larger CVE-2021-37231 refactoring? > Thanks cu Adrian
Bug#993375: Bug#993378: RM: gtkpod -- RoQA; Upstream not active, orphaned & uses a vulnerable embedded library
On Wed, 1 Sep 2021 11:05:09 +0300 Adrian Bunk wrote: > Control: tags 993378 moreinfo > > On Tue, Aug 31, 2021 at 03:49:45PM +0100, Neil Williams wrote: > > Package: ftp.debian.org > > Severity: normal > > > > gtkpod upstream has moved but has not had any activity for over 5 > > years. > > > > When investigating the two CVEs against AtomicParsley, former > > maintainer Matteo F. Vescovi reached out to me to suggest removal > > of gtkpod. > > > > The use case for this package seems to be declining / absent and 4 > > crash bugs are currently open. > > > > Fixes for these bugs and CVEs seem unlikely to appear, it would > > seem best to remove gtkpod from Debian at this point. > > As a user I am quite unhappy when a working package I am using is out > of the void getting am RM bug. > > With software for older hardware it is normal that upstream becomes > inactive, and anything other than declining usage would be a surprise. > > I am also dismayed at the CVEs. At first sight the "two CVEs" might > be for the same bug, with the fix for the first CVE not fixing the > bug. Does manually backporting the one-character change from > CVE-2021-37232 fix everything, even without the larger CVE-2021-37231 > refactoring? Hi Adrian. Sorry, No. The commit linked to CVE-2021-37232 does not even fix the problem described as being fixed by that commit in atomicparsley, at least in my testing using the data file supplied by upstream. I mentioned this in the bug report against atomicparsley - 993366 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993366#5 That atomicparsley data file cannot be used to test gtkpod, only atomicparsley itself. As mentioned already, gtkpod is now orphaned and the maintainer who orphaned it suggested removing the package. (The CVEs are not the only bugs against either atomicparsley or gtkpod). The two CVEs are not the same bug - at least not according to the commits made upstream for the two issues in atomicparsley. Orphaned packages are at risk of sudden removal - until and unless someone adopts the package. -- Neil Williams = https://linux.codehelp.co.uk/ pgpS65oDdtE2j.pgp Description: OpenPGP digital signature
Bug#993375: Bug#993378: RM: gtkpod -- RoQA; Upstream not active, orphaned & uses a vulnerable embedded library
On Wed, 1 Sep 2021 12:08:16 +0300 Adrian Bunk wrote: > On Wed, Sep 01, 2021 at 09:32:09AM +0100, Neil Williams wrote: > >... > > Hi Adrian. > > Hi Neil, > > > Sorry, No. The commit linked to CVE-2021-37232 does not even fix the > > problem described as being fixed by that commit in atomicparsley, at > > least in my testing using the data file supplied by upstream. I > > mentioned this in the bug report against atomicparsley - 993366 > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993366#5 > > > > That atomicparsley data file cannot be used to test gtkpod, only > > atomicparsley itself. > > "atomicparsley itself" is a CLI with a copy of the code, > not much different from gtkpod. > > gtkpod at least tries (in a broken way) to share the library with > other programs. > > > As mentioned already, gtkpod is now orphaned and the maintainer who > > orphaned it suggested removing the package. (The CVEs are not the > > only bugs against either atomicparsley or gtkpod). > > > > The two CVEs are not the same bug - at least not according to the > > commits made upstream for the two issues in atomicparsley. > > > > Orphaned packages are at risk of sudden removal - until and unless > > someone adopts the package. > >... > > Why do you want to screw our users (in this case including me) > with sudden removals? > > QA maintained packages tend to be better maintained than many > packages owned by nearly-MIA maintainers, so why are you forcing > people to move packages out or QA maintainance just for preventing > random people doing sudden removals out of the void? > > I can adopt gtkpod and many other QA maintained packages if that is > the only way to stop removal requests from people like you. > This would change the Maintainer field without fixing any bugs. > > The normal approach is that people file RC bugs for RC issues > or an RC "should this package be removed?" bug against the > package first. This gives people time to react and discuss. Packages do not need to be RC buggy to be removed - indeed, many RC buggy packages remain in unstable for some time as the removal from testing is automated. RoQA and RoM are valid reasons for removal of a package from Debian which do not require any RC bugs to be present. https://ftp-master.debian.org/removals.html -- Neil Williams = https://linux.codehelp.co.uk/ pgpAOnVyJB6UO.pgp Description: OpenPGP digital signature
Bug#993375: Bug#993378: RM: gtkpod -- RoQA; Upstream not active, orphaned & uses a vulnerable embedded library
On Wed, Sep 01, 2021 at 09:32:09AM +0100, Neil Williams wrote: >... > Hi Adrian. Hi Neil, > Sorry, No. The commit linked to CVE-2021-37232 does not even fix the > problem described as being fixed by that commit in atomicparsley, at > least in my testing using the data file supplied by upstream. I > mentioned this in the bug report against atomicparsley - 993366 > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993366#5 > > That atomicparsley data file cannot be used to test gtkpod, only > atomicparsley itself. "atomicparsley itself" is a CLI with a copy of the code, not much different from gtkpod. gtkpod at least tries (in a broken way) to share the library with other programs. > As mentioned already, gtkpod is now orphaned and the maintainer who > orphaned it suggested removing the package. (The CVEs are not the only > bugs against either atomicparsley or gtkpod). > > The two CVEs are not the same bug - at least not according to the > commits made upstream for the two issues in atomicparsley. > > Orphaned packages are at risk of sudden removal - until and unless > someone adopts the package. >... Why do you want to screw our users (in this case including me) with sudden removals? QA maintained packages tend to be better maintained than many packages owned by nearly-MIA maintainers, so why are you forcing people to move packages out or QA maintainance just for preventing random people doing sudden removals out of the void? I can adopt gtkpod and many other QA maintained packages if that is the only way to stop removal requests from people like you. This would change the Maintainer field without fixing any bugs. The normal approach is that people file RC bugs for RC issues or an RC "should this package be removed?" bug against the package first. This gives people time to react and discuss. cu Adrian
Processing of sdl-kitchensink_1.0.9-3_source.changes
sdl-kitchensink_1.0.9-3_source.changes uploaded successfully to localhost along with the files: sdl-kitchensink_1.0.9-3.dsc sdl-kitchensink_1.0.9-3.debian.tar.xz Greetings, Your Debian queue daemon (running on host usper.debian.org)
sdl-kitchensink_1.0.9-3_source.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 01 Sep 2021 14:09:02 +0200 Source: sdl-kitchensink Architecture: source Version: 1.0.9-3 Distribution: unstable Urgency: medium Maintainer: Debian QA Group Changed-By: Didier Raboud Closes: 993421 Changes: sdl-kitchensink (1.0.9-3) unstable; urgency=medium . * Orphan package * Drop unused libavresample-dev B-D (Closes: #993421) * S-V: Upgrade to 4.6.0 without changes needed Checksums-Sha1: f6df42de2379dd0fd23208cfa7b6e92869f501e4 2287 sdl-kitchensink_1.0.9-3.dsc 59c670613fb6fcc6de6767146710764542c97206 3924 sdl-kitchensink_1.0.9-3.debian.tar.xz Checksums-Sha256: ee7d735b6183544a0a659a10b5609e29a99d272ac5c0f9d49bac58d814036de9 2287 sdl-kitchensink_1.0.9-3.dsc 0a51f07177d40bede48b6d9d4bf943f38be22d5677cab6a6c4e31cbc6c7875dc 3924 sdl-kitchensink_1.0.9-3.debian.tar.xz Files: ff8829f6d349325a4a184718131c5749 2287 libs optional sdl-kitchensink_1.0.9-3.dsc 7364964b3e86ab62ea1d9d31a416cb89 3924 libs optional sdl-kitchensink_1.0.9-3.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEJ3k7rA0YCplkx4gZqcb6xg1jAWkFAmEvcB0ACgkQqcb6xg1j AWm+fw//SAnWXhuNB61h++eqA0OMVq+bpQBI6Nrh399fQfqZRrZ4bcYEyNwkGtfL qGEmHxp1cUL7+fM4guMlBXLLCEtUHxPcgVjb85boM3ciWhaI4Lv4d1dShwCgU5pX gciBUWKjC9heLCrnb1sOVpFGJbhqksMp7HN2O9Nu52Ku/l8N7tBXHuh5x4AC9//w Sy0Fize9pxOPu2PoAzHNHRpnnvQJLH+IU11tTC8PgwQN4vq5SkqOm+jia1qGjbW1 3QoyGU4VfVbsFedxmZCq0c/WDuBYJ05FvrirmRVLMWBrnxO9x8CKjYv25TRicF+W MCs0IswTVA6EHMJIYWIRChI7XwZ12Jk/k8/n5UDd7aOvV/LEURVSPrjwZ4Rfr1g1 qQOtnbT0Dx1LBEvTBtRUq8v7BD1V7Q6VZzfGwPa6azVhVvJdCSQAj//V6kGaiuWq U+sNnaxdOALBeuvL47PPsit4+CFY0sVOI3xldHBXOLjmPOndI9Ba5svW24F8TFge PkIkH8K9CZxBtzEC6tteChgsiELg1VKz1UKS/Zcwq4LShBfhrYc+N+WCLFSCDa26 qzjrUGGpAzezouWKLsqUWtFH7LK0Nai0He9x5Eq7dRVScu2SLRuTbTiJukzOGxHt pix+V37cOaSGUxhTgHgyR2k7lm2gsoKoICqwdnhQVXlMhj2ujXc= =NjmS -END PGP SIGNATURE- Thank you for your contribution to Debian.
Processing of argagg_0.4.6-6_source.changes
argagg_0.4.6-6_source.changes uploaded successfully to localhost along with the files: argagg_0.4.6-6.dsc argagg_0.4.6-6.debian.tar.xz Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#990428: ifenslave: Bonding not working on bullseye (using bond-slaves config)
> In your case you could simply remove the stanzas for enp4s0f0 and enp4s0f1 > which would leave you with just the stanza for bond1: > iface bond1 inet static > bond-slaves enp4s0f0 enp4s0f1 Thank you Oleander. It works with this hint (the physical interfaces were left out of the config). Working config: = ck@bullseye:~$ cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback auto bond0 iface bond0 inet static address 192.168.12.4/24 gateway 192.168.12.1 bond-slaves enp3s0f0 enp3s0f1 bond-mode 802.3ad bond-miimon 100 bond-lacp-rate 1 = > That should work but it is still a regression as it breaks configuration > which worked before. Yes, agree. Do you know if your patch (I have not tested) will be included in the next point release? > https://serverfault.com/a/1075192/267378 > > Best regards, > Arunas You mention both bond-master of the physical devices and blond-slaves on the bond interface. This causes networking service to hiccup in my case: Sep 01 15:58:23 irczsrvp09 systemd[1]: Starting Raise network interfaces... Sep 01 15:58:23 irczsrvp09 ifup[1251]: No iface stanza found for master bond0 Sep 01 15:58:23 irczsrvp09 ifup[1249]: run-parts: /etc/network/if-pre-up.d/ifenslave exited with return code 1 Sep 01 15:58:23 irczsrvp09 ifup[1242]: ifup: failed to bring up enp3s0f0 Sep 01 15:58:23 irczsrvp09 ifup[1256]: No iface stanza found for master bond0 Sep 01 15:58:23 irczsrvp09 ifup[1254]: run-parts: /etc/network/if-pre-up.d/ifenslave exited with return code 1 Sep 01 15:58:23 irczsrvp09 ifup[1242]: ifup: failed to bring up enp3s0f1 Sep 01 15:58:23 irczsrvp09 ifup[1261]: No iface stanza found for master bond1 Sep 01 15:58:23 irczsrvp09 ifup[1259]: run-parts: /etc/network/if-pre-up.d/ifenslave exited with return code 1 Sep 01 15:58:23 irczsrvp09 ifup[1242]: ifup: failed to bring up enp4s0f0 Sep 01 15:58:23 irczsrvp09 ifup[1266]: No iface stanza found for master bond1 Sep 01 15:58:23 irczsrvp09 ifup[1264]: run-parts: /etc/network/if-pre-up.d/ifenslave exited with return code 1 Sep 01 15:58:23 irczsrvp09 ifup[1242]: ifup: failed to bring up enp4s0f1 Although the bonding interface seems to work with your workaround, the Systemd service (networking) is stuck at failed state. So for now the "proper" way to fix this seems to be to remove the physical device stanzas and only use the bonding interfaces - until this bug is fixed.
argagg_0.4.6-6_source.changes ACCEPTED into unstable
Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Wed, 01 Sep 2021 15:53:51 +0200 Source: argagg Architecture: source Version: 0.4.6-6 Distribution: unstable Urgency: medium Maintainer: Debian QA Group Changed-By: Didier Raboud Changes: argagg (0.4.6-6) unstable; urgency=medium . * Orphan package . [ Debian Janitor ] * Set upstream metadata fields . [ Didier Raboud ] * S-V: Update to 4.6.0 without changes needed * Run wrap-and-sort -baskt * Fix MIT/Expat license name, thanks to cme * Bump debhelper compat to 13 Checksums-Sha1: 62ad1b0b2f5e9f1b218bdb5511db6c30282edd0c 2021 argagg_0.4.6-6.dsc fd54dcc41727703e76748bb37c3b23601aa3abfc 25996 argagg_0.4.6-6.debian.tar.xz Checksums-Sha256: 106d5b7b2526bae8afad804ecf1930ca0b2e885d5cc82b8f91c062c010b93edf 2021 argagg_0.4.6-6.dsc e35b53a66389e3b03453839cb7626c5b26cc10728281ff792b7b0f7237c7fa8f 25996 argagg_0.4.6-6.debian.tar.xz Files: 7b2358de19134d321eae9a630de23463 2021 devel optional argagg_0.4.6-6.dsc 5f70cb3afb3f5f702d46796975968253 25996 devel optional argagg_0.4.6-6.debian.tar.xz -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEJ3k7rA0YCplkx4gZqcb6xg1jAWkFAmEviU4ACgkQqcb6xg1j AWmxmBAArAPkNSwd4PJsObfVA1h/KjmJ2149sIaVuyOt88eEOZgOK/q8I82W0JR5 0pwTtQJue3uFYYUayxUPAewc8dLYQc53hgiZrjve5lUpzFEpYAxH13EPDN8r5jgE dSEhLFZ8ddL0sq9iIRn81L8aYKs4uU55sg7cGZ0KsX6P9t7aSka00fbNxZvThrWi WD6VGDFg0FvmkCHB/6Jj35YuCNB+sVQGUGz7P7XSoIAVn1cgPMnnAFnu7C1oVGzb R0DT5IyHCd5jpysneQUdIPqPNhQQQK/iSfse4KsD0HD8ZCYqNQIZmxrry5Q9EwiE 1X4TQTEnN4pOEE55bbOmEv9AOmvbh/5tp5UQe9HGswGWoDbf8pDR89WydG2kWrCC ITRyUbmHUF2p56xMAZLLLddIDzTseqUNtkXRbZUPKQdevUzXdKBZ/Kp+YyoNJAz+ aPbgamxfzKxBFNCCrLHyhjFcmjl64C5wRwIzAsDjrRa6aYUX5dRzP77DjiYBJ8e0 DaPJdo9Nvw5fZPU9Vsq0kDpyRkcWIgRli8sp0QM7cJOmfROOBRnlE9AFxVqwgw+y HanDtZghCmsa7r48WXQZC4UMFCGZ5TkZ0BHWZJ2c2rimDzU7rJDQ9SVYV5YmUBCN AP+RH1t8x9wCjEGvV20zzPB60UFa6qNg09zvtXVYQZFEEo0VGwQ= =zhl+ -END PGP SIGNATURE- Thank you for your contribution to Debian.
ifenslave is marked for autoremoval from testing
ifenslave 2.12 is marked for autoremoval from testing on 2021-09-23 It is affected by these RC bugs: 968368: ifenslave: Option bond-master fails to add interface to bond https://bugs.debian.org/968368 990428: ifenslave: Bonding not working on bullseye (using bond-slaves config) https://bugs.debian.org/990428 This mail is generated by: https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl Autoremoval data is generated by: https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl
libguess is marked for autoremoval from testing
libguess 1.2-4 is marked for autoremoval from testing on 2021-10-07 It (build-)depends on packages with these RC bugs: 992894: mit-scheme: fails to migrate to testing for too long https://bugs.debian.org/992894 This mail is generated by: https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl Autoremoval data is generated by: https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl
