Bug#1002956: Remote RCE in rabbitmq-server
On 8/5/22 01:24, Tim Abbott wrote: On Wed, Aug 3, 2022 at 12:22 AM Thomas Goirand <mailto:z...@debian.org>> wrote: Hi Tim, Please don't top-post, we don't do that in Debian, and also: Apologies! FYI, I'm sad too, but there's nothing I can do but pinging again the stable release team about this. You hear me well: the stable release team. Not the security team since they do not want to do a security announcement and an update through stable-security (so it shall be done through a point release, dealing with the stable release team). This means writing to 1002...@bugs.debian.org <mailto:1002...@bugs.debian.org>. That's the only email address that has influence on accepting the fixed version. Feel free to ping that email address until you get a reply. I agree that no reply since the 29th of Jan is sad... I still don't understand why the determination was made to not do a security announcement for this bug, given that it makes a Debian system that installs this package vulnerable to remote RCE without manual intervention. What was discussed with the security team, is that the most common practice is to never expose a RabbitMQ cluster to the internet. We believe most server administrator know it (at least, that's the point of view of the security team, but not necessarily mine...). But given that determination was made, perhaps the best way I can contribute is by making sure this bug thread links to https://blog.zulip.com/2022/01/25/zulip-server-4-9-security-release/#cve-2021-43799-remote-code-execution-vulnerability-involving-rabbitmq <https://blog.zulip.com/2022/01/25/zulip-server-4-9-security-release/#cve-2021-43799-remote-code-execution-vulnerability-involving-rabbitmq>, which has a bunch of public context about the impact of this bug, as well as background explanation that may help release managers who don't know much about Erlang/RabbitMQ. Convincing the stable release team that we must do an update by writing in this bug entry, is exactly what should be done, indeed. Dear stable release team, can we have your opinion here? Cheers, Thomas Goirand (zigo)
Bug#1002956: Remote RCE in rabbitmq-server
Hi Tim, On 8/3/22 02:22, Tim Abbott wrote: Just following up on this -- it makes me sad that this publicly known RCE vulnerability is still not fixed in stable. -Tim Abbott Please don't top-post, we don't do that in Debian, and also: > Because it messes up the order in which people normally read text. > Why is top-posting such a bad thing? > Top-posting. > What is the most annoying thing in e-mail? FYI, I'm sad too, but there's nothing I can do but pinging again the stable release team about this. You hear me well: the stable release team. Not the security team since they do not want to do a security announcement and an update through stable-security (so it shall be done through a point release, dealing with the stable release team). This means writing to 1002...@bugs.debian.org. That's the only email address that has influence on accepting the fixed version. Feel free to ping that email address until you get a reply. I agree that no reply since the 29th of Jan is sad... Cheers, Thomas Goirand (zigo)
Bug#1016069: ceph: CVE-2022-0670
On 7/27/22 09:50, Thomas Goirand wrote: Oh... now I have the problem that Ceph FTBFS with GCC 12... :/ I'll let you know when I can get this fixed. Cheers, Thomas Goirand (zigo) Hi, FYI, I was able to fix the build, so Ceph 16.2.10+ds was uploaded to Unstable, and built on all arch. I also have the information from IRC that CVE-2022-0670 only affects 16.2.x, and not the version in Stable or earlier. So please update the security tracker accordingly. This bug can be completely closed then... (or when 16.2.10 reaches testing). Cheers, Thomas Goirand (zigo)
Bug#1016069: ceph: CVE-2022-0670
On 7/27/22 09:13, Thomas Goirand wrote: On 7/26/22 13:16, Moritz Mühlenhoff wrote: Source: ceph X-Debbugs-CC: t...@security.debian.org Severity: important Tags: security Hi, The following vulnerability was published for ceph. CVE-2022-0670[0]: | A flaw was found in Openstack manilla owning a Ceph File system | "share", which enables the owner to read/write any manilla share or | entire file system. The vulnerability is due to a bug in the "volumes" | plugin in Ceph Manager. This allows an attacker to compromise | Confidentiality and Integrity of a file system. Fixed in RHCS 5.2 and | Ceph 17.2.2. https://ceph.io/en/news/blog/2022/v17-2-2-quincy-released/ If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2022-0670 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0670 Please adjust the affected versions in the BTS as needed. Hi Moritz, If I'm not mistaking, this security hole is only in the 16.2.x series of Ceph, right? I'll upgrade to 16.2.10 immediately. Please let me know about Ceph in Bullseye. Cheers, Thomas Goirand (zigo) Oh... now I have the problem that Ceph FTBFS with GCC 12... :/ I'll let you know when I can get this fixed. Cheers, Thomas Goirand (zigo)
Bug#1016069: ceph: CVE-2022-0670
On 7/26/22 13:16, Moritz Mühlenhoff wrote: Source: ceph X-Debbugs-CC: t...@security.debian.org Severity: important Tags: security Hi, The following vulnerability was published for ceph. CVE-2022-0670[0]: | A flaw was found in Openstack manilla owning a Ceph File system | "share", which enables the owner to read/write any manilla share or | entire file system. The vulnerability is due to a bug in the "volumes" | plugin in Ceph Manager. This allows an attacker to compromise | Confidentiality and Integrity of a file system. Fixed in RHCS 5.2 and | Ceph 17.2.2. https://ceph.io/en/news/blog/2022/v17-2-2-quincy-released/ If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2022-0670 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0670 Please adjust the affected versions in the BTS as needed. Hi Moritz, If I'm not mistaking, this security hole is only in the 16.2.x series of Ceph, right? I'll upgrade to 16.2.10 immediately. Please let me know about Ceph in Bullseye. Cheers, Thomas Goirand (zigo)
Bug#1015299: Files-Exluded: didn't work
Package: numberstation Version: 1.0.1-1~bpo11+1 Severity: important As per FTP master comment after accepting in NEW: "Files-Exluded: didn't work" ALso: "tell upstream about the wrong license mentioned in numberstation-1.0.1/numberstation/window.py" This shall be addressed on the next upload. Cheers, Thomas Goirand (zigo)
Bug#1015011: Upgrading to severity serious
Hi, I did a mistake and uploaded to Unstable instead of Experimental. The result is that this bug becomes a serious one. bmtk is, with Sahara, the only package that still has issues with the new version. Please get it fixed ASAP. FYI, I'm also looking at the issue, but didn't find a fix yet. If you do, please ping me, as your issue looks the same as the one in Sahara. Cheers, Thomas Goirand (zigo)
Bug#1015186: ITP: jruby-rake -- ruby make-like utility - jruby version
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: jruby-rake Version : 12.3.3 Upstream Author : Ruby upstream * URL : https://github.com/ruby/rake * License : Expat Programming Lang: Ruby Description : ruby make-like utility - jruby version Rake is a simple ruby build program with capabilities similar to make. . Rake has the following features: * Rakefiles (rakes version of Makefiles) are completely defined in standard Ruby syntax. No XML files to edit. No quirky Makefile syntax to worry about (is that a tab or a space?) * Users can specify tasks with prerequisites. * Rake supports rule patterns to sythesize implicit tasks. * Rake is lightweight. It can be distributed with other projects as a single file. Projects that depend upon rake do not require that rake be installed on target systems. . This version of the package is for building JRuby itself. Do not use it with the standard Ruby interpreter.
Bug#1014725: Please package newer upstream 4.6.0
A quick update. The package broke a number of packages, and problems are being addressed in Unstable before jsonschema can be uploaded there. Namely, I have already fixed: - designate - nova - python-warlock patches were provided upstream. I'm currently working on: - ironic - sahara I'm currently testing an upstream patch for Ironic, I'm not sure if there's one yet for Sahara. And I filed bugs against filed against: - bmtk - python-asdf Hopefully, I can get all fixed before the end of Debconf 22 (in a week), and then I can upload python-jsonschema to unstable. Cheers, Thomas Goirand
Bug#1015012: python-asdf: autopkgtest fail with python3-jsonschema 4.6.0
Source: python-asdf Version: 2.12.0-1 Severity: important Dear maintainer, I intend to quickly upload python3-jsonschema >= 4, because other package maintainer need that new version for their packages. I uploaded version 4.6.0 to Experimental, and the pseudo-excuses page shows failures in the autopkgtest of your package. Please see this page: https://release.debian.org/britney/pseudo-excuses-experimental.html#python-jsons This bug is using severity important, when python3-jsonschema >= 4 will reach unstable, severity of this bug will be set to serious (ie: RC bug), which can later trigger AUTORM if not addressed. Cheers, Thomas Goirand (zigo)
Bug#1015011: autopkgtest fail with python3-jsonschema 4.6.0
Source: bmtk Version: 1.0.5+ds-1 Severity: important Dear maintainer, I intend to quickly upload python3-jsonschema >= 4, because other package maintainer need that new version for their packages. I uploaded version 4.6.0 to Experimental, and the pseudo-excuses page shows failures in the autopkgtest of your package. Please see this page: https://release.debian.org/britney/pseudo-excuses-experimental.html#python-jsonschema This bug is using severity important, when python3-jsonschema >= 4 will reach unstable, severity of this bug will be set to serious (ie: RC bug), which can later trigger AUTORM if not addressed. Cheers, Thomas Goirand (zigo)
Bug#975378: O: opensysusers
On 7/3/22 22:27, Andrea Pappacoda wrote: Hi Thomas, I'd be happy to maintain this package :) Please go ahead. On Sat, 21 Nov 2020 11:50:14 +0100 Thomas Goirand wrote: > I don't want to deal with the hostility attached with packaging this anymore. > Anyone with more energy is welcome to take over. What hostility are you referring to? I mean, this is related to systemd, but still... I've had to get involved in debates which I didn't want to hear about, like, if opensysusers had value, and how should opensysusers should use dpkg-divert to get itself installed (which is the most stupid way ever to get it to replace systemd's version), and from my perspective, un-cooperative systemd maintainers. I don't care enough to waste my time, suffer too much exposition, and deal with politics on this. I'll wait for your reply before moving forward; I've attempted adopting a package before (glm) but I haven't been successful as I'm not yet a DM/DD. Please take over ASAP. Good luck! Cheers, Thomas Goirand (zigo)
Bug#1013402: python-openstacksdk: FTBFS with Sphinx 5.0, docutils 0.18: FAIL: openstack.tests.unit.identity.v2.test_role.TestRole.test_make_it
On 6/23/22 08:44, Lucas Nussbaum wrote: python-openstacksdk fails to build with Sphinx 5.0 and docutils 0.18, both of which are currently available in experimental. == FAIL: openstack.tests.unit.identity.v2.test_role.TestRole.test_make_it openstack.tests.unit.identity.v2.test_role.TestRole.test_make_it -- testtools.testresult.real._StringException: Traceback (most recent call last): File "/<>/openstack/tests/unit/base.py", line 110, in setUp config = tempfile.NamedTemporaryFile(delete=False) File "/usr/lib/python3.9/tempfile.py", line 686, in NamedTemporaryFile file = _io.open(fd, mode, buffering=buffering, IsADirectoryError: [Errno 21] Is a directory: 3 -- Ran 3856 tests in 42.074s FAILED (failures=1, skipped=1) Hi Lucas, I tried rebuilding the package, both with a normal unstable chroot, and with experimental and sphinx + docutils forced version in d/control, and I couldn't reproduce the above. Reading the stack dump gives a weird feeling, because in a normal environment, tempfile.NamedTemporaryFile() would just work. If there was a bug, it'd be in the standard Python library, which doesn't feel right either. Your thoughts? Cheers, Thomas Goirand (zigo)
Bug#1013488: horizon: FTBFS: ImportError: cannot import name 'force_text' from 'django.utils.encoding' (/usr/lib/python3/dist-packages/django/utils/encoding.py)
On 6/24/22 09:14, Lucas Nussbaum wrote: Source: horizon Version: 3:22.1.0-1 Severity: serious Justification: FTBFS Tags: bookworm sid ftbfs User: lu...@debian.org Usertags: ftbfs-20220624 ftbfs-bookworm Hi, During a rebuild of all packages in sid, your package failed to build on amd64. FYI, 51 out of 52 of the unit test failures were due to the lack of Django 4.x support in python3-django-compressor, which I fixed by uploading the latest django-compressor version. Now trying to fix the remaining... Cheers, Thomas Goirand (zigo)
Bug#989720: No need for a fix
On 6/22/22 18:19, Antoine Beaupré wrote: It's against debian/yoga, but I don't actually know what I mean or which branch I'm supposed to be using there. That's the latest OpenStack stable release. You don't need to know that, the only thing you need to know in the OpenStack team, is that you should send the merge request against whatever is the current default branch. The patch is: https://salsa.debian.org/openstack-team/third-party/openvswitch/-/merge_requests/10.patch Thanks a lot, merged! I also filed a MR against the release notes to try to get the word out there (as we can't really update the NEWS file anymore): https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/133 Great. I guess we can close this ticket when both are merged? Yeah. FYI, I'm about to release 2.17.x in Debian. I'll make sure it closes this bug. Cheers, Thomas Goirand (zigo)
Bug#1005757: python-jsonschema: Please provide latest upstream release 4.4.0
On 6/14/22 22:44, Samuel Henrique wrote: Hello Thomas, Since I added so many autopkgtest, what I can do is upload the latest version to Experimental, and let the Debian CI run its tests against what's currently in Unstable. Then the pseudo excuse page will show how it goes. Maybe you can also deal with the latest version of python-jsonschema in Experimental for a short time too? That would certainly be helpful, the diff on ansible-lint is slowly growing so it would be good to at least have it in experimental. Note I wrote to the OpenStack list and ask if we can upgrade jsonschema. Please allow a few days until I get some replies. Awesome, thank you! -- Samuel Henrique Hi Samuel, You probably saw I uploaded 4.6.0 to Experimental already. Let me know if it works well enough for you. I had to redesign a bit the package as upstream switched to Poetry (from setuptools). As you can see from here: https://release.debian.org/britney/pseudo-excuses-experimental.html#python-jsonschema there are many regressions in OpenStack, as I expected. The most worrisome is the Nova one (Nova is the core of OpenStack, the one that spawns VMs...). I'd very much prefer to have enough time to fix them before uploading jsonschema 4.6.0 to Unstable. Cheers, Thomas Goirand (zigo)
Bug#1005757: python-jsonschema: Please provide latest upstream release 4.4.0
On 5/29/22 15:08, Samuel Henrique wrote: Hello all, The recent releases of ansible-lint (>= 6.1.0) requires python-jsonschema = 4.5.1, mainly due to the following bugfix (thought there might be other changes required from that release): https://github.com/python-jsonschema/jsonschema/pull/940 Thomas, are you aware of anything specific which will break openstack or is it because it hasn't been tested yet? It's because it hasn't been tested yet. I've seen many cases were uploading a single package breaks everything... Since I added so many autopkgtest, what I can do is upload the latest version to Experimental, and let the Debian CI run its tests against what's currently in Unstable. Then the pseudo excuse page will show how it goes. Maybe you can also deal with the latest version of python-jsonschema in Experimental for a short time too? Note I wrote to the OpenStack list and ask if we can upgrade jsonschema. Please allow a few days until I get some replies. Cheers, Thomas Goirand (zigo)
Bug#1012295: RM: libisal [i386] -- ROM; FTBFS on i386
Package: ftp.debian.org Severity: normal Hi, Please remove libisal on the i386 arch. Indeed, it fails to build, because the package is trying to use non-32 bits assembler instructions. Considering what the package does (ie: Erasure coding acceleration) and the fact that there are alternatives (like jerasure) that are doing the exact same thing, I don't see the point spending more time supporting a specific arch. Also, it is very unlikely that someone will want to run such a very CPU intensive code on i386, without SSE registers, anyways. Cheers, Thomas Goirand (zigo)
Bug#1006562: Bug waiting on OpenSSL to migrate
This bug will be fixed in Testing when OpenSSL migrates... Cheers, Thomas Goirand (zigo)
Bug#1005757: python-jsonschema: Please provide latest upstream release 4.4.0
On 2/14/22 14:50, Agathe Porte wrote:
Source: python-jsonschema
Version: 3.2.0-5
Severity: wishlist
X-Debbugs-Cc: deb...@microjoe.org
Dear Maintainer,
I am currently packaging dtschema (see ITP #1005301 [0]). This package
seems to use a validator introduced in 2019 but not available in the
current 3.2 release.
Here is the test failing during package build:
==
ERROR: dtschema (unittest.loader._FailedTest)
--
ImportError: Failed to import test module: dtschema
Traceback (most recent call last):
File "/usr/lib/python3.9/unittest/loader.py", line 470, in _find_test_path
package = self._get_module_from_name(name)
File "/usr/lib/python3.9/unittest/loader.py", line 377, in
_get_module_from_name
__import__(name)
File
"/home/microjoe/dev/debian/result/dt-schema/.pybuild/cpython3_3.9_dt-schema/build/dtschema/__init__.py",
line 1, in
from dtschema.lib import (
File
"/home/microjoe/dev/debian/result/dt-schema/.pybuild/cpython3_3.9_dt-schema/build/dtschema/lib.py",
line 766, in
DTVal = jsonschema.validators.extend(jsonschema.Draft201909Validator,
{'typeSize': typeSize, 'phandle': phandle})
AttributeError: module 'jsonschema' has no attribute 'Draft201909Validator'
--
Ran 1 test in 0.000s
FAILED (errors=1)
It seems to be that providing the latest 4.4.0 release should solve this
issue, and allow me to finish the packaging of the dtschema package. The
`Draft201909Validator` was introduced a commit 6 months ago in upstream
[1].
Bests regards,
Agathe.
Hi,
python-jsonschema is packaged as part of the OpenStack components. Until
OpenStack upgrades to that version, I wont be upgrading the package.
Thanks for your understanding.
Cheers,
Thomas Goirand (zigo)
Bug#1010003: ITP: dynamic-motd -- gives some informations when you log into a server through SSH
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: dynamic-motd Version : 0.04 Upstream Author : Luc Didry * URL : https://github.com/ldidry/dynamic-motd * License : GPL-2 Programming Lang: Python Description : gives some informations when you log into a server through S dynamic-motd replaces the standard /etc/motd prompt by a more dynamic thingy, which is also modular, so you can customize the SSH motd with information from your system.
Bug#1009279: cloud-init: Please drop unneeded dependencies
On 4/11/22 00:15, Brett Holman wrote: Package: cloud-init Version: 21.4-3 Severity: normal Cloud-init no longer uses the following dependencies: python3-prettytable - since 2017 python3-six - since 2020 Both requirements were removed years ago upstream, we should drop them in Debian as well. Cheers, Brett Holman Hi Brett, Reading the source of cloud-init (ie: debian/control), prettytable and six are only build-dependencies. Was this what you meant? Cheers, Thomas Goirand (zigo)
Bug#1009112: python-eventlet: (autopkgtest) needs update for python3.10: tests.patcher_test.test_patcher_existing_locks_locked
This issue was reported upstream: https://github.com/eventlet/eventlet/issues/730 https://github.com/eventlet/eventlet/issues/739 This looks kind of serious, and not just an issue with tests. So blacklisting the failed tests isn't an option. Cheers, Thomas Goirand (zigo)
Bug#1007829: [pkg-netfilter-team] Bug#1007829: arptables - Fails to install: Too many levels of symbolic links
Hi Alberto, Thanks for your reply. I've therefore uploaded in the non-DELAYED queue. I've also pushed the changes to Salsa in a branch called "ack-nmu". Weirdly, I couldn't create a merge request out of it, so you can simply fetch that branch and merge into master and then delete that branch. Cheers, Thomas Goirand (zigo)
Bug#1009056: ITP: puppet-module-voxpupuli-unbound -- Puppet module for unbound
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: puppet-module-voxpupuli-unbound Version : 5.0.0 Upstream Author : Voxpupuli * URL : https://github.com/voxpupuli/puppet-unbound * License : Apache-2.0 Programming Lang: Puppet Description : Puppet module for unbound Puppet lets you centrally manage every important aspect of your system using a cross-platform specification language that manages all the separate elements normally aggregated in different files, like users, cron jobs, and hosts, along with obviously discrete elements like packages, services, and files. . puppet-unbound installs and configure Unbound.
Bug#1007829: [pkg-netfilter-team] Bug#1007829: arptables - Fails to install: Too many levels of symbolic links: debdiff for NMU in DELAYED/2
Hi, As per discussion on IRC and check of the existing prerm, arptables already has the logic in prerm to clean-up old symlinks, so I didn't touch it. Discussing on #debian-devel, it was agreed we need to clean-up eventual remainings of the symlink, if they point to /usr/sbin/*, so that's what I've done in the attached patch. I have attached the debdiff for the NMU that I've uploaded to delayed-2. Let me know if that's fine, or if you would like me to "dcut rm" the upload. Cheers, Thomas Goirand (zigo)diff -Nru arptables-0.0.5/debian/arptables.postinst arptables-0.0.5/debian/arptables.postinst --- arptables-0.0.5/debian/arptables.postinst 2020-05-15 12:14:42.0 +0200 +++ arptables-0.0.5/debian/arptables.postinst 2022-04-06 10:30:56.0 +0200 @@ -5,14 +5,14 @@ set -e -# compat symlinks for /sbin -> /usr/sbin move, to be dropped in buster+1 +# Clean-up the old compat symlinks for /sbin -> /usr/sbin if [ "$1" = "configure" ]; then LIST="arptables arptables-save arptables-restore" for i in $LIST; do - if [ ! -e "/sbin/$i" ]; then - ln -sf /usr/sbin/$i /sbin/$i + if [ -e "/sbin/$i" ] && [ $(readlink /sbin/$i) = /usr/sbin/$i ] ; then + rm /sbin/$i fi done fi diff -Nru arptables-0.0.5/debian/changelog arptables-0.0.5/debian/changelog --- arptables-0.0.5/debian/changelog2020-06-09 17:47:38.0 +0200 +++ arptables-0.0.5/debian/changelog2022-04-06 10:31:00.0 +0200 @@ -1,3 +1,11 @@ +arptables (0.0.5-3.1) unstable; urgency=medium + + * Non-maintainer upload. + * Do not install /sbin/* compat symlink, cleans them if they are still +present (Closes: #1007829). + + -- Thomas Goirand Wed, 06 Apr 2022 10:31:00 +0200 + arptables (0.0.5-3) unstable; urgency=medium * [9e68e1c] d/tests/control: add isolation-machine restriction to tests
Bug#1007829: [pkg-netfilter-team] Bug#1007829: arptables - Fails to install: Too many levels of symbolic links
Hi, Please find attached debdiff to fix this bug. I'll be uploading this to DELAYED/2 queue, as this is affecting a lot of people/packages and we need a fix fast. Please let me know if you prefer to fix it yourself and you wish me to "dcut rm" my upload. Cheers, Thomas Goirand (zigo)diff -Nru arptables-0.0.5/debian/arptables.postinst arptables-0.0.5/debian/arptables.postinst --- arptables-0.0.5/debian/arptables.postinst 2020-05-15 12:14:42.0 +0200 +++ arptables-0.0.5/debian/arptables.postinst 2022-04-06 10:30:56.0 +0200 @@ -5,14 +5,14 @@ set -e -# compat symlinks for /sbin -> /usr/sbin move, to be dropped in buster+1 +# Clean-up the old compat symlinks for /sbin -> /usr/sbin if [ "$1" = "configure" ]; then LIST="arptables arptables-save arptables-restore" for i in $LIST; do - if [ ! -e "/sbin/$i" ]; then - ln -sf /usr/sbin/$i /sbin/$i + if [ -e "/sbin/$i" ] && [ $(readlink /sbin/$i) = /usr/sbin/$i ] ; then + rm /sbin/$i fi done fi diff -Nru arptables-0.0.5/debian/changelog arptables-0.0.5/debian/changelog --- arptables-0.0.5/debian/changelog2020-06-09 17:47:38.0 +0200 +++ arptables-0.0.5/debian/changelog2022-04-06 10:31:00.0 +0200 @@ -1,3 +1,11 @@ +arptables (0.0.5-3.1) unstable; urgency=medium + + * Non-maintainer upload. + * Do not install /sbin/* compat symlink, cleans them if they are still +present (Closes: #1007829). + + -- Thomas Goirand Wed, 06 Apr 2022 10:31:00 +0200 + arptables (0.0.5-3) unstable; urgency=medium * [9e68e1c] d/tests/control: add isolation-machine restriction to tests
Bug#993716: Lowering severity
Hi, I have lowered the severity of this bug to allow the package to migrate back to testing. The reasoning is that, yes, there's an important issue to fix, as upgrade is broken. However, having no bridgeutils in testing is more harmful than this bug. Cheers, Thomas Goirand (zigo)
Bug#950182: [Pkg-puppet-devel] Bug#950182: Bug#950182: Puppet 5.5 EOL in November 2020
On 3/29/22 21:08, Antoine Beaupré wrote: On 2020-02-02 13:06:42, Thomas Goirand wrote: [...] FYI, I packaged and uploaded the first 2 so far, but can't push to Git. Please set me as maintainer or owner, so I can do that. Note that I'm doing a git based workflow, packaging upstream tags, rather than using pristine-tar. If this bothers anyone, please let me know (but please only complain about the workflow if you really have the intention to contribute to the packaging, otherwise you're just getting on my way to be efficient for no reason). Not sure I'm picking the right message to reply to here, but here we go. I see that you uploaded 6.16.0-1 to experimental back in December 2020: https://tracker.debian.org/news/1205795/accepted-puppet-6160-1-source-into-experimental/ Is that package in any shape to ship with bookworm? It would be great to start this transition to get the package down into testing soon... Uploading it will break current puppet-master. Unless we have a solution to replace it, I don't want to do that... Cheers, Thomas Goirand (zigo)
Bug#950182: [Pkg-puppet-devel] Bug#950182: Puppet 5.5 EOL in November 2020
On 3/29/22 21:21, Antoine Beaupré wrote: On 2022-03-29 21:14:42, Thomas Goirand wrote: On 3/29/22 20:58, Antoine Beaupré wrote: On 2020-05-16 21:13:25, Martin Konrad wrote: Hi, The others are related to other operating systems than Debian, so I really wonder if we need them (yum, really? zfs and zone are for Solaris, and scheduled_task is for windows...). If we want to make transitioning from Puppet 5 to Puppet 6 as easy as possible I think there is no way around packaging _all_ modules that were bundled with Puppet 5. Keep in mind that some users might run their Puppet master on Debian while having agents running on different operating systems that might use yum, zfs etc. Given how late we are to this party (Puppet 5 has been EOL over a year now, and Puppet 6 is still not in testing), I don't think that should be a blocker. It's kind of expected that major upgrades in Debian somewhat throw a wrench in your manifests and you need to run around like a chicken with your head cut off to plug all those leaks. That's an upstream issue, and not one we should try to fix ourselves. IMHO. The focus here should be to provide a working Puppet 6 agent, and not fight with the server-side stuff, which, BTW, is in an even worse shape because the puppetserver code is not packaged *at all* in Debian still. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830904 https://veronneau.org/puppetserver-6-a-debian-packaging-post-mortem.html Having Puppet agent 6 in Debian would at least allow us to migrate fleets to an eventually Puppetserver 7 package in Debian bookworm, or at least use the upstream Puppetserver 6/7 packages. A. Hi, I don't agree with this view. Sorry, could you clarify which part you disagree with? I believe that our users would be served better if we can finish the server side of things before uploading a new client with a different version than the server. We've seen how things are done upstream: it's ugly. Pushing our users to move to the upstream packages is a disservice. Maybe we can run a sprint during the coming debcamp so we can work on Jruby and fix everything? Cheers, Thomas Goirand (zigo)
Bug#950182: [Pkg-puppet-devel] Bug#950182: Puppet 5.5 EOL in November 2020
On 3/29/22 20:58, Antoine Beaupré wrote: On 2020-05-16 21:13:25, Martin Konrad wrote: Hi, The others are related to other operating systems than Debian, so I really wonder if we need them (yum, really? zfs and zone are for Solaris, and scheduled_task is for windows...). If we want to make transitioning from Puppet 5 to Puppet 6 as easy as possible I think there is no way around packaging _all_ modules that were bundled with Puppet 5. Keep in mind that some users might run their Puppet master on Debian while having agents running on different operating systems that might use yum, zfs etc. Given how late we are to this party (Puppet 5 has been EOL over a year now, and Puppet 6 is still not in testing), I don't think that should be a blocker. It's kind of expected that major upgrades in Debian somewhat throw a wrench in your manifests and you need to run around like a chicken with your head cut off to plug all those leaks. That's an upstream issue, and not one we should try to fix ourselves. IMHO. The focus here should be to provide a working Puppet 6 agent, and not fight with the server-side stuff, which, BTW, is in an even worse shape because the puppetserver code is not packaged *at all* in Debian still. See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830904 https://veronneau.org/puppetserver-6-a-debian-packaging-post-mortem.html Having Puppet agent 6 in Debian would at least allow us to migrate fleets to an eventually Puppetserver 7 package in Debian bookworm, or at least use the upstream Puppetserver 6/7 packages. A. Hi, I don't agree with this view. The main issue remains jruby. A lot of the other work has been mostly done. At this time, maybe we should giveup on having jruby work with Ruby 3, and accept the parts of it which are embedded (like the ruby interpreter). Cheers, Thomas Goirand (zigo)
Bug#1008262: Please package version >= 6 in Unstable
Package: python3-yaml Version: 5.4.1-1 Severity: important Hi, OpenStack Horizon needs Pyyaml >= 6. Please upload it to unstable. Note: I haven't done a team upload myself, because I'm not sure what it's going to break. Cheers, Thomas Goirand
Bug#1008155: nova: FTBFS with http_proxy or https_proxy set in environment
On 3/23/22 11:30, Andreas Beckmann wrote:
Source: nova
Version: 2:25.0.0~rc1-1
Severity: important
Hi,
nova/experimental started to FTBFS in my build environment with
FAIL:
nova.tests.unit.api.openstack.test_requestlog.TestRequestLogMiddleware.test_logs_mv
nova.tests.unit.api.openstack.test_requestlog.TestRequestLogMiddleware.test_logs_mv
--
testtools.testresult.real._StringException: pythonlogging:'': {{{2022-03-22 14:22:40,758
INFO [nova.service] Updating service version for on from 1 to 61}}}
[...]
File "/usr/lib/python3/dist-packages/wsgi_intercept/_urllib3.py", line 36,
in install
raise RuntimeError(
RuntimeError: http_proxy or https_proxy set in environment, please unset
debian/rules should probably clean the environment before runnign the tests
if that is needed.
External network access will probably be no longer available, though.
Hi,
As you can see, the fail is in wsgi_intercept, which is a library to
intercept WSGI calls, in order to mock the reply from a web server.
Everything is normal here, and working as expected.
I don't see why I should act on this. There is no requirements in Debian
that a package should be buildable with "http_proxy or https_proxy set
in environment".
Could you explain?
Cheers,
Thomas Goirand (zigo)
Bug#1006965: ITP: python-datetimerange -- library that handles time ranges
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-datetimerange Version : 1.2.0 Upstream Author : Tsuyoshi Hombashi * URL : https://github.com/thombashi/DateTimeRange * License : Expat Programming Lang: Python Description : library that handles time ranges DateTimeRange is a Python library to handle a time range. e.g. check whether a time is within the time range, get the intersection of time ranges, truncating a time range, iterate through a time range, and so forth. Note: This is a new (direct) dependency of OpenStack Rating (cloudkitty).
Bug#1006964: ITP: python-typepy -- library for variable type checker/validator/converter at a run time
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-typepy Version : 1.3.0 Upstream Author : Tsuyoshi Hombashi * URL : https://github.com/thombashi/typepy * License : Expat Programming Lang: Python Description : library for variable type checker/validator/converter at a run time Typepy is a Python library for variable type checker/validator/converter at a run time. . Feature: * checking a value type * validate a value for a type * convert a value from a type to the other type Note: this is a new indirect dependency for Cloudkitty.
Bug#1006963: ITP: python-mbstrdecoder -- multi-byte character string decoder
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-mbstrdecoder Version : 1.1.0 Upstream Author : Tsuyoshi Hombashi * URL : https://github.com/thombashi/mbstrdecoder * License : Expat Programming Lang: Python Description : multi-byte character string decoder Mbstrdecoder is a Python library for multi-byte character string decoder. Note: This is a new indirect dependency for Cloudkitty (OpenStack rating).
Bug#1006919: src:cbmc FTBFS
Source: cbmc Version: 5.12-5 Severity: serious Hi, Trying to solve #1006850, I couldn't build cbmc: make[3]: Leaving directory '/<>/src/util' ## Entering langapi /usr/bin/make -C langapi make[3]: Entering directory '/<>/src/langapi' g++ -c -DSATCHECK_MINISAT2 -MMD -MP -std=c++11 -DHAVE_MINISAT2 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Werror -Wno-parentheses -Wno-deprecated -pedantic -Wall -pedantic -Werror -Wno-deprecated-declarations -Wswitch-enum -I .. -o language_util.o language_util.cpp g++ -c -DSATCHECK_MINISAT2 -MMD -MP -std=c++11 -DHAVE_MINISAT2 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Werror -Wno-parentheses -Wno-deprecated -pedantic -Wall -pedantic -Werror -Wno-deprecated-declarations -Wswitch-enum -I .. -o language_file.o language_file.cpp In file included from language_file.cpp:9: language_file.h: In member function ‘void language_filest::remove_file(const string&)’: language_file.h:87:54: error: loop variable ‘method’ of type ‘const std::pair&’ binds to a temporary constructed from type ‘std::pair’ [-Werror=range-loop-construct] 87 | for(const std::pair : lazy_method_map) | ^~ language_file.h:87:54: note: use non-reference type ‘const std::pair’ to make the copy explicit or ‘const std::pair&’ to prevent copying cc1plus: all warnings being treated as errors make[3]: *** [../common:222: language_file.o] Error 1 Please solve it, together with #1006850. Cheers, Thomas Goirand (zigo)
Bug#1006546: python-txaio: Update to latest upstream version
On 2/27/22 13:27, Bastian Germann wrote: Source: python-txaio Severity: wishlist Please update python-txaio to the latest available upstream version, which is 22.2.1 currently. Hi, Like many other components I maintain, txaio follows OpenStack global requirements, available at: https://github.com/openstack/requirements/blob/master/upper-constraints.txt As OpenStack Yoga, which is about to be released, is using txaio 21.2.1, I'm not planning to update txaio for the next 6 months. What is the reason why you need 22.2.1? Is there something else in Debian that needs that version? If so, we may try to test OpenStack Yoga with that version before upgrading. Please let me know. Cheers, Thomas Goirand (zigo)
Bug#1003058: bullseye-pu: package openvswitch/2.15.0+ds1-2
On 2/19/22 19:04, Adam D. Barratt wrote: Control: tags -1 + confirmed On Mon, 2022-01-03 at 14:25 +0100, Thomas Goirand wrote: [ Reason ] Indeed, the updated version I would like to push contains a fix for CVE-2021-36980 (Debian bug #991308), and a fix for having libofproto properly installed if activating dpdk (which fixes #992406 and #989585). This update-alternatives fix has been in Unstable for a long time already. [ Impact ] - CVE-2021-36980. - Non-working DPDK setup when using LLDP. [ Tests ] The OVS package has a test suite that's run at build time. We also set it in real production and it worked for us. Please go ahead, thanks. Regards, Adam Uploaded. Cheers, Thomas Goirand (zigo)
Bug#1005931: Please upgrade to 3.2.0
Package: python3-oauthlib Version: 3.1.1-1 Severity: important Hi, OpenStack Yoga is about to be released, and is tested with oauthlib===3.2.0. Please upgrade python3-oauthlib to that version ASAP. Alternatively, please send me a mail to allow me to NMU the upgrade. Cheers, Thomas Goirand (zigo)
Bug#1005864: Please build depend on python3-pallets-sphinx-themes >= 2.x
Source: jinja2 Version: 3.0.3-1 Severity: important Hi, Jinja2 does not build with the Bullseye version of python3-pallets-sphinx-themes. Please build-depend on version >= 2.x of python3-pallets-sphinx-themes so that backporting is smoother. I tried backporting Jinja2 3.0.3-1 with a backported version of python3-pallets-sphinx-themes 2.0.1-1 and it works (without it, ethicalads.html does not exists). Cheers, Thomas Goirand (zigo)
Bug#1002789: python-pycdlib: FTBFS: failed tests
On 2/14/22 14:56, Lucas Nussbaum wrote: On 14/02/22 at 14:35 +0100, Thomas Goirand wrote: Hi Lucas, Please find, attached, the diff of the build log as you asked. Your thoughts? It's not the same version, are there any relevant differences? Lucas It's the same version. I just do "dch -i -m "Rebuild" to not override my build log. I haven't spotted any relevant difference, indeed... Cheers, Thomas Goirand (zigo)
Bug#1005756: RM: python-pydot-ng -- ROM; deprecated upstream
Package: ftp.debian.org Severity: normal Hi, pydot-ng and pydotplus were created as fork of pydot for OpenStack to use, because upstream wasn't responsive. When I mentionned we effectively had 2 forks for the same thing, they merged back in pydotplus. Now, pydot-ng isn't used anywhere upstream or in Debian. It's probably a good time to get rid of python-pydot-ng in Debian now that this has been solved upstream. Please remove python-pydot-ng from Debian. Cheers, Thomas Goirand (zigo)
Bug#1005632: python-novaclient: FTBFS: make[1]: pyversions: No such file or directory
Hi Lucas & Sandro, It looks like the issue isn't in novaclient, but in prettytable. Indeed, the package registers itself as version 0.0.0 (ie: it shows in the egg-info directory name and in the generated PKG-INFO file). This breaks the version detection from python3-novaclient, which leads to the FTBFS Lucas reported. I've posted a diff over here: https://salsa.debian.org/python-team/packages/prettytable/-/merge_requests/2/diffs This fixed the build of python-novaclient for me (I tried with the built version of prettytable with the mentioned patch). Sando, please either fix it yourself, or allow me to NMU the fix. Cheers, Thomas Goirand (zigo)
Bug#985072: RM: python-ceilometerclient -- ROM; Deprecated upstream
On 2/11/22 06:21, Scott Kitterman wrote: On Fri, 12 Mar 2021 15:37:02 +0100 Thomas Goirand wrote: Package: ftp.debian.org Severity: normal Hi, It's been a few OpenStack releases that there's no ceilometer-api service in OpenStack (only old-stable has it), and therefore, python-ceilometerclient is deprecated upstream. These days, Ceilometer directly pushes metrics to Gnocchi. So, let's remove python-ceilometerclient from Sid and Bullseye before we release. Zigo, What's the plan for this? It doesn't look like the rdepends situation has changed much in almost a year (there's even a new one): Checking reverse dependencies... # Broken Depends: ceilometer: python3-ceilometer heat: python3-heat openstack-meta-packages: openstack-clients vitrage-tempest-plugin: vitrage-tempest-plugin watcher: python3-watcher # Broken Build-Depends: ceilometer: python3-ceilometerclient heat: python3-ceilometerclient watcher: python3-ceilometerclient This is now the lowest numbered rm bug still open. Would you please get the rdepends sorted and then remove the moreinfo tag so we can get this done or decide it's not going to happen and close the bug. Thanks, Scott K Hi Scott, Thanks a lot for the ping, I have to admit I forgot about this. The last dependency issue was solved upstream (for Watcher, with patch at [1] merged last month), so I was able to fix all problems. I uploaded all fixes to Sid a few minutes ago, though maybe you need to wait until these are reaching testing? Please let me know. Cheers, Thomas Goirand (zigo) [1] https://review.opendev.org/c/openstack/watcher/+/823606
Bug#1005318: Please rebase cloud-init version to >= 21.1 in next debian release
On 2/11/22 09:22, Yuhua Zou wrote: Package: cloud-init Version: 20.4.1 Severity:Serious The version of package cloud-init in Debian 11.2 is 20.4.1. Ubuntu 20.4 have bundled cloud-init 21.4 in official repository. Please rebase cloud-init version to >= 21.1 in next debian release. thanks *Why cloud-init are needed to upgrade to >= 21.1:* With cloud-init version >=21.1, we can support the feature “guest OS customization with cloud-init engine” in vmware vsphere. Please check https://github.com/canonical/cloud-init <https://github.com/canonical/cloud-init> Best regards Yuhua Zou Hi Yuhua, You are reporting this issue with a severity "serious". This doesn't match the severity description (which I pasted below). What you are reporting suggests the addition of a new feature in cloud-init, which matches severity "wishlist". There's no Debian policy violation here, so it's not of severity "serious", and this is not a release critical bug. Please pay attention to these classifiers, as they help maintaining a healthy bug tracking. I'm therefore downgrading the severity of this bug to "wishlist". Please note that this has no consequence on if, how or when we are going to address this bug. Cheers, Thomas Goirand (zigo) 1 criticalmakes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package. 2 grave makes the package in question unusable by most or all users, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. 3 serious is a severe violation of Debian policy (that is, the problem is a violation of a 'must' or 'required' directive); may or may not affect the usability of the package. Note that non-severe policy violations may be 'normal,' 'minor,' or 'wishlist' bugs. (Package maintainers may also designate other bugs as 'serious' and thus release-critical; however, end users should not do so.). For the canonical list of issues deserving a serious severity you can refer to this webpage: http://release.debian.org/testing/rc_policy.txt . 4 important a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone. 5 does-not-build a bug that stops the package from being built from source. (This is a 'virtual severity'.) 6 normal a bug that does not undermine the usability of the whole package; for example, a problem with a particular option or menu item. 7 minor things like spelling mistakes and other minor cosmetic errors that do not affect the core functionality of the package. 8 wishlistsuggestions and requests for new features.
Bug#1004899: ITP: numberstation -- TOTP Authenticator application
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: numberstation Version : 1.0.1 Upstream Author : Martijn Braam * URL : https://git.sr.ht/~martijnbraam/numberstation * License : LGPL-3 Programming Lang: C, Python Description : TOTP Authenticator application A Gnome Authenticator clone. This generates 2fa tokens based on secrets installed. It registers as uri-handler for otpauth:// urls so they can be added from Megapixels.
Bug#1002956: New debdiff
On 1/29/22 20:31, Salvatore Bonaccorso wrote: Control: tags -1 + moreinfo Hi Thomas, On Sat, Jan 29, 2022 at 07:55:15PM +0100, Thomas Goirand wrote: My appologies for opening a new bug. I didn't realize #1002956 was still pending my input. I merged both bugs. Please see, attached to this message, the new debdiff, adding the fix for CVE-2021-22116 as well. See my comment from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002956#10 . Isn't the the debian/patches/series missing the listing of CVE-2021-32718_Escape_username_before_displaying_it.patch to actually apply the patch? Regards, Salvatore Correct, fixed, thanks and sorry for the mistake. I wont recreate a debdiff, but please believe me, it's fixed in the Git. Cheers, Thomas Goirand (zigo)
Bug#1002956: New debdiff
My appologies for opening a new bug. I didn't realize #1002956 was still
pending my input. I merged both bugs.
Please see, attached to this message, the new debdiff, adding the fix
for CVE-2021-22116 as well.
Cheers,
Thomas Goirand (zigo)diff -Nru rabbitmq-server-3.8.9/debian/changelog
rabbitmq-server-3.8.9/debian/changelog
--- rabbitmq-server-3.8.9/debian/changelog 2021-04-10 22:59:57.0
+0200
+++ rabbitmq-server-3.8.9/debian/changelog 2022-01-01 18:46:04.0
+0100
@@ -1,3 +1,39 @@
+rabbitmq-server (3.8.9-3+deb11u1) bullseye; urgency=medium
+
+ * CVE-2021-32719: In rabbitmq-server prior to version 3.8.18, when a
+federation link was displayed in the RabbitMQ management UI via the
+`rabbitmq_federation_management` plugin, its consumer tag was rendered
+without proper script tag sanitization. This potentially allows
+for JavaScript code execution in the context of the page. The user must
+be signed in and have elevated permissions (manage federation upstreams
+and policies) for this to occur. Applied upstream patch: Escape the
+consumer-tag value in federation mgmt.
+ * CVE-2021-32718: In rabbitmq-server prior to version 3.8.17, a new user
+being added via management UI could lead to the user's bane being
+rendered in a confirmation message without proper `script` tag
+sanitization, potentially allowing for JavaScript code execution in the
+context of the page. In order for this to occur, the user must be signed
+in and have elevated permissions (other user management).
+ * Closes: #990524
+ * Add a new README.Debian explaining how to secure RabbitMQ.
+ * Stop moving mv /etc/rabbitmq/rabbitmq.conf /etc/rabbitmq/rabbitmq-env.conf.
+ * Generate the Erlang cookie in /var/lib/rabbitmq/.erlang.cookie using
+OpenSSL, rather than letting RabbitMQ use Erlang to generate a poor entropy
+Erlang cookie, which was easily brute-forceable in 10 minutes. The OpenSSL
+generated version has order of magnitudes more possible values, which makes
+it a way harder to bruteforce. If an old Erlang cookie is detected, a new
+one is generated, and rabbitmq-server restarted if it was running.
+ * rabbitmq-server.service now correctly depends on epmd.socket and not the
+epmd@.socket, so it can correctly start after a reboot.
+ * CVE-2021-22116: RabbitMQ all versions prior to 3.8.16 are prone to a denial
+of service vulnerability due to improper input validation in AMQP 1.0
+client connection endpoint. A malicious user can exploit the vulnerability
+by sending malicious AMQP messages to the target RabbitMQ instance having
+the AMQP 1.0 plugin enabled. Added upstream patch: AMQP 1.0 binary parser:
+treat arrays with extra or missing input as fatal errors.
+
+ -- Thomas Goirand Sat, 01 Jan 2022 18:46:04 +0100
+
rabbitmq-server (3.8.9-3) unstable; urgency=medium
[ Adam Cecile ]
diff -Nru rabbitmq-server-3.8.9/debian/control
rabbitmq-server-3.8.9/debian/control
--- rabbitmq-server-3.8.9/debian/control2021-04-10 22:59:57.0
+0200
+++ rabbitmq-server-3.8.9/debian/control2022-01-01 18:46:04.0
+0100
@@ -61,6 +61,7 @@
locales-all,
logrotate,
lsb-base,
+ openssl,
socat,
${misc:Depends},
${python3:Depends},
diff -Nru
rabbitmq-server-3.8.9/debian/patches/CVE-2021-22116_AMQP_1.0_parser_treat_arrays_with_extra_or_missing_input_as_fatal_errors.patch
rabbitmq-server-3.8.9/debian/patches/CVE-2021-22116_AMQP_1.0_parser_treat_arrays_with_extra_or_missing_input_as_fatal_errors.patch
---
rabbitmq-server-3.8.9/debian/patches/CVE-2021-22116_AMQP_1.0_parser_treat_arrays_with_extra_or_missing_input_as_fatal_errors.patch
1970-01-01 01:00:00.0 +0100
+++
rabbitmq-server-3.8.9/debian/patches/CVE-2021-22116_AMQP_1.0_parser_treat_arrays_with_extra_or_missing_input_as_fatal_errors.patch
2022-01-01 18:46:04.0 +0100
@@ -0,0 +1,135 @@
+From 626d5219115d087a2695c0eb243c7ddb7e154563 Mon Sep 17 00:00:00 2001
+From: Michael Klishin
+Date: Wed, 7 Apr 2021 13:42:20 +0300
+Subject: [PATCH] Merge pull request #2953 from
+ rabbitmq/mk-amqp10-parser-infinite-loop
+
+AMQP 1.0 binary parser: treat arrays with extra or missing input as fatal
errors
+
+(cherry picked from commit f37a31de55229e6c763215500e376fa16803390b)
+---
+ .../src/amqp10_binary_parser.erl | 26 +---
+ .../test/binary_parser_SUITE.erl | 59 +++
+ 2 files changed, 78 insertions(+), 7 deletions(-)
+ create mode 100644 deps/amqp10_common/test/binary_parser_SUITE.erl
+
+diff --git a/deps/amqp10_common/src/amqp10_binary_parser.erl
b/deps/amqp10_common/src/amqp10_binary_parser.erl
+index b936f9f4ca8..376ac47aed5 100644
+--- a/deps/amqp10_common/src/amqp10_binary_parser.erl
b/deps/amqp10_common/src/amqp10_binary_parser.erl
+@@ -31,15 +31,15 @@ parse_described(Bin) ->
+ {Value, Rest2} = parse(Rest1),
+ {{described, Descriptor, Value}, Re
Bug#1004513: bullseye-pu: package rabbitmq-server/3.8.9-3
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu Hi, I have prepared an update for rabbitmq-server/3.8.9-3 targetting Bullseye. This contains numerous adjustments. The most important of them being the generation of the file /var/lib/rabbitmq/.erlang.cookie which didn't have enough entropy as per what RabbitMQ generates using Erlang. The direct consequence, is a possible remote execution vulnerability where the attacker simply bruteforce the value of the Erlang cookie. As per what the default was, there's only 200 000 000 possible values (20 upper case chars, so 26 to the power of 20), so it is estimated that in 10 minutes, someone can brutefoce the cookie value. Using "openssl rand -base64 42", we get at lease 2.6353924e+76 possible value which is considerably harder to bruteforce. Besides this, the systemd service dependency is corrected to depend on epmd.socket instead of epmd@.socket, and there's also an upstream patch for the rabbitmq monitoring interface (which is less grave, IMO). On top of this, I added a README.Debian to explain how to correctly secure a rabbitmq-server installation. Hopefully, this will help our users. One thing to note: if someone was copying the older erlang cookie to other servers part of the cluster, it *will* break the cluster, as erlang cookies wont match. However, this is IMO better than leaving an open RCE. Though I don't think this will be the majority case. I expect our users running with the wrong Erlang cookie to be running in a single node setup, and not even knowing about the cookie entropy issue. For this case, the upgrade will fix everything correctly and automatically. [ Reason ] Fixing RCE. Fixing JS bug. Adding doc how to secure rabbitmq. [ Tests ] I manually tested the new setup. The .erlang.cookie is correctly generated, and older installation gets correctly fixed. [ Risks ] Appart from the monitoring web interface of RabbitMQ, which anyways isn't mandatory for running rabbitmq-server, all changes are easy to audit. [ 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 Pleasee allow me to upload rabbitmq-server/3.8.9-3+deb11u1 for the next point release. Cheers, Thomas Goirand (zigo) diff --git a/debian/README.Debian b/debian/README.Debian new file mode 100644 index 000..9d564c4 --- /dev/null +++ b/debian/README.Debian @@ -0,0 +1,134 @@ +*** WARNING *** + +0/ Intro + +RabbitMQ, in its default configuration, is insecure. A number of +security measures are necessary to prevent remote execution of code +from malicious actors. + + +1/ Firewalling + +A default RabbitMQ installation opens the following ports, with the +following authentication schemes: + - 4369: EPMD daemon, for port lookups; IP-based auth limited to + localhost + - 5672: AMQP protcol; username/password auth + - 25672: RabbitMQ "distribution" port for inter-node communication; a + "magic cookie" shared secret for auth + +Unauthorized access to all of these ports is a security risk; you +should configure your firewall to disallow outside access to them. +Speifically, unrestricted access to the port 25672, with the default +weak secret before 3.9.8-3 (see below), EXPOSES YOUR SERVER TO A +REMOTE CODE EXECUTION VULNERABILITY. Unrestricted access to port 4369 +serves to advertise that vulnerability. + +Though not open by default, RabbitMQ may also be configured to open +the following ports, which are also strongly advised to be firewalled: + - 5671: AMQP with SSL + - 15671: Management port with SSL + - 15672: Management port without SSL + + +2/ Erlang cookie + +Prior to Debian version 3.9.8-3, rabbitmq-server generated an Erlang +"magic cookie" shared secret if one did not exist. This secret is +stored in /var/lib/rabbitmq/.erlang.cookie + +However, due to predictable seeds and a non-cryptographic randomizer, +the automatically-generated secret written by Erlang only supplies 20 +to 40 bits of entropy. This allows a remote attacker with access to +port 25672 to brute-force the "magic cookie," potentially within +minutes, authenticate as a remote node, and EXECUTE ARBITRARY CODE. + +Since 3.9.8-3, the rabbitmq-server node will use openssl to generate a +cryptographically-secure cookie during first installation, mitigating +this vulnerability. + +Servers which installed a prior version, and are upgrading to 3.9.8-3 +or higher, ARE STILL VULNERABLE, as the package will not regenerate +the secret if it exists already. This is because the secret is +designed to be shared between nodes in a cluster, and thus +regenerating it would break existing clusters. + +Operators upgrading from earlier versions of rabbitmq-server are +strongly encouraged to generate a new secret. This can be done via:
Bug#970158: pyparsing isn't Python 2 compatible: time to remove pypy support? (was: Bug#970158: Updating the pyparsing Uploaders list)
On 1/26/22 13:46, stefa...@debian.org wrote: Hi Thomas (2022.01.26_10:34:13_+) When building 3.0.7, I get: I: pybuild base:237: pypy setup.py clean Traceback (most recent call last): File "setup.py", line 8, in from pyparsing import __version__ as pyparsing_version File "/<>/pyparsing/__init__.py", line 100 major: int ^ SyntaxError: invalid syntax E: pybuild pybuild:367: clean: plugin distutils failed with: exit code=1: pypy setup.py clean This feels like we need to drop pypy support for this package. Stefano, your thoughts? How should this be handled? It can be dropped, we don't need to keep much Python 2.7 stack alive any more. I'm keeping the bare minimum for virtualenvs to function, and that doesn't require this. There is one reverse-dep, python-packaging, that should have it's 2.7 bits dropped, too. SR I saw it. The package has Matthias Klose as Maintainer, no VCS, and no team. Matthias, can I NMU "your" package to remove the pypy flavor before I fix pyparsing? Cheers, Thomas Goirand (zigo)
Bug#970158: pyparsing isn't Python 2 compatible: time to remove pypy support? (was: Bug#970158: Updating the pyparsing Uploaders list)
On 1/26/22 01:13, Nicholas D Steeves wrote: Hi Pierre-Elliott and Matthew, Pierre-Elliott Bécue writes: Source: pyparsing Version: 2.2.0+dfsg1-2 2.4.7-1 Severity: minor User: m...@qa.debian.org Usertags: mia-teammaint Barry Warsaw has retired, so can't work on the pyparsing package anymore. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. (If the person is listed as Maintainer, what we are asking is to please step in as a new maintainer.) Thanks. Pierre-Elliott, I noticed that Matthew was listed as an Uploader and that the Maintainer is the DPT. If Matthew is still active, then it should be enough to drop Barry from the list. Matthew, are you still active in Debian? If so, PyParsing needs work at Bugs #960548 and #997839, and this bug (#970158) can be solved at the same time :-) Regards, Nicholas When building 3.0.7, I get: I: pybuild base:237: pypy setup.py clean Traceback (most recent call last): File "setup.py", line 8, in from pyparsing import __version__ as pyparsing_version File "/<>/pyparsing/__init__.py", line 100 major: int ^ SyntaxError: invalid syntax E: pybuild pybuild:367: clean: plugin distutils failed with: exit code=1: pypy setup.py clean This feels like we need to drop pypy support for this package. Stefano, your thoughts? How should this be handled? Cheers, Thomas Goirand (zigo)
Bug#1004291: ITP: php-dapphp-radius -- pure PHP RADIUS client based on the SysCo/al implementation
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: php-dapphp-radius Version : 2.5.6 Upstream Author : Drew Phillips * URL : https://github.com/dapphp/radius/ * License : LGPL-3 Programming Lang: PHP Description : pure PHP RADIUS client based on the SysCo/al implementation Dapphp\Radius is a pure PHP RADIUS client for authenticating users against a RADIUS server in PHP. It currently supports basic RADIUS auth using PAP, CHAP (MD5), MSCHAP v1, and EAP-MSCHAP v2. The current 2.5.x branch is tested to work with Microsoft Windows Server 2012 to 2019 Network Policy Server and FreeRADIUS 2 and above. . PAP authentication has been tested on: * Microsoft Radius server IAS * Mideye RADIUS Server * Radl * RSA SecurID * VASCO Middleware 3.0 server * WinRadius * ZyXEL ZyWALL OTP . The PHP openssl extension is required if using MSCHAP v1 or v2. For older PHP versions that have mcrypt without openssl support, then mcrypt is used. Note: This package is to replace the gap left with php-radius removal. I intend to use that in OCI (OpenStack cluster installer) if php-radius PECL extension is not available, which hopefully makes it possible to keep Radius auth in OCI.
Bug#1003796: ITP: ifupdown-ng -- network device manager compatible with ifupdown
On 1/23/22 21:03, d...@darkboxed.org wrote: Hi Thomas, I've been working on the ifupdown-ng packaging today. I had a look at your existing git repo and did incorporate most of the debian/ files from that but decided to start the repo from scratch. The main reason being that I don't feel the gbp-import-ref workflow is quite ready yet so while I would prefer basing Debian packaging on the upstream git repo as you've done it just causes more friction right now in my experience. Hi, I'm not using gbp-import-ref, but my own tooling from openstack-pkg-tools. To import a new tag, I just do: ./debian/rules fetch-upstream-remote git merge -X theirs dch -i # edit changelog to match the new tag name ./debian/rules gen-orig-xz Maybe gbp-import-ref does the same thing? I've used this workflow for all of the OpenStack packages [1] without any issue for YEARS. I'm also not sure what kind of "friction" you're referring to... Could you add me to the debian/ifupdown-ng repo so I can push my work there? In the meantime the repo is here: https://salsa.debian.org/dxld-guest/ifupdown-ng/ One significant thing I noticed is that you seem to have Depends specifically for kfreebsd and hurd which I haven't dealt with yet. Did you test this stuff on those systems? I am not sure why I wrote these dependencies, probably because it was like that upstream already. I haven't tested on these arch, however, it should be easy to do so with Virtualbox or Qemu. FYI, when I first uploaded openrc to Debian, I used Virtualbox with the help of an OpenRC upstream author, so we could check and fix the port. These aren't official arch these days, so it maters less. Ordinarily I would think we could just go and get access porterbox for these arches but since I need to play with networking stuff for testing the porterboxes are likely not going to be much help. Right, porterbox wont be of any help here. Anyway, I have merged all of your changes to the main Salsa repository, and gave you access to it. Since you've audited my work and the package looks like in good enough shape, I have uploaded the final result. It's now up for review on the FTP master NEW queue. Let's hope it clears the NEW queue quickly... :) When it does, I very much welcome you to take care of this package as much as possible yourself, as I'm a fairly busy DD maintaining many packages. I will happily sponsor any change you want to include. Cheers, Thomas Goirand (zigo) [1] https://qa.debian.org/developer.php?login=team%2Bopenstack%40tracker.debian.org
Bug#1000637: generating debian/control is *NOT* policy compliant
Hi, Looks like the php-* PECL packages are getting their debian/control generated at build time from a debian/control.in. If you didn't know, this is *NOT* policy compliant. The policy clearly says source packages must have a not-generated debian/control in good shape (though I haven't taken the time to find where this is written in the policy, I just know it's forbidden...). Please stop doing this. If you still need to generate it, then you can have a look how the Linux kernel package does it. They generate the debian/control from control.in thanks to some internal tooling, but save the debian/control in the generated form in their source package. That may be a nice workaround, and the better way to go for you. Cheers, Thomas Goirand (zigo)
Bug#1003890: ceph-mgr won't start when backported to Bullseye
On 1/19/22 02:49, Norbert Veber wrote:
Thanks for checking! I was using the official Ceph packages from
stable, and have a cluster with a Ceph filesystem (data and metadata
pool), 3 mon and mgr nodes. Manual install.. nothing too crazy.
I compiled the sources, and installed manually with 'dpkg -i'.
Everything restarted fine except the ceph-mgr.
# ceph status
cluster:
id: c792f202-9f83-4f7c-ae08-243ef1afe1d8
health: HEALTH_WARN
no active mgr
services:
mon: 3 daemons, quorum pyre,llama,epsilon (age 34h)
mgr: no daemons active (since 10h)
mds: cephfs-ssd:1 {0=llama=up:active} 2 up:standby
osd: 4 osds: 4 up (since 34h), 4 in (since 3d)
data:
pools: 2 pools, 64 pgs
objects: 50.27k objects, 54 GiB
usage: 118 GiB used, 8.1 TiB / 8.2 TiB avail
pgs: 64 active+clean
Only changed a few config options:
pyre:~# ceph config dump
WHO MASK LEVEL OPTION VALUE RO
global advanced osd_pool_default_size 2
mon advanced auth_allow_insecure_global_id_reclaim false
mgr advanced mgr/dashboard/server_port 8083 *
mgr advanced mgr/dashboard/ssl false *
osd advanced bdev_async_discard true
osd advanced bdev_enable_discard true
Sounds like if all else fails I could blow away this cluster and make a
new one with the new version from scratch. Mostly wanted to upgrade so
I could have multiple filesystems (SSD and HDD).
I kind of want to make sure there's an upgrade path, so this is
important to address. I'll try myself soonish, maybe after Ceph Pacific
got accepted in bullseye-backports.
Cheers,
Thomas Goirand (zigo)
Bug#1003890: ceph-mgr won't start when backported to Bullseye
Hi Norbert, Because of your bug report, it made me try a backport of Ceph to Bullseye. And I couldn't experience what you had. For me, ceph-mgr started with no issue. But I wasn't doing an upgrade, this was a fresh install. Could you explain the steps you made to get to the state you described? I'll soon try an upgrade procedure as well, and see how it goes. Cheers, Thomas Goirand (zigo)
Bug#1003890: ceph-mgr won't start when backported to Bullseye
On 1/17/22 18:55, Norbert Veber wrote: Package: ceph-mgr Version: 16.2.7+ds-4 Severity: wishlist Hi, I downloaded ceph sources from unsable, and compiled sucessfully on Bullseye. However once installed/upgraded over from bullseye version of the packages I can not start ceph-mgr on any node. [...] However still not having any luck after disabling that module. Now I get this: [...] Jan 17 12:24:45 pyre ceph-mgr[67556]: 17: /lib/x86_64-linux-gnu/libpthread.so.0(+0x8ea7) [0x7efeba4feea7] Jan 17 12:24:45 pyre ceph-mgr[67556]: 18: clone() Jan 17 12:24:45 pyre ceph-mgr[67556]: NOTE: a copy of the executable, or `objdump -rdS ` is needed to interpret this. Jan 17 12:24:45 pyre ceph-mgr[67556]: -383> 2022-01-17T12:24:45.262-0500 7efe1cff9700 -1 client.0 error registering admin socket command: (17) File exists Jan 17 12:24:45 pyre ceph-mgr[67556]: -381> 2022-01-17T12:24:45.262-0500 7efe1f7fe700 -1 client.0 error registering admin socket command: (17) File exists Jan 17 12:24:45 pyre ceph-mgr[67556]: -379> 2022-01-17T12:24:45.262-0500 7efe1cff9700 -1 client.0 error registering admin socket command: (17) File exists Jan 17 12:24:45 pyre ceph-mgr[67556]: -377> 2022-01-17T12:24:45.262-0500 7efe1cff9700 -1 client.0 error registering admin socket command: (17) File exists Jan 17 12:24:45 pyre ceph-mgr[67556]: -375> 2022-01-17T12:24:45.262-0500 7efe1cff9700 -1 client.0 error registering admin socket command: (17) File exists Jan 17 12:24:45 pyre ceph-mgr[67556]: -373> 2022-01-17T12:24:45.262-0500 7efe1cff9700 -1 client.0 error registering admin socket command: (17) File exists Jan 17 12:24:45 pyre ceph-mgr[67556]: -370> 2022-01-17T12:24:45.262-0500 7efe1f7fe700 -1 client.0 error registering admin socket command: (17) File exists Jan 17 12:24:45 pyre ceph-mgr[67556]: -365> 2022-01-17T12:24:45.262-0500 7efe1f7fe700 -1 client.0 error registering admin socket command: (17) File exists Jan 17 12:24:45 pyre ceph-mgr[67556]: -361> 2022-01-17T12:24:45.262-0500 7efe1f7fe700 -1 client.0 error registering admin socket command: (17) File exists Jan 17 12:24:45 pyre ceph-mgr[67556]: -357> 2022-01-17T12:24:45.262-0500 7efe1f7fe700 -1 client.0 error registering admin socket command: (17) File exists Jan 17 12:24:45 pyre ceph-mgr[67556]: -1> 2022-01-17T12:24:45.814-0500 7efe8b1ee700 -1 ./src/crush/CrushWrapper.cc: In function 'float CrushWrapper::_get_take_weight_osd_map(int, std::map*) const' thread 7efe8b1ee700 time 2022-01-17T12:24:45.817338-0500 Jan 17 12:24:45 pyre ceph-mgr[67556]: ./src/crush/CrushWrapper.cc: 2393: FAILED ceph_assert(b) Thought I'd check to see if you have any ideas. I have no idea what FAILED ceph_assert(b) is. I assume this doesn't happen on unstable? Hi, I just tested on Sid, doing a manual install as per the documentation, and I can hereby confirm that indeed, this doesn't happen on Unstable. After starting ceph-mgr, "ceph status" shows the mgr daemon is up and running, and stays this way. I'm also interested in building Ceph for bullseye-backports, so I probably will do an official backport and run it. With all things from Ceph, this takes some times. So if you find out a fix, please do provide it in this bug report. Also, if you would like to participate to the packaging, I'd love to have contributors. It's taking a lot of my time to maintain such a huge package. Cheers, Thomas Goirand (zigo)
Bug#1003796: ITP: ifupdown-ng -- network device manager compatible with ifupdown
On 1/15/22 23:31, Daniel Gröber wrote: Package: wnpp Severity: wishlist Owner: Daniel Gröber X-Debbugs-Cc: debian-de...@lists.debian.org, d...@darkboxed.org Hi, * Package name: ifupdown-ng Version : 0.11.3 Upstream Author : Ariadne Conill Maximilian Wilhelm * URL : https://github.com/ifupdown-ng/ifupdown-ng * License : ISC Programming Lang: C, Shell Description : network device manager compatible with ifupdown ifupdown-ng is a network device manager which is backwards compatible with traditional ifup and ifdown as used on Debian and Alpine systems, while solving many design deficits with the original approach through robust error handling and the use of a dependency-solver to determine interface bring-up order. Unlike ifupdown2 (already in Debian) ifudown-ng's core is written in plain C with "executors" written in Shell talking to the kernel and system services, making it quite light yet easy to extend. See also Maximilian Wilhelm's Debconf21 talk: https://debconf21.debconf.org/talks/52-contemporary-networking-configuration-with-ifupdown-ng/ I plan on maintaining this package by myself, however I am looking for a sponsor. --Daniel Hi Daniel, There's already some kind of packaging over here: https://salsa.debian.org/debian/ifupdown-ng I started it, and then stopped, seeing that others were about to do it, in the hope to not get into the packaging of yet-another-thing. However, I'd happily be co-maintainer. Your thoughts? Cheers, Thomas Goirand (zigo)
Bug#1003714: ITP: oci-cli -- Command Line Interface for Oracle Cloud Infrastructure
On 1/14/22 07:03, Paul Wise wrote: Package: wnpp Severity: wishlist Owner: Paul Wise X-Debbugs-Cc: debian-de...@lists.debian.org, debian-cl...@lists.debian.org Control: block -1 by 1003372 * Package name: oci-cli Version : 3.4.1 Upstream Author : Mike Ross and others at Oracle * URL : https://docs.cloud.oracle.com/Content/API/Concepts/cliconcepts.htm * License : Universal Permissive License or Apache Programming Lang: Python Description : Command Line Interface for Oracle Cloud Infrastructure This package is needed by my employer for managing their OCI instances. I plan to maintain it within the Debian Cloud Team after joining it. It depends on oci-python-sdk, which I also intend to package (#1003372). Hi, Just please make sure it doesn't conflict with: packages.debian.org/openstack-cluster-installer-cli Hopefully, yours will be oci-cli, when mine is ocicli ... Cheers, Thomas Goirand (zigo)
Bug#1003469: ceph: FTBFS with fmtlib/8.1.1
On 1/14/22 05:19, Shengjing Zhu wrote: Control: tags -1 patch Please see the patch in attachment. Thanks. Hi ShengJing, Thanks a lot for your patch, I'm rebuilding (and uploading) Ceph right away. Cheers, Thomas Goirand (zigo)
Bug#1003469: ceph: FTBFS with fmtlib/8.1.1
Hi, Have you tried rebuilding the version currently in Unstable, aka Ceph Pacific, version 16.2.7+ds ? That's a few years forward, it should behave a way better, normally. It'd be great if you could try building that version of Ceph instead (I know it's asking for a lot since it takes a really long time to build Ceph, but it'd be nice if you could try...). Cheers, Thomas Goirand (zigo)
Bug#1003442: ITP: refstack-client -- OpenStack platform validation client
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: refstack-client Version : 0.0.0~2021.08.18.fa73ef2524 Upstream Author : OpenStack Foundation * URL : https://opendev.org/openinfra/refstack-client * License : Apache-2.0 Programming Lang: Python Description : OpenStack platform validation client Refstack-client is a command line utility that allows you to execute Tempest test runs based on configurations you specify. When finished running Tempest it can send the passed test data to a RefStack API server.
Bug#1003441: ITP: python-tempestconf -- automatic tempest configuration
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-tempestconf Version : 2.1.0 Upstream Author : OpenStack Foundation * URL : https://opendev.org/openinfra/python-tempestconf * License : Apache-2.0 Programming Lang: Python Description : automatic tempest configuration python-tempestconf will automatically generate the tempest configuration based on your cloud. Note: This is an indirect dependency for refstack-client, which is a tool to validate an OpenStack deployment that I'm also going to package.
Bug#1003058: bullseye-pu: package openvswitch/2.15.0+ds1-2
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
Dear release team,
I'd like to update openvswitch.
[ Reason ]
Indeed, the updated version I would like to push contains a fix for
CVE-2021-36980 (Debian bug #991308), and a fix for having libofproto
properly installed if activating dpdk (which fixes #992406 and
#989585). This update-alternatives fix has been in Unstable for a long
time already.
[ Impact ]
- CVE-2021-36980.
- Non-working DPDK setup when using LLDP.
[ Tests ]
The OVS package has a test suite that's run at build time.
We also set it in real production and it worked for us.
[ Risks ]
IMO, code is rather 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
Cheers,
Thomas Goirand (zigo)
diff -Nru openvswitch-2.15.0+ds1/debian/changelog
openvswitch-2.15.0+ds1/debian/changelog
--- openvswitch-2.15.0+ds1/debian/changelog 2021-02-20 21:58:03.0
+0100
+++ openvswitch-2.15.0+ds1/debian/changelog 2022-01-03 13:53:38.0
+0100
@@ -1,3 +1,14 @@
+openvswitch (2.15.0+ds1-2+deb11u1) bullseye; urgency=medium
+
+ * CVE-2021-36980: use-after-free in decode_NXAST_RAW_ENCAPAdd. Add upstream
+patch (Closes: #991308).
+
+ [ Felix Moessbauer ]
+ * fix ABI incompatibility that crashes OVS when enabling LLDP
+(Closes: #992406).
+
+ -- Thomas Goirand Mon, 03 Jan 2022 13:53:38 +0100
+
openvswitch (2.15.0+ds1-2) unstable; urgency=medium
* Mipsel64 and mipsel: blacklist more tests, as they are failing on these
diff -Nru openvswitch-2.15.0+ds1/debian/openvswitch-common.postinst.in
openvswitch-2.15.0+ds1/debian/openvswitch-common.postinst.in
--- openvswitch-2.15.0+ds1/debian/openvswitch-common.postinst.in
2021-02-20 21:58:03.0 +0100
+++ openvswitch-2.15.0+ds1/debian/openvswitch-common.postinst.in
2022-01-03 13:53:38.0 +0100
@@ -4,7 +4,8 @@
if [ "${1}" = "configure" ] ; then
update-alternatives --install /usr/sbin/ovs-vswitchd ovs-vswitchd
/usr/lib/openvswitch-common/ovs-vswitchd 100 \
---slave /usr/lib/%%MULTIARCH_TRIPLETT%%/libopenvswitch-2.15.so.0.0.0
libopenvswitch.so /usr/lib/openvswitch-common/libopenvswitch-2.15.so.0.0.0
+--slave /usr/lib/%%MULTIARCH_TRIPLETT%%/libopenvswitch-2.15.so.0.0.0
libopenvswitch.so /usr/lib/openvswitch-common/libopenvswitch-2.15.so.0.0.0 \
+--slave /usr/lib/%%MULTIARCH_TRIPLETT%%/libofproto-2.15.so.0.0.0
libofproto.so /usr/lib/openvswitch-common/libofproto-2.15.so.0.0.0
fi
#DEBHELPER#
diff -Nru openvswitch-2.15.0+ds1/debian/openvswitch-switch-dpdk.postinst.in
openvswitch-2.15.0+ds1/debian/openvswitch-switch-dpdk.postinst.in
--- openvswitch-2.15.0+ds1/debian/openvswitch-switch-dpdk.postinst.in
2021-02-20 21:58:03.0 +0100
+++ openvswitch-2.15.0+ds1/debian/openvswitch-switch-dpdk.postinst.in
2022-01-03 13:53:38.0 +0100
@@ -4,7 +4,8 @@
if [ "${1}" = "configure" ] ; then
update-alternatives --install /usr/sbin/ovs-vswitchd ovs-vswitchd
/usr/lib/openvswitch-switch-dpdk/ovs-vswitchd-dpdk 200 \
---slave /usr/lib/%%MULTIARCH_TRIPLETT%%/libopenvswitch-2.15.so.0.0.0
libopenvswitch.so /usr/lib/openvswitch-switch-dpdk/libopenvswitch-2.15.so.0.0.0
+--slave /usr/lib/%%MULTIARCH_TRIPLETT%%/libopenvswitch-2.15.so.0.0.0
libopenvswitch.so /usr/lib/openvswitch-switch-dpdk/libopenvswitch-2.15.so.0.0.0
\
+--slave /usr/lib/%%MULTIARCH_TRIPLETT%%/libofproto-2.15.so.0.0.0
libofproto.so /usr/lib/openvswitch-switch-dpdk/libofproto-2.15.so.0.0.0
fi
#DEBHELPER#
diff -Nru
openvswitch-2.15.0+ds1/debian/patches/CVE-2021-36980_Fix_use-after-free_while_decoding_RAW_ENCAP.patch
openvswitch-2.15.0+ds1/debian/patches/CVE-2021-36980_Fix_use-after-free_while_decoding_RAW_ENCAP.patch
---
openvswitch-2.15.0+ds1/debian/patches/CVE-2021-36980_Fix_use-after-free_while_decoding_RAW_ENCAP.patch
1970-01-01 01:00:00.0 +0100
+++
openvswitch-2.15.0+ds1/debian/patches/CVE-2021-36980_Fix_use-after-free_while_decoding_RAW_ENCAP.patch
2022-01-03 13:53:38.0 +0100
@@ -0,0 +1,87 @@
+Description: CVE-2021-36980: ofp-actions: Fix use-after-free while decoding
RAW_ENCAP.
+ While decoding RAW_ENCAP action, decode_ed_prop() might re-allocate
+ ofpbuf if there is no enough space left. However, function
+ 'decode_NXAST_RAW_ENCAP' continues to use old pointer to 'encap'
+ structure leading to write-after-free and incorrect decoding.
+ .
+ ==3549105==ERROR: AddressSanitizer: heap-use-after-free on address
+ 0x6060011a at pc 0x005f6cc6 bp 0x7ffc3a2d4410 sp 0x7ffc3a2d4408
+ WRITE of size 2 at 0x6060011a thread T0
+ #0 0x5f6cc5 in decode_NXAST_RAW_ENCAP lib/ofp-actions.c:4461:20
+ #1 0x5f0551 in ofpact_decode ./lib/of
Bug#1002956: bullseye-pu: package rabbitmq-server/3.8.9-3 CVE-2021-32718, CVE-2021-32719
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
Hi,
I'd like to update rabbitmq-server to address:
https://bugs.debian.org/990524
That's CVE-2021-32718, CVE-2021-32719.
[ Impact ]
XSS security bugs.
[ Risks ]
The patch only impacts some plugins which aren't activated
by default, so most user aren't even impacted. However, the
patches are also super-small, so why not approved them?
[ 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
Cheers,
Thomas Goirand (zigo)
diff -Nru rabbitmq-server-3.8.9/debian/changelog
rabbitmq-server-3.8.9/debian/changelog
--- rabbitmq-server-3.8.9/debian/changelog 2021-04-10 22:59:57.0
+0200
+++ rabbitmq-server-3.8.9/debian/changelog 2022-01-01 18:46:04.0
+0100
@@ -1,3 +1,23 @@
+rabbitmq-server (3.8.9-3+deb11u1) bullseye; urgency=medium
+
+ * CVE-2021-32719: In rabbitmq-server prior to version 3.8.18, when a
+federation link was displayed in the RabbitMQ management UI via the
+`rabbitmq_federation_management` plugin, its consumer tag was rendered
+without proper script tag sanitization. This potentially allows
+for JavaScript code execution in the context of the page. The user must
+be signed in and have elevated permissions (manage federation upstreams
+and policies) for this to occur. Applied upstream patch: Escape the
+consumer-tag value in federation mgmt.
+ * CVE-2021-32718: In rabbitmq-server prior to version 3.8.17, a new user
+being added via management UI could lead to the user's bane being
+rendered in a confirmation message without proper `script` tag
+sanitization, potentially allowing for JavaScript code execution in the
+context of the page. In order for this to occur, the user must be signed
+in and have elevated permissions (other user management).
+ * Closes: #990524
+
+ -- Thomas Goirand Sat, 01 Jan 2022 18:46:04 +0100
+
rabbitmq-server (3.8.9-3) unstable; urgency=medium
[ Adam Cecile ]
diff -Nru
rabbitmq-server-3.8.9/debian/patches/CVE-2021-32718_Escape_username_before_displaying_it.patch
rabbitmq-server-3.8.9/debian/patches/CVE-2021-32718_Escape_username_before_displaying_it.patch
---
rabbitmq-server-3.8.9/debian/patches/CVE-2021-32718_Escape_username_before_displaying_it.patch
1970-01-01 01:00:00.0 +0100
+++
rabbitmq-server-3.8.9/debian/patches/CVE-2021-32718_Escape_username_before_displaying_it.patch
2022-01-01 18:46:04.0 +0100
@@ -0,0 +1,21 @@
+Description: CVE-2021-32718: Escape username before displaying it
+ All other values displayed in pop-ups are already escaped.
+Author: Michael Klishin
+Date: Thu, 6 May 2021 06:57:43 +0300
+Origin: upstream,
https://github.com/rabbitmq/rabbitmq-server/commit/5d15ffc5ebfd9818fae488fc05d1f120ab02703c.patch
+Bug-Debian: https://bugs.debian.org/990524
+Last-Update: 2022-01-01
+
+diff --git a/deps/rabbitmq_management/priv/www/js/dispatcher.js
b/deps/rabbitmq_management/priv/www/js/dispatcher.js
+index d2842c2da8a..5f1b54dbac8 100644
+--- a/deps/rabbitmq_management/priv/www/js/dispatcher.js
b/deps/rabbitmq_management/priv/www/js/dispatcher.js
+@@ -189,7 +189,7 @@ dispatcher_add(function(sammy) {
+ res = sync_put(this, '/users/:username');
+ if (res) {
+ if (res.http_status === 204) {
+-username = res.req_params.username;
++username = fmt_escape_html(res.req_params.username);
+ show_popup('warn', "Updated an existing user: '" +
username + "'");
+ }
+ update();
diff -Nru
rabbitmq-server-3.8.9/debian/patches/CVE-2021-32719_Escape_the_consumer-tag_value_in_federation_mgmt.patch
rabbitmq-server-3.8.9/debian/patches/CVE-2021-32719_Escape_the_consumer-tag_value_in_federation_mgmt.patch
---
rabbitmq-server-3.8.9/debian/patches/CVE-2021-32719_Escape_the_consumer-tag_value_in_federation_mgmt.patch
1970-01-01 01:00:00.0 +0100
+++
rabbitmq-server-3.8.9/debian/patches/CVE-2021-32719_Escape_the_consumer-tag_value_in_federation_mgmt.patch
2022-01-01 18:46:04.0 +0100
@@ -0,0 +1,21 @@
+Description: CVE-2021-32719 Escape the consumer-tag value in federation mgmt
+ Patches persistent XSS.
+Author: Patrik Ragnarsson
+Date: Sat, 19 Jun 2021 09:23:12 +0200
+Origin: upstream, https://github.com/rabbitmq/rabbitmq-server/pull/3122
+Bug-Debian: https://bugs.debian.org/990524
+Last-Update: 2021-01-01
+
+diff --git
a/deps/rabbitmq_federation_management/priv/www/js/tmpl/federation-upstreams.ejs
b/deps/rabbitmq_federation_management/priv/www/js/tmpl/federation-upstreams.ejs
+index 5b3e14d0638..838eac1eb3b 100644
+---
a/deps/rabbitmq_federation_management/priv/www/js/tmpl/federation-upstre
Bug#1002953: RM: python-traceback2 -- ROM; Not needed anymore
Package: ftp.debian.org Severity: normal Hi, Traceback2 is a backport from Python 3.5 of the standard traceback library for Python2. Unittest2 used to need traceback2, but I patched it so it can now use the standard Python 3 traceback module. Unittest2 with this patch has now reached testing, so we don't need traceback2 anymore. Please remove python-traceback2 from Debian unstable and testing. Note that at some point, unittest2 will have to be removed, though it has many reverse dependencies to be addressed first. Cheers, Thomas Goirand (zigo)
Bug#960222: RM bug filed
I just asked for traceback2 removal.
Bug#732788: Processed (with 5 errors): 732788
On 12/31/21 10:14 PM, Carl Karsten wrote: > What do I need to do to get overlayroot into unstable? Hi, Thanks for your explanation, now I get it. If you want to work on this yourself, you can simply provide a merge request in the Salsa repository over here: https://salsa.debian.org/cloud-team/cloud-initramfs-tools then ping me again in this bug. Cheers, Thomas Goirand (zigo)
Bug#983940: gf-complete: ftbfs with -march=x86-64-v3
Hi Matthias, Thanks for the bug report. Since we use qemu for testing, would you know what kind of flag I need to add to the qemu command line, so that its CPU has the correct flags? Cheers, Thomas Goirand (zigo)
Bug#791445: Diff between the Debian version of jerasure and the one from Ceph
Hi,
I went ahead and checked. Diff of the "src" folder attached.
As one may see, the Debian version is superior, because it does a little
bit more input checkings. So I'm now very much convince that Ceph should
be using the version from Debian, which I'll do ASAP.
Cheers,
Thomas Goirand (zigo)
diff -u -N -r /home/zigo/salsa/openstack/third-party/jerasure/jerasure/src/galois.c src/erasure-code/jerasure/jerasure/src/galois.c
--- /home/zigo/salsa/openstack/third-party/jerasure/jerasure/src/galois.c 2017-12-27 17:12:48.044106991 +0100
+++ src/erasure-code/jerasure/jerasure/src/galois.c 2021-12-29 17:02:21.799474436 +0100
@@ -182,18 +182,6 @@
return 0;
}
-int galois_uninit_field(int w)
-{
- int ret = 0;
- if (gfp_array[w] != NULL) {
-int recursive = 1;
-ret = gf_free(gfp_array[w], recursive);
-free(gfp_array[w]);
-gfp_array[w] = NULL;
- }
- return ret;
-}
-
static void galois_init(int w)
{
if (w <= 0 || w > 32) {
diff -u -N -r /home/zigo/salsa/openstack/third-party/jerasure/jerasure/src/jerasure.c src/erasure-code/jerasure/jerasure/src/jerasure.c
--- /home/zigo/salsa/openstack/third-party/jerasure/jerasure/src/jerasure.c 2017-12-27 17:12:48.044106991 +0100
+++ src/erasure-code/jerasure/jerasure/src/jerasure.c 2021-12-30 09:51:44.751438746 +0100
@@ -246,12 +246,6 @@
if (edd > 0) {
tmpids = talloc(int, k);
-if (!tmpids) {
- free(erased);
- free(dm_ids);
- free(decoding_matrix);
- return -1;
-}
for (i = 0; i < k; i++) {
tmpids[i] = (i < lastdrive) ? i : i+1;
}
@@ -283,7 +277,6 @@
if (matrix == NULL) { return NULL; }
bitmatrix = talloc(int, k*m*w*w);
- if (!bitmatrix) return NULL;
rowelts = k * w;
rowindex = 0;
@@ -704,12 +697,6 @@
if (edd > 0) {
tmpids = talloc(int, k);
-if (!tmpids) {
- free(erased);
- free(dm_ids);
- free(decoding_matrix);
- return -1;
-}
for (i = 0; i < k; i++) {
tmpids[i] = (i < lastdrive) ? i : i+1;
}
@@ -761,10 +748,6 @@
*/
ptrs = talloc(char *, k+m);
- if (!ptrs) {
-free(erased);
-return NULL;
- }
j = k;
x = k;
@@ -854,18 +837,9 @@
}
row_ids = talloc(int, k+m);
- if (!row_ids) return NULL;
ind_to_row = talloc(int, k+m);
- if (!ind_to_row) {
-free(row_ids);
-return NULL;
- }
- if (set_up_ids_for_scheduled_decoding(k, m, erasures, row_ids, ind_to_row) < 0) {
-free(row_ids);
-free(ind_to_row);
-return NULL;
- }
+ if (set_up_ids_for_scheduled_decoding(k, m, erasures, row_ids, ind_to_row) < 0) return NULL;
/* Now, we're going to create one decoding matrix which is going to
decode everything with one call. The hope is that the scheduler
@@ -873,11 +847,6 @@
number of erasures (ddf+cdf) */
real_decoding_matrix = talloc(int, k*w*(cdf+ddf)*w);
- if (!real_decoding_matrix) {
-free(row_ids);
-free(ind_to_row);
-return NULL;
- }
/* First, if any data drives have failed, then initialize the first
ddf*w rows of the decoding matrix from the standard decoding
@@ -886,11 +855,6 @@
if (ddf > 0) {
decoding_matrix = talloc(int, k*k*w*w);
-if (!decoding_matrix) {
- free(row_ids);
- free(ind_to_row);
- return NULL;
-}
ptr = decoding_matrix;
for (i = 0; i < k; i++) {
if (row_ids[i] == i) {
@@ -904,12 +868,6 @@
ptr += (k*w*w);
}
inverse = talloc(int, k*k*w*w);
-if (!inverse) {
- free(row_ids);
- free(ind_to_row);
- free(decoding_matrix);
- return NULL;
-}
jerasure_invert_bitmatrix(decoding_matrix, inverse, k*w);
/*printf("\nMatrix to invert\n");
@@ -1251,7 +1209,6 @@
int index, optodo, i, j;
operations = talloc(int *, k*m*w*w+1);
- if (!operations) return NULL;
op = 0;
index = 0;
@@ -1260,10 +1217,6 @@
for (j = 0; j < k*w; j++) {
if (bitmatrix[index]) {
operations[op] = talloc(int, 5);
- if (!operations[op]) {
- // -ENOMEM
- goto error;
-}
operations[op][4] = optodo;
operations[op][0] = j/w;
operations[op][1] = j%w;
@@ -1277,19 +1230,8 @@
}
}
operations[op] = talloc(int, 5);
- if (!operations[op]) {
-// -ENOMEM
-goto error;
- }
operations[op][0] = -1;
return operations;
-
-error:
- for (i = 0; i <= op; i++) {
-free(operations[op]);
- }
- free(operations);
- return NULL;
}
int **jerasure_smart_bitmatrix_to_schedule(int k, int m, int w, int *bitmatrix)
@@ -1306,35 +1248,12 @@
jerasure_print_bitmatrix(bitmatrix, m*w, k*w, w); */
operations = talloc(int *, k*m*w*w+1);
- if (!operations) return NULL;
op = 0;
diff = talloc(int, m*w);
- if (!diff) {
-free(operations);
-return NULL;
- }
from = talloc(int, m*w);
- if (!from) {
-free(operations);
-free(diff);
-return NULL;
- }
flink = talloc(int
Bug#960222: Uploaded a fix for unittest2
Hi, I uploaded a fix for unittest2 so it wouldn't depend on traceback2. Let's wait until it reaches testing, and then we may attempt to remove traceback2. Cheers, Thomas Goirand (zigo)
Bug#1002789: python-pycdlib: FTBFS: failed tests
Hi Lucas, I wasn't able to reproduce the FTBFS. I'm using a normal sbuild environment, so I don't see what's different from your build. Any clue? Cheers, Thomas Goirand (zigo)
Bug#1002749: ceph: Do not upgrade to Pacific from an older version
On 12/28/21 8:32 PM, Bernd Zeimetz wrote: > Source: ceph > Version: 16.2.6+ds-8 > Severity: critical > > Hi, > > from https://docs.ceph.com/en/latest/releases/pacific/ > > > V16.2.6 PACIFIC > Danger > > DATE: 01 NOV 2021. > > DO NOT UPGRADE TO CEPH PACIFIC FROM AN OLDER VERSION. > > A recently-discovered bug (https://tracker.ceph.com/issues/53062) can cause > data corruption. This bug occurs during OMAP format conversion for clusters > that are updated to Pacific. New clusters are not affected by this bug. > > The trigger for this bug is BlueStore’s repair/quick-fix functionality. This > bug can be triggered in two known ways: > > manually via the ceph-bluestore-tool, or > > automatically, by OSD if bluestore_fsck_quick_fix_on_mount is set to true. > > The fix for this bug is expected to be available in Ceph v16.2.7. > > DO NOT set bluestore_quick_fix_on_mount to true. If it is currently set to > true in your configuration, immediately set it to false. > > DO NOT run ceph-bluestore-tool’s repair/quick-fix commands. > > > > Opening a bug to track it just in case... > > Bernd Hi Bernd, Do I get it right that I "just" need to upgrade to Ceph 16.2.7 from upstream to fix the issue? Cheers, Thomas Goirand (zigo)
Bug#1001395: python-boto: (autopkgtest) needs update for python3.10: 'Mapping' from 'collections' removed
On 12/11/21 7:15 PM, Noah Meyerhans wrote: > On Thu, Dec 09, 2021 at 04:02:24PM +0100, Paul Gevers wrote: >> Source: python-boto >> Version: 2.49.0-3 >> Severity: serious > > We should probably pursue the removal of this package before the > bookworm release rather than trying to drag it forward for another > release. It's dead upstream in favor of the python-boto3 branch. > > On sid we currently see the follow rdeps: > root@c93c6872f764:/# grep-aptavail -w -s Package -F Depends python3-boto > Package: augur > Package: debian-cloud-images-packages > Package: python3-glance > Package: heat-cfntools > Package: python3-bioblend > > Does anybody strongly object to this approach? > > noah > Speaking for those I maintain. Looks like at least glance should be switched to boto3. I just did that, but it FTBFS with something unrelated in tests... :( I don't think I'd mind so much removing heat-cfntools from Debian. I'm not sure if it's still even maintained upstream. The last release was in 2016 ... I've just asked the OpenStack mailing list. Cheers, Thomas Goirand (zigo)
Bug#995394: bullseye-pu: package horizon/3:18.6.2-5
On 12/3/21 5:47 PM, Adam D. Barratt wrote: > Control: tags -1 + confirmed > > On Thu, 2021-09-30 at 17:03 +0200, Thomas Goirand wrote: >> For some reasons, the compiled .mo translations were >> disabled in the package. This update will re-activate them. >> >> [ Reason ] >> I'm really not sure why this was desactivated (I don't remember). >> >> [ Impact ] >> No translations available in the OpenStack Dashboard. >> > > Please go ahead. > > Regards, > > Adam > Uploaded. Thomas
Bug#994064: bullseye-pu: package python-eventlet/0.26.1-7
On 12/3/21 5:25 PM, Julien Cristau wrote: > Control: tag -1 confirmed > > Hi Thomas, > > A couple of comments on the diff below, otherwise fine to go ahead. > > On Fri, Sep 10, 2021 at 09:50:25PM +0200, Thomas Goirand wrote: >> diff -Nru python-eventlet-0.26.1/debian/greendns.orig.py >> python-eventlet-0.26.1/debian/greendns.orig.py >> --- python-eventlet-0.26.1/debian/greendns.orig.py 2021-05-11 >> 08:03:43.0 +0200 >> +++ python-eventlet-0.26.1/debian/greendns.orig.py 2021-09-10 >> 21:42:12.0 +0200 > > That looks odd, this file probably shouldn't be there? This may look odd, but it's there on purpose. Look what's done in override_dh_sphinxdoc: in debian/rules, and you may understand. The debian/rules is doing some modifications to greendns.py so that the doc can be built. > [...] >> diff -Nru python-eventlet-0.26.1/debian/greendns.py >> python-eventlet-0.26.1/debian/greendns.py >> --- python-eventlet-0.26.1/debian/greendns.py2021-05-11 >> 08:03:43.0 +0200 >> +++ python-eventlet-0.26.1/debian/greendns.py2021-09-10 >> 21:42:12.0 +0200 > [...] >> def tcp(q, where, timeout=DNS_QUERY_TIMEOUT, port=53, >> @@ -794,7 +834,19 @@ >> @type source: string >> @param source_port: The port from which to send the message. >> The default is 0. >> -@type source_port: int""" >> +@type source_port: int >> +@type ignore_unexpected: bool >> +@param one_rr_per_rrset: If True, put each RR into its own >> +RRset. >> +@type one_rr_per_rrset: bool >> +@param ignore_trailing: If True, ignore trailing >> +junk at end of the received message. >> +@type ignore_trailing: bool >> +@param sock: the socket to use for the >> +query. If None, the default, a socket is created. Note that >> +if a socket is provided, it must be a nonblocking datagram socket, >> +and the source and source_port are ignored. >> +@type sock: socket.socket | None""" >> >> wire = q.to_wire() >> if af is None: > > The doc for sock here looks like a copy/paste error from the udp case, > and should be a TCP socket instead. > > Looks like > https://github.com/eventlet/eventlet/blob/master/eventlet/support/greendns.py#L861 > still has it wrong. > >> @@ -810,7 +862,10 @@ >> destination = (where, port, 0, 0) >> if source is not None: >> source = (source, source_port, 0, 0) >> -s = socket.socket(af, socket.SOCK_STREAM) >> +if sock: >> +s = sock >> +else: >> +s = socket.socket(af, socket.SOCK_STREAM) >> s.settimeout(timeout) >> try: >> expiration = compute_expiration(dns.query, timeout) I have to admit I don't really understand the above. :/ I just applied the patch that Filippo Giunchedi gave to me, and it magically worked. (multiple users reported this) > otherwise fine to go ahead. Uploaded, thanks a lot, as this issue was really a huge concern for me. Cheers, Thomas Goirand (zigo)
Bug#1000974: Info received (Bug#1000974: copy_move_algo.hpp:1083:10: error: ‘__fallthrough__’ was not declared in this scope; did you mean ‘fallthrough’?)
Please find attached to this message a debdiff fixing the problem.
Cheers,
Thomas Goirand (zigo)
diff -Nru xfsprogs-5.14.0-release/debian/changelog
xfsprogs-5.14.0-release/debian/changelog
--- xfsprogs-5.14.0-release/debian/changelog2021-11-23 21:31:02.0
+0100
+++ xfsprogs-5.14.0-release/debian/changelog2021-12-05 18:47:33.0
+0100
@@ -1,3 +1,11 @@
+xfsprogs (5.14.0-release-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add 0001-Revert-xfs-Fix-fall-through-warnings-for-Clang.patch so that
+xfslibs-dev doesn't define fallthrough globally anymore (Closes: #1000974).
+
+ -- Thomas Goirand Sun, 05 Dec 2021 18:47:33 +0100
+
xfsprogs (5.14.0-release-2) unstable; urgency=medium
* Replace the Debian-only #999879 fix by upstream patch
diff -Nru
xfsprogs-5.14.0-release/debian/patches/0001-Revert-xfs-Fix-fall-through-warnings-for-Clang.patch
xfsprogs-5.14.0-release/debian/patches/0001-Revert-xfs-Fix-fall-through-warnings-for-Clang.patch
---
xfsprogs-5.14.0-release/debian/patches/0001-Revert-xfs-Fix-fall-through-warnings-for-Clang.patch
1970-01-01 01:00:00.0 +0100
+++
xfsprogs-5.14.0-release/debian/patches/0001-Revert-xfs-Fix-fall-through-warnings-for-Clang.patch
2021-12-05 18:47:33.0 +0100
@@ -0,0 +1,343 @@
+From 1d67907760e0b4b53b894c443c70eef474dc7cce Mon Sep 17 00:00:00 2001
+From: Thomas Goirand
+Date: Sun, 5 Dec 2021 18:43:04 +0100
+Subject: [PATCH] Revert "xfs: Fix fall-through warnings for Clang"
+
+This reverts commit df9c7d8d8f3ed0785ed83e7fd0c7ddc92cbfbe15.
+---
+ include/linux.h | 21 -
+ libxfs/xfs_ag_resv.c | 4 ++--
+ libxfs/xfs_alloc.c| 2 +-
+ libxfs/xfs_da_btree.c | 2 +-
+ 4 files changed, 4 insertions(+), 25 deletions(-)
+
+Index: xfsprogs-5.14.0-release/include/linux.h
+===
+--- xfsprogs-5.14.0-release.orig/include/linux.h
xfsprogs-5.14.0-release/include/linux.h
+@@ -359,25 +359,4 @@ fsmap_advance(
+ #include
+ #endif /* HAVE_MAP_SYNC */
+
+-/*
+- * Add the pseudo keyword 'fallthrough' so case statement blocks
+- * must end with any of these keywords:
+- * break;
+- * fallthrough;
+- * continue;
+- * goto ;
+- * return [expression];
+- *
+- * gcc:
https://gcc.gnu.org/onlinedocs/gcc/Statement-Attributes.html#Statement-Attributes
+- */
+-#if defined __has_attribute
+-# if __has_attribute(__fallthrough__)
+-#define fallthrough__attribute__((__fallthrough__))
+-# else
+-#define fallthroughdo {} while (0) /* fallthrough */
+-# endif
+-#else
+-#define fallthroughdo {} while (0) /* fallthrough */
+-#endif
+-
+ #endif/* __XFS_LINUX_H__ */
+Index: xfsprogs-5.14.0-release/libxfs/xfs_ag_resv.c
+===
+--- xfsprogs-5.14.0-release.orig/libxfs/xfs_ag_resv.c
xfsprogs-5.14.0-release/libxfs/xfs_ag_resv.c
+@@ -364,7 +364,7 @@ xfs_ag_resv_alloc_extent(
+ break;
+ default:
+ ASSERT(0);
+- fallthrough;
++ /* fall through */
+ case XFS_AG_RESV_NONE:
+ field = args->wasdel ? XFS_TRANS_SB_RES_FDBLOCKS :
+ XFS_TRANS_SB_FDBLOCKS;
+@@ -406,7 +406,7 @@ xfs_ag_resv_free_extent(
+ break;
+ default:
+ ASSERT(0);
+- fallthrough;
++ /* fall through */
+ case XFS_AG_RESV_NONE:
+ xfs_trans_mod_sb(tp, XFS_TRANS_SB_FDBLOCKS, (int64_t)len);
+ return;
+Index: xfsprogs-5.14.0-release/libxfs/xfs_alloc.c
+===
+--- xfsprogs-5.14.0-release.orig/libxfs/xfs_alloc.c
xfsprogs-5.14.0-release/libxfs/xfs_alloc.c
+@@ -3170,7 +3170,7 @@ xfs_alloc_vextent(
+ }
+ args->agbno = XFS_FSB_TO_AGBNO(mp, args->fsbno);
+ args->type = XFS_ALLOCTYPE_NEAR_BNO;
+- fallthrough;
++ /* FALLTHROUGH */
+ case XFS_ALLOCTYPE_FIRST_AG:
+ /*
+* Rotate through the allocation groups looking for a winner.
+Index: xfsprogs-5.14.0-release/libxfs/xfs_da_btree.c
+===
+--- xfsprogs-5.14.0-release.orig/libxfs/xfs_da_btree.c
xfsprogs-5.14.0-release/libxfs/xfs_da_btree.c
+@@ -279,7 +279,7 @@ xfs_da3_node_read_verify(
+ __this_address);
+ break;
+ }
+- fallthrough;
++ /* fall through */
+ case XFS_DA_NODE_MAGIC:
+ fa = xfs_da3_node_verify(bp);
+ if (fa)
+Index: xfsprogs-5.14.0-release/growfs/xfs_growfs.c
+==
Bug#1000974: copy_move_algo.hpp:1083:10: error: ‘__fallthrough__’ was not declared in this scope; did you mean ‘fallthrough’?
On 12/5/21 4:50 PM, Giovanni Mascellani wrote:
> reassign 1000974 xfslibs-dev
> severity 1000974 important
> retitle 1000974 xfs/linux.h defines common word "fallthrough" breaking
> unrelated headers
> thanks
>
> Hi,
>
> On 04/12/21 23:36, Thomas Goirand wrote:
>> On 12/4/21 5:11 PM, Giovanni Mascellani wrote:
>>> Could you try running that compilation command with g++ -E, so you can
>>> see what BOOST_FALLTHROUGH is actually begin replaced with?
>>
>> Oh, sorry, now I get what you meant (did a c++ --help to understand what
>> -E was doing). Here's the result in
>> CMakeFiles/seastar.dir/src/core/file.cc.o:
>>
>> __attribute__((__attribute__((__fallthrough__;
>>
>> Probably, there's a mistake, and it should really be:
>>
>> __attribute__((__fallthrough__));
>>
>> instead, which is the source of the trouble?
>
> It seems that the problem goes this way:
>
> * Boost defines in /usr/include/boost/config/compiler/gcc.hpp:
>
> #define BOOST_FALLTHROUGH __attribute__((fallthrough))
>
> * But /usr/include/xfs/linux.h defines:
>
> #define fallthrough __attribute__((__fallthrough__))
>
> So the "fallthrough" in Boost's definition is expanded again and causes
> the problem.
>
> I think xfs/linux.h is at fault here, because it aggressively defines a
> common word (while Boost namespaces all its definitions with a BOOST_
> prefix). Unfortunately the C/C++ preprocessor makes it easy to break
> other headers if you define stuff too liberally. This wold also, for
> example, break any program that use the name "fallthrough" for a
> variable, which is a completely reasonable name to use. A simple example
> could be:
> ---
> #include
>
> int main() {
> int fallthrough = 0;
> return fallthrough;
> }
> ---
> which fails compilation with:
> ---
> $ LANG=C gcc test.c
> test.c: In function 'main':
> test.c:4:5: warning: 'fallthrough' attribute not followed by ';'
> [-Wattributes]
> 4 | int fallthrough = 0;
> | ^~~
> test.c:4:21: error: expected identifier or '(' before '=' token
> 4 | int fallthrough = 0;
> | ^
> In file included from test.c:1:
> test.c:5:12: error: expected expression before '__attribute__'
> 5 | return fallthrough;
> | ^~~
> ---
>
> You can probably work around this problem by undefining "fallthrough"
> just after the xfs/linux.h header. In the meantime I am reassigning this
> bug to xfslibs-dev.
>
> Giovanni.
Hi,
I can confirm that commenting away line 373 to 381 of xfs/linux.h solve
the troubles when building Ceph. Downgrading to 5.13.0-1 (using
snapshot.d.o) also solved the trouble, showing that 5.14.0 really is the
trouble here.
Thanks Giovanni for finding this out.
Cheers,
Thomas Goirand (zigo)
Bug#1000974: copy_move_algo.hpp:1083:10: error: ‘__fallthrough__’ was not declared in this scope; did you mean ‘fallthrough’?
On 12/4/21 5:11 PM, Giovanni Mascellani wrote: > Could you try running that compilation command with g++ -E, so you can > see what BOOST_FALLTHROUGH is actually begin replaced with? Oh, sorry, now I get what you meant (did a c++ --help to understand what -E was doing). Here's the result in CMakeFiles/seastar.dir/src/core/file.cc.o: __attribute__((__attribute__((__fallthrough__; Probably, there's a mistake, and it should really be: __attribute__((__fallthrough__)); instead, which is the source of the trouble? Cheers, Thomas Goirand (zigo)
Bug#1000974: copy_move_algo.hpp:1083:10: error: ‘__fallthrough__’ was not declared in this scope; did you mean ‘fallthrough’?
Hi, Thanks for your answer. On 12/4/21 5:11 PM, Giovanni Mascellani wrote: > Hi, > > On 01/12/21 22:21, Thomas Goirand wrote: >> Hi there! >> >> When building Ceph (current version in Experimental), since a few >> days/weeks, >> I get this: >> >> In file included from /root/ceph/ceph/src/seastar/src/core/file.cc:28: >> /usr/include/boost/container/detail/copy_move_algo.hpp: In function >> ‘typename >> boost::move_detail::enable_if_c<(boost::container::dtl::is_memtransfer_copy_assignable> G>::value && true), void>::type boost::container::deep_swap_alloc_n(A >> llocator&, F, typename >> boost::container::allocator_traits::size_type, G, typename >> boost::container::allocator_traits::size_type)’: >> /usr/include/boost/container/detail/copy_move_algo.hpp:1083:10: error: >> ‘__fallthrough__’ was not declared in this scope; did you mean >> ‘fallthrough’? >> 1083 | BOOST_FALLTHROUGH; >> | ^ > > Uhm, that's strange. For gcc that macro should resolve to > __attribute__((fallthrough)), which should just work[1]. > > [1] > https://sources.debian.org/src/boost1.74/1.74.0-13/libs/config/include/boost/config/compiler/gcc.hpp/#L323 Well, that *USED* to work, a few weeks ago, but not Ceph FTBFS because of this problem. > I don't like the idea of using the new [[...]] syntax, because that > would break all the code that is not compiling at least with C++17. Whatever you feel works better is ok for me. I never wrote that what I gave was what should be implemented, I just wrote that it made it work for me with Ceph. Probably we should find something better. > Could you try running that compilation command with g++ -E, so you can > see what BOOST_FALLTHROUGH is actually begin replaced with? Oh, that's funny, when I add -E just right after /usr/bin/c++, then it looks like it's building fine (no error message, and c++ returns zero). Now I probably need to find a way to hard-wire the -E in Ceph (which I honestly have no clue how at the time of writing this... I for the moment just tried that one file that failed, I'll need to make it a rule everywhere, probably...). Cheers, Thomas Goirand (zigo)
Bug#992330: bullseye-pu: package nova/22.2.2-1+deb11u1 (CVE-2021-3654)
Hi Julien,
Thanks for your (unfortunately late) answer.
On 12/3/21 3:11 PM, Julien Cristau wrote:
> Control: tag -1 moreinfo
>
> Hi Thomas,
>
> On Tue, Aug 17, 2021 at 12:57:50PM +0200, Thomas Goirand wrote:
>> Also, I would like to get Nova upgraded to the latest point
>> release, to fix numerous small issues. The release notes for
>> Nova are there:
>>
>> https://docs.openstack.org/releasenotes/nova/victoria.html
>>
> That looks incomplete? Please include a complete description of the
> changes you want approved.
What do you need exactly that isn't available publicly? The full commit
history for Nova Victoria stable branch is here:
https://opendev.org/openstack/nova/commits/branch/stable/victoria
Here are the commits sum-ups:
Changes in nova 22.2.0..22.2.1
--
210abc09b8 guestfs: With libguestfs >= v1.41.1 decode returned bytes to
string
7b4f479647 Dynamically archive FK related records in archive_deleted_rows
21241b38dd Add functional test for bug 1837995
382d64ea36 Centralize sqlite FK constraint enforcement
c7d9d6d9dd Fix the vGPU dynamic options race
276b8db5af Add config parameter 'live_migration_scheme' to live
migration with tls guide
5d1adb2604 libvirt: Use specific user when probing encrypted rbd disks
during extend
3d84097eab api: Log os-resetState as an instance action
831abc9f83 Use absolute path during qemu img rebase
eda11a4875 libvirt: Skip encryption metadata lookups if secret already
exists on host
Changes in nova 22.1.0..22.2.0
--
35112d7667 Handle instance = None in _local_delete_cleanup
4f17ea2f7d Add regression test for bug 1914777
3d86df068a tools: Allow check-cherry-picks.sh to be disabled by an env var
ef348c4eb3 only wait for plugtime events in pre-live-migration
8e12b81839 Disallow CONF.compute.max_disk_devices_to_attach = 0
09784db62f Prevent archiving of pci_devices records because of
'instance_uuid'
Changes in nova 22.0.1..22.1.0
--
eebf94b654 compute: Lock by instance.uuid lock during swap_volume
63d2e62c3a Use subqueryload() instead of joinedload() for (system_)metadata
6b57575092 Fallback to same-cell resize with qos ports
7366e3c375 Reproduce bug 1907522 in functional test
4e5b92545d Add upgrade check about old computes
0c5ca351e2 Warn when starting services with older than N-1 computes
e3da2ca7be lower-constraints: Bump packaging to 20.4
c3a0969329 Omit resource inventories from placement update if zero
eda458828b compute: Don't detach volumes when RescheduledException
raised without retry
95fc161334 Add regression test for bug #1899649
478be6f4fb zuul: Replace nova-live-migration with zuulv3 jobs
f4d62e1a0b Fix a hacking test
82d415d200 Add missing exception
3ecc098d28 Set instance host and drop migration under lock
d768cdbb88 Reproduce bug 1896463 in func env
9a5b6249d6 Use cell targeted context to query BDMs for metadata
Do you insist on reviewing *ALL* of the commits, one by one? As you can
read above, *all* is bugfix only.
Why don't you trust upstream bugfix releases, which contains only
targeted bugfixes only, and that goes through extensive unit and
functional testing? I also tested the point release, and I have it in
production... Products like Firefox ESR get updated this way, and it
doesn't seem to be a problem. Should OpenStack be treated differently?
If so, why?
>> [ Risks ]
>> No risk during upgrade that I know of.
>>
> That is.. not reassuring.
What do you need to re reassured?
>>* Tune nova-api-{,metadata-}uwsgi.ini for performance.
>>
>> This is a minor tweak to the uwsgi.ini default configuration,
>> which I've started pushing on all OpenStack packages in Debian.
>> It's only better with it...
>
> I don't think this is appropriate for stable. There's no information on
> what environment(s) this is tuned for, or benchmarked in.
This simply increases the number of processes.
https://salsa.debian.org/openstack-team/services/nova/-/commit/46a908d772c542eb63d9013ee71d70f820f32e4e
Note that right now, the number of threads is back to "1" (in a later
commit) because otherwise nova-api fails to work properly in some cases,
because of Eventlet threading thing.
The number of process set to 8 is only a better default because without
it, uwsgi starts with the same amount of process as core. With modern
servers, that's a way too much (imagine 32 processes on a 64 core
machine...) and may eat-up too much memory.
What's also very important is the "listen 100" which is comparable to
the same kind of directive in Apache (ie: to accept maximum 100 waiting
connections). Our bench (which I do not have handy, sorry) showed it
helps a lot with performances (approximately x2 faster).
>>* New upstream release.
>>
>> See above.
>
> I'll reserve my opinion on t
Bug#1000974: Fix for this
Hi, If in /usr/include/boost/config/compiler/gcc.hpp, line 322, I change the macro by: #define BOOST_FALLTHROUGH [[gnu::fallthrough]] then everything's fine and Ceph code compiles. Your thoughts? Cheers, Thomas Goirand (zigo)
Bug#1000974: copy_move_algo.hpp:1083:10: error: ‘__fallthrough__’ was not declared in this scope; did you mean ‘fallthrough’?
Package: libboost1.74-dev Version: 1.74.0-13 Severity: important Hi there! When building Ceph (current version in Experimental), since a few days/weeks, I get this: In file included from /root/ceph/ceph/src/seastar/src/core/file.cc:28: /usr/include/boost/container/detail/copy_move_algo.hpp: In function ‘typename boost::move_detail::enable_if_c<(boost::container::dtl::is_memtransfer_copy_assignable::value && true), void>::type boost::container::deep_swap_alloc_n(A llocator&, F, typename boost::container::allocator_traits::size_type, G, typename boost::container::allocator_traits::size_type)’: /usr/include/boost/container/detail/copy_move_algo.hpp:1083:10: error: ‘__fallthrough__’ was not declared in this scope; did you mean ‘fallthrough’? 1083 | BOOST_FALLTHROUGH; | ^ To me, it looks like a bug in Boost itself, as this is where the BOOST_FALLTHROUGH macro is defined. Note that in Ceph, I had the same issue, until I redefined the macro like this directly: #define FMT_FALLTHROUGH [[gnu::fallthrough]] removing the conditional: #if __cplusplus == 201103L || __cplusplus == 201402L which doesn't seem to get some matching, and then the error in the subject of this bug report went away, at least for the Ceph part (well, fmt which Ceph embedds...). Is this still a problem in Ceph, or am I right that it probably is an issue in Boost? I can't get my head around this issue which has been blocking me for weeks. What's annoying is that it used to build fine, and I don't know what changed in unstable to make it fail to way. If the issue is in Ceph's code, then I would happily recieve advices. Your thoughts? Cheers, Thomas Goirand (zigo)
Bug#1000862: possible fix
On 11/30/21 2:15 PM, Landry Breuil wrote: > Fwiw, i replaced eventlet/support/greendns.py by the version shipped in > eventlet 0.32.0 (eg after > https://github.com/eventlet/eventlet/commit/aeb0390094a1c3f29bb4f25a8dab96587a86b3e8) > and the minimal testcase now works. > > [30/11 14:07] root@wxs1.fluela:/tmp $sudo mv greendns.py > /usr/lib/python3/dist-packages/eventlet/support/greendns.py > [30/11 14:08] root@wxs1.fluela:/tmp $python3 ./testdnspy.py > dmfrjf4ips8xa.cloudfront.net. 60 IN A 143.204.229.111 > dmfrjf4ips8xa.cloudfront.net. 60 IN A 143.204.229.121 > dmfrjf4ips8xa.cloudfront.net. 60 IN A 143.204.229.30 > dmfrjf4ips8xa.cloudfront.net. 60 IN A 143.204.229.26 > > cf attached patch between both files. > > would it be possible to expand > https://sources.debian.org/patches/python-eventlet/0.26.1-7/Replace-dnspython-_compute_expiration-by-_compute_times.patch/ > with the full commit and ship 0.26.1-8 to bullseye, or i will have to > live with /etc/hosts kludges for now ? > > i'm not sure, but maybe sid and bookworm are also affected by the same > bug as eventlet is only 0.30.0 there. Hi Landry, I'm very much aware of the situation. We prepared a patch for Eventlet, which is waiting for the Debian Stable release team approval. Please see this bug entry: https://bugs.debian.org/994064 I'm therefore CC-ing this release team bug, since you're the 2nd person to complain that this hasn't been approved yet. If you look into this bug entry, you'll see that I am referencing a build with the patch that is available here: http://bullseye-victoria.debian.net/debian/pool/bullseye-victoria-backports-nochange/main/p/python-eventlet/ Please test python3-eventlet_0.26.1-7+deb11u1_all.deb from that place, and let me know if it works for you, and fixes the problem you are reporting here. Please write your report to 994...@bugs.debian.org so that you participate convincing the Debian Stable Release Team that this Eventlet update should happen. FYI, that's the most important bit for the release team: to know that an update doesn't break anything more, and that it's been tested. Hopefully, with your help, the updated 0.26.1-7+deb11u1 version of Eventlet can be approved into Debian Bullseye. Cheers, Thomas Goirand (zigo)
Bug#1000555: RM: flask-assets -- ROM; depends on non-maintainable python-flask-script
Package: ftp.debian.org Severity: normal Dear FTP master, Since Flask 2.0 was uploaded, python-flask-script FTBFS. python-flask-script has no support upstream, no commit since 2017. Both flask-assets and python-flask-script have no reverse dependency. So I'm hereby asking to remove both python-flask-script and flask-assets which depends on python-flask-script. Note that I asked on the Debian Python Team list, and nobody opposed to it. This bug is for flask-assets while another one has been written for python-flask-script. Cheers, Thomas Goirand
Bug#1000556: RM: python-flask-script -- ROM; FTBFS, no support upstream, no reverse dep
Package: ftp.debian.org Severity: normal Dear FTP master, Since Flask 2.0 was uploaded, python-flask-script FTBFS. python-flask-script has no support upstream, no commit since 2017. Both flask-assets and python-flask-script have no reverse dependency. So I'm hereby asking to remove both python-flask-script and flask-assets which depends on python-flask-script. Note that I asked on the Debian Python Team list, and nobody opposed to it. This bug is for python-flask-script while another one has been written for flask-assets. Cheers, Thomas Goirand
Bug#989463: provide /var/lib/shim-signed/mok/MOK.(priv|pem|der)
On 11/18/21 7:15 AM, Tomas Pospisek wrote: > On Thu, 18 Nov 2021, Thomas Goirand wrote: > >> On 11/17/21 11:01 AM, Tomas Pospisek wrote: >>> Our instructions on Secure Boot [1] are a bit scatterbrained and do not >>> specify precisely where the key should exist at. >> >> I was the one who wrote them, after *A LOT* of research about it on the >> internet. It was hard to find, really. >> >> I just explained how to sign, with no intention to have this automated >> (at the time), so no wonder there's no standard path... > > I did not intend my characterisation of the instructions as a critique > of your work. No worries, I didn't take it this way! :) >> Hopefully, we can have the automation to sign DKMS modules in a non-leaf >> package. I would strongly suggest we get a package with a very explicit >> name in it, like "dkms-automatic-mok-signing" so it would do the work. I >> would absolutely *not* go the path of disabling secure boot when a DKMS >> module gets installed... > > Since I have not looked further I am *guessing* that Ubuntu does the > automatic creation of the MOK key in the shim-signed package. So I think > it should be possible to lift Ubuntu's work out of there and also put it > into the shim-signed package, into postinst or so. > > *t As I understand, doing updates of shim-signed requires a signature from Microsoft, so probably it's not the best place to do some change. As for module automatic signatures, maybe this could go into the dkms package itself, with some kind of configuration? Again, just a suggestion... :) Cheers, Thomas Goirand (zigo)
Bug#989463: provide /var/lib/shim-signed/mok/MOK.(priv|pem|der)
On 11/17/21 11:01 AM, Tomas Pospisek wrote: > Our instructions on Secure Boot [1] are a bit scatterbrained and do not > specify precisely where the key should exist at. I was the one who wrote them, after *A LOT* of research about it on the internet. It was hard to find, really. I just explained how to sign, with no intention to have this automated (at the time), so no wonder there's no standard path... > I would edit those instruction so that they create the key at the same > location Ubuntu has its MOK keys. However I would prefer not to collide > with some tools or automation or scripts that do the same at the same > place. Please go ahead, and explain that this is the Ubuntu path. > I think it'd be preferable if Debian created (or however Ubuntu does it) > it's key automatically at that same place as Ubuntu has them, which > would make most of the instructions in the wiki [1] unnecessary and > would make the user experience much easier and smoother since the > (upstream) virtualbox package could install and sign it's modules by > itself without any user interaction, just like it happens under Ubuntu (?). > > ? Well, to begin with, I wonder why the upstream virtualbox package is pushing its compiled modules at the wrong location, but yeah, sure! Hopefully, we can have the automation to sign DKMS modules in a non-leaf package. I would strongly suggest we get a package with a very explicit name in it, like "dkms-automatic-mok-signing" so it would do the work. I would absolutely *not* go the path of disabling secure boot when a DKMS module gets installed... That's only suggestion, and I'm not volunteering, so that's only my 2 cents of comments... :) Cheers, Thomas Goirand (zigo)
Bug#999762: bullseye-pu: package lshw/02.18.85-0.7
Package: release.debian.org Severity: normal Tags: bullseye User: release.debian@packages.debian.org Usertags: pu Hi, I would like to update Bullseye with the latest version of lshw as in unstable/testing. [ Reason ] The Bullseye version of lshw has bugs with its json output, rendering the hardware report agent of openstack-cluster-installer unuseable in some cases, depending on the hardware. [ Impact ] Broken json output, non-successful hardware report in OCI. [ Tests ] We've been using the latest version of lshw for months without a glitch. [ Risks ] No risk that I can see. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [ ] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable Note: I'm not providing a debdiff, since that's just the version in unstable. I'd just upload it as: 02.19.git.2021.06.19.996aaad9c7-2~deb11u1 if you agree. Cheers, Thomas Goirand (zigo)
Bug#999644: RM: tumgreyspf -- RoQA; RC buggy, upstream vanished
On 11/14/21 9:29 AM, Scott Kitterman wrote: > Package: ftp.debian.org > Severity: normal > > This missed the last release and requires porting to a newer Python. > Upstream has also shutdown. I don't think it serves a point to keep > this in Debian anymore. > > Maintainer is cc'ed in case he has a different view. > > Scott K > I'm fine with it going away. I have to recognize I haven't done the work in time and probably wont have time to do it later. Cheers, Thomas Goirand (zigo)
Bug#981350: Closing this bug
Hi, As this is a known problem which IMO should be address upstream, there's little I can do as a package maintainer, so I'm closing this bug. Cheers, Thomas Goirand (zigo)
Bug#999557: RM: python-pika-pool -- ROM; no reverse depends, no upstream activity
Package: ftp.debian.org Severity: normal Dear FTP masters, Please remove python-pika-pool from the archive because: - There's no activity usptream (opened issues unadressed, etc.) - There's no reverse dependency in Debian anymore - The new python-pika makes this package FTBFS Cheers, Thomas Goirand (zigo)
Bug#999500: python-pika-pool test fails with python-pika 1.2.0 (currently in experimental); upstream seems inactive
Hi Sergio, Since there's no reverse dependency for this package, and as you wrote, there's no active upstream, I wonder if it's not time to simply remove python-pika-pool from Debian. Your thoughts? Cheers, Thomas Goirand (zigo)
Bug#999547: RM: python-subunit2sql -- ROM; FTBFS, not maintained upstream, no reverse depends
Package: ftp.debian.org Severity: normal Hi, python-subunit2sql used to be a (build-)dependency for python3-stestr. However, in my last upload of stestr (ie: 3.2.1-1), I removed this dependency, following what upstream did. Therefore, when stestr 3.2.1 reaches testing, we wont have any reason to keep python-subunit2sql. Please remove it from the archive, as its maintenance in Debian is no longer sustainable. Cheers, Thomas Goirand (zigo)
Bug#999392: python-wrapt ftbfs with Python 3.10 (test failures)
Hi, I just tried rebuilding the package and couldn't reproduce. What am I missing? Could you give for example an sbuild command to use? FYI, I just manually added python3.10-dev in debian/control to make sure it would be pulled, but maybe I'm missing something? Cheers, Thomas Goirand (zigo)
Bug#999457: FTBFS, no reverse deps
Package: ftp.debian.org Severity: normal Hi, Please remove python-misaka from Debian. It FTBFS, and there's no reverse dependency for this package if I'm not mistaking (let me know if I checked this wrongly). Cheers, Thomas Goirand (zigo)
Bug#999400: cloud-init: Update cloud-init in stable for newer version of Azure IMDS
On 11/10/21 5:51 PM, Noah Meyerhans wrote: > On Wed, Nov 10, 2021 at 05:05:12PM +0100, Martin Zobel-Helas wrote: >> Due to an update on the Azure side, it would be helpful to support the >> newer API version of IMDS within cloud-init, a patch, that didn't make >> it to stable, as of the time the change was made, changes on cloud-init >> weren't allowed in the Debian freeze process. >> >> The proposed change can be found here: >> https://github.com/canonical/cloud-init/pull/884/, though the patch on >> Github will not apply cleanly directly on the version of cloud-init in >> stable. I would be willing to prepare a more clean patch for that. > > Could we also get the fix for > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979974 into stable at > the same time? (Assuming it's actually needed; if you could help with > confirmation of that it would be good.) > >> Also this code only affects one cloud vendor and should not break stuff >> on other cloud vendors platform. It only adds information for IMDS. > > Agreed, I think the SRMs will be OK with this. We should show as much > evidence of testing as is practical to help ease any concerns that they > may have. > >> Would this be a patch we would agree to be carried through the full >> release cycle of Debian 11? > > It looks reasonable to me. > > noah > Martin, As per the discussion on Jitsi last evening, if you provide the patches, I can attempt to fix the package in Stable. Cheers, Thomas Goirand (zigo)
Bug#994064: python3-dnspython and eventlet incompatibility
On 11/5/21 2:02 PM, Arnaud Morin wrote: > Hey team, > I am working on installing openstack neutron from openstack victoria > extrepo. > > In my neutron config, I am setting transport-url with a fqdn, e.g.: > transport_url = rabbit://user:p...@rabbit.arnaudmorin.fr:5672 > > But, this is not working, due to a bug between eventlet (which seems to > be used by neutron) and dnspython (see [1] and [2]) > > I have two possible workarounds: > * using an IP instead of FQDN > * downgrading dnspython to <2.0.0 (1.16.0) > > I also tested the latest eventlet, but it seems too new for neutron > victoria. > > I havn't tested xena, but if it's relying on the same python > dependencies, it will also fail. > > What is the recommendation from the community about this? > Should I report this as a bug? (If so, I dont remember where, so I'd > appreciate a hint :)) > > Cheers, Arnaud. > > [1] https://github.com/eventlet/eventlet/issues/629 > [2] https://github.com/eventlet/eventlet/issues/619 Hi Arnaud, It is well known that there is an issue with Eventlet as in Bullseye, and dnspython 2.0. However, we have a patch for it. I opened a release team bug in the hope they accept the package, but so far, they haven't replied to me. Please read this bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994064 I am hereby CC-ing the bug, so that the release team sees it really affects Debian users. In advance of the release team acceptance, I have just dropped (a few minutes ago) the patched package as it will be uploaded when the stable release team accepts it: http://bullseye-victoria.debian.net/debian/pool/bullseye-victoria-backports-nochange/main/p/python-eventlet/ Pleaese try it, and let me know if it solves your troubles. If it doesn't, there's still a workaround: write in /etc/hosts all of the entries you need, like the entry for rabbit.arnaudmorin.fr as per your transport_url directive. This way, Neutron will not use the Eventlet greendns function (or at least, it will not use dnspython to resolve). Please really let me know (and the Debian bug) if the patched Eventlet fixes your trouble first though, as I didn't have the issue (because my setup always write all the cluster nodes in /etc/hosts), and I need to know if that fixes it. Cheers, Thomas Goirand (zigo)
Bug#998451: ITP: neutron-ha-tool -- additional command line utility for OpenStack Neutron HA operations
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: neutron-ha-tool Version : 0.0.3 Upstream Author : Axel Jacquet * URL : https://salsa.debian.org/openstack-team/services/neutron-ha-tool * License : Apache-2.0 Programming Lang: Python Description : additional command line utility for OpenStack Neutron HA operations Neutron HA tool allows one to manipulate the different components of OpenStack Neutron. For example, it makes it possible to delete, list or migrate all the agents that Neutron provides. This way, it is possible to delete, list or migrate virtual routers in a full HA way.
