Bug#1061552: crmsh broken with python3-parallax 1.0.6
Indeed, parallax.run was added only in version 1.0.7 by https://github.com/krig/parallax/commit/38bac0eb3cb20e9df8cbbf585cf9353793ffdba2. Thanks for the report! -- Feri (only acknowledging it; I don't use crmsh, so no promises).
Bug#997016: RFS: swtpm/0.7.0-rc2-1 [ITA] -- Libtpms-based TPM emulator
Seunghun Han writes: >>> swtpm - Libtpms-based TPM emulator >>> swtpm-dev - Include files for the TPM emulator's CUSE interface >>> swtpm-libs - Common libraries for TPM emulators >> >> Why do you deviate from the usual libswtpm-dev/libswtpm0 package names? >> Including the SO version in the package name enables installing >> incompatible versions side-by-side, which is useful. >> >> Also, shipping static libraries (like libswtpm_libtpms.a) is generally >> recommended against in Debian. Does this package warrant it? > > The upstream version already has some debian-related files, and I > changed them to adopt the package. The author of it wants to name it > like libswtpm0, so I used the name. The static libraries are also > involved in upstream debian files. Should I change the name like > libswtpm instead of libswtpm0 and remove static libraries from the > package? I questioned the package name, not the names of the shared object within. After a closer look, though, libswtpm_libtpms.so.0.0.0 looks more like an internal convenience library than something which other projects call into. If this is so, the package name loses its relevance, I wonder why it's packaged separately, even. Or why it isn't compiled straight into the single binary (swtpm) linked against it. >>> swtpm-tools - Tools for the TPM emulator >> >> Why do you put swtpm-create-tpmca, swtpm-create-user-config-files and >> swtpm-localca into /usr/share/swtpm instead of /usr/bin? (This emits >> several Lintian information tags.) > > The author of the upstream project wanted to put them to > /usr/share/swtpm. The files are just for the initialization and don't > be used for TPM operations directly, so maybe he wanted to put > /usr/share/swtpm instead of /usr/bin. Should I move them to /usr/bin? That they have man pages suggests that they are meant for human use. That their man pages are in section 8 suggests that they should live in /usr/sbin. But this is unreliable, since even the *.conf man pages are in section 8, while those belong to section 5. This actually depends on whether the executables are generally used by the system administrator or nonprivileged users (or only internally, in which case the scripts would indeed belong into /usr/share/swtpm). I started to suspect that the current decision wasn't based on the expected usage pattern, but rather on the implementation method (interpreted script or compiled binary), which isn't very useful. But I know too little about the swtpm ecosystem to be sure about the best filesystem layout for the future. -- Regards, Feri
Bug#997016: RFS: swtpm/0.7.0-rc2-1 [ITA] -- Libtpms-based TPM emulator
Seunghun Han writes: > * Package name: swtpm >Version : 0.7.0-rc2-1 Hi, The upstream version number should be 0.7.0~rc2 with a tilde instead of a hyphen to ensure proper ordering (as Lintian warns about). To do such transformations automatically, put something like this in the watch file: uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\d*)$/$1~$2/ > swtpm - Libtpms-based TPM emulator > swtpm-dev - Include files for the TPM emulator's CUSE interface > swtpm-libs - Common libraries for TPM emulators Why do you deviate from the usual libswtpm-dev/libswtpm0 package names? Including the SO version in the package name enables installing incompatible versions side-by-side, which is useful. Also, shipping static libraries (like libswtpm_libtpms.a) is generally recommended against in Debian. Does this package warrant it? > swtpm-tools - Tools for the TPM emulator Why do you put swtpm-create-tpmca, swtpm-create-user-config-files and swtpm-localca into /usr/share/swtpm instead of /usr/bin? (This emits several Lintian information tags.) -- Thanks for you work! Regards, Feri
Bug#995569: debhelper: act on service files placed in usr/lib/systemd/system
Niels Thykier writes: > Unfortunately, I have no intention of acting on this request until the > tech-ctte has resolved their advice on how they want the /usr-merge > transition to be resolved (per #995569). > [...] > I wish I could provide you with something better, but I am personally > not ready to invest in implementing this feature while there is a > considerably risk that I would need to revert it again or it would be > interpreted as "promoting dissent" against the upcoming /usr-merge > transition[1]. > [...] > [1] I have raised objections in public about some of the /usr-merge > transition plans. I feel this is not an entirely theoretical concern > that other project members would see it as a statement from me if I was > to implement this feature without the explicit approval of the tech-ctte > at this point in time. Hi Niels, Wow. Ugh. Thanks for your elaborate answer. Don't worry, I can certainly live without this feature, and I'm perfectly fine with this aspect being handled as a minor bullet point in the eventual /usr-merge transition plan. The main point of my report was to avoid losing sight of the issue. And you've already ensured that. :) -- Thanks again, Feri
Bug#918137: marked as pending in lintian
Felix Lechner writes: > According to my research, the functionality was added in this commit [1] and > released in this one [2] as part of init-system-helpers 1.52. Hi Felix, Thanks for the thorough research and the fix. Does this mean that Debhelper is too strict generating the init-system-helpers (>= 1.54~) pre-dependency and it should use >= 1.52~ instead? -- Thanks, Feri
Bug#991423: xmltooling: autopkgtest regression since mid-July 2021
Control: forwarded -1 https://issues.shibboleth.net/jira/browse/CPPXT-151 Hi Graham, Thanks for the report! I think it's just some fallout from the upstream wiki migration. Let's see if they can provide a quick fix. -- Regards, Feri.
Bug#991005: unblock: corosync/3.1.2-2
Adrian Bunk writes: > Please age package corosync > > * [f641780] New patch: stats: fix crash when iterating over deleted keys. > Cherry-picked from v3.1.4. > (change by Ferenc Wágner) > > autopkgtest for corosync/3.1.2-2: amd64: Pass, arm64: Pass, armhf: Pass, > i386: Pass, ppc64el: Pass > Too young, only 7 of 20 days old > > This would reach 20 days after the deadline July 17th. Thanks for submitting the request, Adrian! I second it as maintainer. Upstream released 3.1.4 with this single crash fix, so I planned to request an unblock anyway (since corosync is a key package, aging it is not enough). -- Thanks, Feri
Bug#987941: buster-pu: package pacemaker/2.0.1-5+deb10u2
On Wed, 09 Jun 2021 09:17:26 +0200 wf...@niif.hu wrote:
> Andreas kindly provided further refinements for his patch in #985173.
> I'll update this stable update request with the new debdiff shortly.
Here it is:
$ debdiff pacemaker_2.0.1-5+deb10u1.dsc pacemaker_2.0.1-5+deb10u2.dsc
diff -Nru pacemaker-2.0.1/debian/changelog pacemaker-2.0.1/debian/changelog
--- pacemaker-2.0.1/debian/changelog2020-11-07 20:21:48.0 +0100
+++ pacemaker-2.0.1/debian/changelog2021-06-10 21:45:34.0 +0200
@@ -1,3 +1,19 @@
+pacemaker (2.0.1-5+deb10u2) buster; urgency=medium
+
+ [ Andreas Beckmann ]
+ * [1088b23] pacemaker-resource-agents: Bump Breaks+Replaces: pacemaker
+to (<< 2)
+A new upstream release instroduced as security update 1.1.24-0+deb9u1 in
+stretch added the new file /usr/lib/ocf/resource.d/pacemaker/ifspeed to
+pacemaker, while it resides in pacemaker-resource-agents in buster.
+(Closes: #985173)
+ * [4f1844b] libpe-status28/libpengine27: Add Breaks against libpe-
+status10/libpengine10 (>= 1.1.24)
+The version in stretch-security shipped libraries with SOVERSION 16
+instead of 10. (See: #981088)
+
+ -- Ferenc Wágner Thu, 10 Jun 2021 21:45:34 +0200
+
pacemaker (2.0.1-5+deb10u1) buster-security; urgency=high
* [bf23450] Apply patch series fixing CVE-2020-25654: ACL bypass.
diff -Nru pacemaker-2.0.1/debian/control pacemaker-2.0.1/debian/control
--- pacemaker-2.0.1/debian/control 2020-11-07 20:21:48.0 +0100
+++ pacemaker-2.0.1/debian/control 2021-06-10 21:44:36.0 +0200
@@ -84,9 +84,9 @@
${misc:Depends},
# split out of pacemaker so that pacemaker-remote can also use them:
Breaks:
- pacemaker (<< 1.1.14-2~),
+ pacemaker (<< 2),
Replaces:
- pacemaker (<< 1.1.14-2~),
+ pacemaker (<< 2),
Description: cluster resource manager general resource agents
${S:X-Common-Description}
.
@@ -270,6 +270,10 @@
Depends:
${misc:Depends},
${shlibs:Depends},
+Breaks:
+# The new upstream version in stretch-security shipped
+# SOVERSION 16 instead of 10 (see #981088), get it removed:
+ libpe-status10 (>= 1.1.24),
Description: cluster resource manager Policy Engine status library
${S:X-Common-Description}
.
@@ -282,6 +286,10 @@
Depends:
${misc:Depends},
${shlibs:Depends},
+Breaks:
+# The new upstream version in stretch-security shipped
+# SOVERSION 16 instead of 10 (see #981088), get it removed:
+ libpengine10 (>= 1.1.24),
Description: cluster resource manager Policy Engine library
${S:X-Common-Description}
.
I'm ready to upload if you agree.
--
Thanks,
Feri
Bug#987941: Acknowledgement (buster-pu: package pacemaker/2.0.1-5+deb10u2)
Andreas kindly provided further refinements for his patch in #985173. I'll update this stable update request with the new debdiff shortly. -- Feri
Bug#959757: This is a regression
Peter Leipold writes: > On 5/2/21 2:54 PM, Salvatore Bonaccorso wrote: > >> On Sun, Jul 05, 2020 at 01:15:38PM +0200, wf...@niif.hu wrote: >> >>> I started to see this problem after upgrading from 5.4.0-0.bpo.4-amd64 >>> to 5.5.0-0.bpo.2-amd64. It goes like: >> >> Do you still have the issue reproducible with a recent kernel from >> unstable or buster-backports? > > Hi, I'm the original reporter. FYI, the problem was fixed with one of > the kernel updates on last summer. It's stable since then. Hi, I certainly can't reproduce it with the current 5.10.24-1~bpo10+1. Not even with 5.10.13-1~bpo10+1, and I haven't got older logs anymore. -- Feri
Bug#987662: unblock: shibboleth-sp/3.2.2+dfsg1-1
Sebastian Ramacher writes: > Since the new upstream release only fixes the security issue, let's take > 3.2.2+dfsg1-1. Thanks, uploaded. -- Feri
Bug#987608: shibboleth-sp: Session recovery feature contains a null pointer deference
Salvatore Bonaccorso writes: > MITRE has assigned CVE-2021-31826 for this issue. Thanks. I guess you don't want a new security upload for this, but I'll certainly include it in the changelog of the unstable upload. (And in the changelog of the next security upload, whenever that happens.) -- Feri
Bug#892058: Thanks for the reminder
Hi, Thanks for the timely reminder with all the relevant dates included. I find this service useful and I'm grateful for it. -- Feri
Bug#981088: pacemaker: crm shell can't be executed due to a library error
Markus Koschany writes: > Am Freitag, den 26.03.2021, 16:37 +0100 schrieb wf...@niif.hu: > >> Thorsten Rehm writes: >> >>> In my opinion the crmsh package should be more strict with the >>> pacemaker-cli-utils package >> >> Sorry for not looking into this sooner. What do you mean by being >> "more strict"? Does crmsh require a specific version of >> pacemaker-cli-utils to function correctly? > > Yes, exactly. There should be a versioned dependency on > pacemaker-cli-utils. What kind of versioned dependency? What's your source? I don't maintain crmsh, so I'm not familiar with its requirements. >> While that's possible, I don't think it has anything to do with your >> problem, which is that crm_mon requires the libpe_status.so.10 shared >> library, but that is not provided by the 1.1.24-0+deb9u1 version of >> libpe-status10. Because it switched to providing libpe_status.so.16 >> instead. The library changed SONAME, but the package name did not >> change, which is forbidden. The same applies to libpengine10. >> >> Markus, I know introducing new packages through the security channel >> is highly unusual, but is it entirely impossible? Or can you >> recommend some other solution? > > In my opinion this issue has been resolved in Stretch. It's up to you > if you want to tighten the dependency on pacemaker-cli-utils in > unstable releases but we don't need to change that in Stretch right > now. I wonder if pacemaker Recommending the same version of pacemaker-cli-utils would have helped here... probably not. Switching to Depends isn't unreasonable, but not compelling either. > Pacemaker works fine, there was just a corner case when some packages > were put on hold hence my suggestion to tighten the dependency. You needn't put anything on hold to reproduce this problem. Just install pacemaker-cli-utils from stretch, then upgrade libpe-status10 from stretch-security, and crm_mon can't start anymore. Surely it isn't a common scenario, and any affected users are probably past this by now, but this is the gist of the problem. We may leave it at there, though. > We usually don't change package names in oldstable releases. In this > case there were no other reverse-dependencies which had to be > rebuilt. If there were any we would just rebuilt affected packages. I see. This still risks breaking software built by the user, because it violates Policy 8.1: "The run-time shared library must be placed in a package whose name changes whenever the SONAME of the shared library changes." Anyway, we have to find out if there's anything to do here. -- Thanks, Feri
Bug#985173: pacemaker-resource-agents: missing Breaks+Replaces: pacemaker (<< 2)
Hi Andreas, Sorry for not responding sooner, some mail forwarding problem intervened. Looks like there's another serious problem with the security upload breaking the buster upgrade path, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981088. I haven't asked the Security Team yet, but if that problem can be solved through the security channel, then maybe this one could be as well? I mean a hypothetical 1.1.24-0+deb9u2 upload would (besides introducing the new binary packages for the new SONAMEs to fix #981088) also move /usr/lib/ocf/resource.d/pacemaker/ifspeed from pacemaker into pacemaker-resource-agents, fixing the buster upgrade. Do you think that would work out well? Or should we push this change regardless into buster and unstable and bullseye? (I understand that introducing libpe-status16 wouldn't fix the damage already done by 1.1.24-0+deb9u2, and the workaround (upgrading pacemaker-cli-utils) is easy and already happened anyway in most of the cases. So we could also follow the tactic of leaving stretch-security alone, and tighten Breaks+Replaces in buster and beyond as you implemented here.) -- Thanks, Feri
Bug#981088: pacemaker: crm shell can't be executed due to a library error
Control: reassign -1 libpe-status10 1.1.24-0+deb9u1 Control: severity -1 serious Thorsten Rehm writes: > In my opinion the crmsh package should be more strict with the > pacemaker-cli-utils package Sorry for not looking into this sooner. What do you mean by being "more strict"? Does crmsh require a specific version of pacemaker-cli-utils to function correctly? While that's possible, I don't think it has anything to do with your problem, which is that crm_mon requires the libpe_status.so.10 shared library, but that is not provided by the 1.1.24-0+deb9u1 version of libpe-status10. Because it switched to providing libpe_status.so.16 instead. The library changed SONAME, but the package name did not change, which is forbidden. The same applies to libpengine10. Markus, I know introducing new packages through the security channel is highly unusual, but is it entirely impossible? Or can you recommend some other solution? -- Thanks, Feri
Bug#984888: pam-mysql: Newly added test with 323 hashed passwords fail on s390x
Balint Reczey writes: > On Sun, Mar 14, 2021 at 3:49 PM wrote: > >> Debugging suggests that the internal SHA-1 implementation does not work >> on big-endian architectures. The easy way out is switching to the >> libcrypto implementation (the package already depends on libssl1.1 and >> the PAM module links against libcrypto.so.1). The hard way is finding >> the bug and fixing it for arbitrary endianness. I wonder which one the >> Release Team prefers... > > I'm sure the Release Team would prefer using a well known SHA > implementation rather than an internal one especially when the > internal one proved to be broken. Actually the fix is already uploaded, though debci hasn't tested it yet. The internal implementation had the necessary conditional compilation directives, but the corresponding Autoconf test was missing. So a one-line patch (already merged upstream) sufficed. In the past I tried to persuade upstream into dropping the internal crypto routines, but the idea didn't get traction. -- Cheers, Feri
Bug#983569: [Pkg-net-snmp-devel] Bug#983569: net-snmp: please enable systemd integration
wf...@debian.org writes: > Turns out the upstream socket activation code does not include UDP. > I addressed that in the merge request as well. For what it's worth, net-snmp upstream merged the patch from https://github.com/net-snmp/net-snmp/pull/274. -- Regards, Feri
Bug#985054: coturn: fails to purge: rmdir: failed to remove '/var/lib/turn': No such file or directory
Control: tag 985054 + pending Andreas Beckmann writes: > That's something I haven't come across so far ;-) (Conditional usage > of /usr/share/doc content in postinst, unconditional usage of the > generated side effect in postrm purge.) > Please move the bits needed by the package out of /usr/share/doc/$pkg > to /usr/share/$pkg and use it from there. The schema file is already present there as well, so it's a simple matter of changing the path in the postinst. > PS: for your reference, this is the template we use for packages > failing to access /usr/share/doc content in nodocs tests: [...] Thanks, that's abundantly clear. Pity it wasn't triggered, but the report was right anyway. -- Feri
Bug#985054: coturn: fails to purge: rmdir: failed to remove '/var/lib/turn': No such file or directory
wf...@niif.hu writes: > Andreas Beckmann writes: > >> According to policy 7.2 you cannot rely on the depends being available >> during purge, only the essential packages are available for sure. > > I can't see coturn rely on any of its dependencies during purge, do you? Hi Andreas, Have you got anything to add here? >> (this was observed in a piuparts nodocs test) > > Could you please explain to me what a "nodocs" test is? I read through the Salsa repo, I get it now. > Since the postinst creates /var/lib/turn/turndb if it doesn't exist, > I've got no idea how /var/lib/turn can be missing during purge. Now I understand: it's created only if the needed schema file is present. Unfortunately it's used from under /usr/share/doc. I'll upload a fix shortly. -- Thanks, Feri
Bug#985405: src:shibboleth-sp: Error templates allow query-based override of variables
Moritz Muehlenhoff writes: > debdiff looks fine, please upload when you had a chance to test it The updated packages work fine in our infrastructure. I uploaded the full source package. -- Thanks, Feri
Bug#985405: src:shibboleth-sp: Error templates allow query-based override of variables
Dear Security Team,
Please review the debdiff below for a buster-security upload.
The advisory text changed a little meanwhile, adding credits to Toni
Huttunen, Fraktal Oy for discovering the problem, mentioning the style
sheet spoofing and adding some mitigation tips.
I haven't got a concrete exploit on hand, but I'll start testing the
updated package shortly.
diff -Nru shibboleth-sp-3.0.4+dfsg1/debian/changelog
shibboleth-sp-3.0.4+dfsg1/debian/changelog
--- shibboleth-sp-3.0.4+dfsg1/debian/changelog 2019-03-16 20:51:16.0
+0100
+++ shibboleth-sp-3.0.4+dfsg1/debian/changelog 2021-03-17 16:55:49.0
+0100
@@ -1,3 +1,26 @@
+shibboleth-sp (3.0.4+dfsg1-1+deb10u1) buster-security; urgency=high
+
+ * [594074b] New patch: SSPCPP-922 - Add externalParameters option to Errors
+element.
+Fix a phishing vulnerability: Template generation allows external
+parameters to override placeholders
+The primitive template engine used to render error pages allows
+replacement via query parameters also, though this is not a typical
+need. Because of this feature, it's possible to cause the SP to
+display some templates containing values supplied externally by URL
+manipulation. Though the values are encoded to prevent script
+injection, the content nevertheless appears to come from the server
+and so would be interpreted as trustworthy, allowing email addresses,
+logos, or support URLs to be manipulated by an attacker.
+This update adds a new setting to the configuration called
+externalParameters, which defaults to false. When false, support for
+this "feature" is disabled.
+https://shibboleth.net/community/advisories/secadv_20210317.txt
+https://issues.shibboleth.net/jira/browse/SSPCPP-922
+Thanks to Scott Cantor (Closes: #985405)
+
+ -- Ferenc Wágner Wed, 17 Mar 2021 16:55:49 +0100
+
shibboleth-sp (3.0.4+dfsg1-1) unstable; urgency=medium
* [f284741] New upstream release: 3.0.4
diff -Nru shibboleth-sp-3.0.4+dfsg1/debian/gbp.conf
shibboleth-sp-3.0.4+dfsg1/debian/gbp.conf
--- shibboleth-sp-3.0.4+dfsg1/debian/gbp.conf 2019-03-13 20:06:54.0
+0100
+++ shibboleth-sp-3.0.4+dfsg1/debian/gbp.conf 2021-03-17 16:21:54.0
+0100
@@ -1,5 +1,5 @@
[DEFAULT]
-debian-branch = debian/master
+debian-branch = debian/buster
upstream-branch = upstream/latest
pristine-tar = True
diff -Nru shibboleth-sp-3.0.4+dfsg1/debian/patches/series
shibboleth-sp-3.0.4+dfsg1/debian/patches/series
--- shibboleth-sp-3.0.4+dfsg1/debian/patches/series 2019-03-16
20:48:54.0 +0100
+++ shibboleth-sp-3.0.4+dfsg1/debian/patches/series 2021-03-17
16:54:46.0 +0100
@@ -3,3 +3,4 @@
Debianize-the-systemd-service-file-of-shibd.patch
seckeygen-defaults-for-Debian.patch
Use-runstatedir-from-future-Autoconf-2.70.patch
+SSPCPP-922-Add-externalParameters-option-to-Errors-elemen.patch
diff -Nru
shibboleth-sp-3.0.4+dfsg1/debian/patches/SSPCPP-922-Add-externalParameters-option-to-Errors-elemen.patch
shibboleth-sp-3.0.4+dfsg1/debian/patches/SSPCPP-922-Add-externalParameters-option-to-Errors-elemen.patch
---
shibboleth-sp-3.0.4+dfsg1/debian/patches/SSPCPP-922-Add-externalParameters-option-to-Errors-elemen.patch
1970-01-01 01:00:00.0 +0100
+++
shibboleth-sp-3.0.4+dfsg1/debian/patches/SSPCPP-922-Add-externalParameters-option-to-Errors-elemen.patch
2021-03-17 16:54:46.0 +0100
@@ -0,0 +1,125 @@
+From: Scott Cantor
+Date: Tue, 16 Mar 2021 10:56:22 -0400
+Subject: SSPCPP-922 - Add externalParameters option to Errors element
+
+https://issues.shibboleth.net/jira/browse/SSPCPP-922
+
+Closes: #985405
+---
+ schemas/shibboleth-3.0-native-sp-config.xsd | 1 +
+ shibsp/ServiceProvider.cpp | 11 +--
+ shibsp/handler/impl/AttributeCheckerHandler.cpp | 12 ++--
+ shibsp/handler/impl/FormSessionInitiator.cpp| 12 +++-
+ shibsp/handler/impl/LogoutHandler.cpp | 10 +-
+ 5 files changed, 40 insertions(+), 6 deletions(-)
+
+diff --git a/schemas/shibboleth-3.0-native-sp-config.xsd
b/schemas/shibboleth-3.0-native-sp-config.xsd
+index 5bfa3a2..3b1a664 100644
+--- a/schemas/shibboleth-3.0-native-sp-config.xsd
b/schemas/shibboleth-3.0-native-sp-config.xsd
+@@ -732,6 +732,7 @@
+
+
+
++
+
+
+
+diff --git a/shibsp/ServiceProvider.cpp b/shibsp/ServiceProvider.cpp
+index aacbba1..b9f6e4c 100644
+--- a/shibsp/ServiceProvider.cpp
b/shibsp/ServiceProvider.cpp
+@@ -71,9 +71,16 @@ namespace shibsp {
+ if (!app)
+ app = request.getServiceProvider().getApplication(nullptr);
+
+-const PropertySet* props=app->getPropertySet("Errors");
++const PropertySet* props = app->getPropertySet("Errors");
+
+-// First look for settings in the request map of the form pageError.
++// If the externalParameters option isn't set, clear out the request
field.
++pair externalParameters =
++
Bug#983569: [Pkg-net-snmp-devel] Bug#983569: net-snmp: please enable systemd integration
wf...@debian.org writes: > Craig Small writes: > >> Also, how confident are you writing unit files? I can write them but must >> admit I don't fully understand some of the more exotic features such as >> socket activation. > > My on-hands experience with socket activation is rather limited, but the > concept is not new, inetd did the trick in a more limited way. The > technology is widely used and there's even a short snmptrapd.socket > upstream, albeit with a somewhat confusing comment about matching. > > Aside, I'd recommend using Type=exec everywhere instead of (the default) > Type=simple for the sake of better error reporting. I opened https://salsa.debian.org/debian/net-snmp/-/merge_requests/8 with all these changes and more. And with a new autopkgtest. :) >> The net-snmp upstream seems to think you only should do socket >> activation for snmptrapd only, but I think you are only targeting that >> one anyway. > > Yes. Turns out the upstream socket activation code does not include UDP. I addressed that in the merge request as well. Unfortunately this makes the change rather bigger than I expected originally. -- Regards, Feri
Bug#984888: pam-mysql: Newly added test with 323 hashed passwords fail on s390x
Balint Reczey writes: > Autopkgtests are failing in CI on s390x due to the following newly added > tests: > > ... > OK: Y_MD5: correct password accepted > OK: Y_MD5: incorrect password refused > FAIL: mysql: correct password refused > OK: mysql: incorrect password refused > ... (It isn't the 323 variant that fails, but anyway...) Debugging suggests that the internal SHA-1 implementation does not work on big-endian architectures. The easy way out is switching to the libcrypto implementation (the package already depends on libssl1.1 and the PAM module links against libcrypto.so.1). The hard way is finding the bug and fixing it for arbitrary endianness. I wonder which one the Release Team prefers... -- Feri
Bug#984888: pam-mysql: Newly added test with 323 hashed passwords fail on s390x
Balint Reczey writes:
> Autopkgtests are failing in CI on s390x due to the following newly added
> tests:
>
> debian/tests/auth:
> ...
> 'mysql': { 'crypt': 2, '323': 'false', 'hash':
> '*1A8A8D8A90F03E8A15D4FFB3FC91A4693F077A84' }, # select
> PASSWORD('foopwd')
> ...
Szia Bálint,
Could you plese show me what SELECT PASSWORD('foopwd') returns on the
server fired up by the autopkgtest on s390x? I can't easily try this
myself, but I plan to add this to the test in the next upload.
--
Thanks,
Feri
Bug#985054: coturn: fails to purge: rmdir: failed to remove '/var/lib/turn': No such file or directory
Andreas Beckmann writes: > According to policy 7.2 you cannot rely on the depends being available > during purge, only the essential packages are available for sure. Hi Andreas, I can't see coturn rely on any of its dependencies during purge, do you? > (this was observed in a piuparts nodocs test) Could you please explain to me what a "nodocs" test is? Since the postinst creates /var/lib/turn/turndb if it doesn't exist, I've got no idea how /var/lib/turn can be missing during purge. Was it removed by the testing framework for being "unowned", for example? (Anyway, I agree that the postrm should be protected from such occurrences.) > From the attached log (scroll to the bottom...): > > Purging configuration files for coturn (4.5.2-2) ... > rmdir: failed to remove '/var/lib/turn': No such file or directory > dpkg: error processing package coturn (--purge): >installed coturn package post-removal script subprocess returned error > exit status 1 > Errors were encountered while processing: >coturn > > Why don't you ship the (empty) directory in the package and let dpkg > take care of creation and removal? The postinst creates a database in /var/lib/turn, so dpkg --remove could only emit a warning about not removing an empty directory in most cases. So the database (and the containing /var/lib/turn directory) must be removed by the postrm during purge. Thus I don't see much point in shipping an empty /var/lib/turn, but I may be overlooking something. And I actually do, as this bug report proves; but what is it? (BTW the current setup has another problem: /var/lib/turn must also be writable by the server for the SQLite database within being writable.) -- Thanks, Feri
Bug#984501: unblock: libqb/2.0.3-1
Sebastian Ramacher writes: > The changes look ok. Under the assumption that the upload happens soon, > please go ahead. Thank you, uploaded. -- Regards, Feri
Bug#983569: [Pkg-net-snmp-devel] Bug#983569: net-snmp: please enable systemd integration
Craig Small writes: > On Fri, 26 Feb 2021 at 23:12, Ferenc Wágner wrote: > >> file. If you aren't comfortable with changing the unit files now, >> shortly before hard freeze, at least enabling support in the daemons >> would still be very useful and also very easy with the --with-systemd >> configure flag. That wouldn't change behavior, only enable taking >> advantage of the support via local configuration. If you're interested, >> I'm willing to open a merge request for easier review. The Salsa CI >> passed on my fork with the trivial change. > > Do you know if anything is linked to a systemd library (therefore the > dependencies change) is that is enabled? Hi Craig, No, the necessary systemd code is included in snmplib/sd-daemon.c and appears in libnetsnmp.so, so the new binaries aren't linked against libsystemd. > Also, how confident are you writing unit files? I can write them but must > admit I don't fully understand some of the more exotic features such as > socket activation. My on-hands experience with socket activation is rather limited, but the concept is not new, inetd did the trick in a more limited way. The technology is widely used and there's even a short snmptrapd.socket upstream, albeit with a somewhat confusing comment about matching. Aside, I'd recommend using Type=exec everywhere instead of (the default) Type=simple for the sake of better error reporting. > The net-snmp upstream seems to think you only should do socket > activation for snmptrapd only, but I think you are only targeting that > one anyway. Yes. > A merge request on salsa seems the easiest way for me. If its not too big > an impact then it might be able to get it in before the freeze. I opened the simplest possible merge request based on the tree I did my testing on. It does not touch the unit files. I'm afraid whatever we do, we'll have to get a manual unblock from the release team, if they keep to their schedule (and they'll probably do so). -- Regards, Feri
Bug#983598: lintian: package-installs-apt-sources emitted for packages whose names end in -archive-keyring
Felix Lechner writes: > On Fri, Feb 26, 2021 at 2:36 PM Ferenc Wágner wrote: > >> only the first suffix is exempted > > Which package triggers the false positive, please? Thank you! Hi Felix, The one I created tonight based on the instructions at https://wiki.debian.org/DebianRepository/UseThirdParty, called elastic-archive-keyring. It indeed ships a file under /etc/apt/sources.list.d. (And another under /etc/apt/preferences.d, which Lintian also complains about, but that tag hasn't got contradicting documentation.) -- Regards, Feri
Bug#981404: Fix seems incomplete
Hi, The patch in this bug report very much shrinks the window of the vulnerability, but doesn't close it completely: the file is still created with default permissions, then chmodded as a separate step. It's hard, but not impossible to still win the race and open the file before the chmod, enabling the same attack. I recommend something like fd = open(dstFileName, O_WRONLY|O_CREAT|O_EXCL, 0600); if (fd != -1) f = fdopen( fd, "wb" ); if (fd == -1 || f == NULL) DISPLAYLEVEL(1, "zstd: %s: %s\n", dstFileName, strerror(errno)); return f; for example. -- Regards, Feri
Bug#981230: Unrecoverable split.
On Wed, 27 Jan 2021 23:21:08 + Maurizio Cimaschi wrote: > it seems that in version 3.0.1 of corosync there's a bug which causes > unrecoverable splits; it seems that it had been corrected in 3.0.3. Please > see Github issue #506. > > -> https://github.com/corosync/corosync/issues/506 > > The issue is unclear if the bug is in corosync or in Kronosnet, and it > seems to suggests to use at least library version 1.13. Besides in > buster-backports there's already version 1.16. To my best understanding this issue was actually in Kronosnet. Can you reproduce the problem with the backports version (1.16-2~bpo10+1) installed? > Please could the upgrade to newer version of corosync be considered ? It > should also require a dependency on the same version of > "libknet" in backports. I'll certainly consider backporting Corosync if really needed. -- Regards, Feri
Bug#979450: booth: autopkgtest fails on ci-worker-ppc64el-01 (but apparently not on other ppc64el workers)
Paul Gevers writes: > On 27-01-2021 22:41, Valentin Vidic wrote: > >> On Wed, Jan 27, 2021 at 10:37:56PM +0100, Paul Gevers wrote: >> >>> debian@ci-worker-ppc64el-01:~$ sudo cat /etc/lxc/default.conf >>> # MANAGED WITH CHEF; DON'T CHANGE BY HAND >>> lxc.net.0.type = veth >>> lxc.net.0.link = virbr0 >>> lxc.net.0.flags = up >>> lxc.apparmor.profile = generated >>> lxc.apparmor.allow_nesting = 1 >> >> I think this is only for new containers and for the existing ones these >> options would be in /var/lib/lxc//config. Also apparmor >> should log mount failures in kernel log or somewhere... > > We generate fresh containers on a daily basis. Hi Paul, These systemd messages are emitted during service setup, before the service binary is even started, and are very much characteristic to the Apparmor misconfiguration described in the LXC 3 NEWS file. I can readily reproduce them with another systemd-hardened package: systemd[697]: coturn.service: Failed to set up mount namespacing: Permission denied systemd[697]: coturn.service: Failed at step NAMESPACE spawning /usr/bin/turnserver: Permission denied and such messages are neatly paired with these in the host syslog: audit: type=1400 audit(1611830306.349:157): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxc-container-default-cgns" name="/" pid=27587 comm="(rnserver)" flags="rw, rslave" Can you see such messages? Are you sure that the failed runs had lxc.apparmor.profile = generated lxc.apparmor.allow_nesting = 1 in their LXC configuration? -- Feri
Bug#979450: booth: autopkgtest fails on ci-worker-ppc64el-01 (but apparently not on other ppc64el workers)
On Wed, 6 Jan 2021 22:31:26 +0100 Paul Gevers wrote: > Do you have any idea why the test would only be failing on this host? Hi Paul, Not offhand. It certainly failed to start the Corosync daemon (which should automatically start after installation, but that's beside the point). So there's ample chance this is a Corosync peculiarity after all; can't you see a similar pattern in the Corosync autopkgtest results? I often find myself wishing the logs were available when debugging autopkgtest failures. Before I'm starting to add journal dumps everywhere: don't you think it would be sensible to automatically add the created journal file (or something equivalent) to the test log or artifacts? -- Thanks, Feri
Bug#979320: transition: xmltooling
Sebastian Ramacher writes: > On 2021-01-05 10:47:56 +0100, Ferenc Wágner wrote: > >> I'd like to do successive sourceful uploads for these (the updated >> packages are already in experimental). The two other impacted >> packages build fine without any change: shibboleth-resolver and >> moonshot-gss-eap. > > Please go ahead The sourceful uploads of xmltooling, opensaml and shibboleth-sp are done and built or all release architectures, please trigger the binNMUs for shibboleth-resolver and moonshot-gss-eap. -- Thanks, Feri
Bug#909267: library-not-linked-against-libc: downgrade from error
On Mon, 15 Jun 2020 15:23:28 -0700 Felix Lechner wrote: > Hi Russ, > >> I wonder if we would get all of the utility out of the tag if instead it >> looked for shared libraries with no NEEDED metadata. Doesn't shared-lib-without-dependency-information check for that? >> I think it's only catching libraries that aren't linked with anything >> else Unfortunately library-not-linked-against-libc fires for thin wrapper libraries and adaptor plugins as well (for example) since as-needed linking is the default. > This tag will be removed in the near future. Sounds great! -- Thanks, Feri
Bug#978155: transition: libqb
Sebastian Ramacher writes: > On 2020-12-26 19:43:53 +0100, Ferenc Wágner wrote: > >> I'd like to transition to libqb version 2. The dependency list is >> fairly short, and mostly contains packages under the HA Team umbrella. >> The only breakage is caused by symbols file changes, which I'm ready to >> fix by sourceful uploads of corosync and pacemaker. The kronosnet >> package will also receive a sourceful upload to use the new binary >> package doxygen2man. Altogether I rebuilt the following packages in >> preparation: >> >> kronosnet (with source changes) >> corosync (with source changes) >> corosync-qdevice >> pacemaker (with source changes) >> dlm >> booth >> fence-virt >> sbd >> ocfs2-tools >> lvm2 >> usbguard > > Please go ahead with the uploads to unstable. Hi, Thanks for triggering the sbd binNMU right after the pacemaker upload finished buiding on all architectures! The other packages mentioned above are all transitive build dependencies, I think they are safe to be left alone. There's one last thing which may cause problems (or not): the libqb testing migration is blocked with the excuse "missing build on all". However, libqb-doc isn't built anymore, so libqb 2 doesn't ship any arch-all packages. If this needs manual intervention, please effect it. Whoops, you already requested its removal in #979045. I'm amazed by your level of attention! Much appreciated! -- Thanks, Feri
Bug#977331: Archive rebuild with Autconf 2.70
On Mon, 21 Dec 2020 09:45:24 +0100 Matthias Klose wrote: > will try to get an archive test rebuild done. Hi, Lucas did an archive rebuild with a beta release, see https://lists.gnu.org/archive/html/autoconf/2020-09/msg00027.html (Just in case you didn't notice.) -- Regards, Feri
Bug#977568: xml-security-c changes for xalan 1.12
Bill Blough writes: > I've uploaded xalan 1.12 to unstable. If you would like me to NMU > xml-security-c with the necessary changes (attached to 977568), I would > be happy to do so. Hi Bill, Thanks for the patch, I included it in the xml-security-c 2.0.2-4 upload. -- Regards, Feri
Bug#974009: debhelper: please document that dh_installsystemd ignores unit failures in maintainer scripts
Michael Biebl writes: > On Mon, 09 Nov 2020 00:40:31 +0100 =?utf-8?q?Ferenc_W=C3=A1gner?= > wrote: > >> I was surprised that a daemon start failure during install did not stop >> dpkg from exiting with a successful exit status. After much digging I >> found https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766194#22, which >> explains the asymmetry with dh_installinit. > > I'm not sure there is an asymmetry with sysvinit, on the contrary. Hi Michael, I actually took the wording from the linked comment, where Niels wrote: "Note that debhelper's tooling for init scripts vs. systemd has the asymmetry that the systemd tooling ignores all failures basically." Since the maintainer script snippets generated for SysV init scripts don't ignore the init script failures, the asymmetry is clearly present. But let's not dwell on this. >> While I'd find an option for this more appropriate than different >> behavior, I also feel like the current state merits some much more >> prominent documentation at least. Please consider addig it to the >> respective compat level as well. > > The "not-fail-on-failures" in dh-systemd (and later dh_installsystemd) > was modelled after sysvinit where SysV init scripts typically have an > "exit 0" at the end of the init script, thus basically ignoring any > error in the init script. Maybe, but that's at the clear discretion of the package maintainer. (And I don't find it correct practice, but that's not my point now.) > systemd/systemctl internally is more strict, that's why we picked the > "|| true" approach to mimic the old sysvinit behaviour. My problem is that this rather mimics badly written init scripts, without even warning the maintainers (who supposedly want to take advantage of the more correct/strict systemd behaviour) or letting them opt out (without wholly ditching the debhelper maintscript snippets). > Obviously, we could change that to be more picky and abort if a service > fails to start. Question is: do we want that? And if so, why? See above. But I'm not sure that changing behaviour would be a good idea, that's why I asked for documentation in this report. I was bitten by this in autopkgtest settings, so I'll be adding daemon status checks to my autopakgtests. It just took me too long to find out that this behaviour is intended, because I didn't expect the above asymmetry and the manual pages don't mention it either. -- Thanks, Feri
Bug#974563: corosync unable to communicate with pacemaker 1.1.16-1+deb9u1 which contains the fix for CVE-2020-25654
On Tue, 17 Nov 2020 09:16:48 +0100 Markus Koschany wrote: > This time I intend to upgrade pacemaker to the latest upstream release > in the 1.1.x branch which is currently 1.1.24~rc1. This one also > includes fixes for CVE-2018-16878 and CVE-2018-16877. Hi Markus, Please close #927714 if you fix those CVEs. Unfortunately I forgot to upload the prepared package after getting the blessing of the Security Team, so it slept in my local packaging repo until I noticed it again importing your 1.1.16-1+deb9u1 upload. Tagged as wferi/1.1.16-1+deb9u1 and pushed to Salsa in case you want to have a look; lacking it might even be the reason behind the current IPC problems, I don't know. -- Cheers, Feri
Bug#973254: pacemaker: CVE-2020-25654 upload prepared
Moritz Mühlenhoff writes: > On Sat, Nov 07, 2020 at 08:56:38PM +0100, wf...@niif.hu wrote: > >> I propose a security upload with the debdiff below. The patch series >> posted by upstream against 2.0.3 applies cleanly to the buster source, >> and is hereby included. I'll try to do some testing while you review. > > Thanks, this looks. I also compared the upstream 2.0.3 patch set against > the update Ubuntu released for their 20.4 release (which also ships > 2.0.3) and which is identical (and without reported regressions so far) Cool. One can't possibly test all relevant use cases here. > Please upload to security-master if your tests were fine as well Done. I managed to provoke some of the new denials with the updated package, and basic cluster operation remained unperturbed. I think the changelog entry will work well enough as the DSA text. The LTS update used a shorter version, which is fine as well. > (and remember to build with -sa since pacemaker is new in > buster-security (ftp.debian.org and security.debian.org don't share > tarballs) The --source-only-changes switch of sbuild seems to counteract -sa, but I tried to revert that with changestool. Hope it's fine. If only I also remembered to remove the buildinfo file... Or is that problem fixed already? Salvatore Bonaccorso writes: > Thanks for your upload to unstable! > > On Tue, Nov 10, 2020 at 10:34:18PM +, Debian FTP Masters wrote: >>* [6956006] New upstream pre-release (2.0.5~rc2) (Closes: #973254) > > Bonus point: please do include the assigned CVE id references which > makes it easier to cross-check and track fixes for security issues. I'll add the CVE ID to the changelog in the next upload, sorry. > Thanks for your work here and for the stable upload! Rather: thanks for your (plural) tireless work archive wide! -- Cheers, Feri
Bug#973254: pacemaker: CVE-2020-25654 upload prepared
Control: tag 973254 + patch
Dear Security Team,
I propose a security upload with the debdiff below. The patch series
posted by upstream against 2.0.3 applies cleanly to the buster source,
and is hereby included. I'll try to do some testing while you review.
Regards,
Feri
diff -Nru pacemaker-2.0.1/debian/changelog pacemaker-2.0.1/debian/changelog
--- pacemaker-2.0.1/debian/changelog2019-06-02 14:01:06.0 +0200
+++ pacemaker-2.0.1/debian/changelog2020-11-07 20:21:48.0 +0100
@@ -1,3 +1,19 @@
+pacemaker (2.0.1-5+deb10u1) buster-security; urgency=high
+
+ * [bf23450] Apply patch series fixing CVE-2020-25654: ACL bypass.
+A vulnerability was found in Pacemaker allowing a user who is in the
+haclient group but restricted by ACLs to bypass those ACLs, providing
+cluster-wide arbitrary code execution with root privileges. When the
+enable-acl cluster option isn't set to true, members of the haclient
+group (and root) can modify Pacemaker's CIB without restriction, which
+already gives them these capabilities, so there is no additional
+exposure in that case.
+More info: https://www.openwall.com/lists/oss-security/2020/10/27/1
+Patches:
https://lists.clusterlabs.org/pipermail/developers/2020-October/002324.html
+Thanks to Ken Gaillot (Closes: #973254)
+
+ -- Ferenc Wágner Sat, 07 Nov 2020 20:21:48 +0100
+
pacemaker (2.0.1-5) unstable; urgency=medium
* [17ae230] Backport three more patches from upstream fixing memory safety
diff -Nru pacemaker-2.0.1/debian/gbp.conf pacemaker-2.0.1/debian/gbp.conf
--- pacemaker-2.0.1/debian/gbp.conf 2019-06-02 13:44:18.0 +0200
+++ pacemaker-2.0.1/debian/gbp.conf 2020-11-07 19:23:46.0 +0100
@@ -1,5 +1,5 @@
[DEFAULT]
-debian-branch = debian/master
+debian-branch = debian/buster
upstream-branch = upstream/latest
[import-orig]
diff -Nru
pacemaker-2.0.1/debian/patches/CVE-2020-25654/Fix-fencer-restrict-certain-IPC-requests-to-privileged-us.patch
pacemaker-2.0.1/debian/patches/CVE-2020-25654/Fix-fencer-restrict-certain-IPC-requests-to-privileged-us.patch
---
pacemaker-2.0.1/debian/patches/CVE-2020-25654/Fix-fencer-restrict-certain-IPC-requests-to-privileged-us.patch
1970-01-01 01:00:00.0 +0100
+++
pacemaker-2.0.1/debian/patches/CVE-2020-25654/Fix-fencer-restrict-certain-IPC-requests-to-privileged-us.patch
2020-11-07 19:43:41.0 +0100
@@ -0,0 +1,105 @@
+From: Ken Gaillot
+Date: Fri, 9 Oct 2020 11:55:26 -0500
+Subject: Fix: fencer: restrict certain IPC requests to privileged users
+
+The fencer IPC API allows clients to register fence devices.
+
+If ACLs are enabled, this could allow an ACL-restricted user to bypass ACLs to
+configure fencing. If the user is able to install executables to the standard
+fencing agent locations, have arbitrary code executed as root (the standard
+locations generally require root for write access, so that is unlikely to be an
+issue).
+
+If ACLs are not enabled, users in the haclient group have full access to the
+CIB, which already gives them these capabilities, so there is no additional
+exposure in that case.
+
+This commit does not restrict unprivileged users from using other fencing API,
+such as requesting actual fencing.
+---
+ daemons/fenced/fenced_commands.c | 41
+ 1 file changed, 37 insertions(+), 4 deletions(-)
+
+diff --git a/daemons/fenced/fenced_commands.c
b/daemons/fenced/fenced_commands.c
+index b394fd6..1cc7d06 100644
+--- a/daemons/fenced/fenced_commands.c
b/daemons/fenced/fenced_commands.c
+@@ -2474,6 +2474,18 @@ handle_request(crm_client_t * client, uint32_t id,
uint32_t flags, xmlNode * req
+ const char *op = crm_element_value(request, F_STONITH_OPERATION);
+ const char *client_id = crm_element_value(request, F_STONITH_CLIENTID);
+
++bool allowed = true;
++
++#if ENABLE_ACL
++/* IPC commands related to fencing configuration may be done only by
++ * privileged users (i.e. root or hacluster) when ACLs are supported,
++ * because all other users should go through the CIB to have ACLs applied.
++ */
++if (client != NULL) {
++allowed = is_set(client->flags, crm_client_flag_ipc_privileged);
++}
++#endif
++
+ crm_element_value_int(request, F_STONITH_CALLOPTS, _options);
+
+ if (is_set(call_options, st_opt_sync_call)) {
+@@ -2623,27 +2635,43 @@ handle_request(crm_client_t * client, uint32_t id,
uint32_t flags, xmlNode * req
+ } else if (crm_str_eq(op, STONITH_OP_DEVICE_ADD, TRUE)) {
+ const char *device_id = NULL;
+
+-rc = stonith_device_register(request, _id, FALSE);
++if (allowed) {
++rc = stonith_device_register(request, _id, FALSE);
++} else {
++rc = -EACCES;
++}
+ do_stonith_notify_device(call_options, op, rc, device_id);
+
+ } else if (crm_str_eq(op, STONITH_OP_DEVICE_DEL, TRUE)) {
+ xmlNode *dev =
Bug#971427: lintian: false positive package-contains-documentation-outside-usr-share-doc for SNMP MIB files
Control: tags 971427 - moreinfo "Chris Lamb" writes: >> SNMP MIB files are generally /usr/share/snmp/mibs/*.txt, though >> these text files aren't documentation. Please make them exempt >> from package-contains-documentation-outside-usr-share-doc. > > Totally ACK that these are false-positives. However, I am not sure > that this is a general or widespread issue which would warrant an > exception being made in Lintian itself. > > As in, compared to adding a Lintian override in your specific > package. Hi Chris, Based on main/Contents-amd64, the following packages are affected: corosync-notifyd 1 keepalived3 pacemaker-common 1 pcs-snmp 2 libsnmp-base 13 cyrus-common 1 dnsdist 1 pdns-recursor 1 I'll certainly add overrides to my packages if Lintian doesn't make the exception. -- Regards, Feri
Bug#968684: libqb: Please make autopkgtests cross-test-friendly
On Wed, 19 Aug 2020 14:04:15 -0700 Steve Langasek
wrote:
> In Ubuntu, we have moved the i386 architecture to a compatibility-only layer
> on amd64, and therefore we are also moving our autopkgtest infrastructure to
> test i386 binaries in a cross-environment.
>
> This requires changes to some tests so that they are cross-aware and can do
> the right thing.
Hi,
Would the following change work for Ubuntu? I find using a single code
path slightly cleaner.
(https://salsa.debian.org/ha-team/libqb/-/commit/21c2e77428fa0e2bba35b43523a7af028bc3e676)
commit 21c2e77428fa0e2bba35b43523a7af028bc3e676 (HEAD -> debian/crosstest,
salsa/debian/crosstest)
Author: Ferenc Wágner
Date: Sat Aug 22 18:30:57 2020 +0200
Make our autopkgtest cross-test-friendly
diff --git a/debian/tests/control b/debian/tests/control
index 35c6ed9a..0354a969 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,3 +1,5 @@
-Depends: libqb-dev, gcc, libc6-dev, pkg-config
+Depends: libqb-dev,
+ build-essential,
+ pkg-config,
Tests: ipc
Restrictions: allow-stderr
diff --git a/debian/tests/ipc b/debian/tests/ipc
index e24cf411..baec3e8e 100755
--- a/debian/tests/ipc
+++ b/debian/tests/ipc
@@ -1,14 +1,18 @@
#!/bin/sh -ex
+DEB_HOST_GNU_TYPE=$(dpkg-architecture -q DEB_HOST_GNU_TYPE)
+CC=$DEB_HOST_GNU_TYPE-gcc
+PKG_CONFIG=$DEB_HOST_GNU_TYPE-pkg-config
+
cd examples
# the os_base.h in-tree header includes inttypes.h for the examples
ln -sf /usr/include/inttypes.h os_base.h # -f to enable repeated runs
-gcc $(pkg-config --cflags libqb) \
+$CC $($PKG_CONFIG --cflags libqb) \
-o ipcserver ipcserver.c \
-$(pkg-config --libs libqb)
-gcc $(pkg-config --cflags libqb) \
+$($PKG_CONFIG --libs libqb)
+$CC $($PKG_CONFIG --cflags libqb) \
-o ipcclient ipcclient.c \
-$(pkg-config --libs libqb)
+$($PKG_CONFIG --libs libqb)
OUT="${AUTOPKGTEST_ARTIFACTS:-.}/out.txt"
ERR="${AUTOPKGTEST_ARTIFACTS:-.}/err.txt"
--
Feri
Bug#680148: python-pam: Please include python3 support
Florian Best writes: > I would be interested in maintaining this package. Great! Do you happen to know the upstream project for this software? The single upstream version ever uploaded to Debian is 0.4.2 from 1999. It could be useful to know if upstream moved on, the project was replaced by another, or whatever happened. Just to make sure your work isn't put into something abandoned if better alternatives are available. > I am not yet a Debian Maintainer and don't yet know how to get > one. But I'll read about it. You become a Debian Maintainer by maintaining packages. You can contribute without having any official status, you just need somebody to upload (sponsor) your work. After establishing a track record, you can apply for direct upload rights. If you decide that you'd like to maintain this package, take a look at https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging which is the definitive reference for package salvaging. I suggest that you open the ITS bug as explained therein, create a packaging repository, import the previous dscs to incorporate the past history of the package, then add further changes fixing this bug and doing other changes you wish. Finally, upload your package to mentors.debian.net and also advertise it here to find sponsors. Don't hesitate to ask for help here or (better) on the mentors list if needed, you'll find some starting points at https://wiki.debian.org/DebianMentorsFaq. On the other hand, if you (or anybody) don't want to commit for longer term maintainership, we'll have to migrate off this package or do another NMU to fix this issue for the short term. -- Regards, Feri
Bug#950488: buster-pu: package kronosnet/1.8-2
wf...@niif.hu writes: > We'd be immensely grateful for your input on this matter, since your > position more or less determines how we can plan to support the HA users > in Debian. We'd still prefer a stable update (either to 1.13 as in the > original request or to a more recent stable release), but if that isn't > possible, we'll move forward with backports. (Which isn't a particularly > appealing option in itself, because the imminent libqb 2 transition will > cause much churn across the stack.) Dear Stable Release Team, Although we've uploaded 1.16-2~bpo10+1 to backports, we'd still be interested in doing a stable update (as above) if possible. Is there anything we can do to that end? -- Thanks, Feri
Bug#964244: stretch-pu: package xml-security-c/1.7.3-4+deb9u2
"Adam D. Barratt" writes: > Please go ahead, bearing in mind that the window for getting fixes into > the final stretch point release closes this weekend. Thanks, uploaded. -- Feri
Bug#959757: This is a regression
Control: found -1 5.5.0-0.bpo.2-amd64 I started to see this problem after upgrading from 5.4.0-0.bpo.4-amd64 to 5.5.0-0.bpo.2-amd64. It goes like: [21825.096887] rtw_pci :04:00.0: start vif dc:f5:05:54:f6:0d on port 0 [21829.406272] wlo1: authenticate with 38:43:7d:8a:89:0e [21829.914017] wlo1: send auth to 38:43:7d:8a:89:0e (try 1/3) [21829.935816] wlo1: authenticated [21829.941105] wlo1: associate with 38:43:7d:8a:89:0e (try 1/3) [21829.984243] wlo1: RX AssocResp from 38:43:7d:8a:89:0e (capab=0x1511 status=0 aid=3) [21829.986178] rtw_pci :04:00.0: sta 38:43:7d:8a:89:0e joined with macid 0 [21830.045633] rtw_pci :04:00.0: wrong bfee role [21830.048864] wlo1: associated [21830.050828] [ cut here ] [21830.051893] invalid ra report c2h length [21830.052890] WARNING: CPU: 2 PID: 280 at drivers/net/wireless/realtek/rtw88/fw.c:117 rtw_fw_c2h_cmd_handle+0x11a/0x130 [rtw88] [21830.053924] Modules linked in: cmac bnep bbswitch(OE) snd_sof_pci snd_sof_intel_hda_common snd_sof_intel_hda snd_sof_intel_byt snd_sof_intel_ipc snd_sof snd_sof_xtensa_dsp nls_ascii snd_soc_skl nls_cp437 snd_soc_hdac_hda vfat btusb snd_hda_ext_core fat btrtl snd_soc_sst_ipc snd_hda_codec_hdmi btbcm snd_soc_sst_dsp btintel ext4 snd_soc_acpi_intel_match x86_pkg_temp_thermal snd_soc_acpi snd_hda_codec_realtek intel_powerclamp rtwpci mbcache coretemp snd_soc_core snd_hda_codec_generic bluetooth jbd2 rtw88 ledtrig_audio snd_compress kvm_intel snd_hda_intel mac80211 drbg kvm snd_intel_dspcfg uvcvideo videobuf2_vmalloc irqbypass snd_hda_codec joydev videobuf2_memops ansi_cprng videobuf2_v4l2 asus_nb_wmi snd_hda_core cfg80211 videobuf2_common ecdh_generic intel_cstate asus_wmi snd_hwdep ecc intel_rapl_msr efi_pstore sparse_keymap intel_uncore videodev snd_pcm serio_raw intel_rapl_perf pcspkr snd_timer mc iTCO_wdt efivars wmi_bmof snd mei_me processor_thermal_device rfkill iTCO_vendor_support [21830.053944] soundcore hid_multitouch watchdog crc16 libarc4 intel_rapl_common mei int3403_thermal sg intel_soc_dts_iosf intel_pch_thermal ac int340x_thermal_zone tpm_crb tpm_tis tpm_tis_core tpm rng_core int3400_thermal evdev acpi_thermal_rel acpi_pad acpi_tad efivarfs ip_tables x_tables autofs4 btrfs blake2b_generic xor zstd_decompress zstd_compress raid6_pq libcrc32c crc32c_generic algif_skcipher af_alg dm_crypt dm_mod sd_mod hid_generic spi_pxa2xx_platform dw_dmac dw_dmac_core i2c_designware_platform i2c_designware_core i915 crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel ahci libahci i2c_algo_bit mxm_wmi drm_kms_helper xhci_pci xhci_hcd aesni_intel libata drm usbcore crypto_simd cryptd glue_helper scsi_mod i2c_hid i2c_i801 intel_lpss_pci hid intel_lpss idma64 usb_common mfd_core battery wmi video button [21830.063782] CPU: 2 PID: 280 Comm: kworker/u16:2 Tainted: G OE 5.5.0-0.bpo.2-amd64 #1 Debian 5.5.17-1~bpo10+1 [21830.064901] Hardware name: ASUSTeK COMPUTER INC. VivoBook_ASUSLaptop X430FN_S430FN/X430FN, BIOS X430FN.308 05/28/2019 [21830.066026] Workqueue: phy0 rtw_c2h_work [rtw88] [21830.067158] RIP: 0010:rtw_fw_c2h_cmd_handle+0x11a/0x130 [rtw88] [21830.068241] Code: cc 35 00 00 e8 f7 33 0d 00 e9 77 ff ff ff 48 89 ee 4c 89 f7 e8 07 70 ff ff e9 67 ff ff ff 48 c7 c7 c1 e4 2d c1 e8 a1 6c 80 de <0f> 0b e9 54 ff ff ff e8 4a 6a 80 de 66 2e 0f 1f 84 00 00 00 00 00 [21830.069391] RSP: 0018:ac2d8073be30 EFLAGS: 00010286 [21830.070515] RAX: RBX: 93e3a126bfd8 RCX: [21830.071635] RDX: 93e3a5ca9740 RSI: 93e3a5c99a48 RDI: 93e3a5c99a48 [21830.072694] RBP: 93e39b91b000 R08: 0426 R09: 00aa [21830.073764] R10: R11: ac2da09d8220 R12: 93e3a0a65b78 [21830.074835] R13: 0006 R14: 93e3a0a61e60 R15: 93e3a0a65c30 [21830.075842] FS: () GS:93e3a5c8() knlGS: [21830.076866] CS: 0010 DS: ES: CR0: 80050033 [21830.077827] CR2: 558372174ed8 CR3: 00015540a004 CR4: 003606e0 [21830.078780] Call Trace: [21830.079736] ? skb_dequeue+0x52/0x60 [21830.080674] rtw_c2h_work+0x40/0x60 [rtw88] [21830.081602] process_one_work+0x1a7/0x360 [21830.082532] worker_thread+0x30/0x390 [21830.083458] ? create_worker+0x1a0/0x1a0 [21830.084385] kthread+0x112/0x130 [21830.085353] ? kthread_park+0x80/0x80 [21830.086276] ret_from_fork+0x35/0x40 [21830.087246] ---[ end trace defb67375a180861 ]--- [21831.010482] wlo1: deauthenticated from 38:43:7d:8a:89:0e (Reason: 2=PREV_AUTH_NOT_VALID) [21831.045061] rtw_pci :04:00.0: sta 38:43:7d:8a:89:0e with macid 0 left [21831.722504] wlo1: authenticate with 38:43:7d:8a:89:41 [21832.230266] wlo1: send auth to 38:43:7d:8a:89:41 (try 1/3) [21832.236978] wlo1: authenticated [21832.242505] wlo1: associating with AP with corrupt probe response [21832.247217] wlo1: associate with 38:43:7d:8a:89:41 (try 1/3) [21832.274448] wlo1: RX AssocResp from
Bug#922984: stretch update requested
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964244
Bug#962454: Link failures after upgrade to +deb10u1
Alberto Gonzalez Iniesta writes: > Hi, again. After some days with libknet1=1.16-2, I'm still getting > errors from time to time (less than with buster's libknet1): > Jun 22 01:16:54 selma corosync[28610]: [KNET ] link: host: 1 link: 0 is > down > Jun 22 01:16:54 selma corosync[28610]: [KNET ] host: host: 1 (passive) > best link: 1 (pri: 1) > Jun 22 01:16:55 selma corosync[28610]: [KNET ] rx: host: 1 link: 0 is up > Jun 22 01:16:55 selma corosync[28610]: [KNET ] host: host: 1 (passive) > best link: 0 (pri: 1) > Jun 24 06:50:30 selma corosync[28610]: [KNET ] link: host: 1 link: 0 is > down > Jun 24 06:50:30 selma corosync[28610]: [KNET ] host: host: 1 (passive) > best link: 1 (pri: 1) > Jun 24 06:50:31 selma corosync[28610]: [KNET ] rx: host: 1 link: 0 is up > Jun 24 06:50:31 selma corosync[28610]: [KNET ] host: host: 1 (passive) > best link: 0 (pri: 1) Hi, Is this with corosync 3.0.1-2+deb10u1? Please enable debug logging and collect full info for a link flap. Do these correlate with some cluster or host activity? Does your network link transfer big packets (up to 65536 bytes) reliably? Can you capture the Kronosnet network traffic (preferably on both nodes) around the time of a link flap? I won't be able to interpret such detailed information, but I suggest you open an issue at https://github.com/kronosnet/kronosnet/issues complete with it. -- Regards, Feri
Bug#963081: src:camera.app: Please switch to using pkg-config for libgphoto2
Yavor Doganov writes: > wf...@niif.hu wrote: > >> Yavor Doganov writes: >> >>> Thanks; I'll fix this shortly -- the upload will depend on my sponsor >>> though. Meanwhile, feel free to upload libgphoto2 whenever you like >>> and raise the severity of this bug to serious. >> >> Did so, thanks. I'm willing to sponsor your upload fixing this issue if >> needed. > > It has a bunch of other changes so I'm not sure you'll be comfortable > reviewing them. And I've already contacted my sponsor... Anyway, the > updated package is available at mentors.d.n and also on Salsa. Some of those changes are indeed out of my zone. :) > P.S. I noticed that libgphoto2/2.5.25-1 FTBFS almost everywhere, you > might want to take a look. Yes, stupid overlook. Thanks for the heads-up, fixed! -- Feri
Bug#963081: src:camera.app: Please switch to using pkg-config for libgphoto2
Control: severity -1 serious Yavor Doganov writes: > Thanks; I'll fix this shortly -- the upload will depend on my sponsor > though. Meanwhile, feel free to upload libgphoto2 whenever you like > and raise the severity of this bug to serious. Did so, thanks. I'm willing to sponsor your upload fixing this issue if needed. -- Regards, Feri
Bug#950488: buster-pu: package kronosnet/1.8-2
Dear Stable Release Team, We'd be immensely grateful for your input on this matter, since your position more or less determines how we can plan to support the HA users in Debian. We'd still prefer a stable update (either to 1.13 as in the original request or to a more recent stable release), but if that isn't possible, we'll move forward with backports. (Which isn't a particularly appealing option in itself, because the imminent libqb 2 transition will cause much churn across the stack.) -- Thanks, Feri
Bug#347650: Buster links with --as-needed by default
Hi, Just noting that according to #956146 "the bullseye toolchain defaults to linking with --as-needed", so this won't hurt us so bad in the future. -- Feri
Bug#950488: buster-pu: package kronosnet/1.8-2
Control: tags -1 - moreinfo "Adam D. Barratt" writes: > Apologies for not replying sooner. No problem. I was starting to accept that my request was so outlandish that it didn't even warrant a reply. :) > On Sun, 2020-02-02 at 14:47 +0100, Ferenc Wágner wrote: >> I'v got a bold request: please let me update Kronosnet in buster from >> 1.8-2 to 1.13-something to fix #946222. During the buster freeze >> period, upstream released 1.9 and 1.10, but those didn't bring >> important >> fixes, so I didn't request freeze exceptions for them. However, when >> Proxmox VE 6.0 got released (based on Debian buster), their users >> reported lots of intertwined bugs, and the developers iterated >> through >> 1.11, 1.12 and 1.13 in quick succession to fix them, see the linked >> https://forum.proxmox.com/threads/pve-5-4-11-corosync-3-x-major-issues.56124. > > Do upstream have a stable or LTS tree? I see that unstable currently > contains 1.15, so 1.X is presumably not it. Actually it is. Even 1.16 was released on Thursday from the stable1 branch, I just haven't got around uploading it yet. The master branch contains bigger changes targeting a future Kronosnet 2. > Usually when considering a larger update, we'd be looking for > information such as: > > - What sort of changes get included in upstream releases? Are they just > bug fixes, or are there new features included, or other changes? The bulk is bug fixes, but there are occasional feature changes as well. Besides man page improvements and improved error reporting, ACL and zstd support was added in 1.10, for example. I didn't deem those worth a freeze exception, though. 1.11 to 1.13 focused on fixing PMTU discovery, and this is the main reason for this stable update request, but meanwhile added a new API and musl support (the ABI remained stable). I linked to the above release announcements in the message opening this bug, but here are the later ones, too: 1.14 https://lists.kronosnet.org/pipermail/users/2020-January/25.html All fixes. Sounds useful, even though the most serious part does not affect the stock buster kernels. 1.15 https://lists.kronosnet.org/pipermail/users/2020-March/26.html All fixes. Nice to have, but not critical unless your application gathers statistics. 1.16 https://lists.kronosnet.org/pipermail/users/2020-April/27.html Fixes a special SCTP case. But also contains some code reorganization, to fix build issues under GCC 10. Otherwise, it's meant to be a no-op, as https://github.com/kronosnet/kronosnet/pull/301#issuecomment-620515274 explains in detail. > - What sort of testing do the new releases get? Is the testing > automated? Yes, https://ci.kronosnet.org/ runs across the full Kronosnet - Corosync - Pacemaker stack, so correct operation is ensured on a basic level. The maintainers also run more complicated tests on large clusters on a regular basis (it's an official RedHat project with dedicated staff). HA cluster setups are very diverse, though, and the failures they are designed to mitigate are even more so. This is why the past releases had to concentrate on fixing various connectivity recovery scenarios. > - What sort of regressions are reported against new releases? How > quickly are they resolved? There aren't many. The developer team is active and responsive, see https://github.com/kronosnet/kronosnet/issues/218 for example. The cooperation with Corosync (only known user of Kronosnet) is fluid, they are managed under the same umbrella. The above report came from Proxmox, a company specializing in HA virtualization (based on Debian). They were the main driving force behind the 1.11-1.13 updates, seeking to provide support for their customers. Since they upgraded to 1.13, things calmed down; they're sitting at 1.14 since February as far as I can see (https://git.proxmox.com/?p=kronosnet.git). Hope it answers your questions, just flip back the moreinfo tag if not. Meanwhile I'll upload 1.16 to unstable. -- Feri
Bug#955206: freeradius: Daemon has write privilege to configuration
"Debian Bug Tracking System" writes: > - set ReadOnlyDirectories to the configuration (Closes: #955206) Well, not very transparent or general, but certainly address my main concern. However, the file ownerships still send the wrong message to me. Could you please explain why the configuration files are owned by the freerad user? -- Thanks, Feri
Bug#953189: src:libgphoto2: fails to migrate to testing for too long
Hi, I'd like to upload the new versions of gphoto2 and libgphoto2 to fix this migration bug (and to make use of them in qstopmotion). If you agree, please accept my membership request on Salsa and I'll go ahead. -- Thanks, Feri
Bug#896463: autopkgtest-build-lxc times out waiting for network-online.target
On Mon, 2 Jul 2018 12:10:34 +0200 Paul Gevers wrote: > On Sat, 21 Apr 2018 12:15:28 +0200 =?utf-8?q?Ferenc_W=C3=A1gner?= > wrote: > >> --- /usr/bin/autopkgtest-build-lxc 2018-04-18 10:44:36.0 +0200 >> +++ /home/wferi/autopkgtest-build-lxc2018-04-19 18:36:05.937432180 >> +0200 >> @@ -123,7 +123,7 @@ >> } >> >> # wait until a systemd based container has networking >> -if ! echo '[ ! -d /run/systemd/system ] || systemctl start >> network-online.target' | timeout 60 lxc-attach --name=$1 -- sh -e; then >> +if ! echo '[ ! -d /run/systemd/system ] || systemctl start >> network-online.target' | lxc-attach --name=$1 -- sh -e; then >> echo "Timed out waiting for container to start >> network-online.target" >&2 >> exit 1 >> fi >> >> That is, simply removing "timeout 60". > > I fear that this may work for you, but isn't robust. I think we want > some form of timeout there to prevent infinite hang-ups. > >> Maybe an alternate solution could be designed by installing a systemd >> service in the guest to run the setup-testbed and customize scripts >> without requiring these lxc-attach commands. Just an idea, I'll be >> happy with any fix you prefer. > > I think this isn't a great solution either, as that means we depend on > systemd in the guest. I don't think we should (yet?). Hi Paul, What about forgetting about network-online.target and similar hacks (https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ doesn't think about it highly) altogether, and instead configuring apt-get for a dozen or so retries (that seems to be the first command in setup-testbed requiring network access). The build process is rather noisy already, so this could be a simple init-system-agnostic solution. -- Regards, Feri
Bug#950478: buster-pu: package corosync/3.0.1-2
"Adam D. Barratt" writes: > On Sun, 2020-02-02 at 12:46 +0100, Ferenc Wágner wrote: > >> +corosync (3.0.1-2+deb10u1) buster; urgency=medium >> + >> + * [f826af9] This branch is for buster updates > > That doesn't really belong in the package changelog. Agreed. >> + * [bfbfd3e] New patch: totemsrp: Reduce MTU to left room second >> mcast. >> +Thanks to Jan Friesse (Closes: #950476) >> > > Please go ahead. Uploaded with pruned changelog. -- Thanks, Feri
Bug#680148: python-pam: Please include python3 support
Hi, Sadly, it looks like Dima Barksy, the maintainer, isn't around any more. Is anybody interested in salvaging this package? (Both in the sense of keeping it around after the Python 2 removal in bullseye and in that of https://wiki.debian.org/PackageSalvaging.) -- Regards, Feri
Bug#950139: buster-pu: package xmltooling/3.0.4-1
"Adam D. Barratt" writes: > On Fri, 2020-01-31 at 23:30 +0100, wf...@niif.hu wrote: > >> +xmltooling (3.0.4-1+deb10u1) buster; urgency=medium >> + >> + * [7c6eb12] This branch is for buster updates >> + * [97e580e] New patch: CPPXT-145 - DataSealer is sharing non- >> thread safe keys. > > Please go ahead; thanks. Uploaded. -- Thanks, Feri
Bug#950139: buster-pu: package xmltooling/3.0.4-1
On Wed, 29 Jan 2020 12:24:36 +0100 =?utf-8?q?Ferenc_W=C3=A1gner?=
wrote:
> I'm looking for guidance first: I'd like to fix #950135 (libxmltooling8:
> Race condition bug in new session cookie feature leads to SP crash) in
> buster.
> [...]
> Upstream cut a new release (3.0.5) for this fix specifically, but the
> full diff between 3.0.4 and 3.0.5 is much longer due to changes in the
> version number in several files, VC project files, generated Autotools
> files, RPM spec file and Windows resource file. Still not huge, and
> most of that is entirely irrelevant for Debian. But in the 3.0.5-1
> upload I included some packaging changes (mainly autopkgtest and Salsa
> CI, but also a no-effect upgrade to debhelper compat 12). I guess you'd
> rather not review all this in a stable update, right? Then I'll add a
> quilt patch and submit that, as you prefer.
Here's the minimal debdiff containing only a quilt patch:
$ debdiff xmltooling_3.0.4-1.dsc xmltooling_3.0.4-1+deb10u1.dsc
diff -Nru xmltooling-3.0.4/debian/changelog xmltooling-3.0.4/debian/changelog
--- xmltooling-3.0.4/debian/changelog 2019-03-14 14:58:36.0 +0100
+++ xmltooling-3.0.4/debian/changelog 2020-01-31 23:06:07.0 +0100
@@ -1,3 +1,11 @@
+xmltooling (3.0.4-1+deb10u1) buster; urgency=medium
+
+ * [7c6eb12] This branch is for buster updates
+ * [97e580e] New patch: CPPXT-145 - DataSealer is sharing non-thread safe
keys.
+Thanks to Scott Cantor (Closes: #950135)
+
+ -- Ferenc Wágner Fri, 31 Jan 2020 23:06:07 +0100
+
xmltooling (3.0.4-1) unstable; urgency=high
* [f185b26] New upstream security release: 3.0.4
diff -Nru xmltooling-3.0.4/debian/gbp.conf xmltooling-3.0.4/debian/gbp.conf
--- xmltooling-3.0.4/debian/gbp.conf2019-03-14 14:34:19.0 +0100
+++ xmltooling-3.0.4/debian/gbp.conf2020-01-31 22:59:40.0 +0100
@@ -1,5 +1,5 @@
[DEFAULT]
-debian-branch = debian/master
+debian-branch = debian/buster
upstream-branch = upstream/latest
pristine-tar = True
diff -Nru
xmltooling-3.0.4/debian/patches/CPPXT-145-DataSealer-is-sharing-non-thread-safe-keys.patch
xmltooling-3.0.4/debian/patches/CPPXT-145-DataSealer-is-sharing-non-thread-safe-keys.patch
---
xmltooling-3.0.4/debian/patches/CPPXT-145-DataSealer-is-sharing-non-thread-safe-keys.patch
1970-01-01 01:00:00.0 +0100
+++
xmltooling-3.0.4/debian/patches/CPPXT-145-DataSealer-is-sharing-non-thread-safe-keys.patch
2020-01-31 23:04:41.0 +0100
@@ -0,0 +1,42 @@
+From: Scott Cantor
+Date: Tue, 1 Oct 2019 19:16:19 -0400
+Subject: CPPXT-145 - DataSealer is sharing non-thread safe keys
+
+Xmltooling versions 3.0.0 to 3.0.4 suffer from a race condition bug that
+leads to a crash under load.
+
+https://issues.shibboleth.net/jira/browse/CPPXT-145
+
+Closes: #950135
+---
+ xmltooling/security/impl/DataSealer.cpp | 8 ++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+diff --git a/xmltooling/security/impl/DataSealer.cpp
b/xmltooling/security/impl/DataSealer.cpp
+index c7ec7f9..aef85b7 100644
+--- a/xmltooling/security/impl/DataSealer.cpp
b/xmltooling/security/impl/DataSealer.cpp
+@@ -156,8 +156,10 @@ string DataSealer::wrap(const char* s, time_t exp) const
+
+ safeBuffer ciphertext;
+ try {
++// Keys are not threadsafe, use a clone to encrypt.
++scoped_ptr clonedKey(defaultKey.second->clone());
+ scoped_ptr
method(XENCEncryptionMethod::create(env.get(), algorithm));
+-if (!handler->encryptToSafeBuffer(, method.get(),
defaultKey.second, dummydoc, ciphertext)) {
++if (!handler->encryptToSafeBuffer(, method.get(), clonedKey.get(),
dummydoc, ciphertext)) {
+ throw XMLSecurityException("Data encryption failed.");
+ }
+ }
+@@ -235,8 +237,10 @@ string DataSealer::unwrap(const char* s) const
+ unsigned int len = 0;
+ safeBuffer plaintext;
+ try {
++// Keys are not threadsafe, use a clone to decrypt.
++scoped_ptr clonedKey(requiredKey.second->clone());
+ scoped_ptr
method(XENCEncryptionMethod::create(env.get(), algorithm));
+-len = handler->decryptToSafeBuffer(, method.get(),
requiredKey.second, dummydoc, plaintext);
++len = handler->decryptToSafeBuffer(, method.get(),
clonedKey.get(), dummydoc, plaintext);
+ }
+ catch (const XSECException& ex) {
+ auto_ptr_char msg(ex.getMsg());
diff -Nru xmltooling-3.0.4/debian/patches/series
xmltooling-3.0.4/debian/patches/series
--- xmltooling-3.0.4/debian/patches/series 1970-01-01 01:00:00.0
+0100
+++ xmltooling-3.0.4/debian/patches/series 2020-01-31 23:04:41.0
+0100
@@ -0,0 +1 @@
+CPPXT-145-DataSealer-is-sharing-non-thread-safe-keys.patch
I'm ready to upload this if you feel like going straight to 3.0.5-1 (in
unstable) would be too much.
--
Thanks,
Feri
Bug#948715: stretch-pu: package xml-security-c/1.7.3-4+deb9u1
On Tue, 28 Jan 2020 08:42:50 + "Adam D. Barratt" wrote: > On 2020-01-12 14:39, Ferenc Wágner wrote: > >> +xml-security-c (1.7.3-4+deb9u2) stretch; urgency=medium >> + >> + * [12dd825] New patches: DSA verification crashes OpenSSL on invalid >> +combinations of key content. >> +Particular KeyInfo combinations result in incomplete DSA key structures >> +that OpenSSL can't handle without crashing. In the case of Shibboleth >> +SP software this manifests as a crash in the shibd daemon. Exploitation >> +is believed to be possible only in deployments employing the PKIX trust >> +engine, which is generally recommended against. >> +The upstream patches backported from 2.0.2 apply analogous safeguards to >> +the RSA and ECDSA key handling as well. > > Please go ahead. Uploaded. -- Thanks, Feri
Bug#947936: chrony: Does (still) not start properly on boot on buster
Hi, Don't you think #873057 is actually the same issue discovered with ntp? Please consider merging it in if you agree. -- Thanks, Feri
Bug#945741: tcvt: Python2 removal in sid/bullseye
wf...@niif.hu writes: > Helmut Grohne writes: > >> On Wed, Nov 27, 2019 at 11:58:53PM +, Sandro Tosi wrote: >> >>> - Convert your Package to Python3. This is the preferred option. >> >> Upstream here. While tcvt started on Python2, much of its development >> actually happend on Python3, so just changing the #! should work. > > And I wanted to package it for Python3 in the first place. I'm puzzled > that it uses Python2 despite dh --with python3 and the python3 build > dependency. I'd be grateful for an explanation or some suggestions. Maybe I expected too much of dh_python3. Patching the interpreter name to /usr/bin/python3 works of course, I'm just not sure it's best practice. -- Regards, Feri
Bug#945741: tcvt: Python2 removal in sid/bullseye
Helmut Grohne writes: > On Wed, Nov 27, 2019 at 11:58:53PM +, Sandro Tosi wrote: > >> - Convert your Package to Python3. This is the preferred option. > > Upstream here. While tcvt started on Python2, much of its development > actually happend on Python3, so just changing the #! should work. And I wanted to package it for Python3 in the first place. I'm puzzled that it uses Python2 despite dh --with python3 and the python3 build dependency. I'd be grateful for an explanation or some suggestions. -- Thanks, Feri
Bug#895450: slapd: segfault in back_mdb
Ryan Tandy writes:
> With your coredump, could you dig a little further into the two
> "sml_mod" structures and show their sm_desc/sm_values/sm_nvalues?
Sure:
(gdb) p *modlist->sml_mod.sm_desc
$8 = {ad_next = 0x0, ad_type = 0x5652a198da20, ad_cname = {bv_len = 3, bv_val =
0x5652a198d900 "uid"}, ad_tags = {bv_len = 0, bv_val = 0x0}, ad_flags = 0,
ad_index = 47}
(gdb) p *modlist->sml_mod.sm_values
$9 = {bv_len = 12, bv_val = 0x7ff46c11d940 "jeszenszkyan"}
(gdb) p *modlist->sml_mod.sm_nvalues
$10 = {bv_len = 12, bv_val = 0x7ff46c11d990 "jeszenszkyan"}
and
(gdb) p *modlist->sml_next->sml_mod.sm_desc
$11 = {ad_next = 0x0, ad_type = 0x5652a198da20, ad_cname = {bv_len = 3, bv_val
= 0x5652a198d900 "uid"}, ad_tags = {bv_len = 0, bv_val = 0x0},
ad_flags = 0, ad_index = 47}
(gdb) p *modlist->sml_next->sml_mod.sm_values
$12 = {bv_len = 11, bv_val = 0x7ff46c11d860 "jeszenszkya"}
(gdb) p *modlist->sml_next->sml_mod.sm_nvalues
$13 = {bv_len = 11, bv_val = 0x7ff46c11d8b0 "jeszenszkya"}
> (For the "sm_op" values, 1 is LDAP_MOD_DELETE and 4096 is
> SLAP_MOD_SOFTADD.)
Makes sense, I guess...
> Also, if the frame is still valid, the contents of "dni" in
> syncrepl_entry (frame #4) would be useful too.
(gdb) up
#4 0x5652a06c29df in syncrepl_entry (syncCSN=0x7ff46c115400,
syncUUID=0x7ff47a6ca070, syncstate=, modlist=0x7ff47a6c9d30,
entry=0x5652a19a8f38, op=0x7ff47a6ca760, si=0x5652a1a39600) at
../../../../servers/slapd/syncrepl.c:3273
3273rc = op->o_bd->be_modrdn( op, _modify );
(gdb) p dni
$14 = {new_entry = 0x5652a19a8f38, dn = {bv_len = 45, bv_val = 0x7ff46c000ff0
"uid=jeszenszkyan,ou=users,o=niifi,o=niif,c=hu"}, ndn = {bv_len = 45,
bv_val = 0x7ff46c001028 "uid=jeszenszkyan,ou=users,o=niifi,o=niif,c=hu"},
nnewSup = {bv_len = 0, bv_val = 0x0}, renamed = 1, delOldRDN = 1,
modlist = 0x7ff47a6c9d30, mods = 0x0, oldNcount = 1, oldDesc =
0x5652a198dc00, newDesc = 0x5652a198dc00}
(gdb) p *dni.new_entry
$16 = {e_id = 0, e_name = {bv_len = 44, bv_val = 0x7ff46c115430
"uid=jeszenszkya,ou=users,o=niifi,o=niif,c=hu"}, e_nname = {bv_len = 44,
bv_val = 0x7ff46c1191c0 "uid=jeszenszkya,ou=users,o=niifi,o=niif,c=hu"},
e_attrs = 0x5652a19bed90, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0},
e_private = 0x0}
(gdb) p dni.modlist->sml_mod
$18 = {sm_desc = 0x5652a198d870, sm_values = 0x7ff46c119200, sm_nvalues =
0x7ff46c8bd960, sm_numvals = 1, sm_op = 2, sm_flags = 0, sm_type = {bv_len = 2,
bv_val = 0x7ff46c114aed "cn"}}
(gdb) p dni.modlist->sml_mod.sm_desc
$19 = (AttributeDescription *) 0x5652a198d870
(gdb) p *dni.modlist->sml_mod.sm_desc
$20 = {ad_next = 0x5652a1bfcf80, ad_type = 0x5652a198d650, ad_cname = {bv_len =
2, bv_val = 0x5652a198d590 "cn"}, ad_tags = {bv_len = 0, bv_val = 0x0},
ad_flags = 0, ad_index = 46}
(gdb) p *dni.modlist->sml_mod.sm_values
$21 = {bv_len = 16, bv_val = 0x7ff46c10d5c0 "Jeszenszky Andor"}
(gdb) p *dni.modlist->sml_mod.sm_nvalues
$22 = {bv_len = 16, bv_val = 0x7ff46c8bd990 "jeszenszky andor"}
[...]
(gdb) p
dni.modlist->sml_next->sml_next->sml_next->sml_next->sml_next->sml_next->sml_next->sml_next
$32 = (Modifications *) 0x0
(gdb) p *dni.oldDesc
$34 = {ad_next = 0x0, ad_type = 0x5652a198da20, ad_cname = {bv_len = 3, bv_val
= 0x5652a198d900 "uid"}, ad_tags = {bv_len = 0, bv_val = 0x0},
ad_flags = 0, ad_index = 47}
Hope this helps.
--
Regards,
Feri
Bug#895450: slapd: segfault in back_mdb
Control: tag -1 - moreinfo
On Wed, 11 Apr 2018 10:08:25 -0700 Ryan Tandy wrote:
> On Wed, Apr 11, 2018 at 06:41:08PM +0200, Ferenc Wágner wrote:
>
>> slapd[4515]: segfault at 4c ip 7f71abdbfc9b sp 7f716f184780 error 4
>> in back_mdb-2.4.so.2.10.7[7f71abdb+39000]
>
> Not familiar to me, nor to upstream based on the information provided.
> Feel free to remove the 'moreinfo' tag if it happens again and you're
> able to capture a core or stacktrace.
Hi Ryan,
One and a half year later, and I've got a core dump! Stretch system,
slapd 2.4.44+dfsg-5+deb9u3, segmentation fault at the same point, but
with a different value:
Dec 19 10:31:40 birch slapd[19274]: do_syncrep2: rid=001 LDAP_RES_INTERMEDIATE
- NEW_COOKIE
Dec 19 10:31:40 birch slapd[19274]: do_syncrep2: rid=001 NEW_COOKIE:
rid=001,csn=20191219093138.816310Z#00#000#00
Dec 19 10:31:40 birch slapd[19274]: slap_queue_csn: queueing 0x7ff460102d90
20191219093138.816310Z#00#000#00
Dec 19 10:31:40 birch slapd[19274]: slap_graduate_commit_csn: removing
0x7ff460102d90 20191219093138.816310Z#00#000#00
Dec 19 10:31:59 birch slapd[19274]: do_syncrep2: rid=001
cookie=rid=001,csn=20191219093159.802851Z#00#000#00
Dec 19 10:31:59 birch slapd[19274]: syncrepl_message_to_entry: rid=001 DN:
uid=jeszenszkya,ou=users,o=niifi,o=niif,c=hu, UUID:
6eb0ba40-14b1-1039-9559-11af45fdb739
Dec 19 10:31:59 birch slapd[19274]: syncrepl_entry: rid=001
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY)
Dec 19 10:31:59 birch slapd[19274]: syncrepl_entry: rid=001 be_search (0)
Dec 19 10:31:59 birch slapd[19274]: syncrepl_entry: rid=001
uid=jeszenszkya,ou=users,o=niifi,o=niif,c=hu
Dec 19 10:31:59 birch slapd[19274]: slap_queue_csn: queueing 0x7ff46c11d760
20191219093159.802851Z#00#000#00
Dec 19 10:31:59 birch kernel: [3068983.104734] slapd[19276]: segfault at
80b9542009 ip 7ff4b7304c9b sp 7ff47a6c9700 error 4 in
back_mdb-2.4.so.2.10.7[7ff4b72f5000+39000]
Some random info that looked useful at first sight:
(gdb) bt
#0 mdb_modify_internal (op=op@entry=0x7ff47a6ca760,
tid=tid@entry=0x5652a1c04f50,
modlist=0x7ff46c11d8d0, e=e@entry=0x7ff47a6c9850,
text=text@entry=0x7ff47a6ca020,
textbuf=textbuf@entry=0x7ff47a6c98d0 "\024", textlen=256)
at ../../../../../servers/slapd/back-mdb/modify.c:99
#1 0x7ff4b7307f8e in mdb_modrdn (op=0x7ff47a6ca760, rs=0x7ff47a6ca000)
at ../../../../../servers/slapd/back-mdb/modrdn.c:509
#2 0x5652a06cb040 in overlay_op_walk (op=op@entry=0x7ff47a6ca760,
rs=0x7ff47a6ca000,
which=op_modrdn, oi=0x5652a1a2a850, on=)
at ../../../../servers/slapd/backover.c:677
#3 0x5652a06cb19d in over_op_func (op=0x7ff47a6ca760, rs=,
which=)
at ../../../../servers/slapd/backover.c:730
#4 0x5652a06c29df in syncrepl_entry (syncCSN=0x7ff46c115400,
syncUUID=0x7ff47a6ca070,
syncstate=, modlist=0x7ff47a6c9d30, entry=0x5652a19a8f38,
op=0x7ff47a6ca760,
si=0x5652a1a39600) at ../../../../servers/slapd/syncrepl.c:3273
#5 do_syncrep2 (op=op@entry=0x7ff47a6ca760, si=si@entry=0x5652a1a39600)
at ../../../../servers/slapd/syncrepl.c:1040
#6 0x5652a06c4134 in do_syncrepl (ctx=ctx@entry=0x7ff47a6cac10,
arg=arg@entry=0x5652a1a21e90)
at ../../../../servers/slapd/syncrepl.c:1564
#7 0x5652a065deed in connection_read_thread (ctx=0x7ff47a6cac10, argv=0xb)
at ../../../../servers/slapd/connection.c:1296
#8 0x7ff4bbe3efda in ?? () from
/usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
#9 0x7ff4ba3a74a4 in start_thread (arg=0x7ff47a6cb700) at
pthread_create.c:456
#10 0x7ff4ba0e9d0f in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:97
(gdb) p *modlist
$9 = {sml_mod = {sm_desc = 0x5652a198dc00, sm_values = 0x7ff46c11d910,
sm_nvalues = 0x7ff46c11d960,
sm_numvals = 1, sm_op = 1, sm_flags = 0, sm_type = {bv_len = 0, bv_val =
0x0}},
sml_next = 0x7ff46c11d7f0}
(gdb) p *modlist->sml_next
$10 = {sml_mod = {sm_desc = 0x5652a198dc00, sm_values = 0x7ff46c11d830,
sm_nvalues = 0x7ff46c11d880,
sm_numvals = 1, sm_op = 4096, sm_flags = 0, sm_type = {bv_len = 0, bv_val =
0x0}},
sml_next = 0x80b9541fed}
(gdb) p mod
$12 = (Modification *) 0x80b9541fed
(gdb) p >sm_op
$13 = (short *) 0x80b9542009
The end of the console output:
$ /usr/sbin/slapd -h ldapi:/// -F /etc/ldap/slapd.d -d Stats,Stats2
[...]
5dfb4079 conn=1001 op=4783 SRCH base="o=niifi,o=niif,c=hu" scope=2 deref=0
filter="(&(objectClass=posixAccount)(uid=jsj))"
5dfb4079 conn=1001 op=4783 SRCH attr=uidNumber cn gecos uid objectClass
homeDirectory gidNumber loginShell
5dfb4079 conn=1001 op=4783 SEARCH RESULT tag=101 err=0 nentries=0 text=
Segmentation fault
I'm ready to extract more info from the core dump or provide the
configuration if needed. In short, it's a partial replica (constrained
by ACLs) from a wheezy slapd (2.4.40-4~bpo70+2).
--
Thanks,
Feri
Bug#886974: note to self
A random observation: the segmentation fault happens after outputting 4096 bytes to the test log. It may be related to stdio buffering and thus it may never appear with line buffered output.
Bug#873057: ntpd startup broke after buster upgrade
Hi, I agree that in theory this should work, but apparently it isn't reliable. During the first two startups after the buster upgrade ntpd was started, but during the third startup it was skipped: $ systemctl status ntp.service systemd-timesyncd.service ● ntp.service - Network Time Service Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor preset: enabled) Active: inactive (dead) Docs: man:ntpd(8) ● systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled) Drop-In: /lib/systemd/system/systemd-timesyncd.service.d └─disable-with-time-daemon.conf Active: inactive (dead) Condition: start condition failed at Tue 2019-09-17 19:21:35 CEST; 1 day 16h ago └─ ConditionFileIsExecutable=!/usr/sbin/ntpd was not met Docs: man:systemd-timesyncd.service(8) While man systemd.unit says that "the unit that conflicts will be started and the unit that is conflicted is stopped", this doesn't always work out as expected. From the syslog of the last two reboots: wferi@noc7:~$ zegrep "Network Time|Reached target" /var/log/syslog.2.gz Sep 17 18:16:02 noc7 systemd[1]: Reached target Local File Systems (Pre). Sep 17 18:16:02 noc7 systemd[1]: Reached target Swap. Sep 17 18:16:02 noc7 systemd[1]: Reached target Network (Pre). Sep 17 18:16:02 noc7 systemd[1]: Reached target Local File Systems. Sep 17 18:16:02 noc7 systemd[1]: Reached target RPC Port Mapper. Sep 17 18:16:02 noc7 systemd[1]: Reached target Remote File Systems (Pre). Sep 17 18:16:02 noc7 systemd[1]: Reached target Remote File Systems. Sep 17 18:16:02 noc7 systemd[1]: Reached target System Initialization. Sep 17 18:16:02 noc7 systemd[1]: Reached target Paths. Sep 17 18:16:02 noc7 systemd[1]: Reached target Sockets. Sep 17 18:16:02 noc7 systemd[1]: Reached target Basic System. Sep 17 18:16:02 noc7 systemd[1]: Reached target Timers. Sep 17 18:16:46 noc7 systemd[1]: Reached target Network. Sep 17 18:16:46 noc7 systemd[1]: Starting Network Time Service... Sep 17 18:16:46 noc7 systemd[1]: Reached target Network is Online. Sep 17 18:16:47 noc7 systemd[1]: Started Network Time Service. Sep 17 18:16:47 noc7 systemd[1]: Reached target Login Prompts. Sep 17 18:16:59 noc7 systemd[1]: Reached target Multi-User System. Sep 17 18:16:59 noc7 systemd[1]: Reached target Graphical Interface. Sep 17 19:21:38 noc7 systemd[1]: Reached target Local File Systems (Pre). Sep 17 19:21:38 noc7 systemd[1]: Reached target Network (Pre). Sep 17 19:21:38 noc7 systemd[1]: Reached target Swap. Sep 17 19:21:38 noc7 systemd[1]: Reached target Local File Systems. Sep 17 19:21:38 noc7 systemd[1]: Condition check resulted in Network Time Synchronization being skipped. Sep 17 19:21:38 noc7 systemd[1]: Reached target RPC Port Mapper. Sep 17 19:21:38 noc7 systemd[1]: Reached target Remote File Systems (Pre). Sep 17 19:21:38 noc7 systemd[1]: Reached target Remote File Systems. Sep 17 19:21:38 noc7 systemd[1]: Reached target System Initialization. Sep 17 19:21:38 noc7 systemd[1]: Reached target Sockets. Sep 17 19:21:38 noc7 systemd[1]: Reached target Timers. Sep 17 19:21:38 noc7 systemd[1]: Reached target Paths. Sep 17 19:21:38 noc7 systemd[1]: Reached target Basic System. Sep 17 19:21:41 noc7 systemd[1]: Reached target Network. Sep 17 19:21:42 noc7 systemd[1]: Reached target Network is Online. Sep 17 19:21:42 noc7 systemd[1]: Reached target Login Prompts. Sep 17 19:21:54 noc7 systemd[1]: Reached target Multi-User System. Sep 17 19:21:54 noc7 systemd[1]: Reached target Graphical Interface. Some more details (hopefully defaults): $ systemctl show -p After,Before,Wants,WantedBy,Requres,RequiredBy,Conflicts,ConflictedBy ntp.service systemd-timesyncd.service Wants= RequiredBy= WantedBy=multi-user.target Conflicts=shutdown.target systemd-timesyncd.service ConflictedBy= Before=multi-user.target shutdown.target After=-.mount systemd-tmpfiles-setup.service sysinit.target system.slice tmp.mount var.mount systemd-journald.socket network.target basic.target Wants=time-sync.target RequiredBy= WantedBy=sysinit.target Conflicts=shutdown.target ConflictedBy=ntp.service Before=time-sync.target sysinit.target shutdown.target After=var.mount systemd-journald.socket systemd-tmpfiles-setup.service system.slice -.mount tmp.mount systemd-sysusers.service systemd-remount-fs.service I failed to identify the problem, your help would be much welcome. -- Thanks, Feri
Bug#928605: No irq handler for vector
Hi, I'm also getting such messages since the buster upgrade: Message from syslogd@lant at Aug 26 20:05:12 ... kernel:[686221.093605] do_IRQ: 1.52 No irq handler for vector Message from syslogd@lant at Aug 27 01:03:12 ... kernel:[704101.075251] do_IRQ: 1.43 No irq handler for vector -- Regards, Feri
Bug#843640: bluez: Unable to transfer files over bluetooth - no file transfer settings shown
I can transfer files to my computer only if "Accept files from trusted devices" in "Transfer Settings" in the "Local Services" dialog is *unchecked*. Otherwise the accept dialog does not appear on incoming transfers, and in 40 seconds the transfer eventually times out with FORBIDDEN(0x43). The sending device is trusted. -- Regards, Feri
Bug#933398: resource-agents: ZFS resource agent contains a bashism and fails
Valentin Vidić writes: > The updated for stable is a bit more tricky because: > > https://www.debian.org/doc/manuals/developers-reference/ch05.html#upload-stable > "Basically, a package should only be uploaded to stable if one of the > following > happens: > > * a truly critical functionality problem As I understand it, the resource agent does not work at all currently. I'd consider this "truly critical", but we'll have to ask the stable release team. -- Feri
Bug#930887: [Debian-ha-maintainers] Bug#930887: CVE-2019-10153
Valentin Vidić writes: > On Mon, Jun 24, 2019 at 02:03:11PM +0200, wf...@niif.hu wrote: > >> According to https://security-tracker.debian.org/tracker/CVE-2019-10153, >> the vulnerable code is not present in stretch. However, I don't >> understand why this does not count: >> >> https://salsa.debian.org/ha-team/fence-agents/blob/debian/4.0.25-1/fence/agents/rhevm/fence_rhevm.py#L124 >> >> Also, according to http://pycurl.io/docs/latest/unicode.html#unicode the >> URL conversion to ASCII can fail even when it's implicit, though that >> probably isn't user controllable, thus may not count. > > I suppose the upstream marked it for 4.3.3 https://bugzilla.redhat.com/show_bug.cgi?id=1716286 is more general, mentioning "fence-agents prior to version 4.3.4" > but we can make a fix for stretch to be on the safe side? I think so, but I may overlook something. Also, I find the switch to UTF-8 decoding a somewhat unsatisfactory fix: is it wise to depend on the result being correctly UTF-8 encoded? If anything goes wrong, an exception is thrown all the same, it depends on the server. It may be desirable, though, I don't know a thing about rhevm. -- Feri
Bug#930887: [Debian-ha-maintainers] Bug#930887: CVE-2019-10153
Moritz Muehlenhoff writes: > Please see https://bugzilla.redhat.com/show_bug.cgi?id=1716286 Hi Moritz, According to https://security-tracker.debian.org/tracker/CVE-2019-10153, the vulnerable code is not present in stretch. However, I don't understand why this does not count: https://salsa.debian.org/ha-team/fence-agents/blob/debian/4.0.25-1/fence/agents/rhevm/fence_rhevm.py#L124 Also, according to http://pycurl.io/docs/latest/unicode.html#unicode the URL conversion to ASCII can fail even when it's implicit, though that probably isn't user controllable, thus may not count. -- Thanks, Feri
Bug#930671: libauthen-radius-perl: most basic usage stopped working
gregor herrmann writes: > Upstream has now closed the CPAN RT ticket and released a 0.31 > version which fixes the issue (differently). > > I've "backported" the fix (i.e. took most of the 0.31 diff and added > it as a quilt patch) and pushed it to git. For convenience I'm also > attaching the patch here. > > Feri, could you try this patch as well so that we can be sure that it > works before we proceed with an upload and unblock request? I built 0.29-2 from Salsa and installed it. It works fine for my (very limited) purposes. -- Thanks, Feri
Bug#930671: libauthen-radius-perl: most basic usage stopped working
Niko Tyni writes: > I've reported this upstream with the attached proposed patch. Hi Niko, I tried to apply the Radius.pm part to the installed package, but it failed at first due to a whitespace error: the installed file is indented with TAB characters, not spaces like your patch. After adjusting that the patched code works fine for me. > Will wait a bit before applying the patch for Debian in case upstream > has comments. Great, thanks a lot! -- Regards, Feri
Bug#930671: additional info
Commenting out the offending conditional die() in /usr/share/perl5/Authen/Radius.pm:865 restores the expected behavior. On the other hand, loading dictionary.rfc2865 does not make any difference. -- Regards, Feri
Bug#927159: libqb: CVE-2019-12779: Insecure Temporary Files
Dear Security Team,
I'm ready to upload libqb-1.0.1-1+deb9u1 with the following debdiff:
diff -Nru libqb-1.0.1/debian/changelog libqb-1.0.1/debian/changelog
--- libqb-1.0.1/debian/changelog2016-12-07 14:55:45.0 +0100
+++ libqb-1.0.1/debian/changelog2019-06-16 23:41:50.0 +0200
@@ -1,3 +1,21 @@
+libqb (1.0.1-1+deb9u1) stretch-security; urgency=high
+
+ * [38e0e13] Backport upstream security fixes for CVE-2019-12779.
+Libqb creates files in world-writable directories (/dev/shm, /tmp) with
+rather predictable file names (for example in case of USBGuard with names
+like /dev/shm/qb-usbguard-request-7096-835-12-data). Also O_EXCL flag is
+not used when opening the files. This could be exploited by a local
+attacker to overwrite privileged system files (if not restricted by
+sandboxing, MAC or symlinking policies).
+Original report: https://github.com/ClusterLabs/libqb/issues/338
+Add O_EXCL: https://github.com/ClusterLabs/libqb/pull/339
+Use mkdtemp():https://github.com/ClusterLabs/libqb/pull/345
+Regression fixes: https://github.com/ClusterLabs/libqb/pull/349
+(Closes: #927159)
+ * [79734d7] Acknowledge new internal symbol
+
+ -- Ferenc Wágner Sun, 16 Jun 2019 23:41:50 +0200
+
libqb (1.0.1-1) unstable; urgency=medium
[ Christoph Berg ]
diff -Nru libqb-1.0.1/debian/gbp.conf libqb-1.0.1/debian/gbp.conf
--- libqb-1.0.1/debian/gbp.conf 2016-12-07 14:47:16.0 +0100
+++ libqb-1.0.1/debian/gbp.conf 2019-06-16 22:48:22.0 +0200
@@ -1,14 +1,12 @@
[DEFAULT]
-debian-branch = debian/master
+debian-branch = debian/stretch
upstream-branch = upstream/latest
-debian-tag-msg = Debian release %(version)s
-
-[import-orig]
pristine-tar = True
-[gbp-pq]
-patch-numbers = False
-
-[gbp-dch]
+[dch]
+full = True
multimaint-merge = True
id-length = 7
+
+[pq]
+patch-numbers = False
diff -Nru libqb-1.0.1/debian/libqb0.symbols libqb-1.0.1/debian/libqb0.symbols
--- libqb-1.0.1/debian/libqb0.symbols 2016-12-07 14:47:16.0 +0100
+++ libqb-1.0.1/debian/libqb0.symbols 2019-06-16 23:41:22.0 +0200
@@ -236,5 +236,6 @@
qb_util_timespec_from_epoch_get@Base 0.11.1
qb_vsnprintf_deserialize@Base 0.11.1
qb_vsnprintf_serialize@Base 0.14.2
+ remove_tempdir@Base 1.0.1-1+deb9u1~
strlcat@Base 0.11.1
strlcpy@Base 0.11.1
diff -Nru
libqb-1.0.1/debian/patches/CVE-2019-12779/Allow-group-access-to-the-IPC-directory.patch
libqb-1.0.1/debian/patches/CVE-2019-12779/Allow-group-access-to-the-IPC-directory.patch
---
libqb-1.0.1/debian/patches/CVE-2019-12779/Allow-group-access-to-the-IPC-directory.patch
1970-01-01 01:00:00.0 +0100
+++
libqb-1.0.1/debian/patches/CVE-2019-12779/Allow-group-access-to-the-IPC-directory.patch
2019-06-16 23:10:03.0 +0200
@@ -0,0 +1,29 @@
+From: =?utf-8?q?Ferenc_W=C3=A1gner?=
+Date: Thu, 18 Apr 2019 13:20:38 +0200
+Subject: Allow group access to the IPC directory
+
+And don't abort if we aren't permitted to chown() it. The client might
+still have the privileges to enter it.
+---
+ lib/ipc_setup.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/lib/ipc_setup.c b/lib/ipc_setup.c
+index f6f1d7d..6183001 100644
+--- a/lib/ipc_setup.c
b/lib/ipc_setup.c
+@@ -640,11 +640,12 @@ handle_new_connection(struct qb_ipcs_service *s,
+ res = -errno;
+ goto send_response;
+ }
+- res = chown(c->description, c->auth.uid, c->auth.gid);
+- if (res != 0) {
++ if (chmod(c->description, 0770)) {
+ res = -errno;
+ goto send_response;
+ }
++ /* chown can fail because we might not be root */
++ (void)chown(c->description, c->auth.uid, c->auth.gid);
+
+ /* We can't pass just a directory spec to the clients */
+ strncat(c->description,"/qb", CONNECTION_DESCRIPTION);
diff -Nru
libqb-1.0.1/debian/patches/CVE-2019-12779/Errors-are-represented-as-negative-values.patch
libqb-1.0.1/debian/patches/CVE-2019-12779/Errors-are-represented-as-negative-values.patch
---
libqb-1.0.1/debian/patches/CVE-2019-12779/Errors-are-represented-as-negative-values.patch
1970-01-01 01:00:00.0 +0100
+++
libqb-1.0.1/debian/patches/CVE-2019-12779/Errors-are-represented-as-negative-values.patch
2019-06-16 23:10:03.0 +0200
@@ -0,0 +1,27 @@
+From: =?utf-8?q?Ferenc_W=C3=A1gner?=
+Date: Wed, 17 Apr 2019 15:09:42 +0200
+Subject: Errors are represented as negative values
+
+---
+ lib/ipc_setup.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/lib/ipc_setup.c b/lib/ipc_setup.c
+index a66004d..f6f1d7d 100644
+--- a/lib/ipc_setup.c
b/lib/ipc_setup.c
+@@ -637,12 +637,12 @@ handle_new_connection(struct qb_ipcs_service *s,
+ snprintf(c->description, CONNECTION_DESCRIPTION,
+"/dev/shm/qb-%d-%d-%d-XX", s->pid, ugp->pid,
c->setup.u.us.sock);
+ if (mkdtemp(c->description) == NULL) {
+- res =
Bug#929467: RFS: tfortune-1.0.0 [ITP]
Andre Noll writes: > I also had to override dh_autoreconf for reasons explained in the > commit message. It isn't a packaging issue, I just wonder: why do you wrap configure? The usual approach to making it available is distributing it (and not requiring Autoconf to build the software from the distribution tarball, only to build it from the VCS checkout). -- Regards, Feri
Bug#927714: CVE-2019-3885 CVE-2018-16877 CVE-2018-16878
On Wed, 24 Apr 2019 17:50:02 +0200 wf...@niif.hu wrote: > On Mon, 22 Apr 2019 09:07:04 +0200 Salvatore Bonaccorso > wrote: > >>> Please see https://www.openwall.com/lists/oss-security/2019/04/17/1 >> >> Please note that when fixing the issues, in the original patchsets >> there were some behaviour regressions, I think they should be adressed >> in the followups as noted in >> https://www.openwall.com/lists/oss-security/2019/04/18/2 > > After several readings of the followup you linked to I think those > "prior behavioral changes" are the fixes themselves, that is, the more > thorough authorization checks. Don't you agree? According to https://github.com/ClusterLabs/pacemaker/pull/1750#issuecomment-494765240, those behavioral changes are already addressed in the pull request. > I proceeded to apply the patches in the pull request to the pacemaker > quilt queue. Unfortunately they introduce new symbols in libcrmcommon: > crm_ipc_is_authentic_process and pcmk__ipc_is_authentic_process_active. > Am I expected to update the libtool version info in light of this? I left those internal symbols unaccounted for now, just tell if it needs adjustment. As per the previous comment CVE-2019-3885 does not affect 1.1.16 (the version in stretch), so that patch was left out (you may want to indicate this in the security tracker). On the other hand three followup patches fixing two bugs in the security fixes are included based on https://lists.clusterlabs.org/pipermail/users/2019-May/025822.html. Here is the full glorious debdiff: diff -Nru pacemaker-1.1.16/debian/changelog pacemaker-1.1.16/debian/changelog --- pacemaker-1.1.16/debian/changelog 2016-12-01 14:15:23.0 +0100 +++ pacemaker-1.1.16/debian/changelog 2019-06-02 08:08:12.0 +0200 @@ -1,3 +1,35 @@ +pacemaker (1.1.16-1+deb9u1) stretch-security; urgency=high + + [ Christoph Berg ] + * [d3d1561] Remove myself from Uploaders. + + [ Ferenc Wágner ] + * [53a63fc] Backport upstream security fixes from pull request #1749. +1. CVE-2018-16877: Insufficient local IPC client-server authentication + on the client's side can lead to local privesc. A local attacker + could use this flaw, and combine it with other IPC weaknesses, to + achieve local privilege escalation. +2. CVE-2018-16878: Insufficient verification inflicted preference of + uncontrolled processes can lead to DoS. +The backported patch bundles were taken from + https://src.fedoraproject.org/rpms/pacemaker/c/f48a85ec68e299dfc53655b121e661b7c488ed71?branch=f28: +- High-pacemakerd-vs.-IPC-procfs-confused-deputy-authentic.patch + (fixes CVE-2018-16877 and CVE-2018-16878) +- Med-controld-fix-possible-NULL-pointer-dereference.patch + (fixes an additional problem which is more likely triggerable now that + the problems related to CVE-2018-16878 are avoided) +CVE-2019-3885 does not affect Pacemaker 1.1.16, so +High-libservices-fix-use-after-free-wrt.-alert-handl.patch is not +included in this backport. +Thanks to Jan Pokorný (Closes: #927714) + * [fcbaaae] Acknowledge the new symbols + * [babde58] Backport three more patches from upstream fixing memory safety +bugs. +Clearing up fallout from the preceding security fixes. +Thanks to Ken Gaillot + + -- Ferenc Wágner Sun, 02 Jun 2019 08:08:12 +0200 + pacemaker (1.1.16-1) unstable; urgency=medium * [d90daf5] Refresh our patches diff -Nru pacemaker-1.1.16/debian/control pacemaker-1.1.16/debian/control --- pacemaker-1.1.16/debian/control 2016-12-01 14:14:42.0 +0100 +++ pacemaker-1.1.16/debian/control 2019-05-18 16:41:29.0 +0200 @@ -5,7 +5,6 @@ Uploaders: Richard B Winters , Ferenc Wágner , - Christoph Berg , Adrian Vondendriesch , Build-Depends: cluster-glue-dev, diff -Nru pacemaker-1.1.16/debian/gbp.conf pacemaker-1.1.16/debian/gbp.conf --- pacemaker-1.1.16/debian/gbp.conf2016-12-01 14:07:08.0 +0100 +++ pacemaker-1.1.16/debian/gbp.conf2019-05-22 11:01:26.0 +0200 @@ -1,15 +1,12 @@ [DEFAULT] -debian-branch = debian/master +debian-branch = debian/stretch upstream-branch = upstream/latest -debian-tag-msg = Debian release %(version)s - -[import-orig] pristine-tar = True -[gbp-pq] +[pq] patch-numbers = False -[gbp-dch] +[dch] full = True multimaint-merge = True id-length = 7 diff -Nru pacemaker-1.1.16/debian/libcrmcommon3.symbols pacemaker-1.1.16/debian/libcrmcommon3.symbols --- pacemaker-1.1.16/debian/libcrmcommon3.symbols 2016-12-01 14:14:42.0 +0100 +++ pacemaker-1.1.16/debian/libcrmcommon3.symbols 2019-05-22 11:56:47.0 +0200 @@ -94,6 +94,7 @@ crm_ipc_default_buffer_size@Base 1.1.11 crm_ipc_destroy@Base 1.1.9 crm_ipc_get_fd@Base 1.1.9 + crm_ipc_is_authentic_process@Base 1.1.16-1+deb9u1~ crm_ipc_name@Base 1.1.9 crm_ipc_new@Base 1.1.9 crm_ipc_prepare@Base 1.1.9 @@ -292,6 +293,7 @@ parse_date@Base 1.1.9 parse_op_key@Base 1.1.9
Bug#927714: CVE-2019-3885 CVE-2018-16877 CVE-2018-16878
On Mon, 22 Apr 2019 09:07:04 +0200 Salvatore Bonaccorso wrote: >> Please see https://www.openwall.com/lists/oss-security/2019/04/17/1 > > Please note that when fixing the issues, in the original patchsets > there were some behaviour regressions, I think they should be adressed > in the followups as noted in > https://www.openwall.com/lists/oss-security/2019/04/18/2 Hi Salvatore, After several readings of the followup you linked to I think those "prior behavioral changes" are the fixes themselves, that is, the more thorough authorization checks. Don't you agree? I proceeded to apply the patches in the pull request to the pacemaker quilt queue. Unfortunately they introduce new symbols in libcrmcommon: crm_ipc_is_authentic_process and pcmk__ipc_is_authentic_process_active. Am I expected to update the libtool version info in light of this? -- Thanks, Feri
Bug#926162: unblock: opensaml/3.0.1-1
Control: tags -1 - moreinfo Niels Thykier writes: > Please go ahead with the upload and remove the moreinfo tag when it is > ready for unblocking. Hi, opensaml 3.0.1-1 is already in unstable, ready for unblocking. -- Thanks, Feri
Bug#925978: shibboleth-sp2-common: fills up the /var/cache directory with incommon-metadata.xml.XXXX
Control: reassign 925978 src:shibboleth-sp Control: forwarded 925978 https://issues.shibboleth.net/jira/browse/SSPCPP-731 Control: tags 925978 + upstream Control: fixed 925978 3.0.2+dfsg1-1 Matt Weatherford writes: > This continues to happen, but is easy to manually clear up so low > priority... I wanted to report it out of respect for the work you > guys do & in hopes its already fixed in the 3.0 release "Cantor, Scott" writes: > Those are discovery feed cache files, and yes, it's fixed in V3, it > was a regression that got fixed and rebroken a couple of times. It's > an easy fix to backport if need be. Thanks for the report, Matt, and thanks for the fix, Scott. As we're currently working on backporting V3 to stretch, I've got no immediate plans to do a stable update for this. However, I'm somewhat confused about the fix: [1] says it's a "one character fix", but d2e6d712 is a little more elaborate. How do these fit together? [1] https://issues.shibboleth.net/jira/browse/SSPCPP-731?focusedCommentId=27304=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-27304 -- Thanks, Feri
Bug#925524: init-system-helpers: Please provide a stretch backport for debhelper 12~
Michael Biebl writes: > Personally I prefer to revert the compat bumps when doing backports for > stretch (like in [1]) as I like to to keep the impact on the stable > system as minimal as possible. Pulling in a newer i-s-h is a rather > significant change. I see. Dropping back to compat 10 is certainly an option, now that I know that only compat 11 is affected. Thing is, this package never used compat 10, so this requires careful review. > Thankfully not as significant as we had between jessie → stretch. So a > backport of i-s-h might indeed be feasible on a cursory glance. Given that it would potentially help several maintainers, could you please give this some more serious consideration? Strictly on the theoretical level, of course. :) -- Thanks, Feri
Bug#925524: init-system-helpers: Please provide a stretch backport for debhelper 12~
Felipe Sateler writes: > I'm not opposed to a backport, and I don't think there are many > problems with attempting it. However, I do not have time to prepare > and test such a backport. Help welcome. I can do the busy-work of backporting, but I lack the perspective to tell whether it's feasible now or in the long run. Looking at the changelog it feels safe to install 1.56 on a stretch system, and this close to the release I wouldn't expect anything to come up before stretch-backports closes, though... -- Regards, Feri
Bug#925524: init-system-helpers: Please provide a stretch backport for debhelper 12~
Niels Thykier writes: > I don't think I have much to add to it really beyond what is covered in > https://nthykier.wordpress.com/2019/01/04/debhelper-compat-12-is-now-released/ Thanks for the good writeup, I missed it. > Sure it would be great to have one less caveat for upgrating to compat > 12. But mostly release compat 12 before buster was to ensure people > could assume compat 12 was present in buster (and less about stretch). I see. I was forced to compat 12 by #887904 for shibboleth-sp back in August, and now we try to backport it to stretch. Working around #887904 on compat 11 does not seem a simple exercise for me, that's why I decided to pursue an init-system-helpers backport. Please correct me if I overlook something. > Related note (with my RT hat on): Please defer debhelper compat bumps > for anything targeting buster as it is not considered a "minimal change". I didn't even think of such things. :) However, now that you reminded me, I've got a tricky minimal change for your RT hat, let me put that forward as well... -- Thanks, Feri
Bug#925524: init-system-helpers: Please provide a stretch backport for debhelper 12~
On Tue, 26 Mar 2019 11:29:29 +0100 =?utf-8?q?Ferenc_W=C3=A1gner?= wrote: > Debhelper compat level 12 is stable and available in stretch-backports, > but uses the --skip-systemd-native option of invoke-rc.d, thus adds > init-system-helpers (>= 1.54~) to misc:Pre-Depends. This is necessary > to fix https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887904. > However, the resulting pre-dependency can't be satisfied in stretch, > making the resulting binaries of compat 12 packages uninstallable in > stretch. Could you please provide a stretch backport of a suitable > init-system-helpers version to accompany debhelper 12~, or do you > recommend some other solution to this problem? (I suppose installing a > newer version of init-system-helpers manually to a stretch system > wouldn't break it, but it's rather inconvenient even if you confirm it.) Hi Niels, I'm not sure you noticed this report. In any case, I'd be much interested to hear your opinion concerning this issue. -- Thanks, Feri
Bug#925354: [Debian-ha-maintainers]: Bug#925354: pacemaker-dev: missing Breaks+Replaces: libcrmcluster1-dev
Valentin Vidic writes: > On Mon, Mar 25, 2019 at 03:45:58PM +0100, Andreas Beckmann wrote: > >> In that case you should probably add Breaks+Replaces against all of the >> old -dev packages that were merged, just to be on the safe side. > > Yes, that is the plan. I think wferi will take care of it if he > has time? Yes, I'm on it. It's somewhat bizarre: libcrmcluster1-dev wasn't part of jessie or stretch. Similarly, pacemaker-dev was present in wheezy only, until I reintroduced it recently, and looks like its ghost came back to haunt us. I didn't anticipate piuparts to start with wheezy when testing buster upgrades. -- Thanks, Feri
Bug#924962: unblock: coturn/4.5.1.1-1
Dear Release Team, I sponsored the late upload of 4.5.1.1-1, please let me try to make up for that by providing some more information (hopefully) in favor of the unblock. First of all, the Docker changes, which are the biggest part of the src debdiff, do not affect the binary package at all, please just ignore them. On Tue, 19 Mar 2019 09:25:13 +0100 =?utf-8?b?TcOpc3rDoXJvcyBNaWjDoWx5?= wrote: > In 4.5.1.0 we droped root privilege but we didn't considered that in > the defualt file logging it will cause an issue. The issue is the logs being put into (after several fallback steps due to lack of privileges) the private tmpfs created by systemd. This makes them ephemeral, and uses memory for doing so. Also, the package does not provide any logrotate config, so syslog is a better choice for this reason as well. This change is implemented by shipping the conffile /etc/turnserver.conf again (it was inadvertently dropped from 4.5.1.0-1) and patching it to use syslog. The TTL query always returns 0 on Sparc64, so the relay code has use the default 64 on that architecture to work at all. This is a workaround for some bug, possibly in libc. The "pwd check" part fixes a NULL pointer dereference, which was an oversight, a regression introduced in 4.5.1.0. All the remaining changes fix #916919, the alignment problem. -- Thanks for your consideration, Feri
Bug#924748: unblock: shibboleth-sp/3.0.4+dfsg1-1
Control: tag -1 - moreinfo Jonathan Wiltshire writes: > Please go ahead and remove the moreinfo tag when it is ready to unblock. Thanks, uploaded. Looks like Niels has already unblocked it, but I'm removing the moreinfo tag nevertheless. -- Regards, Feri
Bug#924577: unblock: xmltooling/3.0.4-1
Emilio Pozuelo Monfort writes: > The diff looks fine, please go ahead with 3.0.4-1. Uploaded, thanks! -- Feri
Bug#924346: xmltooling: CVE-2019-9628: XML parser class fails to trap exceptions on malformed XML declaration
Moritz Muehlenhoff writes: > On Tue, Mar 12, 2019 at 10:19:00AM +0100, wf...@niif.hu wrote: > >> The resulting packages works fine in my setup. However, I failed to >> reproduce the original issue under stretch. After consulting upstream, >> it turns out that the old Xerces library actually helps somewhat in this >> case, please see Scott Cantor's reply below. So the known exploit >> (using an invalid XML declaration) does not work on stable, but if >> somebody finds a way to trigger a DOMException in Xerces 3.1, any >> xmltooling users will crash all the same. See also his comment on >> https://issues.apache.org/jira/browse/XERCESC-2016. > > I think we can still fix this via stretch-security OK, uploaded. > it's better to fix the root cause nonetheless. Even though the Xerces change is suspicious, the documentation allows the parser to throw DOMExceptions, so they must be handled by the callers, which this fix achieves. -- Regards, Feri
Bug#924346: xmltooling: CVE-2019-9628: XML parser class fails to trap exceptions on malformed XML declaration
Salvatore Bonaccorso writes: > On Sat, Mar 09, 2019 at 07:25:52PM +0100, wf...@niif.hu wrote: > >> I reserved a CVE from Mitre, backported the probable patch to >> xmltooling 1.6.0-4+deb9u1 in stable and prepared a tentative package >> with it, please see the debdiff below. I plan to add more >> substantive info to the changelog as I get hold of any, but I expect >> no other changes. > > Thanks for preparing the update, the issue is now public, so filled a > respective Debian bug for it. Thanks, Salvatore! > Were you able to test the resulting package in some extend under > stretch? The resulting packages works fine in my setup. However, I failed to reproduce the original issue under stretch. After consulting upstream, it turns out that the old Xerces library actually helps somewhat in this case, please see Scott Cantor's reply below. So the known exploit (using an invalid XML declaration) does not work on stable, but if somebody finds a way to trigger a DOMException in Xerces 3.1, any xmltooling users will crash all the same. See also his comment on https://issues.apache.org/jira/browse/XERCESC-2016. JFYI: we plan to upload the Shibboleth 3 stack to stretch-backports, which will use the xerces-c 3.2 stretch backport. These will be fixed packages, though, in whatever form the Release Team gives its blessing for. > I think it sounds sensible to release a DSA for it, so in case yes > please do upload to security-master (you might add the Debian bug > closer as well if you need to rebuild and want to add additional > information). It will add the closer and the extra information, but won't upload to security-master unless you tell me so again after reassessing the situation based on the new information here. "Cantor, Scott" writes: > Yeah, it's a Xerces change. I didn't make it, but it was applied to > the trunk as part of XERCES-2016 and there's a very odd change that > causes the XMLScanner to leak through versions that start with "1." It > doesn't look correct to me, but it's not for me to say. > > Anything up to Xerces 3.1.x catches that and raises the old > XMLException type that was already caught. Xerces 3.2 ends up with a > DOMException, which is what caused the crash. > > Now: the bug is still a bug. I have no idea under what conditions > other DOMExceptions could be triggered, and if it happens, you have a > crash. And the DOMLSParser::parse method is absolutely allowed to > throw that type of exception, that's in the docs and in the DOM > standard. But this specific case is only exploitable under Xerces 3.2. > > Personally, I would just push the fix and be done with it, it's not a > hard change, but it's certainly your call. I had to because I require > Xerces 3.2 at this point in all my packages. > > I may update the advisory, but I'm not enthused about overcomplicating > the message I'm sending with more caveats and conditions. > > Good catch though. > > -- Scott -- Regards, Feri
Bug#923740: unblock: pacemaker/2.0.1-1
Control: tags -1 - moreinfo Jonathan Wiltshire writes: > On Tue, Mar 05, 2019 at 09:45:26AM +0100, Paul Gevers wrote: > >> I propose you let 2.0.1~rc5-1 migrate to testing, upload 2.0.1-1 to >> unstable after that, provide us with a debdiff between 2.0.1~rc5-1 and >> 2.0.1-1 in this bug report and we'll look at that diff. That way, the >> review is much more trivial for us. Please remove the moreinfo tag once >> we are there. > > ~rc5-1 just migrated. Indeed, thanks for the note! Accordingly, 2.0.1-1 is uploaded, and the debdiff has already been posted earlier. So, dear Release Team, please unblock pacemaker 2.0.1-1. -- Thanks, Feri
Bug#923740: unblock: pacemaker/2.0.1-1
Paul Gevers writes: > I propose you let 2.0.1~rc5-1 migrate to testing Hi Paul, OK, this is what Niels suggested as well (I think). > upload 2.0.1-1 to unstable after that Without a definite ACK from you? > provide us with a debdiff between 2.0.1~rc5-1 and 2.0.1-1 in this bug > report That's what I submitted in the first place, so already done. > Please remove the moreinfo tag once we are there. I'll do so once 2.0.1~rc5-1 migrated to testing. > By the way, you would have probably missed it by more than one day. I'm tragic at simulating archive maintenance in my head. :) Upload time of day certainly is a factor in such computations, and I don't know the timing of the cron jobs. If you happen to know offhand: which was the last second for uploads targeting buster to not need a manual unblock? -- Thanks, Feri
Bug#843419: init-d-script: please provide a way to not use the --name option of start-stop-daemon
Dmitry Bogatov writes:
> What about this patch? Would it satisfy your need?
Perfectly. The extra braces (${COMMAND_NAME}, ${NAME}) look somewhat
alien, but as you prefer.
> Can you please review wording -- I am very bad at writing manpages.
I'm no native speaker either, but inserted a couple of
articles/alternatives below.
> +Argument to
The argument of the
> +.I --name
> +option of
option of the
> +.B start-stop-daemon
> +program is COMMAND_NAME variable, if it is set, or NAME otherwise.
program is the value of the COMMAND_NAME variable if set, otherwise the
value of the NAME variable.
> +.P
> If the daemon support reloading, implement the do_reload function to
If the daemon supports...
I hope this makes sense. Do you think it can reach buster? It isn't
critical, though. Thanks for your work!
--
Cheers,
Feri
Bug#922984: xml-security-c: ECDSA XML signature generation segmentation fault
Alejandro Claro writes: > We found a bug in Apache Santuario C, related to ECDSA signature > generation, few years ego. We provide the fix to the Apache team, and > Scott Cantor kindly accepted the fix in the project. How ever the fix > was introduced in series 2.x of the the library. Dear Alejandro, I can propose your fix for the next stable update, but I don't know when that will be released. On the other hand, if this buffer overflow leads to an exploitable vulnerability, the Security Team could fast-track the fix. Have you got such a scenario? -- Thanks, Feri
Bug#843419: init-d-script: please provide a way to not use the --name option of start-stop-daemon
control: tags -1 -moreinfo
Dmitry Bogatov writes:
> Sorry, I do not understand. You, as init script writer, choose value of
> argument to $NAME. Why can't you limit it to required length?
Sorry, I indeed left out important context, thus even I had difficulty
recalling the reason for my report now. So:
I use /lib/init/init-d-script to provide an init script for the
corosync-qdevice daemon. I have to set NAME="corosync-qdevice", because
the NAME variable is used in several informational messages as well
besides as the --name value for start-stop-daemon. But then I have to
override the do_start_cmd() and do_stop_cmd() shell functions to use the
correct --name value (or not use one at all). The other choice would be
letting the informational messages use the truncated name, which is
suboptimal in a different (and visible) way.
I imagine that having an optional COMM_NAME (pick any name) variable
would solve this nicely, if it was used in preference to NAME for the
--name option of start-stop-daemon if it was set, like
start-stop-daemon --name "${COMM_NAME:-$NAME}"
or maybe even (just an untested idea):
if [ -n "${COMM_NAME:=$NAME}" ]; then
NAME_ARG="--name=$COMM_NAME"
else
NAME_ARG=""
fi
[...]
start-stop-daemon [...] "$NAME_ARG" [...]
--
Thanks,
Feri
Bug#923050: RFS: pk2/1.2.1-1 [ITP] -- 2D Oldschool platform game where you control a rooster
Hi, Is the g++ dependency of the main game binary intentional? I built the game for stretch, it went OK (after reducing the debhelper compatibility level to 11, but that isn't a problem). The game starts, but I'm unable to select a map: the presented list is empty, though strace shows it finds the /usr/share/games/pk2/data/episodes directory. Also, it tries to create the config directory in /usr/share/games/pk2/data, which fails with permission denied. -- Regards, Feri
