Processed: severity
Processing commands for cont...@bugs.debian.org: > severity 990320 normal Bug #990320 [sssd] sssd - Fails after upgrade from Buster Severity set to 'normal' from 'serious' > thanks Stopping processing here. Please contact me if you need assistance. -- 990320: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990320 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#990320: [Pkg-sssd-devel] Bug#990320: sssd - Fails after upgrade from Buster
severity: normal thanks On 25.6.2021 19.07, Bastian Blank wrote: Package: sssd Version: 2.4.1-2 Severity: serious After upgrade from Buster, several components of sssd simply fail: | ● sssd-nss.socket loaded failed failed SSSD NSS Service responder socket | sssd-pac.socket loaded active listening SSSD PAC Service responder socket | ● sssd-pam-priv.socket loaded failed failed SSSD PAM Service responder private socket | ● sssd-ssh.socket loaded failed failed SSSD SSH Service responder socket | ● sssd-sudo.socket loaded failed failed SSSD Sudo Service responder socket So all the sockets are broken and the system is in degraded mode due to failed units. Bastian Check the logs for why that happens.. the above says nothing. -- t
Bug#990692: uif: does not apply filter rules anymore when started
Package: uif Severity: grave Version: 1.1.9-3 Some time ago I spotted that the "uif" firewall script when run on a Debian 11 system does not set iptables filter rules correctly anymore. Only today, I found time to investigate the cause on this issue. I have a patch ready and will upload it in a minute. Greets, Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgpYL3xIBAVxm.pgp Description: Digitale PGP-Signatur
Processed: Re: Bug#990058: libnss3: increase symbol version for SSL_GetChannelInfo when SSLChannelInfo size changes
Processing commands for cont...@bugs.debian.org: > severity 990058 normal Bug #990058 [libnss3] libnss3: increase symbol version for SSL_GetChannelInfo when SSLChannelInfo size changes Severity set to 'normal' from 'serious' > thanks Stopping processing here. Please contact me if you need assistance. -- 990058: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990058 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#990058: libnss3: increase symbol version for SSL_GetChannelInfo when SSLChannelInfo size changes
severity 990058 normal thanks With #990059 addressed in 2:3.67-2, this can be downgraded to normal. The problem also exists with other functions, which is why I'll keep this open for a more complete and long-term solution. Mike On Fri, Jun 18, 2021 at 03:09:36PM -0600, Kevin Locke wrote: > Package: libnss3 > Version: 2:3.67-1 > Severity: serious > Tags: patch > Justification: Policy 8.6.3.3 > X-Debbugs-Cc: Sebastian Ramacher , Carsten Schoenert > > > Dear Maintainer, > > Thunderbird 1:78.11.0-1 in testing is unable to establish some (all?) > TLS connections when run with libnss3 2:3.61-1, because it was built > with libnss3-dev 2:3.66-1. The issue occurs because the size of > SSLChannelInfo increased between NSS 3.61 and 3.66 (due to the addition > of PRBool isFIPS). SSL_GetChannelInfo takes both a pointer to and size > of SSLChannelInfo as arguments. If the size is greater than the size it > expects, it returns SECFailure, causing the connection to fail. See > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989839#48 for details. > > The issue is being discussed on debian-release, where Sebastian Ramacher > pointed out that the libnss3 symbol file should bump the minimum version > requirement for all symbols that works with SSLChannelInfo.[1] I agree. > As far as I can tell, SSL_GetChannelInfo is the only such symbol. I > believe it should be bumped to 2:3.66 for package 2:3.67 and bumped in > future versions whenever the size of SSLChannelInfo changes. I've > attached a patch to do so. > > Thanks for considering, > Kevin > > [1]: https://lists.debian.org/debian-release/2021/06/msg00597.html > > -- System Information: > Debian Release: 11.0 > APT prefers testing-debug > APT policy: (990, 'testing-debug'), (990, 'testing'), (500, > 'unstable-debug'), (500, 'testing-security'), (500, 'stable-debug'), (500, > 'unstable'), (500, 'oldstable'), (101, 'experimental'), (1, > 'experimental-debug') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.13.0-rc6 (SMP w/4 CPU threads) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages libnss3 depends on: > ii libc6 2.31-12 > ii libnspr4 2:4.29-1 > ii libsqlite3-0 3.34.1-3 > > libnss3 recommends no packages. > > libnss3 suggests no packages. > > -- no debconf information > >From eaffc616b99dd2be285ade5df072cfa1e30924fe Mon Sep 17 00:00:00 2001 > Message-Id: > > From: Kevin Locke > Date: Fri, 18 Jun 2021 14:41:27 -0600 > Subject: [PATCH] libnss3.symbols: bump SSL_GetChannelInfo to 2:3.66 > > PRBool isFIPS was added to SSLChannelInfo in NSS 3.66, causing its size > to increase. Since SSL_GetChannelInfo is called with > sizeof(SSLChannelInfo) and returns SECFailure when called with a larger > size than it expects, it creates a version incompatibility where > programs compiled with NSS >= 3.66 do not function correction when > loaded with NSS < 3.66, as in #989839 for thunderbird. > > To avoid breakage, bump the version of SSL_GetChannelInfo, as suggested > by Sebastian Ramacher in > https://lists.debian.org/debian-release/2021/06/msg00597.html > > Signed-off-by: Kevin Locke > --- > debian/libnss3.symbols | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/debian/libnss3.symbols b/debian/libnss3.symbols > index 5213379c..2bb7294a 100644 > --- a/debian/libnss3.symbols > +++ b/debian/libnss3.symbols > @@ -154,5 +154,5 @@ libssl3.so libnss3 #MINVER# > (symver)NSS_3.4 2:3.13.4-2~ > (symver)NSS_3.7.4 2:3.13.4-2~ > SSL_GetCipherSuiteInfo@NSS_3.4 2:3.44.0 > - SSL_GetChannelInfo@NSS_3.4 2:3.34 > + SSL_GetChannelInfo@NSS_3.4 2:3.66 > SSL_GetPreliminaryChannelInfo@NSS_3.21 2:3.44.0 > -- > 2.30.2 >
Processed: Re: Bug#988289 closed by Håvard Flaget Aasen (Re: htmldoc: CVE-2019-19630)
Processing control commands:
> fixed -1 1.8.27-8+deb9u1
Bug #988289 {Done: Håvard Flaget Aasen } [src:htmldoc]
htmldoc: CVE-2019-19630
The source 'htmldoc' and version '1.8.27-8+deb9u1' do not appear to match any
binary packages
Marked as fixed in versions htmldoc/1.8.27-8+deb9u1.
> fixed -1 1.9.3-1+deb10u1
Bug #988289 {Done: Håvard Flaget Aasen } [src:htmldoc]
htmldoc: CVE-2019-19630
Marked as fixed in versions htmldoc/1.9.3-1+deb10u1.
--
988289: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988289
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#988289: closed by Håvard Flaget Aasen (Re: htmldoc: CVE-2019-19630)
Control: fixed -1 1.8.27-8+deb9u1 Control: fixed -1 1.9.3-1+deb10u1 'Control: bts command' does not work on -done@, thus resending the commands. Andreas
Bug#990692: marked as done (uif: does not apply filter rules anymore when started)
Your message dated Sun, 04 Jul 2021 21:33:23 + with message-id and subject line Bug#990692: fixed in uif 1.1.9-5 has caused the Debian Bug report #990692, regarding uif: does not apply filter rules anymore when started to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 990692: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990692 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: uif Severity: grave Version: 1.1.9-3 Some time ago I spotted that the "uif" firewall script when run on a Debian 11 system does not set iptables filter rules correctly anymore. Only today, I found time to investigate the cause on this issue. I have a patch ready and will upload it in a minute. Greets, Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de pgps4FL6LXjHg.pgp Description: Digitale PGP-Signatur --- End Message --- --- Begin Message --- Source: uif Source-Version: 1.1.9-5 Done: Mike Gabriel We believe that the bug you reported is fixed in the latest version of uif, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 990...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Mike Gabriel (supplier of updated uif package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 04 Jul 2021 22:59:36 +0200 Source: uif Architecture: source Version: 1.1.9-5 Distribution: unstable Urgency: medium Maintainer: Mike Gabriel Changed-By: Mike Gabriel Closes: 990692 Changes: uif (1.1.9-5) unstable; urgency=medium . * debian/patches: + Add 1003_correctly-quote-when-opening-pipe.patch. Use double quotes in open statement to properly evaluate variables. (Closes: #990692). Checksums-Sha1: dedd0a023a042f32ba051764ea28cb5af6bd5647 1803 uif_1.1.9-5.dsc 90d00e4588b71c6d8c5d628c05de5d5b0be46164 27040 uif_1.1.9-5.debian.tar.xz f70ff92b12390c1ca9f8a9c59b35b20ae09fb466 5893 uif_1.1.9-5_source.buildinfo Checksums-Sha256: 410f8e98a8c84fc5e09c2f575777f7363c3ad0bcc4bf20168a2c4129f7b442c2 1803 uif_1.1.9-5.dsc ecf2b9f16b9d092413c45c227c1b4ecbe6c71140c909b940a9f140da850d9959 27040 uif_1.1.9-5.debian.tar.xz 1bc55f33b8bea6a3a113d6260191a600d4d69eeedb8acbbf37525ba53892b0df 5893 uif_1.1.9-5_source.buildinfo Files: 0fd0d348edba796fef4b8d7ce0fd07ce 1803 net optional uif_1.1.9-5.dsc 7e0a149828583624c322a6df60754f3a 27040 net optional uif_1.1.9-5.debian.tar.xz f48f6af7ff6a3eeb7de3ff59d6bbbcd0 5893 net optional uif_1.1.9-5_source.buildinfo -BEGIN PGP SIGNATURE- iQJJBAEBCAAzFiEEm/uu6GwKpf+/IgeCmvRrMCV3GzEFAmDiJYIVHHN1bndlYXZl ckBkZWJpYW4ub3JnAAoJEJr0azAldxsx1ygQAJHizA9EScZwE2f1euZgLp19BPJq TPqgo3QuiW68q7Em1idVVn/QzuaYjxq6xufxZCZN0dU18NoiPVtXHvdMcA9+bBY+ BtPpWk++60fqU89rjxY4oCwMcYxxiu9WgvR50B1H5l03Nwyal14salhaj3v3emB4 MseZ2dii/EubuGNDHd+LD3SWdaNGOvdUoDoU9TDq/aDzv/JRTe8tIqaOEZi1WveB 9qZQY3KwOoOxbCswESBLvsWWCFXUrJ8Xe6VbkZ2Qu7gAXTB/gZ3MHn7NqXcfmLEB gPPa0LmOPRfn8ehcppj58gbzSMyYJwSrf4AicQfXLGM1cXwHoPN5fxcOLKi1zsWk MHIvDRfKeBXM/Sv6F6QLxKo9AWq5XgZJt/PtUFdh4EgoYLDGdwIVcevTbm+iSSE3 NfNSXGooNjufYE1EDh8KGNYbLJ/GXExasry3e0lO8vhX7m3MgZYkz51g14JPgwbY 0EKEA2AbT9Ig/oqMw+v8DVlZDS+6qKvjogUMkU21cavVgFMVjTWeVqnVQrFCqRi9 Hq3uIiI3muGuqSd5sjOnvU2SDsRoer64Jy53YgirdWi3RRQThQsICdtEfLSUGar0 OkoRGM8sDuI1GgXQiX+S8EPlsko9G1i2HEUm02apkVxkUn1xh26WiW9RPhbBSPRE +GRMPEOCOIkr2orI =rLMH -END PGP SIGNATURE End Message ---
Bug#988289: marked as done (htmldoc: CVE-2019-19630)
Your message dated Sun, 4 Jul 2021 22:39:56 +0200 with message-id and subject line Re: htmldoc: CVE-2019-19630 has caused the Debian Bug report #988289, regarding htmldoc: CVE-2019-19630 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 988289: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988289 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: htmldoc Version: 1.8.27-8 Severity: serious Tags: security User: debian...@lists.debian.org Usertags: piuparts Control: fixed -1 1.8.27-8+deb8u1 Control: fixed -1 1.9.7-1 Hi, CVE-2019-19630 is fixed in jessie-lts but not stretch-lts, making upgrades difficult since jessie-security has a newer version than stretch(-security). Please upload the fix to stretch-lts, too. And as it looks, this is also unfixed in buster. htmldoc | 1.8.27-8| jessie | source htmldoc | 1.8.27-8| stretch | source htmldoc | 1.8.27-8+deb8u1 | jessie-security | source htmldoc | 1.9.3-1 | buster | source htmldoc | 1.9.11-2| bullseye| source htmldoc | 1.9.11-2| sid | source Andreas --- End Message --- --- Begin Message --- Control: fixed -1 1.8.27-8+deb9u1 Control: fixed -1 1.9.3-1+deb10u1 Hi, Patches from upstream have been applied to fix CVE-2019-19630, in both stretch and buster. The version in stretch is now 1.8.27-8+deb9u1, which also eases the upgrade from jessie. Regards, Håvard--- End Message ---
Processed: unarchiving 987374, cloning 987374, retitle -1 to gpac: CVE-2020-35980 ..., found -1 in 1.0.1+dfsg1-4
Processing commands for cont...@bugs.debian.org:
> unarchive 987374
Bug #987374 {Done: Reinhard Tartler } [src:gpac] gpac:
CVE-2020-35979 CVE-2020-35980 CVE-2020-35981 CVE-2020-35982
Unarchived Bug 987374
> clone 987374 -1
Bug #987374 {Done: Reinhard Tartler } [src:gpac] gpac:
CVE-2020-35979 CVE-2020-35980 CVE-2020-35981 CVE-2020-35982
Bug 987374 cloned as bug 990691
> # CVE-2020-35980 yet unfixed
> retitle -1 gpac: CVE-2020-35980
Bug #990691 {Done: Reinhard Tartler } [src:gpac] gpac:
CVE-2020-35979 CVE-2020-35980 CVE-2020-35981 CVE-2020-35982
Changed Bug title to 'gpac: CVE-2020-35980' from 'gpac: CVE-2020-35979
CVE-2020-35980 CVE-2020-35981 CVE-2020-35982'.
> forwarded -1 https://github.com/gpac/gpac/issues/1661
Bug #990691 {Done: Reinhard Tartler } [src:gpac] gpac:
CVE-2020-35980
Set Bug forwarded-to-address to 'https://github.com/gpac/gpac/issues/1661'.
> found -1 1.0.1+dfsg1-4
Bug #990691 {Done: Reinhard Tartler } [src:gpac] gpac:
CVE-2020-35980
Marked as found in versions gpac/1.0.1+dfsg1-4; no longer marked as fixed in
versions gpac/1.0.1+dfsg1-4 and reopened.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
987374: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987374
990691: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990691
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#988214: Bug#989037: Bug#988214: fixed in rails 2:6.0.3.7+dfsg-1
Hi Utkarsh, On Fri, Jun 18, 2021 at 10:23:39PM +0200, Paul Gevers wrote: > Hi Utkarsh > > On 06-06-2021 06:14, Paul Gevers wrote: > > I am hoping it's possible to just downgrade the *dependency* in rails > > only, such that the upload can happen via unstable. There is no "direct > > bullseye" route. Or do you expect you'll have to make (lots) of changes > > to rails to match the right ruby-marcel package? If that's the case, > > than ruby-marcel/unstable isn't a drop in replacement for > > ruby-marcel/bullseye and I'd expect that ruby-marcel/unstable would need > > a versioned Breaks for reverse dependent packages (ruby-activestorage), > > but I'm not seeing that. > > Did your experimenting (as discussed on IRC last week) yield anything? Since the bullseye release is fastly approaching, do you have any news on the above? Regards, Salvatore
Bug#990183: libopenscap8: libopenscap.so.8 is missing from libopenscap8 and is expected by scap-workbench
Hi
On 2021-07-04 04:04:13 +0900, Hideki Yamane wrote:
> On Sat, 3 Jul 2021 21:36:53 +0900
> Hideki Yamane wrote:
> > Mostly done, still have an error with autopkgtest for python3-openscap
>
> Updated. Passed all salsa-ci test as below, and eliminate most of
> lintian warning/info.
> https://salsa.debian.org/henrich/openscap/-/pipelines/265972
>
>
> diff -Nru openscap-1.3.4/debian/changelog openscap-1.3.4/debian/changelog
> --- openscap-1.3.4/debian/changelog 2021-02-02 00:22:30.0 +0900
> +++ openscap-1.3.4/debian/changelog 2021-06-30 16:33:53.0 +0900
> @@ -1,3 +1,37 @@
> +openscap (1.3.4-1.1) UNRELEASED; urgency=medium
> +
> + * Non-maintainer upload.
> +
> + * Package structure changes
> +- Apply soname change (libopenscap8 -> 25)
> +- Split libopenscap25 to openscap-scanner, openscap-utils and
> + openscap-common
> +- Drop -dbg package and unnecessary lintian-overrides
> + * debian/control
> +- Specify https for upstream URL
> +- Use debhelper-compat (= 13) to not forget to install necessary files
> + with dh_missing
> +- Add missing dependencies: libacl1-dev, libblkid-dev, libglib2.0-dev,
> + libyaml-dev, librpm-dev, libpopt-dev, libprocps-dev, libopendbx1-dev,
> + libxmlsec1-dev, doxygen, graphviz, asciidoc,
> + * Drop unnecessary debian/compat
> + * debian/rules
> +- Enable documentation build
> +- Enable hardening
> + * Add openscap-common.docs to install HTML docs
> + * debian/openscap-scanner.install
> +- Install bash-completion
> + * openscap-utils.install
> +- Install autotailor and scap-as-rpm
> + * Add debian/openscap-{scanner,utils}.manpages
> +
> + * Trim trailing whitespace.
> + * Update watch file format version to 4.
> + * Set upstream metadata fields: Bug-Database, Bug-Submit.
> + * Drop unnecessary dependency on dh-autoreconf.
> +
> + -- Hideki Yamane Wed, 30 Jun 2021 16:33:53 +0900
Doing a transition now and adding new binary packages is already
stretching the rules a lot. So please keep all the other changes to a
minimum. Especially changing debhelper compat level is undesirable
during the freeze (see
https://release.debian.org/bullseye/freeze_policy.html)
More comments below.
> +
> openscap (1.3.4-1) unstable; urgency=medium
>
>* New upstream version 1.3.4
> diff -Nru openscap-1.3.4/debian/compat openscap-1.3.4/debian/compat
> --- openscap-1.3.4/debian/compat 2021-02-02 00:22:30.0 +0900
> +++ openscap-1.3.4/debian/compat 1970-01-01 09:00:00.0 +0900
> @@ -1 +0,0 @@
> -11
> diff -Nru openscap-1.3.4/debian/control openscap-1.3.4/debian/control
> --- openscap-1.3.4/debian/control 2021-02-02 00:22:30.0 +0900
> +++ openscap-1.3.4/debian/control 2021-06-30 16:33:53.0 +0900
> @@ -2,7 +2,7 @@
> Priority: optional
> Maintainer: Pierre Chifflier
> Uploaders: Philippe Thierry
> -Build-Depends: debhelper (>= 13),
> +Build-Depends: debhelper-compat (= 13),
> cmake,
> libpcre3-dev,
> libxml2-dev,
> @@ -18,19 +18,30 @@
> libattr1-dev,
> libldap2-dev,
> libbz2-dev,
> +libacl1-dev,
> +libblkid-dev,
> +libglib2.0-dev,
> +libyaml-dev,
> +librpm-dev,
> +libpopt-dev,
> +libprocps-dev,
> +libopendbx1-dev,
> +libxmlsec1-dev,
> +doxygen, graphviz,
> +asciidoc,
> pkg-config,
> dh-python,
> chrpath,
> libdbus-1-dev
> +Section: admin
> X-Python3-Version: >= 3.9
> Standards-Version: 4.5.1
> -Section: libs
> -Homepage: http://www.open-scap.org/
> +Homepage: https://www.open-scap.org/
>
> Package: libopenscap-dev
> Section: libdevel
> Architecture: linux-any
> -Depends: libopenscap8 (= ${binary:Version}), ${misc:Depends},
> ${python3:Depends}, libjs-jquery
> +Depends: libopenscap25 (= ${binary:Version}), ${misc:Depends},
> ${python3:Depends}, libjs-jquery
> Description: Set of libraries enabling integration of the SCAP line of
> standards
> OpenSCAP is a set of open source libraries providing an easier path
> for integration of the SCAP line of standards. SCAP is a line of
> @@ -48,13 +59,13 @@
> .
> This package contains the development files for OpenSCAP.
>
> -Package: libopenscap8
> +Package: libopenscap25
> Section: libs
> Architecture: linux-any
> -Conflicts: libopenscap0, libopenscap1, libopenscap3
> -Replaces: libopenscap0, libopenscap1, libopenscap3
> +Conflicts: libopenscap0, libopenscap1, libopenscap3, libopenscap8,
> +Replaces: libopenscap0, libopenscap1, libopenscap3, libopenscap8,
> Pre-Depends: ${misc:Pre-Depends}
> -Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends}
> +Depends: ${shlibs:Depends}, ${misc:Depends},
> Description: Set of libraries enabling integration of the SCAP line of
> standards
> OpenSCAP is a set of open source libraries providing an easier path
> for integration of the SCAP line of standards. SCAP is a line of
> @@ -69,11 +80,13 @@
>* Common Vulnerability Scoring System (CVSS
Processed: Re: Bug#924009: closed by Dimitrios Eftaxiopoulos (Bug not reproduced)
Processing control commands: > reassign -1 src:freefem++ Bug #924009 [freefem++] FreeFem++ crashes with exit status 132 Bug reassigned from package 'freefem++' to 'src:freefem++'. Ignoring request to alter found versions of bug #924009 to the same values previously set Ignoring request to alter fixed versions of bug #924009 to the same values previously set > severity -1 serious Bug #924009 [src:freefem++] FreeFem++ crashes with exit status 132 Severity set to 'serious' from 'important' > retitle -1 Baseline violation in i386 (-mmx -msse2) and amd64 (-mavx) Bug #924009 [src:freefem++] FreeFem++ crashes with exit status 132 Changed Bug title to 'Baseline violation in i386 (-mmx -msse2) and amd64 (-mavx)' from 'FreeFem++ crashes with exit status 132'. > found -1 3.47+dfsg1-1 Bug #924009 [src:freefem++] Baseline violation in i386 (-mmx -msse2) and amd64 (-mavx) Marked as found in versions freefem++/3.47+dfsg1-1. -- 924009: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924009 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#990458: babel umd support is limited
On Sat, 03 Jul 2021 23:01:35 +0530 Pirate Praveen wrote: > I switched to rollup for generating umd and removed add-module-exports > plugin and it is working now. Possibly defining "autosize" global with > @babel/plugin-transform-modules-umd without add-module-exports plugin > would have worked as well. I tried this option today and it did not work. Looks like this is a known limitaion of babel umd plugin. https://github.com/babel/babel/issues/10696 so we will stick with rollup.
Bug#990263: podman sets oom_score_adj to -1000 for processes inside the
control: severity -1 normal control: reassign -1 conmon control: tags -1 +patch +upstream On Thu, 01 Jul 2021 08:29:07 +0200 Max Bruckner wrote: > I just found the bug and the fix! It's not in podman but in conmon! > > See https://github.com/containers/conmon/releases/tag/v2.0.29 and > https://github.com/containers/conmon/commit/b033cb5dfde6de05e63408fc839f1bb641cddd85 Great :) > Yes, when running as normal user it just doesn't have the permissions to set > negative OOM score adjustments, that's why > it's 0. Aha, I got it. > Probably because it's the conmon version that matters. I can reproduce it on > Archlinux as well by downgrading conmon to > 2.0.28 Let's reassign this bug to conmon, then (as above control header). > I'm new to debian bug reports and only saw the "breaks the whole system" > criterium in the list that "reportbug" printed. > So feel free to downgrade. Not sure if I have the permission to do so as the > bug reporter, but if so I don't even know > how to. Thanks, I did. If you would have a chance to do so, please check above of this mail :) -- Hideki Yamane
Processed: Re: podman sets oom_score_adj to -1000 for processes inside the
Processing control commands: > severity -1 normal Bug #990263 [podman] podman sets oom_score_adj to -1000 for processes inside the container so the system breaks in OOM situations Severity set to 'normal' from 'critical' > reassign -1 conmon Bug #990263 [podman] podman sets oom_score_adj to -1000 for processes inside the container so the system breaks in OOM situations Bug reassigned from package 'podman' to 'conmon'. No longer marked as found in versions libpod/3.0.1+dfsg1-2. Ignoring request to alter fixed versions of bug #990263 to the same values previously set > tags -1 +patch +upstream Bug #990263 [conmon] podman sets oom_score_adj to -1000 for processes inside the container so the system breaks in OOM situations Added tag(s) patch. Bug #990263 [conmon] podman sets oom_score_adj to -1000 for processes inside the container so the system breaks in OOM situations Added tag(s) upstream. -- 990263: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990263 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#982794: firefox-esr: illegal instruction in libxul.so on armhf
Processing control commands: > found -1 78.11.0esr-1 Bug #982794 [firefox-esr] firefox-esr: illegal instruction in libxul.so on armhf Marked as found in versions firefox-esr/78.11.0esr-1. -- 982794: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982794 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#982794: firefox-esr: illegal instruction in libxul.so on armhf
Control: found -1 78.11.0esr-1 Hi Hideki and Jochen, Thank you for both of your responses. On Thu, Jul 01, 2021 at 08:08:44AM +0200, Jochen Sprickerhof wrote: > * Hideki Yamane [2021-06-28 22:35]: > > Can you reproduce it on freshly installed bullseye sytem? After apt upgrade (firefox now at 78.11.0esr-1), the issue is still there. The offending instruction is the same and the backtrace looks very similar. Given that the cause seems well understood (use of NEON instructions on a non-NEON system), I don't think a fresh install would give us any new information. > I only found this reference for NEON on armhf: > > "NEON and VFP/VFP2/VFP3 remain an optional part of the architecture." > > https://wiki.debian.org/ArmHardFloatPort#VFP In addition: "VFPv3-D16 is the common denominator of the processors to support here (therefore the recommended build option is -mfpu=vfpv3-d16)" https://wiki.debian.org/ArmHardFloatPort/VfpComparison#FPU I couldn't find a more authoritative definition of the supported architecture subset for the armhf port. > If this is still reproducible, I see two options: > - Disable NEON code. > - Depend on the neon-support dummy package. Agreed. > > > Kernel: Linux 3.5.7-14-ARCH (PREEMPT) > > It seems that is not the kernel bullseye provides. Correct. The default Debian armhf kernel doesn't give me video, and I forgot whether it even boots. > > And it maybe help to provide its hardware information, too. > The bug author wrote: > > > > This is on a Marvell Dove system, with VFPv3-D16. From /proc/cpuinfo: > > > Features : swp half thumb fastmult vfp edsp iwmmxt thumbee vfpv3 > > > vfpv3d16 tls More specifically, this is on a SolidRun CuBox (first generation, so not the CuBox-i or CuBox-M). I noticed that some time ago, the severity of this bug was raised from normal to serious. While it is serious on my system, I had set it to normal because it likely affects only a relatively small number of systems. And while I would appreciate this bug getting resolved, making it release critical seems unnecessary. Regards, Vincent.
Bug#986293: closed by Debian FTP Masters (reply to Adrian Bunk ) (Bug#986293: fixed in virtuoso-opensource 7.2.5.1+dfsg-3.1)
On Tue, Jun 29, 2021 at 02:52:49PM +0200, Andreas Beckmann wrote: > On 23/05/2021 16.21, Debian Bug Tracking System wrote: > > virtuoso-opensource (7.2.5.1+dfsg-3.1) unstable; urgency=medium > > > * Drop the libvirtuoso5.5-cil package. (Closes: #986293) > > * Updated debconf translations: > > I've just reintroduced the -cil package (avoiding NEW since it was still as > cruft in sid) since the upgrade error was actually caused by the mono > dependency cycle. (mono fix is in experimental/NEW and RT approved) > > Do you want to get the translation updates unbocked? There is little point in getting the translation updates unblocked when another update is pending for fixing/removing libvirtuoso5.5-cil. > On 01/05/2021 17.14, Adrian Bunk wrote: > > In any case there is a bug that libvirtuoso5.5-cil lost all dependencies > > except cli-common in bullseye. > > I haven't looked at that. Do you want to file a new bug for it? > (#986293 has been reassigned to mono) So file a new bug and then revert your NMU? My fix for that was removing the package, since I did not find any other solution. > Andreas cu Adrian
Bug#990561: marked as done (libuv1: CVE-2021-22918)
Your message dated Sun, 04 Jul 2021 08:16:49 + with message-id and subject line Bug#990561: fixed in libuv1 1.40.0-2 has caused the Debian Bug report #990561, regarding libuv1: CVE-2021-22918 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 990561: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990561 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Source: libuv1 X-Debbugs-CC: t...@security.debian.org Severity: grave Tags: security Hi, the latest nodejs security release included an issue in libuv: https://nodejs.org/en/blog/vulnerability/july-2021-security-releases/ The patch hasn't landed in libuv.git, but here's the patch as applied by nodejs: https://github.com/nodejs/node/commit/d33aead28bcec32a2a450f884907a6d971631829 For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-22918 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22918 Please adjust the affected versions in the BTS as needed. --- End Message --- --- Begin Message --- Source: libuv1 Source-Version: 1.40.0-2 Done: Dominique Dumont We believe that the bug you reported is fixed in the latest version of libuv1, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 990...@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Dominique Dumont (supplier of updated libuv1 package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmas...@ftp-master.debian.org) -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Sun, 04 Jul 2021 09:43:38 +0200 Source: libuv1 Architecture: source Version: 1.40.0-2 Distribution: unstable Urgency: medium Maintainer: Dominique Dumont Changed-By: Dominique Dumont Closes: 990561 Changes: libuv1 (1.40.0-2) unstable; urgency=medium . * add patch for CVE-2021-22918 (Closes: #990561) Checksums-Sha1: bef65c1905b17ce2c38945be3e871463ca133a00 1997 libuv1_1.40.0-2.dsc 1c5ec7416007a789fee14c8dece281485cdf733d 23904 libuv1_1.40.0-2.debian.tar.xz c02a0916576e0c90dd8b287e0452df438f56f718 6906 libuv1_1.40.0-2_source.buildinfo Checksums-Sha256: 474cc846bbc36e68da06539d57a0f26b890fc113e9598a45e8aa6230877c7ce7 1997 libuv1_1.40.0-2.dsc cf4ec6b8d02e5eaece8a93636599935e2b3cc242df1976bfc24453816e50755f 23904 libuv1_1.40.0-2.debian.tar.xz 6ff8f2049f5b015cc0eb90758adcf24980e4914e580c62ecaa4cea3fd4483ad8 6906 libuv1_1.40.0-2_source.buildinfo Files: 1cdcbba5aa763c49eb37861407509bef 1997 libs optional libuv1_1.40.0-2.dsc 66213e34d996de29ec5ddfcdd72b331a 23904 libs optional libuv1_1.40.0-2.debian.tar.xz fa415efc26fb8eb1bcf02779c4bbfcd5 6906 libs optional libuv1_1.40.0-2_source.buildinfo -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEn3I5/LZk8Qsz6dwDwx9P2UmrK2wFAmDhZyAACgkQwx9P2Umr K2zU0A/+KqbUMLG5znDqI85XpYb9dK/bAt1IcuSdWxCOosRyZuKERwwS+zOcONrs WlfSQhX6F797Y9RvkLq/a38SZukbu1TAv2cocOrX5RVBda6h5AjXF7/0/TbBMYVz vDhQwsmfrKLJqP5A5eXYqQBts9rJjSNoD3hcnOb0JLFy0oNyv7mSU601iMx3Xmri lCpbopdi/Ezf29/cNXBFIve5SwCe2L6PGl/QRdQ4YxRrjP8KHIex37BUZ+gPhe5O uqY/8hwUBr1cvfhQu8TN6ios47tKni/9emZgOByRq5d5JEHOLYph2SKGjVegOPoI fnEp2A7sbd5i6kXr02k72qqsqFV4Du7N4PNQgp3WDiYaxOL7OwypgLZtKMUnW10a Ma9CF7fjxEMuxE8bwW9qFJ6OhBHoMuyxMYCgYHw98nJMaaYINW3xA+q+V9WnpVdW Q++UVVOn5lxu5rmE16SszyLXC4jhF8QoI9vQsCygSIc+XjsWwqj2lnKtTKdDpyrz +DXOD1PKoKNYyRobSZwstuJ4bruIn5+XXyvBRASOC1o6gmGAzUTP2NXJbEhu3Z7+ h+6s9BNvTdIoUEz9StGw/+px8qRZM0k+HJ42LrTAIY5myDSzlWOThkSkdDQfMrVX AXS+xWDy+5brA2pB/mItRbZwaqZxR3aphPEEH77ufIN84paGaSc= =tNsH -END PGP SIGNATURE End Message ---
Bug#990561: libuv1: CVE-2021-22918
On Friday, 2 July 2021 10:36:18 CEST you wrote: > The patch hasn't landed in libuv.git, but here's the patch as applied > by nodejs: > https://github.com/nodejs/node/commit/d33aead28bcec32a2a450f884907a6d9716318 > 29 This patch modifies a file that was introduced in version 1.24. So I guess that buster and backport are also vulnerables. I will upload a new package to unstable soon. All the best.
