Bug#1069725: nagios-plugins-contrib: pmp-check-mysql-file-privs generates WARN state on default MariaDB installation

[Moritz Schlarb]

Source: nagios-plugins-contrib
Version: 46.20240417
Severity: normal
Tags: upstream

On a not heavily modified default installation, the check pmp-check-mysql-file-
privs gives the following warning by default:

WARN files with wrong ownership: /var/lib/mysql/debian-10.11.flag

(
For systems that have been upgraded, it is probably even more:
WARN files with wrong ownership: /var/lib/mysql/mysql_upgrade_info
/var/lib/mysql/debian-10.5.flagWARN
)

Of course, a workaround would be to chown those files, since that should not do
much harm, but it might be nice to just patch the check to ignore those
(debian-specific) files.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1069252: bookworm-pu: package libapache2-mod-auth-openidc/2.4.12.3-2+deb12u1

[Moritz Schlarb]

Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: libapache2-mod-auth-open...@packages.debian.org, 
t...@security.debian.org
Control: affects -1 + src:libapache2-mod-auth-openidc
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
Backported the patch to fix CVE-2024-24814.
Does not require DSA as per #1064183#28.

[ Impact ]
DoS when `OIDCSessionType client-cookie` is set and
a crafted Cookie header is supplied
https://github.com/OpenIDC/mod_auth_openidc/security/advisories/GHSA-
hxr6-w4gc-7vvv

[ Tests ]
Manually on own infra.

[ Risks ]
Patch has minimal complexity but is from the upstream author
who is generally very knowledgable about his code.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
Added upstream commit as patch that fixes oidc_util_get_chunked_cookie
function to properly handle chunked cookies and decline malicious ones.

[ Other info ]
diff -Nru libapache2-mod-auth-openidc-2.4.12.3/debian/changelog 
libapache2-mod-auth-openidc-2.4.12.3/debian/changelog
--- libapache2-mod-auth-openidc-2.4.12.3/debian/changelog   2023-05-02 
11:48:09.0 +0200
+++ libapache2-mod-auth-openidc-2.4.12.3/debian/changelog   2024-04-18 
14:20:00.0 +0200
@@ -1,3 +1,16 @@
+libapache2-mod-auth-openidc (2.4.12.3-2+deb12u1) bookworm; urgency=medium
+
+  * CVE-2024-24814: Missing input validation on mod_auth_openidc_session_chunks
+cookie value made the server vulnerable to a Denial of Service (DoS)
+attack. If an attacker manipulated the value of the OpenIDC cookie to a
+very large integer like , the server struggled with the request for
+a long time and finally returned a 500 error. Making a few requests of this
+kind caused servers to become unresponsive, and so attackers could thereby
+craft requests that would make the server work very hard and/or crash with
+minimal effort. (Closes: #1064183)
+
+ -- Moritz Schlarb   Thu, 18 Apr 2024 14:20:00 +0200
+
 libapache2-mod-auth-openidc (2.4.12.3-2) unstable; urgency=high
 
   * Add patch to Fix CVE-2023-28625 (Closes: #1033916)
diff -Nru libapache2-mod-auth-openidc-2.4.12.3/debian/gbp.conf 
libapache2-mod-auth-openidc-2.4.12.3/debian/gbp.conf
--- libapache2-mod-auth-openidc-2.4.12.3/debian/gbp.conf2023-05-02 
11:41:28.0 +0200
+++ libapache2-mod-auth-openidc-2.4.12.3/debian/gbp.conf2024-04-18 
14:20:00.0 +0200
@@ -1,2 +1,3 @@
 [DEFAULT]
 pristine-tar = True
+debian-branch = bookworm
diff -Nru 
libapache2-mod-auth-openidc-2.4.12.3/debian/patches/0001-Fix-CVE-2023-28625-segfault-DoS-when-OIDCStripCookie.patch
 
libapache2-mod-auth-openidc-2.4.12.3/debian/patches/0001-Fix-CVE-2023-28625-segfault-DoS-when-OIDCStripCookie.patch
--- 
libapache2-mod-auth-openidc-2.4.12.3/debian/patches/0001-Fix-CVE-2023-28625-segfault-DoS-when-OIDCStripCookie.patch
 2023-05-02 11:47:32.0 +0200
+++ 
libapache2-mod-auth-openidc-2.4.12.3/debian/patches/0001-Fix-CVE-2023-28625-segfault-DoS-when-OIDCStripCookie.patch
 2024-04-18 14:20:00.0 +0200
@@ -1,9 +1,9 @@
 From: Moritz Schlarb 
 Date: Tue, 2 May 2023 11:44:18 +0200
 Subject: Fix CVE-2023-28625: segfault DoS when OIDCStripCookies is set
+
 Origin: upstream, 
https://github.com/OpenIDC/mod_auth_openidc/security/advisories/GHSA-f5xw-rvfr-24qr
 Applied-Upstream: 2.4.13.2, 
https://github.com/OpenIDC/mod_auth_openidc/commit/c0e1edac3c4c19988ccdc7713d7aebfce6ff916a
-
 ---
  src/mod_auth_openidc.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
diff -Nru 
libapache2-mod-auth-openidc-2.4.12.3/debian/patches/0002-fix-DoS-CVE-2024-24814.patch
 
libapache2-mod-auth-openidc-2.4.12.3/debian/patches/0002-fix-DoS-CVE-2024-24814.patch
--- 
libapache2-mod-auth-openidc-2.4.12.3/debian/patches/0002-fix-DoS-CVE-2024-24814.patch
   1970-01-01 01:00:00.0 +0100
+++ 
libapache2-mod-auth-openidc-2.4.12.3/debian/patches/0002-fix-DoS-CVE-2024-24814.patch
   2024-04-18 14:20:00.0 +0200
@@ -0,0 +1,60 @@
+From: Hans Zandbelt 
+Date: Tue, 6 Feb 2024 23:45:40 +0100
+Subject: [PATCH] release 2.4.15.2: fix DoS CVE-2024-24814
+
+fix CVE-2024-24814: DoS when 'OIDCSessionType client-cookie' is set and
+a crafted Cookie header is supplied
+https://github.com/OpenIDC/mod_auth_openidc/security/advisories/GHSA-hxr6-w4gc-7vvv
+
+Signed-off-by: Hans Zandbelt 
+---
+ src/util.c | 35 +--
+ 1 file changed, 17 insertions(+), 18 deletions(-)
+
+diff --git a/src/util.c b/src/util.c
+index e1f0a3a..7a86c24 100644
+--- a/src/util.c
 b/src/util.c
+@@ -1325,25 +1325,24 @@ static char* 
oidc_util_get_chunk_cookie_name(request_rec *r,
+  */
+ char* oidc_util_get_chunked_cookie(request_rec *r, const char *cookieName,
+   int chunkSize) {
+-  char *cookieValue = NULL;
+-  char

Bug#1069253: bullseye-pu: package libapache2-mod-auth-openidc/2.4.9.4-0+deb11u4

[Moritz Schlarb]

Package: release.debian.org
Severity: normal
Tags: bullseye
X-Debbugs-Cc: libapache2-mod-auth-open...@packages.debian.org, 
t...@security.debian.org
Control: affects -1 + src:libapache2-mod-auth-openidc
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
Backported the patch to fix CVE-2024-24814.
Does not require DSA as per #1064183#28.

[ Impact ]
DoS when `OIDCSessionType client-cookie` is set and
a crafted Cookie header is supplied
https://github.com/OpenIDC/mod_auth_openidc/security/advisories/GHSA-
hxr6-w4gc-7vvv

[ Tests ]
Manually on own infra.

[ Risks ]
Patch has minimal complexity but is from the upstream author
who is generally very knowledgable about his code.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
Added upstream commit as patch that fixes oidc_util_get_chunked_cookie
function to properly handle chunked cookies and decline malicious ones.

[ Other info ]
diff -Nru libapache2-mod-auth-openidc-2.4.9.4/debian/changelog 
libapache2-mod-auth-openidc-2.4.9.4/debian/changelog
--- libapache2-mod-auth-openidc-2.4.9.4/debian/changelog2023-05-02 
12:59:57.0 +0200
+++ libapache2-mod-auth-openidc-2.4.9.4/debian/changelog2024-04-18 
14:27:26.0 +0200
@@ -1,3 +1,16 @@
+libapache2-mod-auth-openidc (2.4.9.4-0+deb11u4) bullseye; urgency=high
+
+  * CVE-2024-24814: Missing input validation on mod_auth_openidc_session_chunks
+cookie value made the server vulnerable to a Denial of Service (DoS)
+attack. If an attacker manipulated the value of the OpenIDC cookie to a
+very large integer like , the server struggled with the request for
+a long time and finally returned a 500 error. Making a few requests of this
+kind caused servers to become unresponsive, and so attackers could thereby
+craft requests that would make the server work very hard and/or crash with
+minimal effort. (Closes: #1064183)
+
+ -- Moritz Schlarb   Thu, 18 Apr 2024 14:27:26 +0200
+
 libapache2-mod-auth-openidc (2.4.9.4-0+deb11u3) bullseye-security; urgency=high
 
   * Add patch to Fix CVE-2023-28625 (Closes: #1033916)
diff -Nru 
libapache2-mod-auth-openidc-2.4.9.4/debian/patches/0004-fix-DoS-CVE-2024-24814.patch
 
libapache2-mod-auth-openidc-2.4.9.4/debian/patches/0004-fix-DoS-CVE-2024-24814.patch
--- 
libapache2-mod-auth-openidc-2.4.9.4/debian/patches/0004-fix-DoS-CVE-2024-24814.patch
1970-01-01 01:00:00.0 +0100
+++ 
libapache2-mod-auth-openidc-2.4.9.4/debian/patches/0004-fix-DoS-CVE-2024-24814.patch
2024-04-18 14:25:44.0 +0200
@@ -0,0 +1,60 @@
+From: Hans Zandbelt 
+Date: Tue, 6 Feb 2024 23:45:40 +0100
+Subject: [PATCH] release 2.4.15.2: fix DoS CVE-2024-24814
+
+fix CVE-2024-24814: DoS when 'OIDCSessionType client-cookie' is set and
+a crafted Cookie header is supplied
+https://github.com/OpenIDC/mod_auth_openidc/security/advisories/GHSA-hxr6-w4gc-7vvv
+
+Signed-off-by: Hans Zandbelt 
+---
+ src/util.c | 35 +--
+ 1 file changed, 17 insertions(+), 18 deletions(-)
+
+diff --git a/src/util.c b/src/util.c
+index c6453d0..6782293 100644
+--- a/src/util.c
 b/src/util.c
+@@ -1288,25 +1288,24 @@ static char* 
oidc_util_get_chunk_cookie_name(request_rec *r,
+  */
+ char* oidc_util_get_chunked_cookie(request_rec *r, const char *cookieName,
+   int chunkSize) {
+-  char *cookieValue = NULL;
+-  char *chunkValue = NULL;
+-  int i = 0;
+-  if (chunkSize == 0) {
+-  cookieValue = oidc_util_get_cookie(r, cookieName);
+-  } else {
+-  int chunkCount = oidc_util_get_chunked_count(r, cookieName);
+-  if (chunkCount > 0) {
+-  cookieValue = "";
+-  for (i = 0; i < chunkCount; i++) {
+-  chunkValue = oidc_util_get_cookie(r,
+-  
oidc_util_get_chunk_cookie_name(r, cookieName, i));
+-  if (chunkValue != NULL)
+-  cookieValue = apr_psprintf(r->pool, 
"%s%s", cookieValue,
+-  chunkValue);
+-  }
+-  } else {
+-  cookieValue = oidc_util_get_cookie(r, cookieName);
++  char *cookieValue = NULL, *chunkValue = NULL;
++  int chunkCount = 0, i = 0;
++  if (chunkSize == 0)
++  return oidc_util_get_cookie(r, cookieName);
++  chunkCount = oidc_util_get_chunked_count(r, cookieName);
++  if (chunkCount == 0)
++  return oidc_util_get_cookie(r, cookieName);
++  if ((chunkCount < 0) || (chunkCount > 99)) {
++  oidc_warn(r, "chunk count out of bounds: %d", chunkCount);
++ 

Bug#1064183: libapache2-mod-auth-openidc: CVE-2024-24814

[Moritz Schlarb]

Dear Salvatore,

I've prepared, built, tested and uploaded fixed versions for bullseye 
(2.4.9.4-0+deb11u4), bookworm (2.4.12.3-2+deb12u1) and trixie (2.4.15.7-1).


Would you like to issue a DSA for them or is it enough that they are 
included in the next stable point release?


Regards,
Moritz

On 18.02.24 07:57, Salvatore Bonaccorso wrote:

Source: libapache2-mod-auth-openidc
Version: 2.4.15.1-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libapache2-mod-auth-openidc.

CVE-2024-24814[0]:
| mod_auth_openidc is an OpenID Certified™ authentication and
| authorization module for the Apache 2.x HTTP server that implements
| the OpenID Connect Relying Party functionality. In affected versions
| missing input validation on mod_auth_openidc_session_chunks cookie
| value makes the server vulnerable to a denial of service (DoS)
| attack. An internal security audit has been conducted and the
| reviewers found that if they manipulated the value of the
| mod_auth_openidc_session_chunks cookie to a very large integer, like
| , the server struggles with the request for a long time and
| finally gets back with a 500 error. Making a few requests of this
| kind caused our server to become unresponsive. Attackers can craft
| requests that would make the server work very hard (and possibly
| become unresponsive) and/or crash with minimal effort. This issue
| has been addressed in version 2.4.15.2. Users are advised to
| upgrade. There are no known workarounds for this vulnerability.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-24814
 https://www.cve.org/CVERecord?id=CVE-2024-24814
[1] 
https://github.com/OpenIDC/mod_auth_openidc/security/advisories/GHSA-hxr6-w4gc-7vvv
[2] 
https://github.com/OpenIDC/mod_auth_openidc/commit/4022c12f314bd89d127d1be008b1a80a08e1203d

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore


--
Moritz Schlarb
Unix und Cloud
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz

OpenPGP-Fingerprint: DF01 2247 BFC6
 5501 AFF2 8445 0C24 B841 C7DD BAAF


smime.p7s
Description: S/MIME Cryptographic Signature

Bug#1062085: seafile-gui: Title bar on Wayland is not working as expected

[Moritz Schlarb]

Package: seafile-gui
Version: 9.0.3+ds1-1
Severity: normal
Tags: patch upstream
Forwarded: https://github.com/haiwen/seafile-client/issues/991

Especially, the window can not be moved


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-5-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages seafile-gui depends on:
ii  libc6   2.37-14
ii  libgcc-s1   13.2.0-10
ii  libglib2.0-02.78.3-2
ii  libjansson4 2.14-2+b2
ii  libqt5core5a5.15.10+dfsg-6
ii  libqt5dbus5 5.15.10+dfsg-6
ii  libqt5gui5  5.15.10+dfsg-6
ii  libqt5network5  5.15.10+dfsg-6
ii  libqt5webkit5   5.212.0~alpha4-33
ii  libqt5widgets5  5.15.10+dfsg-6
ii  libquazip5-10.9.1-3
ii  libseafile0 9.0.3-1
ii  libsearpc1  3.3.0+really3.3+git20230527.783141f-1
ii  libsqlite3-03.45.0-1
ii  libstdc++6  13.2.0-10
ii  seafile-daemon  9.0.3-1

seafile-gui recommends no packages.

Versions of packages seafile-gui suggests:
ii  seafile-cli  9.0.3-1

-- no debconf information

Bug#1061419: burp.timer claims to be a timer unit for burp client, but isn't

[Moritz Schlarb]

Package: burp
Version: 3.1.4-1
Severity: normal
X-Debbugs-Cc: mar...@uni-mainz.de

The package contains a burp.timer systemd timer unit file which claims to be a
timer unit for running burp as a client service, but this is not true because
the corresponding burp.service starts burp in server mode!
(This can lead to obscure problems because starting burp server creates CA
certificates and such which then don't match the ones from the real server.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-5-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages burp depends on:
ii  init-system-helpers  1.66
ii  libacl1  2.3.1-6
ii  libc62.37-13
ii  libcrypt11:4.4.36-4
ii  libncurses6  6.4+20240113-1
pn  librsync2
ii  libssl3  3.1.4-2
ii  libtinfo66.4+20240113-1
ii  zlib1g   1:1.3.dfsg-3+b1

Versions of packages burp recommends:
ii  openssl  3.1.4-2

burp suggests no packages.

Bug#1061288: libnss-docker: Does not work OOTB with Docker Engine 25 anymore

[Moritz Schlarb]

Package: libnss-docker
Version: 0.02-1.1
Severity: normal

Docker Engine v25 (not yet natively packaged as docker.io, I know - but docker-
ce from their repo has it) deprecates legacy API versions:
https://docs.docker.com/engine/deprecated/#deprecate-legacy-api-versions

This affects libnss-docker, because it has API version 1.21 (set at configure
time).

A workaround until Docker Engine v26 would be to set
DOCKER_MIN_API_VERSION=1.21 for the Docker Daemon, but after that, a minimum of
1.24 is required.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-5-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libnss-docker depends on:
ii  libc6  2.37-13

libnss-docker recommends no packages.

Versions of packages libnss-docker suggests:
pn  docker.io  

-- no debconf information

Bug#1060462: Fix indentation in embpfastcgi.pl

[Moritz Schlarb]

Control: tags -1 +patch

I've attached a patch and made a merge request on salsa to include it in 
the packaging:

https://salsa.debian.org/perl-team/modules/packages/libembperl-perl/-/merge_requests

Regards,
--
Moritz Schlarb
Unix und Cloud
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz

OpenPGP-Fingerprint: DF01 2247 BFC6
 5501 AFF2 8445 0C24 B841 C7DD BAAF
From: Moritz Schlarb 
Date: Thu, 11 Jan 2024 21:00:24 +0100
Subject: Fix indentation in heredoc in embpfastcgi.pl.templ

---
 embpfastcgi.pl.templ | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/embpfastcgi.pl.templ b/embpfastcgi.pl.templ
index 9c07d9b..967a2d7 100644
--- a/embpfastcgi.pl.templ
+++ b/embpfastcgi.pl.templ
@@ -45,7 +45,7 @@ while ($request -> Accept() >= 0)
 $ENV{SERVER_SOFTWARE} Embperl $Embperl::VERSION [$time]
 
 
-EOT
+EOT
 }
 }
 


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060462: libembperl-perl: Syntax error regarding heredoc in /usr/lib/cgi-bin/embpfastcgi.pl line 37

[Moritz Schlarb]

Source: libembperl-perl
Version: 2.5.0-17
Severity: normal
Tags: upstream

Can't find string terminator "EOT" anywhere before EOF at /usr/lib/cgi-
bin/embpfastcgi.pl line 37.


-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-5-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1000061: cfengine3: depends on obsolete pcre3 library

[Moritz Schlarb]

Control: tags -1 + patch

https://github.com/cfengine/core/pull/5391


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055453: update

[Moritz Schlarb]

Dear Andrew,

On 06.11.23 20:55, and...@arobeia.co.uk wrote:
See also discussion on upstream github 
https://github.com/OpenIDC/mod_auth_openidc/discussions/1067


thanks - I'll be watching that for some solution!

Regards,
--
Moritz Schlarb
Unix und Cloud
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz

OpenPGP-Fingerprint: DF01 2247 BFC6
 5501 AFF2 8445 0C24 B841 C7DD BAAF


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1020495: Patch to build network-manager-strongswan against GTK 4, too

[Moritz Schlarb]

Control: tags -1 + patch

Hi everyone,

the attached patch actually builds against GTK 4.
The previous version contained support for that, but didn't actually 
build for it.


Regards,
--
Moritz Schlarb
Unix und Cloud
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz

OpenPGP-Fingerprint: DF01 2247 BFC6
 5501 AFF2 8445 0C24 B841 C7DD BAAF
commit f77d5441f5d5014265473a4e76d368c3c2288165
Author: Moritz Schlarb 
Date:   Tue May 23 15:08:02 2023 +0200

Build editor component with GTK 4 too

Since the editor plugin contains logic to decide whether to load the
GTK 3 or GTK 4 version at runtime, this makes strongswan connections
editable from both nm-connection-editor as well as Gnome Settings.

Closes: #1020495
Closes: #1036607

diff --git a/debian/control b/debian/control
index fc236e2..a1fb9a0 100644
--- a/debian/control
+++ b/debian/control
@@ -6,9 +6,12 @@ Maintainer: Harald Dunkel 
 Build-Depends: debhelper-compat (= 13)
 	, network-manager-dev (>= 1.14)
 	, libnma-dev (>= 1.8)
+	, libnma-gtk4-dev (>= 1.8)
 	, libnm-dev (>= 1.14)
 	, libdbus-glib-1-dev
 	, libgtk-3-dev
+	, libgtk-4-dev
+	, libgtk-4-bin
 	, libsecret-1-dev
 	, automake
 	, gnome-common
diff --git a/debian/rules b/debian/rules
index e41c840..d4ac4e5 100755
--- a/debian/rules
+++ b/debian/rules
@@ -4,7 +4,7 @@
 	dh $@
 
 override_dh_auto_configure:
-	dh_auto_configure -- --without-libnm-glib --with-charon=/usr/lib/ipsec/charon-nm --libexecdir="\$$(prefix)/lib/NetworkManager"
+	dh_auto_configure -- --with-gtk4 --without-libnm-glib --with-charon=/usr/lib/ipsec/charon-nm --libexecdir="\$$(prefix)/lib/NetworkManager"
 
 override_dh_clean:
 	dh_clean -XNetworkManager-strongswan.metainfo.xml nm-strongswan-service.name


OpenPGP_signature
Description: OpenPGP digital signature

Bug#884650: fixed 884650 5.9.8-5

[Moritz Schlarb]

Control: fixed -1 5.9.8-5

I can't say how and when this got fixed, but it doesn't seem to happen 
anymore:


Mai 23 10:31:55 schlarb-0 charon-nm[170874]: 10[ENC] generating IKE_AUTH 
request 1 [ IDi N(INIT_CONTACT) CERTREQ CPRQ(ADDR ADDR6 DNS NBNS DNS6) 
SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_6_ADDR) 
N(ADD_6_ADDR) N(ADD_6_ADDR) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]


--
Moritz Schlarb
Unix und Cloud
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz

OpenPGP-Fingerprint: DF01 2247 BFC6
 5501 AFF2 8445 0C24 B841 C7DD BAAF


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1036607: "Error: unable to load VPN connection editor"

[Moritz Schlarb]

Package: network-manager-strongswan
Version: 1.6.0-1
Severity: important

When trying to add a new IPsec/IKEv2 connection or edit an existing one, the
Gnome Settings dialog just shows "Error: unable to load VPN connection editor".

With nm-connection-editor, it still works...


-- System Information:
Debian Release: 12.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-security'), (500, 'unstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages network-manager-strongswan depends on:
ii  libc62.36-9
ii  libglib2.0-0 2.74.6-2
ii  libgtk-3-0   3.24.37-2
ii  libnm0   1.42.4-1
ii  libnma0  1.10.6-1
ii  libsecret-1-00.20.5-3
ii  network-manager  1.42.4-1
ii  strongswan-nm5.9.8-5

network-manager-strongswan recommends no packages.

network-manager-strongswan suggests no packages.

-- no debconf information

Bug#1035377: unblock: libapache2-mod-auth-openidc/2.4.12.3-2

[Moritz Schlarb]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: libapache2-mod-auth-open...@packages.debian.org
Control: affects -1 + src:libapache2-mod-auth-openidc

Please unblock package libapache2-mod-auth-openidc

Fixes CVE-2023-28625 "segfault DoS when OIDCStripCookies is set".

[ Reason ]
Fixes #1033916 by fixing CVE-2023-28625.

[ Impact ]
The CVE with  Base Score:  7.5 HIGH
Vector:  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
would persist in the new stable release.

[ Tests ]
The patch has been verified by upstream and I have successfully
tested the new package version in our infrastructure.

[ Risks ]
The newly added patch changes just two lines by adding a
null pointer check. I don't see anything getting worse by
that.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

unblock libapache2-mod-auth-openidc/2.4.12.3-2

Bug#1033916: libapache2-mod-auth-openidc: CVE-2023-28625: segfault DoS when OIDCStripCookies is set

[Moritz Schlarb]

Dear Security Team,

regarding fixing this in Bullseye 
(https://salsa.debian.org/debian/libapache2-mod-auth-openidc/-/compare/769c3920203e7c64f6ff9456ee6858ac0cb034f0...a8e821213ac28ca0909ca4f1bf512de5e35f90fa):


Shall I upload this to security or proposed-updates?

Best regards,
Moritz

On 03.04.23 22:38, Salvatore Bonaccorso wrote:

Source: libapache2-mod-auth-openidc
Version: 2.4.12.3-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for libapache2-mod-auth-openidc.

CVE-2023-28625[0]:
| mod_auth_openidc is an authentication and authorization module for the
| Apache 2.x HTTP server that implements the OpenID Connect Relying
| Party functionality. In versions 2.0.0 through 2.4.13.1, when
| `OIDCStripCookies` is set and a crafted cookie supplied, a NULL
| pointer dereference would occur, resulting in a segmentation fault.
| This could be used in a Denial-of-Service attack and thus presents an
| availability risk. Version 2.4.13.2 contains a patch for this issue.
| As a workaround, avoid using `OIDCStripCookies`.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-28625
 https://www.cve.org/CVERecord?id=CVE-2023-28625
[1] 
https://github.com/OpenIDC/mod_auth_openidc/security/advisories/GHSA-f5xw-rvfr-24qr

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore


--
Moritz Schlarb
Unix und Cloud
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz

OpenPGP-Fingerprint: DF01 2247 BFC6
 5501 AFF2 8445 0C24 B841 C7DD BAAF


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1027894: QAudioOutput crashes on Qt 6 (SIGSEGV)

[Moritz Schlarb]

Hi everyone,

from the stack trace by Gael and some experimenting myself I figured it 
is probably this qt6-multimedia upstream bug: 
https://bugreports.qt.io/browse/QTBUG-108221


Regards,
Moritz

On 09.01.23 09:47, Gael Le Mignot wrote:

Hello,

I can confirm the bug on my own Sid, after upgrading end of last week.

A quick GDB gives me the following stacktrace :

Thread 1 "python3" received signal SIGSEGV, Segmentation fault.
0x714efb03 in QMediaDevices::audioOutputs() () from 
/lib/x86_64-linux-gnu/libQt6Multimedia.so.6
(gdb) bt
#0  0x714efb03 in QMediaDevices::audioOutputs() () at 
/lib/x86_64-linux-gnu/libQt6Multimedia.so.6
#1  0x714f1825 in QMediaDevices::defaultAudioOutput() () at 
/lib/x86_64-linux-gnu/libQt6Multimedia.so.6
#2  0x714d4a89 in QAudioOutput::QAudioOutput(QObject*) () at 
/lib/x86_64-linux-gnu/libQt6Multimedia.so.6
#3  0x715a55f9 in  () at 
/usr/lib/python3/dist-packages/PyQt6/QtMultimedia.abi3.so
#4  0x715a5742 in  () at 
/usr/lib/python3/dist-packages/PyQt6/QtMultimedia.abi3.so
#5  0x753912fc in  () at 
/usr/lib/python3/dist-packages/PyQt6/sip.cpython-310-x86_64-linux-gnu.so
#6  0x556cfd7a in _PyObject_MakeTpCall ()
#7  0x556ca092 in _PyEval_EvalFrameDefault ()
#8  0x556cf014 in _PyObject_FastCallDictTstate ()
#9  0x556e227c in  ()
#10 0x556cfd7a in _PyObject_MakeTpCall ()
#11 0x556ca092 in _PyEval_EvalFrameDefault ()
#12 0x5579fa90 in  ()
#13 0x5579f9e2 in PyEval_EvalCode ()
#14 0x557a4d67 in  ()
#15 0x556d9224 in  ()
#16 0x556cac5b in _PyEval_EvalFrameDefault ()
#17 0x556d8fd5 in _PyFunction_Vectorcall ()
#18 0x556c9d02 in _PyEval_EvalFrameDefault ()
#19 0x556d8fd5 in _PyFunction_Vectorcall ()
#20 0x556c534d in _PyEval_EvalFrameDefault ()
#21 0x556d8fd5 in _PyFunction_Vectorcall ()
#22 0x556c5163 in _PyEval_EvalFrameDefault ()
#23 0x556d8fd5 in _PyFunction_Vectorcall ()
#24 0x556c5163 in _PyEval_EvalFrameDefault ()
#25 0x556d8fd5 in _PyFunction_Vectorcall ()
#26 0x556d8447 in  ()
#27 0x557a479c in _PyObject_CallMethodIdObjArgs ()
#28 0x555ddcc6 in  ()
#29 0x556c7b2c in _PyEval_EvalFrameDefault ()
#30 0x5579fa90 in  ()
#31 0x5579f9e2 in PyEval_EvalCode ()
#32 0x557c5d53 in  ()
#33 0x557c058a in  ()
#34 0x557c5ae2 in  ()
#35 0x557c517a in _PyRun_SimpleFileObject ()
#36 0x557c4ed4 in _PyRun_AnyFileObject ()
#37 0x557b8c0c in Py_RunMain ()
#38 0x55794e67 in Py_BytesMain ()
#39 0x77cbc18a in __libc_start_call_main 
(main=main@entry=0x55794e30, argc=argc@entry=2, 
argv=argv@entry=0x7fffe7c8)
 at ../sysdeps/nptl/libc_start_call_main.h:58
#40 0x77cbc245 in __libc_start_main_impl
  (main=0x55794e30, argc=2, argv=0x7fffe7c8, init=, 
fini=, rtld_fini=, stack_end=0x7fffe7b8)
 at ../csu/libc-start.c:381
#41 0x55794d61 in _start ()

It seems something internal to Qt6Multimedia or PyQt, I wonder if one of
those packages don't need to be recompiled after some ABI change. But it
could be something else, I'm no expert in Qt.

Regards,



--
Moritz Schlarb
Unix und Cloud
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz

OpenPGP-Fingerprint: DF01 2247 BFC6
 5501 AFF2 8445 0C24 B841 C7DD BAAF


OpenPGP_signature
Description: OpenPGP digital signature

Bug#905136: RFP: libnginx-mod-security -- Nginx ModSecurity

[Moritz Schlarb]

Control: noowner -1
Control: retitle 905136 'RFP: libnginx-mod-security -- Nginx ModSecurity'

Since the Nginx maintainers explicitly do not want to support external modules
and also not add new modules to their bundle packages, I don't see how this can
go futher right now.

Cheers,
Moritz


signature.asc
Description: This is a digitally signed message part

Bug#1026799: buster-pu: package libapache2-mod-auth-openidc/2.3.10.2-1+deb10u2

[Moritz Schlarb]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: libapache2-mod-auth-open...@packages.debian.org, Debian Security 
Team 
Control: affects -1 + src:libapache2-mod-auth-openidc

[ Reason ]
Backported redirect url validations from upstream version 2.4.12.2
which include a fix for CVE-2022-23527[1]:
> Versions prior to 2.4.12.2 are vulnerable to Open Redirect.
> When providing a logout parameter to the redirect URI, the
> existing code in oidc_validate_redirect_url() does not properly
> check for URLs that start with /\t, leading to an open redirect.

[ Impact ]
> Users unable to upgrade can mitigate the issue by configuring
> mod_auth_openidc to only allow redirection when the destination
> matches a given regular expression with OIDCRedirectURLsAllowed.

[ Tests ]
Manually tested the package with the fix on our infrastructure, no problems
found.

[ Risks ]
Since I backported the whole check block, that includes more checks
than just for the tab character, the change in this p-u is not quite
minimal, but all the other checks do have a purpose of security
enhancement, so I think it's worth to have them. And the whole block
of code is already checked by more people.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
- Backported whole url check block in oidc_validate_redirect_url
  from the latest version 2.4.12.2 [2]
- Also backported new helper function oidc_util_strcasestr as a dependency

[ Other info ]
(Anything else the release team should know.)

[1]: https://security-tracker.debian.org/tracker/CVE-2022-23527
[2]:
https://github.com/zmartzone/mod_auth_openidc/commit/87119f44b9a88312dbc1f752d720bcd2371b94a8
diff -Nru libapache2-mod-auth-openidc-2.3.10.2/debian/changelog 
libapache2-mod-auth-openidc-2.3.10.2/debian/changelog
--- libapache2-mod-auth-openidc-2.3.10.2/debian/changelog   2019-11-27 
11:09:17.0 +0100
+++ libapache2-mod-auth-openidc-2.3.10.2/debian/changelog   2022-12-21 
11:40:16.0 +0100
@@ -1,3 +1,12 @@
+libapache2-mod-auth-openidc (2.3.10.2-1+deb10u2) buster; urgency=medium
+
+  * Backport fix for CVE-2022-23527: prevent open redirect in default setup
+when OIDCRedirectURLsAllowed is not configured
+see: 
https://github.com/zmartzone/mod_auth_openidc/security/advisories/GHSA-q6f2-285m-gr53
+(Closes: #1026444)
+
+ -- Moritz Schlarb   Wed, 21 Dec 2022 11:40:16 +0100
+
 libapache2-mod-auth-openidc (2.3.10.2-1+deb10u1) buster; urgency=medium
 
   * Add patch for CVE-2019-14857
diff -Nru 
libapache2-mod-auth-openidc-2.3.10.2/debian/patches/0003-Fix-CVE-2022-23527-prevent-open-redirect.patch
 
libapache2-mod-auth-openidc-2.3.10.2/debian/patches/0003-Fix-CVE-2022-23527-prevent-open-redirect.patch
--- 
libapache2-mod-auth-openidc-2.3.10.2/debian/patches/0003-Fix-CVE-2022-23527-prevent-open-redirect.patch
 1970-01-01 01:00:00.0 +0100
+++ 
libapache2-mod-auth-openidc-2.3.10.2/debian/patches/0003-Fix-CVE-2022-23527-prevent-open-redirect.patch
 2022-12-21 11:39:39.0 +0100
@@ -0,0 +1,79 @@
+From: Moritz Schlarb 
+Date: Tue, 20 Dec 2022 12:04:24 +0100
+Subject: Fix CVE-2022-23527: prevent open redirect
+
+- CVE-2022-23527: prevent open redirect in default setup when 
OIDCRedirectURLsAllowed is not configured
+  see: 
https://github.com/zmartzone/mod_auth_openidc/security/advisories/GHSA-q6f2-285m-gr53
+---
+ src/mod_auth_openidc.c | 14 ++
+ src/mod_auth_openidc.h |  1 +
+ src/util.c | 19 +++
+ 3 files changed, 34 insertions(+)
+
+diff --git a/src/mod_auth_openidc.c b/src/mod_auth_openidc.c
+index 916d60d..d1d8609 100644
+--- a/src/mod_auth_openidc.c
 b/src/mod_auth_openidc.c
+@@ -2989,6 +2989,20 @@ static apr_byte_t 
oidc_validate_post_logout_url(request_rec *r, const char *url,
+   oidc_error(r, "%s: %s", *err_str, *err_desc);
+   return FALSE;
+   }
++  if (   (strstr(url, "/%09") != NULL) || (oidc_util_strcasestr(url, 
"/%2f") != NULL)
++  || (strstr(url, "/\t") != NULL)
++  || (strstr(url, "/%68") != NULL) || 
(oidc_util_strcasestr(url, "/http:") != NULL)
++  || (oidc_util_strcasestr(url, "/https:") != NULL) || 
(oidc_util_strcasestr(url, "/javascript:") != NULL)
++  || (strstr(url, "/〱") != NULL) || (strstr(url, "/〵") != 
NULL)
++  || (strstr(url, "/ゝ") != NULL) || (strstr(url, "/ー") != 
NULL)
++  || (strstr(url, "/〱") != NULL) || (strstr(url, "/ｰ") != 
NULL)
++  || (strstr(url, "/<") != NULL) |

Bug#1026447: bullseye-pu: package libapache2-mod-auth-openidc/2.4.9.4-0+deb11u2

[Moritz Schlarb]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: libapache2-mod-auth-open...@packages.debian.org, Debian Security 
Team 
Control: affects -1 + src:libapache2-mod-auth-openidc

[ Reason ]
Backported redirect url validations from upstream version 2.4.12.2
which include a fix for CVE-2022-23527[1]:
> Versions prior to 2.4.12.2 are vulnerable to Open Redirect.
> When providing a logout parameter to the redirect URI, the
> existing code in oidc_validate_redirect_url() does not properly
> check for URLs that start with /\t, leading to an open redirect.

[ Impact ]
> Users unable to upgrade can mitigate the issue by configuring
> mod_auth_openidc to only allow redirection when the destination
> matches a given regular expression with OIDCRedirectURLsAllowed.

[ Tests ]
Manually tested the package with the fix on our infrastructure, no problems
found.

[ Risks ]
Since I backported the whole check block, that includes more checks
than just for the tab character, the change in this p-u is not quite
minimal, but all the other checks do have a purpose of security
enhancement, so I think it's worth to have them. And the whole block
of code is already checked by more people.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
- Backported whole url check block in oidc_validate_redirect_url
  from the latest version 2.4.12.2 [2]
- Also backported new helper function oidc_util_strcasestr as a dependency

[ Other info ]
(Anything else the release team should know.)

[1]: https://security-tracker.debian.org/tracker/CVE-2022-23527
[2]:
https://github.com/zmartzone/mod_auth_openidc/commit/87119f44b9a88312dbc1f752d720bcd2371b94a8
diff -Nru libapache2-mod-auth-openidc-2.4.9.4/debian/changelog 
libapache2-mod-auth-openidc-2.4.9.4/debian/changelog
--- libapache2-mod-auth-openidc-2.4.9.4/debian/changelog2022-02-23 
12:16:08.0 +0100
+++ libapache2-mod-auth-openidc-2.4.9.4/debian/changelog2022-12-20 
12:20:52.0 +0100
@@ -1,3 +1,12 @@
+libapache2-mod-auth-openidc (2.4.9.4-0+deb11u2) bullseye; urgency=medium
+
+  * Backport fix for CVE-2022-23527: prevent open redirect in default setup
+when OIDCRedirectURLsAllowed is not configured
+see: 
https://github.com/zmartzone/mod_auth_openidc/security/advisories/GHSA-q6f2-285m-gr53
+(Closes: #1026444)
+
+ -- Moritz Schlarb   Tue, 20 Dec 2022 12:20:52 +0100
+
 libapache2-mod-auth-openidc (2.4.9.4-0+deb11u1) bullseye; urgency=medium
 
   * New upstream version 2.4.9.4
diff -Nru 
libapache2-mod-auth-openidc-2.4.9.4/debian/patches/0002-Fix-CVE-2022-23527-prevent-open-redirect.patch
 
libapache2-mod-auth-openidc-2.4.9.4/debian/patches/0002-Fix-CVE-2022-23527-prevent-open-redirect.patch
--- 
libapache2-mod-auth-openidc-2.4.9.4/debian/patches/0002-Fix-CVE-2022-23527-prevent-open-redirect.patch
  1970-01-01 01:00:00.0 +0100
+++ 
libapache2-mod-auth-openidc-2.4.9.4/debian/patches/0002-Fix-CVE-2022-23527-prevent-open-redirect.patch
  2022-12-20 12:20:03.0 +0100
@@ -0,0 +1,82 @@
+From: Moritz Schlarb 
+Author: Hans Zandbelt 
+Date: Tue, 20 Dec 2022 12:04:24 +0100
+Subject: Fix CVE-2022-23527: prevent open redirect
+
+- CVE-2022-23527: prevent open redirect in default setup when 
OIDCRedirectURLsAllowed is not configured
+  see: 
https://github.com/zmartzone/mod_auth_openidc/security/advisories/GHSA-q6f2-285m-gr53
+
+Origin: backport, 
https://github.com/zmartzone/mod_auth_openidc/commit/87119f44b9a88312dbc1f752d720bcd2371b94a8
+Forwarded: not-needed
+---
+ src/mod_auth_openidc.c | 14 ++
+ src/mod_auth_openidc.h |  1 +
+ src/util.c | 18 ++
+ 3 files changed, 33 insertions(+)
+
+diff --git a/src/mod_auth_openidc.c b/src/mod_auth_openidc.c
+index b36f6c1..099c716 100644
+--- a/src/mod_auth_openidc.c
 b/src/mod_auth_openidc.c
+@@ -2543,6 +2543,20 @@ static apr_byte_t 
oidc_validate_redirect_url(request_rec *r, oidc_cfg *c,
+   oidc_error(r, "%s: %s", *err_str, *err_desc);
+   return FALSE;
+   }
++  if (   (strstr(url, "/%09") != NULL) || (oidc_util_strcasestr(url, 
"/%2f") != NULL)
++  || (strstr(url, "/\t") != NULL)
++  || (strstr(url, "/%68") != NULL) || 
(oidc_util_strcasestr(url, "/http:") != NULL)
++  || (oidc_util_strcasestr(url, "/https:") != NULL) || 
(oidc_util_strcasestr(url, "/javascript:") != NULL)
++  || (strstr(url, "/〱") != NULL) || (strstr(url, "/〵") != 
NULL)
++  || (strstr(url, "/ゝ") != NULL) || (strstr(url, "/ー") != 
NULL)

Bug#1026444: libapache2-mod-auth-openidc: CVE-2022-23527

[Moritz Schlarb]

Source: libapache2-mod-auth-openidc
Severity: important
Tags: patch upstream security
X-Debbugs-Cc: Debian Security Team 

Versions prior to 2.4.12.2 are vulnerable to Open Redirect. When providing a
logout parameter to the redirect URI, the existing code in
oidc_validate_redirect_url() does not properly check for URLs that start with
/\t, leading to an open redirect. This issue has been patched in version
2.4.12.2. Users unable to upgrade can mitigate the issue by configuring
mod_auth_openidc to only allow redirection when the destination matches a given
regular expression with OIDCRedirectURLsAllowed.

https://security-tracker.debian.org/tracker/CVE-2022-23527

https://github.com/zmartzone/mod_auth_openidc/security/advisories/GHSA-q6f2-285m-gr53

https://github.com/zmartzone/mod_auth_openidc/commit/87119f44b9a88312dbc1f752d720bcd2371b94a8


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-5-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1021392: dput: Ambiguity when dput thinks package is already uploaded

[Moritz Schlarb]

Package: dput
Version: 1.1.2
Severity: normal
Tags: patch

This bit me recently, because I uploaded a package, which got rejected because
my uid wasnt in dm acl for the package and after that was fixed, I tried
uploading again and the current wording led me to believe that there is
something on the ftp-master side that needs to be resolved - but of course,
that wasn't the case ;-)

I've proposed adding a line about the logfile here:
https://salsa.debian.org/debian/dput/-/merge_requests/9

But maybe it would be even wiser to just advertise using the -f option in this
case?

Regards,
Moritz


-- Package-specific info:

-- /etc/dput.cf --
# Example dput.cf that defines the host that can be used
# with dput for uploading.

[DEFAULT]
login   = *
method  = ftp
hash= md5
allow_unsigned_uploads  = 0
allow_dcut  = 0
run_lintian = 0
run_dinstall= 0
check_version   = 0
scp_compress= 0
post_upload_command =
pre_upload_command  =
passive_ftp = 1
default_host_main   =
allowed_distributions   = (?!UNRELEASED)

[ftp-master]
fqdn= ftp.upload.debian.org
incoming= /pub/UploadQueue/
login   = anonymous
allow_dcut  = 1
method  = ftp
# Please, upload your package to the proper archive
# 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions   = (?!UNRELEASED|.*-security)

# https://lists.debian.org/debian-project/2009/05/msg00036.html
[ftp-eu]
fqdn= ftp.eu.upload.debian.org
method  = ftp
incoming= /pub/UploadQueue/
login   = anonymous
allow_dcut  = 1
# Please, upload your package to the proper archive
# 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions   = (?!UNRELEASED|.*-security)

# https://lists.debian.org/debian-devel-announce/2008/09/msg7.html
[ssh-upload]
login   = *
# login = another_username
fqdn= ssh.upload.debian.org
method  = scp
incoming= /srv/upload.debian.org/UploadQueue/
allow_dcut  = 1
# Please, upload your package to the proper archive
# 
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#bug-security-upload
allowed_distributions   = (?!UNRELEASED|.*-security)

# And if you want to override one of the defaults, add it here.
# For example, comment out the next line
# post_upload_command   = /path/to/some/script
# pre_upload_command= /path/to/some/script

[security-master]
fqdn= ftp.security.upload.debian.org
method  = ftp
incoming= /pub/SecurityUploadQueue
login   = anonymous
allow_dcut  = 1
# This has been added at the request of the security team.
# Please be sure to know what you are doing before taking it out.
pre_upload_command  = /usr/share/dput/helper/security-warning

[security-master-unembargoed]
fqdn= ftp.security.upload.debian.org
method  = ftp
incoming= /pub/OpenSecurityUploadQueue
login   = anonymous
allow_dcut  = 1
# This has been added at the request of the security team.
# Please be sure to know what you are doing before taking it out.
pre_upload_command  = /usr/share/dput/helper/security-warning

[ubuntu]
fqdn= upload.ubuntu.com
method  = ftp
incoming= /
login   = anonymous

[ppa]
fqdn= ppa.launchpad.net
method  = ftp
# replace  with your Launchpad ID
incoming= ~/ubuntu
login   = anonymous

[mentors]
method  = ftp
fqdn= mentors.debian.net
incoming= /pub/UploadQueue
login   = anonymous

[local]
method  = local
incoming= ~/public_html/debian/mini-dinstall/incoming
run_dinstall= 0
post_upload_command = /usr/bin/mini-dinstall --batch


# Local variables:
# coding: utf-8
# mode: conf
# End:
# vim: fileencoding=utf-8 filetype=config :

-- /home/moschlar/.config/dput/dput.cf --

-- /home/moschlar/.dput.cf --
No package or host has been provided, see dput -h

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dput depends on:
ii  python33.10.6-1
ii  python3-debian 0.1.48

Bug#976308: ITA: cfengine3 -- tool for configuring and maintaining network machines

[Moritz Schlarb]

Hi everyone,

I'd be happy to help with this package, too.
Please also add me to the Salsa group when possible.

Regards,
Moritz


OpenPGP_signature
Description: OpenPGP digital signature

Bug#945578: buster-pu: package libapache2-mod-auth-openidc/2.3.10.2-1

[Moritz Schlarb]

Dear Adam,

On 05.08.22 21:33, Adam D. Barratt wrote:


Ping? We're in the process of organising the final point release for
buster, as support for it transitions over to the LTS team, so if you
would still like to fix it via pu then the upload needs to happen soon.


Thanks for the additional reminder and I am so so sorry for simply 
forgetting about this until now...
Especially given that everything had been ready since I opened this 
buster-pu bug...


I have just now uploaded the package for the buster distribution.

Best wishes,
--
Moritz Schlarb
Unix und Cloud
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz

OpenPGP-Fingerprint: DF01 2247 BFC6
 5501 AFF2 8445 0C24 B841 C7DD BAAF


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016477: seafile-gui: Can't perform SSO Login: ERR_CERT_AUTHORITY_INVALID

[Moritz Schlarb]

Package: seafile-gui
Version: 8.0.7+ds1-1
Severity: important

Trying to use the Login with SSO function just leads to:

This site can’t be reached

The webpage at https://seafile.rlp.net/shib-
login?shib_client_version=8.0.7_platform=linux_device_name=blurb_platform_version=_device_id=blurb
might be temporarily down or it may have moved permanently to a new web
address.
ERR_CERT_AUTHORITY_INVALID

...


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages seafile-gui depends on:
ii  libc62.33-8
ii  libgcc-s112.1.0-7
ii  libglib2.0-0 2.72.3-1
ii  libjansson4  2.14-2
ii  libqt5core5a 5.15.4+dfsg-4
ii  libqt5dbus5  5.15.4+dfsg-4
ii  libqt5gui5   5.15.4+dfsg-4
ii  libqt5network5   5.15.4+dfsg-4
ii  libqt5webenginewidgets5  5.15.10+dfsg-4
ii  libqt5widgets5   5.15.4+dfsg-4
ii  libquazip5-1 0.9.1-2
ii  libseafile0  8.0.7-1
ii  libsearpc1   3.2.0-8+really3.2+git20220425.54145b0-1
ii  libsqlite3-0 3.39.2-1
ii  libstdc++6   12.1.0-7
ii  seafile-daemon   8.0.7-1

seafile-gui recommends no packages.

Versions of packages seafile-gui suggests:
ii  seafile-cli  8.0.7-1

-- no debconf information

Bug#1006993: meld: Unable to compare remote folders (from FUSE mountpoints, e.g. GVFS)

[Moritz Schlarb]

Package: meld
Version: 3.20.4-2
Severity: normal
Tags: upstream, patch
Forwarded: https://gitlab.gnome.org/GNOME/meld/-/issues/497

Dear Maintainers,

I want to point you to upstream bug #497
(https://gitlab.gnome.org/GNOME/meld/-/issues/497) which includes more details
on the problem including responses from an upstream developer referencing a
specific commit which fixes this issue and noting that is has been fixed in the
released version 3.21.1
Maybe you can just bump the whole package to that version?

Best regards,
Moritz


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.16.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages meld depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  gir1.2-gtksource-3.0 3.24.11-2+b1
ii  libgtk-3-0   3.24.31-1
ii  libgtksourceview-3.0-1   3.24.11-2+b1
ii  patch2.7.6-7
ii  python3  3.9.8-1
ii  python3-cairo1.20.1-3
ii  python3-gi   3.42.0-3
ii  python3-gi-cairo 3.42.0-3

Versions of packages meld recommends:
ii  yelp  42~beta-2

meld suggests no packages.

-- no debconf information

Bug#1006316: bullseye-pu: package libapache2-mod-auth-openidc/2.4.9-1

[Moritz Schlarb]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: t...@security.debian.org

Dear stable release managers and security team,

I kindly ask you to allow version 2.4.9.4 of the aforementioned
 package to be included in proposed-updates to fix CVE-2021-39191
 and the regression mentioned in #891224#49ff.

I would prefer to just be able to introduce this plainly as the
(smaller-than-patch) upstream release for simplicity.

[ Reason ]

To quote the corresponding changelog entry:

libapache2-mod-auth-openidc (2.4.9.4-1) unstable; urgency=medium

  * New upstream version 2.4.9.4
  * Fix "CVE-2021-39191" (Closes: #993648)
  * 2.4.9.2 fixed a regression regarding segfault at reload/restart
(Closes: #883616, #891224, #868949)

 -- Moritz Schlarb   Tue, 07 Sep 2021 09:37:15 +0200

[ Impact ]

Apache2 continues to segfault when graceful reloading.
CVE-2021-39191 continues to be exploitable
("There are no known workarounds aside from upgrading to a patched version.")

[ Tests ]

We've used that version on some of our internal testing servers
for the two months it was current without any further issues.

[ Risks ]

The total change in actual source code is not that big and most of it
actually comes from the fix for CVE-2021-39191.
https://github.com/zmartzone/mod_auth_openidc/compare/v2.4.9...v2.4.9.4

[ Checklist ]

  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

Thanks,
Moritz
diff -Nru libapache2-mod-auth-openidc-2.4.9/auth_openidc.conf 
libapache2-mod-auth-openidc-2.4.9.4/auth_openidc.conf
--- libapache2-mod-auth-openidc-2.4.9/auth_openidc.conf 2021-07-22 
18:31:06.0 +0200
+++ libapache2-mod-auth-openidc-2.4.9.4/auth_openidc.conf   2021-09-03 
10:41:21.0 +0200
@@ -744,6 +744,8 @@
 # "claims" : the claims in the id_token are passed in individual 
headers/environment variables
 # "payload" :the payload of the id_token is passed as a JSON object in the 
"OIDC_id_token_payload" header/environment variable
 # "serialized" : the complete id_token is passed in compact serialized format 
in the "OIDC_id_token" header/environment variable
+# Note that when OIDCSessionType client-cookie is set, the id_token itself is 
not stored in the session/cookie and as such
+# the headers for the "payload" and "serialized" option will not be created.
 # When not defined the default "claims" is used.
 #OIDCPassIDTokenAs [claims|payload|serialized]+
 
@@ -886,6 +888,8 @@
 #   timeout (int)  : the session inactivity timeout (Unix 
timestamp in seconds)
 #   remote_user (string)   : the remote user name
 #   session (object)   : (for debugging) mod_auth_openidc specific 
session data such as "remote user", "session expiry", "session id" and a 
"state" object
+# Note that when using ProxyPass / you may have to add a proxy exception for 
the Redirect URI 
+# for this to work, e.g. ProxyPass /redirect_uri !
 # When not defined the session hook will not return any data but a HTTP 404
 #OIDCInfoHook 
[iat|access_token|access_token_expires|id_token|userinfo|refresh_token|exp|timeout|remote_user|session]+
 
@@ -914,8 +918,9 @@
 #OIDCStateInputHeaders [none|user-agent|x-forwarded-for|both]
 
 # Define one or more regular expressions that specify URLs (or domains) 
allowed for post logout and
-# other redirects such as the "return_to" value on refresh token requests, and 
the "login_uri" value
-# on session management based logins through the OP iframe, e.g.:
+# other redirects such as the "return_to" value on refresh token requests, the 
"login_uri" value
+# on session management based logins through the OP iframe, and the 
"target_link_uri" parameter in
+# 3rd-party initiated logins, e.g.:
 #   OIDCRedirectURLsAllowed ^https://www.example.com 
^https://(\w+).example.org ^https://example.net/app
 # or:
 #   OIDCRedirectURLsAllowed ^https://www.example.com/logout$ 
^https://www.example.com/app/return_to$ 
diff -Nru libapache2-mod-auth-openidc-2.4.9/AUTHORS 
libapache2-mod-auth-openidc-2.4.9.4/AUTHORS
--- libapache2-mod-auth-openidc-2.4.9/AUTHORS   2021-07-22 18:31:06.0 
+0200
+++ libapache2-mod-auth-openidc-2.4.9.4/AUTHORS 2021-09-03 10:41:21.0 
+0200
@@ -72,5 +72,8 @@
Adam Stadler <https://github.com/tzfx>
Steffen Greber <https://github.com/codemaker219>
Iain Heggie <https://github.com/iainh>
+   Dirk Kok <https://github.com/Foxite>
+   Meheni https://github.com/Meheni
+
 
 
diff -Nru libapache2-mod-auth-openidc-2.4.9/ChangeLog 
libapache2-mod-auth-openidc-2.4.9.4/ChangeLog
--- libapache2-mod-auth-op

Bug#891224: occurs in bullseye release

[Moritz Schlarb]

Oh wow, okay, yes...
Sorry. I'm probably just to tired for anything...

That issue looks familiar and in my Git Repo for 
libapache2-mod-auth-openidc I even have a tag called debian/2.4.9.4-1, 
so I probably already nearly solved this but apparently did not release...


Sorry about that!
I'll submit this to proposed-updates.

Thanks for you patience,
Moritz

On 23.02.22 11:11, Hamish Moffatt wrote:


It's listed as fixed in the upstream release notes for 2.4.9.2: 
https://github.com/zmartzone/mod_auth_openidc/releases/tag/v2.4.9.2



Regards
Hamish

On 23/2/22 20:57, Hamish Moffatt wrote:

Hi Moritz,

Even after a full restart (systemctl restart apache2), it still causes 
a segfault on every "apache2ctl graceful".


vagrant up (debian/bullseye64)
sudo -i
apt update
apt install apache2; apt install libapache2-mod-auth-openidc
systemctl restart apache2
apache2ctl graceful


/var/log/apache2/error says:

[Wed Feb 23 09:54:04.187005 2022] [core:notice] [pid 2554:tid 
140034803486016] AH00052: child pid 2678 exit signal Segmentation 
fault (11)


following every "apache2ctl graceful".



regards

Hamish



On 23/2/22 20:46, Moritz Schlarb wrote:

Dear Hamish,

sorry, I didn't think all the way through what you were writing.

Actually, enabling (and probably disabling) modules in Apache2 always 
requires a restart of the main daemon process - so performing a 
graceful restart/reload is simply not supported here (you are 
experiencing the actual reason for that).


That's also why I wasn't able to reproduce in the first place - 
because I restarted Apache after installing the Module out of muscle 
memory. ;-)


Hope that helps,
Moritz

On 17.01.22 00:55, Hamish Moffatt wrote:
I'm seeing this in bullseye with a brand new apache install. Every 
graceful restart (apache2ctl graceful) causes a segfault.


I don't have PHP or any other non-fault modules installed.

To reproduce: Set up fresh VM; apt install apache2; apt install 
libapache2-mod-auth-openidc; apache2ctl graceful



[Sun Jan 16 23:55:27.742953 2022] [mpm_event:notice] [pid 2412:tid 
140640895987008] AH00493: SIGUSR1 received.  Doing graceful restart
AH00558: apache2: Could not reliably determine the server's fully 
qualified domain name, using 127.0.0.2. Set the 'ServerName' 
directive globally to suppress this message
[Sun Jan 16 23:55:27.759267 2022] [mpm_event:notice] [pid 2412:tid 
140640895987008] AH00489: Apache/2.4.52 (Debian) configured -- 
resuming normal operations
[Sun Jan 16 23:55:27.759284 2022] [core:notice] [pid 2412:tid 
140640895987008] AH00094: Command line: '/usr/sbin/apache2'
[Sun Jan 16 23:55:27.759752 2022] [core:notice] [pid 2412:tid 
140640895987008] AH00052: child pid 2480 exit signal Segmentation 
fault (11)



This did not occur in buster.


Hamish








--
Moritz Schlarb
Unix und Cloud
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz

OpenPGP-Fingerprint: DF01 2247 BFC6
 5501 AFF2 8445 0C24 B841 C7DD BAAF

Bug#891224: occurs in bullseye release

[Moritz Schlarb]

Dear Hamish,

sorry, I didn't think all the way through what you were writing.

Actually, enabling (and probably disabling) modules in Apache2 always 
requires a restart of the main daemon process - so performing a graceful 
restart/reload is simply not supported here (you are experiencing the 
actual reason for that).


That's also why I wasn't able to reproduce in the first place - because 
I restarted Apache after installing the Module out of muscle memory. ;-)


Hope that helps,
Moritz

On 17.01.22 00:55, Hamish Moffatt wrote:
I'm seeing this in bullseye with a brand new apache install. Every 
graceful restart (apache2ctl graceful) causes a segfault.


I don't have PHP or any other non-fault modules installed.

To reproduce: Set up fresh VM; apt install apache2; apt install 
libapache2-mod-auth-openidc; apache2ctl graceful



[Sun Jan 16 23:55:27.742953 2022] [mpm_event:notice] [pid 2412:tid 
140640895987008] AH00493: SIGUSR1 received.  Doing graceful restart
AH00558: apache2: Could not reliably determine the server's fully 
qualified domain name, using 127.0.0.2. Set the 'ServerName' directive 
globally to suppress this message
[Sun Jan 16 23:55:27.759267 2022] [mpm_event:notice] [pid 2412:tid 
140640895987008] AH00489: Apache/2.4.52 (Debian) configured -- resuming 
normal operations
[Sun Jan 16 23:55:27.759284 2022] [core:notice] [pid 2412:tid 
140640895987008] AH00094: Command line: '/usr/sbin/apache2'
[Sun Jan 16 23:55:27.759752 2022] [core:notice] [pid 2412:tid 
140640895987008] AH00052: child pid 2480 exit signal Segmentation fault 
(11)



This did not occur in buster.


Hamish


--
Moritz Schlarb
Unix und Cloud
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz

OpenPGP-Fingerprint: DF01 2247 BFC6
 5501 AFF2 8445 0C24 B841 C7DD BAAF

Bug#891224: occurs in bullseye release

[Moritz Schlarb]

Dear Hamish,

can you please send us more information on your setup?

E.g. the output of:
apache2ctl -M
and
dpkg -l *apache*

Thanks,
Moritz

On 17.01.22 00:55, Hamish Moffatt wrote:
I'm seeing this in bullseye with a brand new apache install. Every 
graceful restart (apache2ctl graceful) causes a segfault.


I don't have PHP or any other non-fault modules installed.

To reproduce: Set up fresh VM; apt install apache2; apt install 
libapache2-mod-auth-openidc; apache2ctl graceful



[Sun Jan 16 23:55:27.742953 2022] [mpm_event:notice] [pid 2412:tid 
140640895987008] AH00493: SIGUSR1 received.  Doing graceful restart
AH00558: apache2: Could not reliably determine the server's fully 
qualified domain name, using 127.0.0.2. Set the 'ServerName' directive 
globally to suppress this message
[Sun Jan 16 23:55:27.759267 2022] [mpm_event:notice] [pid 2412:tid 
140640895987008] AH00489: Apache/2.4.52 (Debian) configured -- resuming 
normal operations
[Sun Jan 16 23:55:27.759284 2022] [core:notice] [pid 2412:tid 
140640895987008] AH00094: Command line: '/usr/sbin/apache2'
[Sun Jan 16 23:55:27.759752 2022] [core:notice] [pid 2412:tid 
140640895987008] AH00052: child pid 2480 exit signal Segmentation fault 
(11)



This did not occur in buster.


Hamish


--
Moritz Schlarb
Unix und Cloud
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz

OpenPGP-Fingerprint: DF01 2247 BFC6
 5501 AFF2 8445 0C24 B841 C7DD BAAF


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1005938: ITP: libapache2-mod-oauth2 -- OAuth 2.x Resource Server module for the Apache HTTPd web server

[Moritz Schlarb]

Package: wnpp
Severity: wishlist
Owner: Moritz Schlarb 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: libapache2-mod-oauth2
  Version : 3.2.2
  Upstream Author : Hans Zandbelt 
* URL : https://github.com/zmartzone/mod_oauth2
* License : AGPL-3
  Programming Lang: C
  Description : OAuth 2.x Resource Server module for the Apache HTTPd web
server

A module for Apache HTTP Server 2.x that makes the Apache web server operate as
a OAuth 2.0 Resource Server, validating OAuth 2.0 bearer access tokens and
setting headers/environment variables based on the validation results.

Support for using Apache HTTPd as an OAuth 2.0 Resource Server has previously
also been provided by libapache2-mod-auth-openidc, but that functionality there
is deprecated and users are encouraged to move to this project instead (cf.
https://github.com/zmartzone/mod_auth_openidc/blob/master/src/config.c#L2380).

It's primary dependency (apart from Apache itself) liboauth2 (incidentally by
the same upstream author) is already packaged in Debian.

Bug#970863: nagstamon: Correct GPL-2 in copyright to GPL-2+

[Moritz Schlarb]

Hi Bastian,

On 24.09.20 16:34, Bastian Germann wrote:

On Thu, 24 Sep 2020 15:33:08 +0200 Bastian Germann
 wrote:

Source: nagstamon
Severity: normal

Please correct the copyright file to say GPL-2+ (which is the package's
license) instead of GPL-2 (only). This has an impact on the package
because it is a derivative work of pyqt5, which is GPL-3 licensed and
thus incompatible with GPL-2 only.


I see that debian/* are amongst the GPL-2 only licensed files.
Carl and Moritz, would you please consider relicensing to GPL-2+? That
will be necessary at least for the patches.


I do not object.
Carl, what about you?

Regards,

--
Moritz Schlarb
Unix und Cloud
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz

OpenPGP-Fingerprint: DF01 2247 BFC6
 5501 AFF2 8445 0C24 B841 C7DD BAAF

Bug#979571: seafile-gui: Single-Sign-On functionality is missing

[Moritz Schlarb]

Package: seafile-gui
Version: 7.0.10-2
Severity: important

For some reason, the Single-Sign-On functionality for login is not enabled
anymore (although it should be, according to d/rules...)



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-5-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages seafile-gui depends on:
ii  libc6   2.31-6
ii  libgcc-s1   10.2.1-3
ii  libglib2.0-02.66.4-1
ii  libjansson4 2.13.1-1
ii  libqt5core5a5.15.2+dfsg-2
ii  libqt5dbus5 5.15.2+dfsg-2
ii  libqt5gui5  5.15.2+dfsg-2
ii  libqt5network5  5.15.2+dfsg-2
ii  libqt5widgets5  5.15.2+dfsg-2
ii  libquazip5-10.9.1-1
ii  libseafile0 7.0.10-1
ii  libsearpc1  3.2.0-7-g50ff08b-1
ii  libsqlite3-03.34.0-1
ii  libstdc++6  10.2.1-3
ii  seafile-daemon  7.0.10-1

seafile-gui recommends no packages.

Versions of packages seafile-gui suggests:
ii  seafile-cli  7.0.10-1

-- no debconf information

Bug#974213: ITP: seadrive-fuse -- Seafile drive client FUSE daemon

[Moritz Schlarb]

Dear Henry,

I'm sorry for the slow progress on this issue - but I'm not really super 
confident that we get this done in time before the freeze.


The biggest issue I discovered is that the seadrive code is not yet made 
compatible with GnuTLS - it only support OpenSSL.
But because of the license incompability betwen OpenSSL and GPL-3, 
Debian can not ship it like this.


For the classical Seafile client, this has been added after some back 
and forth and I think it would be possible to just look at the relevant 
patches there and try to add the required changes here, too.


Regards,
Moritz

On 27.12.20 11:01, Henry-Nicolas Tourneur wrote:

Hello Moritz,

Thanks for this ITP :-)

Would you use some help to get it packaged?
I noticed you are already involved with the other seafile software components in
Debian.

It would be really great to have seadrive pieces in time for the freeze of
bullseye.

Best regards,



--
Moritz Schlarb
Unix und Cloud
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz

OpenPGP-Fingerprint: DF01 2247 BFC6
 5501 AFF2 8445 0C24 B841 C7DD BAAF

Bug#976894: telegram-desktop: Telegram crashes because X11 connection broke

[Moritz Schlarb]

forwarded 976894 https://github.com/telegramdesktop/tdesktop/issues/8506
thanks

See also https://gitlab.freedesktop.org/xorg/xserver/-/issues/1072

--
Moritz Schlarb
Unix und Cloud
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz

OpenPGP-Fingerprint: DF01 2247 BFC6
 5501 AFF2 8445 0C24 B841 C7DD BAAF

Bug#976894: telegram-desktop: Telegram crashes because X11 connection broke

[Moritz Schlarb]

Sorry, missed to add the following:

Manually installing qtwayland5 and then running with
QT_QPA_PLATFORM=wayland telegram-desktop
makes it run again.

On 09.12.20 09:47, Moritz Schlarb wrote:

forwarded 976894 https://github.com/telegramdesktop/tdesktop/issues/8506
thanks

See also https://gitlab.freedesktop.org/xorg/xserver/-/issues/1072



--
Moritz Schlarb
Unix und Cloud
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz

OpenPGP-Fingerprint: DF01 2247 BFC6
 5501 AFF2 8445 0C24 B841 C7DD BAAF

Bug#975048: apache2-bin: AuthLDAPBindPassword exec: directive creates zombie processes

[Moritz Schlarb]

Package: apache2-bin
Version: 2.4.46-1~bpo10
Severity: important
Tags: patch upstream
Forwarded: https://bz.apache.org/bugzilla/show_bug.cgi?id=61817
X-Debbugs-Cc: mar...@uni-mainz.de

We are experiencing the following bug that has previously been reported to
upstream:
Bug 61817 - AuthLDAPBindPassword exec: directive (ap_get_exec_line()) creates
defunct/zombie
https://bz.apache.org/bugzilla/show_bug.cgi?id=61817

This is what ps looks like after 6 hours:
ps auxfw | grep -C3 apache
USERPID %CPU %MEMVSZ   RSS TTY  STAT START   TIME COMMAND
root   7239  0.0  0.0   9780  4944 ?Rs   12:11   0:00 ps auxfw
root  1  0.0  6.5 1861092 534936 ?  Ss   05:31   0:03
/usr/sbin/apache2 -DFOREGROUND -k start
infosys 440  1.6  0.9 4446004 76156 ?   Sl   05:31   6:44
/usr/sbin/apache2 -DFOREGROUND -k start
infosys 574  0.0  0.0  0 0 ?Z05:31   0:00  \_ [cat]

infosys 575  0.0  0.0  0 0 ?Z05:31   0:00  \_ [cat]

infosys 642  0.0  0.0  0 0 ?Z05:32   0:00  \_ [cat]

--
infosys7147  0.0  0.0  0 0 ?Z12:06   0:00  \_ [cat]

infosys7157  0.0  0.0  0 0 ?Z12:08   0:00  \_ [cat]

infosys7158  0.0  0.0  0 0 ?Z12:08   0:00  \_ [cat]

infosys 442  1.2  0.8 4437720 71588 ?   Sl   05:31   4:51
/usr/sbin/apache2 -DFOREGROUND -k start
infosys 572  0.0  0.0  0 0 ?Z05:31   0:00  \_ [cat]

infosys 573  0.0  0.0  0 0 ?Z05:31   0:00  \_ [cat]

infosys 640  0.0  0.0  0 0 ?Z05:32   0:00  \_ [cat]


And we are indeed using the
AuthLDAPBindPassword "exec:/bin/cat <...>"
directive in our Apache configuration.

Please consider including a/the patch in the current stable and the buster-
backports version of the package.



-- Package-specific info:

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apache2-bin is related to:
pn  apache2  
ii  apache2-bin  2.4.46-1

Bug#974214: ITP: seadrive-gui -- Seafile drive client GUI part

[Moritz Schlarb]

Package: wnpp
Severity: wishlist
Owner: Moritz Schlarb 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: seadrive-gui
  Version : 2.0.7
  Upstream Author : Seafile Ltd. 
* URL : https://github.com/haiwen/seadrive-gui
* License : Apache-2.0
  Programming Lang: C++
  Description : Seafile drive client GUI part

Seafile is a file syncing and sharing software with file encryption
and group sharing, emphasis on reliability and high performance.

Seafile is an open source cloud storage system with privacy protection
and teamwork features. Collections of files are called libraries. Each
library can be synced separately. A library can also be encrypted with
a user chosen password. Seafile also allows users to create groups and
easily sharing files into groups.

The Seafile drive (or SeaDrive) client is a caching, on demand downloading
client implementation.

This is also the main difference to the classical seafile client (in the
"seafile" package), which syncs the whole content of Seafile libraries onto the
local filesystem allowing offline access, too.

This is the desktop integration which relies on seadrive-fuse for the actual
filesystem implementation.

Bug#974213: ITP: seadrive-fuse -- Seafile drive client FUSE daemon

[Moritz Schlarb]

Package: wnpp
Severity: wishlist
Owner: Moritz Schlarb 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: seadrive-fuse
  Version : 2.0.6
  Upstream Author : Seafile Ltd. 
* URL : https://github.com/haiwen/seadrive-fuse
* License : GPL-3.0
  Programming Lang: C
  Description : Seafile drive client FUSE daemon

Seafile is a file syncing and sharing software with file encryption
and group sharing, emphasis on reliability and high performance.

Seafile is an open source cloud storage system with privacy protection
and teamwork features. Collections of files are called libraries. Each
library can be synced separately. A library can also be encrypted with
a user chosen password. Seafile also allows users to create groups and
easily sharing files into groups.

The Seafile drive (or SeaDrive) client is a caching, on demand downloading
client implementation.

This is also the main difference to the classical seafile client (in the
"seafile" package), which syncs the whole content of Seafile libraries onto the
local filesystem allowing offline access, too.

This is the main dependency for the accompanying seadrive-gui package which
provides desktop integration.

Bug#973363: node-uid-number: package does not install get-uid-gid.js file from source

[Moritz Schlarb]

Package: node-uid-number
Version: 0.0.6-1
Severity: grave
Tags: patch
Justification: renders package unusable

The source for this package also includes a file named get-uid-gid.js which is
not installed with the package files.

This causes an unrelated npm/npx command to fail with:

18116 silly postinstall core-js@3.6.5
18117 info lifecycle core-js@3.6.5~postinstall: core-js@3.6.5
18118 verbose lifecycle core-js@3.6.5~postinstall: unsafe-perm in lifecycle
false
18119 verbose stack Error: Cannot find module './get-uid-gid.js'
18119 verbose stack at Function.Module._resolveFilename
(internal/modules/cjs/loader.js:636:15)
18119 verbose stack at Function.resolve
(internal/modules/cjs/helpers.js:33:19)
18119 verbose stack at uidNumber (/usr/lib/nodejs/uid-number/uid-
number.js:31:24)
18119 verbose stack at runCmd (/usr/share/npm/node_modules/npm-
lifecycle/index.js:267:5)
18119 verbose stack at runPackageLifecycle
(/usr/share/npm/node_modules/npm-lifecycle/index.js:228:3)
18119 verbose stack at Array. (/usr/lib/nodejs/slide/lib/bind-
actor.js:15:8)
18119 verbose stack at LOOP (/usr/lib/nodejs/slide/lib/chain.js:15:14)
18119 verbose stack at chain (/usr/lib/nodejs/slide/lib/chain.js:20:5)
18119 verbose stack at lifecycle_ (/usr/share/npm/node_modules/npm-
lifecycle/index.js:167:3)
18119 verbose stack at /usr/share/npm/node_modules/npm-
lifecycle/index.js:104:9
18119 verbose stack at /usr/share/npm/node_modules/npm-
lifecycle/index.js:218:12
18119 verbose stack at /usr/lib/nodejs/graceful-fs/polyfills.js:287:18
18119 verbose stack at FSReqWrap.oncomplete (fs.js:154:5)
18120 verbose cwd /tmp/bla
18121 verbose Linux 4.19.0-12-amd64
18122 verbose argv "/usr/bin/node" "/usr/share/npm/bin/npm-cli.js" "install"
"sb@latest" "--global" "--prefix" "/root/schlarbm/.npm/_npx/19136" "--loglevel"
"error" "--json"
18123 verbose node v10.21.0
18124 verbose npm  v6.14.8
18125 error code MODULE_NOT_FOUND
18126 error Cannot find module './get-uid-gid.js'
18127 verbose exit [ 1, true ]



-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (700, 'stable-updates'), (700, 'stable'), (60, 'testing'), (50, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-12-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages node-uid-number depends on:
ii  nodejs  10.21.0~dfsg-1~deb10u1

node-uid-number recommends no packages.

node-uid-number suggests no packages.

Bug#962693: mariadb-server-core-10.3: Recovery failure : loop of Read redo log up to LSN (MDEV-21826)

[Moritz Schlarb]

Package: mariadb-server-core-10.3
Version: 10.3.22-0+deb10u1
Severity: important
Tags: upstream
Forwarded: https://jira.mariadb.org/browse/MDEV-21826
Control: forwarded -1 https://jira.mariadb.org/browse/MDEV-21826

Dear Maintainers,

we are continuously plagued from upstream bug
[MDEV-21826](https://jira.mariadb.org/browse/MDEV-21826).

The workaround is to set `innodb_buffer_pool_instances=1`, but for
performance
reasons this is not so nice.

Would you mind releasing another stable update with just this patch
(https://github.com/MariaDB/server/commit/09e8707d90a8a73887fd4f22b64df43ff4669556.patch)
or the whole 10.3.23 version?

Best regards,
Moritz Schlarb
Unix und Cloud
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz

OpenPGP-Fingerprint: DF01 2247 BFC6
 5501 AFF2 8445 0C24 B841 C7DD BAAF



-- System Information:
Debian Release: 10.4
  APT prefers stable-updates
  APT policy: (700, 'stable-updates'), (700, 'stable'), (60, 'testing'),
(50, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mariadb-server-core-10.3 depends on:
ii  libaio1 0.3.112-3
ii  libc6   2.30-4
ii  libcrypt1   1:4.4.10-10
ii  libgnutls30 3.6.7-4+deb10u4
ii  liblz4-11.8.3-1
ii  libpcre32:8.39-12
ii  libsnappy1v51.1.7-1
ii  libstdc++6  10.1.0-3
ii  libsystemd0 241-7~deb10u4
ii  mariadb-common  1:10.3.22-0+deb10u1
ii  zlib1g  1:1.2.11.dfsg-1

mariadb-server-core-10.3 recommends no packages.

mariadb-server-core-10.3 suggests no packages.



signature.asc
Description: OpenPGP digital signature

Bug#944646: nagstamon: crash when acknowledging alert from an Icinga server

[Moritz Schlarb]

Control: forwarded -1 https://github.com/HenriWahl/Nagstamon/issues/612

Dear Jonathan,

On 13.11.19 11:06, Jonathan Wiltshire wrote:
> When acknowledging an alert from an Icinga2 server a traceback occurs
> submitting the form:
> 
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/Nagstamon/QUI/__init__.py", line 3967, 
> in acknowledge
> self.server.set_acknowledge(info_dict)
>   File "/usr/lib/python3/dist-packages/Nagstamon/Servers/Generic.py", line 
> 359, in set_acknowledge
> all_services)
>   File "/usr/lib/python3/dist-packages/Nagstamon/Servers/IcingaWeb2.py", line 
> 368, in _set_acknowledge
> CSRFToken = formtag.findNext('input', {'name':'CSRFToken'})['value']
> AttributeError: 'NoneType' object has no attribute 'findNext'
> Aborted
> 
> The icinga-web2 version used is 2.6.2.

I just uploaded the next released version of Nagstamon (3.4-1) - could
you please try it again with that version?

I couldn't reproduce it in that version with the Demo site at
https://icinga.com/demo/.

Regards,
-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF



signature.asc
Description: OpenPGP digital signature

Bug#945578: buster-pu: package libapache2-mod-auth-openidc/2.3.10.2-1

[Moritz Schlarb]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

Fixes CVE-2019-14857 (Open redirect in logout url when using URLs with
backslashes) by improving validation of the post-logout URL parameter
(backported from upstream, see https://salsa.debian.org/debian/libapache2-mod-
auth-openidc/commit/17e31b94a71ef02d1417bee6b0ef7b7379b40375)

-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (700, 'stable-updates'), (700, 'stable'), (60, 'testing'), (50,
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru libapache2-mod-auth-openidc-2.3.10.2/debian/changelog 
libapache2-mod-auth-openidc-2.3.10.2/debian/changelog
--- libapache2-mod-auth-openidc-2.3.10.2/debian/changelog   2019-01-29 
21:40:30.0 +0100
+++ libapache2-mod-auth-openidc-2.3.10.2/debian/changelog   2019-11-27 
11:09:17.0 +0100
@@ -1,3 +1,10 @@
+libapache2-mod-auth-openidc (2.3.10.2-1+deb10u1) buster; urgency=medium
+
+  * Add patch for CVE-2019-14857
+(Closes: #942165)
+
+ -- Moritz Schlarb   Wed, 27 Nov 2019 11:09:17 +0100
+
 libapache2-mod-auth-openidc (2.3.10.2-1) unstable; urgency=medium
 
   * New upstream version 2.3.10.2
diff -Nru libapache2-mod-auth-openidc-2.3.10.2/debian/gbp.conf 
libapache2-mod-auth-openidc-2.3.10.2/debian/gbp.conf
--- libapache2-mod-auth-openidc-2.3.10.2/debian/gbp.conf2019-01-29 
21:40:30.0 +0100
+++ libapache2-mod-auth-openidc-2.3.10.2/debian/gbp.conf2019-11-27 
11:08:14.0 +0100
@@ -1,2 +1,3 @@
 [DEFAULT]
 pristine-tar = True
+debian-branch = buster
diff -Nru 
libapache2-mod-auth-openidc-2.3.10.2/debian/patches/0002-improve-validation-of-the-post-logout-URL-parameter-.patch
 
libapache2-mod-auth-openidc-2.3.10.2/debian/patches/0002-improve-validation-of-the-post-logout-URL-parameter-.patch
--- 
libapache2-mod-auth-openidc-2.3.10.2/debian/patches/0002-improve-validation-of-the-post-logout-URL-parameter-.patch
 1970-01-01 01:00:00.0 +0100
+++ 
libapache2-mod-auth-openidc-2.3.10.2/debian/patches/0002-improve-validation-of-the-post-logout-URL-parameter-.patch
 2019-11-27 11:08:14.0 +0100
@@ -0,0 +1,137 @@
+From: Moritz Schlarb 
+Date: Wed, 16 Oct 2019 10:53:49 +0200
+Subject: improve validation of the post-logout URL parameter on logout
+
+From https://github.com/zmartzone/mod_auth_openidc/compare/5c15dfb~1...v2.4.0.3
+
+Fixes https://security-tracker.debian.org/tracker/CVE-2019-14857
+---
+ src/mod_auth_openidc.c | 101 ++---
+ 1 file changed, 63 insertions(+), 38 deletions(-)
+
+diff --git a/src/mod_auth_openidc.c b/src/mod_auth_openidc.c
+index 5b971d5..916d60d 100644
+--- a/src/mod_auth_openidc.c
 b/src/mod_auth_openidc.c
+@@ -2938,6 +2938,61 @@ out:
+   return rc;
+ }
+ 
++static apr_byte_t oidc_validate_post_logout_url(request_rec *r, const char 
*url,
++  char **err_str, char **err_desc) {
++  apr_uri_t uri;
++  const char *c_host = NULL;
++
++  if (apr_uri_parse(r->pool, url, ) != APR_SUCCESS) {
++  *err_str = apr_pstrdup(r->pool, "Malformed URL");
++  *err_desc = apr_psprintf(r->pool, "Logout URL malformed: %s", 
url);
++  oidc_error(r, "%s: %s", *err_str, *err_desc);
++  return FALSE;
++  }
++
++  c_host = oidc_get_current_url_host(r);
++  if ((uri.hostname != NULL)
++  && ((strstr(c_host, uri.hostname) == NULL)
++  || (strstr(uri.hostname, c_host) == 
NULL))) {
++  *err_str = apr_pstrdup(r->pool, "Invalid Request");
++  *err_desc =
++  apr_psprintf(r->pool,
++  "logout value \"%s\" does not 
match the hostname of the current request \"%s\"",
++  apr_uri_unparse(r->pool, , 
0), c_host);
++  oidc_error(r, "%s: %s", *err_str, *err_desc);
++  return FALSE;
++  } else if ((uri.hostname == NULL) && (strstr(url, "/") != url)) {
++  *err_str = apr_pstrdup(r->pool, "Malformed URL");
++  *err_desc =
++  apr_psprintf(r->pool,
++  "No hostname was parsed and it 
does not seem to be relative, i.e starting with '/': %s",
++  url);
++  oidc_error(r, "%s: %s", *err_str, *err_desc);
++  return FALSE;
++} else if ((uri.hostname == NULL) && (strstr(url, &

Bug#923009: fixed 923009 seafile/7.0.2-1

[Moritz Schlarb]

Hi Salvatore,

On 10.11.19 21:51, Salvatore Bonaccorso wrote:
> Hi Moritz,
> 
> Sorry for the late reply.

Same here ;)

> It depends, and there is not rule written in stone. In this case I was
> thinking of concluding to keep the issue open until at least upstream
> clarifies on
> https://github.com/haiwen/seafile/issues/350#issuecomment-548307815
> (respectively if there will be a step towards not only making version
> 3 the fefault but disalowing as well the older formats).
> 
> Do you disagree or agree on that?

Yes, we can of course keep it open at least until then, I will ask there
again.

>>> Were you able to reach out to MITRE (via the webform) to have the
>>> references and description updated?
>>
>> I filled it out (on 06.03.19 as CVE Request 652193 FWIW), but did never
>> receive a response and it doesn't look like any changes were made... :(
> 
> Can you reping the autoreply you got asking for a status update?

I did - still waiting.

Regards,
-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF



signature.asc
Description: OpenPGP digital signature

Bug#923009: fixed 923009 seafile/7.0.2-1

[Moritz Schlarb]

Hi Salvatore,

thanks for following up!

On 30.10.19 17:33, Salvatore Bonaccorso wrote:
> On Wed, Oct 30, 2019 at 11:27:34AM +0100, Moritz Schlarb wrote:
>> fixed 923009 seafile/7.0.2-1
> 
> I guess I have lost some context here. Can you clarify the following
> before I proceed to mark the fixed version for the CVE as well in the
> security-tracker?
> 
> The question is following: 923009, respective CVE-2013-7469 is
> associated with upstream issue
> https://github.com/haiwen/seafile/issues/350 . But there ws o closure
> of this issue. In the previous BTS message you mentioned that the CVE
> assignment was inaccurate, is the issue fixed with the new 0003 patch?

Now that I think harder about it, it is probably not totally fixed since
it is still possible to use libraries encrypted with the older
encryption format version ( < 3 ). The patch just makes the new
encryption version ( 3 ) work with GPL_CRYPTO. Since libraries are
created by the server side component (not yet/ever in Debian), the used
encryption version is not really configurable by the user here.

What would be your interpretation of the relevant Debian guidelines in
this case, where the foot-gun is still there, but at least the default
should be better now?

> Were you able to reach out to MITRE (via the webform) to have the
> references and description updated?

I filled it out (on 06.03.19 as CVE Request 652193 FWIW), but did never
receive a response and it doesn't look like any changes were made... :(

Regards,
-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF



signature.asc
Description: OpenPGP digital signature

Bug#942165: CVE-2019-14857

[Moritz Schlarb]

Same for stretch:
https://salsa.debian.org/debian/libapache2-mod-auth-openidc/commit/e0b3eac21212b12562721ab3c903c4f24eef9e8f

On 16.10.19 11:19, Moritz Schlarb wrote:
> Hi everyone,
> 
> I have prepared a backport of the patches for the version packaged in
> Buster:
> https://salsa.debian.org/debian/libapache2-mod-auth-openidc/commit/17e31b94a71ef02d1417bee6b0ef7b7379b40375
> 
> If you deem necessary and sufficient, please release as a security
> update or otherwise I'll try to get it in in proposed-updates.
> 
> Regards,
> Moritz (another one)
> 
> On 11.10.19 10:14, Moritz Muehlenhoff wrote:
>> Package: libapache2-mod-auth-openidc
>> Severity: grave
>> Tags: security
>>
>> Please see: 
>> https://groups.google.com/forum/#!topic/mod_auth_openidc/boy1Ba3Gdk4
>>
>> https://github.com/zmartzone/mod_auth_openidc/commit/5c15dfb08106c2451c2c44ce7ace6813c216ba75
>> https://github.com/zmartzone/mod_auth_openidc/commit/ce37080c6aea30aabae8b4a9b4eea7808445cc8e
>> https://github.com/zmartzone/mod_auth_openidc/pull/451
>>
>> Cheers,
>> Moritz
>> 
>>
> 

-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF



signature.asc
Description: OpenPGP digital signature

Bug#942165: CVE-2019-14857

[Moritz Schlarb]

Hi everyone,

I have prepared a backport of the patches for the version packaged in
Buster:
https://salsa.debian.org/debian/libapache2-mod-auth-openidc/commit/17e31b94a71ef02d1417bee6b0ef7b7379b40375

If you deem necessary and sufficient, please release as a security
update or otherwise I'll try to get it in in proposed-updates.

Regards,
Moritz (another one)

On 11.10.19 10:14, Moritz Muehlenhoff wrote:
> Package: libapache2-mod-auth-openidc
> Severity: grave
> Tags: security
> 
> Please see: 
> https://groups.google.com/forum/#!topic/mod_auth_openidc/boy1Ba3Gdk4
> 
> https://github.com/zmartzone/mod_auth_openidc/commit/5c15dfb08106c2451c2c44ce7ace6813c216ba75
> https://github.com/zmartzone/mod_auth_openidc/commit/ce37080c6aea30aabae8b4a9b4eea7808445cc8e
> https://github.com/zmartzone/mod_auth_openidc/pull/451
> 
> Cheers,
>     Moritz
> 
> 

-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF



signature.asc
Description: OpenPGP digital signature

Bug#939170: linux-image-5.2.0-2-amd64: does not suspend completely, locks up

[Moritz Schlarb]

Source: linux
Version: 5.2.9-2
Followup-For: Bug #939170

Hi everyone,

I'm seeing the same issue with linux-image-5.2.0-2-amd64=5.2.9-2 on Lenovo
Thinkpad X1 Carbon 4th Gen.

Best regards,
Moritz



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#790623: Upstream support for third party modules and out-of-tree building?

[Moritz Schlarb]

Dear Maintainers,

would you be so kind to make a statement on the current state of
upstream support for third party modules and out-of-tree building?

Regards,
-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF
<>

signature.asc
Description: OpenPGP digital signature

Bug#905136: RFP: libnginx-mod-security -- Nginx ModSecurity

[Moritz Schlarb]

Control: retitle -1 ITP: libnginx-mod-security -- Nginx ModSecurity

* Package name: libnginx-mod-security
  Version : 1.0.0
  Upstream Author : Felipe Zimmerle ,
Andrei Belov 
* URL : https://github.com/SpiderLabs/ModSecurity-nginx
* License : Apache-2.0
  Programming Lang: C
  Description : ModSecurity v3 Nginx Connector

On Tue, 31 Jul 2018 15:34:43 +0100 Sam Bull  wrote:
> Package: wnpp
> Severity: wishlist
> 
> * Package name: libnginx-mod-security
>   Version : 3.0.0
>   Upstream Author : Nginx 
> * URL : https://www.nginx.com/
> * License : BSD
>   Programming Lang: C
>   Description : Nginx ModSecurity
> 
> Some instructions on setting this up:
> https://www.nginx.com/blog/compiling-and-installing-modsecurity-for-open-source-nginx/
> 
> 
<>

signature.asc
Description: OpenPGP digital signature

Bug#928975: Copyright concerns regarding Seafile

[Moritz Schlarb]

Dear Michael,

On 15.05.19 17:12, Michael Lustfield wrote:
> When I first looked the source package, I only looked at d/copyright. Since I
> didn't see Files-Excluded, and the upstream tarball didn't include '+dfsg' in
> the name, I assumed the infringing files were not included.
> 
> Looking closer, I see that the files were actually removed, so this
> source/package doesn't actually constitute a copyright violation, although 
> this
> is still a problem in upstream.
>
> Moritz, would you be willing to include Files-Excluded: common/db-wrapper in
> d/copyright and add +dfsg to d/watch? It looks like you're currently removing
> the files manually and this method will help prevent future maintainers from
> accidentally including these files. This also allows you to use uscan to
> automatically remove the problematic files.

It's actually two separate upstream projects (seafile and
seafile-server, where the latter could be seen as an extended edition of
the first - yes, that means code duplication...). So the orig.tar.gz is
actually clean by default ;-)

Regards,
-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF
<>

signature.asc
Description: OpenPGP digital signature

Bug#865830: Copyright concerns regarding Seafile

[Moritz Schlarb]

Dear all,

as maintainer of the Seafile client packages (libsearpc, seafile and
seafile-client), I would like to thank Jan-Henrik for bringing this to
our attention.

There have already been such findings in the past, regarding some code
taken from git, and the discussion regarding libzdb in the past, as you
mentioned. I remember discussing the problems regarding linking to
OpenSSL, too.

However, all of the database related code is *only* contained in the
Seafile server implementation (https://github.com/haiwen/seafile-server,
RFP at #865830) and not in the Seafile client implementation
(https://github.com/haiwen/seafile) that I have packaged for Debian.

I disagree that this should serve as a reason for *not* including the
client packages in the next Debian release.

What do others think about that?

I will however forward these findings to the developers at Seafile Ltd
and ask them for a proper resolution.

Best regards,
-- 
Moritz Schlarb
<>

signature.asc
Description: OpenPGP digital signature

Bug#923009: seafile: CVE-2013-7469

[Moritz Schlarb]

Hi there,

we've been in touch with the upstream developers and I want to add the
following to the discussion:

After reading through the code thoroughly, I want to add the
clarification, that the summary of the CVE is not really correct:

Every encrypted library uses the same salt. (That will be fixed by
upstream).

For each encrypted library, PBKDF2 is used to generate the encryption
key and IV from the user-supplied password for that library (and the salt).

That concludes that two libraries only have the same IV, if users used
the same password for them.

I'll try to update the CVE description for more clarity and for an
update on the NVD classification.

Best regards,
-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF
<>

signature.asc
Description: OpenPGP digital signature

Bug#905014: I'm adopting dhcpy6d

[Moritz Schlarb]

Control: retitle -1 ITA: dhcpy6d -- MAC address aware DHCPv6 server
written in Python
Control: owner -1 !
Control: affects -1 = dhcpy6d

Hi everyone,

I'm willing to adopt dhcpy6d.

I will create a project in the Salsa PAPT namespace for it.
Someone needs to add me to the upload ACL though.

Regards,
Moritz

Bug#914606: apache2 setup-instance (apache-multi) logrotation (#914606)

[Moritz Schlarb]

Control: tags -1 + patch

Hi Horst,

I've prepared a patch for this issue:
https://salsa.debian.org/apache-team/apache2/merge_requests/7

Regards,
-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF
<>

signature.asc
Description: OpenPGP digital signature

Bug#919991: clusterssh: sometimes fails to open sessions with "Interrupted system call"

[Moritz Schlarb]

Package: clusterssh
Version: 4.13.2-2
Severity: important

Hi,

ClusterSSH in Buster sometimes fails to open one or more sessions with:

> Cannot open pipe for reading when talking to linux1 : Interrupted system call
> Use of uninitialized value $win in concatenation (.) or string at
/usr/share/perl5/App/ClusterSSH.pm line 639.
> linux1  session closed

I don't know who exactly is the culprit here, maybe Perl, but if someone gave
me some pointers, I'd be happy to investigate.

Regards,
Moritz



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages clusterssh depends on:
ii  libexception-class-perl 1.44-1
ii  libtry-tiny-perl0.30-1
ii  libx11-protocol-other-perl  30-1
ii  libx11-protocol-perl0.56-7
ii  openssh-client  1:7.9p1-5
ii  perl5.28.1-3
ii  perl-tk 1:804.033-2+b3
ii  xterm   342-1

clusterssh recommends no packages.

clusterssh suggests no packages.

-- no debconf information

Bug#919990: stretch-pu: package chkrootkit/0.50-4+b2

[Moritz Schlarb]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

As reported in #600109, /etc/cron.daily/chkrootkit contains a regular
expression to filter out dhclient3 and dhcpd3 as false positives from the
packet sniffer test. However, the binaries don't exist anymore, they have been
renamed to dhclient and dhcpd respectively.

I propose to backport the fix to this regex from chkrootkit/0.52-2 in Buster.

Debdiff is attached.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru chkrootkit-0.50/debian/changelog chkrootkit-0.50/debian/changelog
--- chkrootkit-0.50/debian/changelog2016-12-27 13:14:43.0 +0100
+++ chkrootkit-0.50/debian/changelog2019-01-21 11:45:44.0 +0100
@@ -1,3 +1,14 @@
+chkrootkit (0.50-4+deb9u1) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * Backport fix for regular expression for filtering out dhcpd and dhclient as
+false positives from the packet sniffer test.
+
+  [ Lorenzo "Palinuro" Faletra ]
+  * Update /etc/cron.daily/chkrootkit (Closes: #600109)
+
+ -- Moritz Schlarb   Mon, 21 Jan 2019 11:45:44 +0100
+
 chkrootkit (0.50-4) unstable; urgency=low
 
   * [132754e] Fix windigo false positive (Closes:#796599)
diff -Nru chkrootkit-0.50/debian/cron.daily chkrootkit-0.50/debian/cron.daily
--- chkrootkit-0.50/debian/cron.daily   2016-12-27 13:14:43.0 +0100
+++ chkrootkit-0.50/debian/cron.daily   2019-01-21 11:44:19.0 +0100
@@ -19,7 +19,7 @@
eval $CHKROOTKIT $RUN_DAILY_OPTS > 
$LOG_DIR/log.today.raw 2>&1
# the sed expression replaces the messages 
about /sbin/dhclient3 /usr/sbin/dhcpd3
# with a message that is the same whatever 
order eth0 and eth1 were scanned
-   sed -r -e 's,eth(0|1)(:[0-9])?: PACKET 
SNIFFER\((/sbin/dhclient3|/usr/sbin/dhcpd3)\[[0-9]+\]\),eth\[0|1\]: PACKET 
SNIFFER\([dhclient3|dhcpd3]{PID}\),' \
+   sed -r -e 's,eth(0|1)(:[0-9])?: PACKET 
SNIFFER\((/sbin/dhclient|/usr/sbin/dhcpd)\[[0-9]+\]\),eth\[0|1\]: PACKET 
SNIFFER\([dhclient|dhcpd]{PID}\),' \
-e 's/(! \w+\s+)[ 0-9]{4}[0-9]/\1#/' 
$LOG_DIR/log.today.raw > $LOG_DIR/log.today
 if [ ! -f $LOG_DIR/log.expected ]; then
echo "ERROR: No file 
$LOG_DIR/log.expected"

Bug#918101: cfengine3: Please package new LTS release (3.12) before Buster freezes

[Moritz Schlarb]

Source: cfengine3
Severity: wishlist

Dear Maintainer,

please consider packaging the latest LTS release (3.12.1) before the Buster
freezes begin.

IMHO this makes sense if you look at the upstream support timeline at
https://cfengine.com/product/supported-versions/ - support for 3.10 will stop
just after Buster is actually released, whereas 3.12 will overlap more with the
Buster support timeline.

Christoph and I are happy to help with the package maintanance.

Regards,
Moritz



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#913818: seafile-applet: symbol lookup error: seafile-applet: undefined symbol: seafile_checkout_task_get_type (seafile 6.2.5-2)

[Moritz Schlarb]

Control: fixed -1 seafile/6.2.5-3

Hey you,

sorry, I missed this bug - must've thought they were replys to the other
bug (#913818).

I had failed to ensure that the packages from src:seafile and
src:seafile-client migrate together... But all is good now!

Best regards,
Moritz

On Thu, 15 Nov 2018 16:59:09 +0100 Orfeas Theofanis 
wrote:
> Package: libseafile0
> Version: 6.2.5-2
> 
> libseafile0 and seafile-daemon were upgraded to 6.2.5-2 from 6.1.8-1 
> and will no longer work.
> Running seafile-applet no longer works, and this error shows up:
>  seafile-applet: symbol lookup error: seafile-applet: undefined symbol: 
> seafile_checkout_task_get_type
> Relevant logs:
> applet.log and ccnet.log only have entries from before the upgrade.
> seafile.log:
> [11/12/18 17:13:56] sync-mgr.c(739): Repo 'Screenshots' sync state 
> transition from 'uploading' to 'initializing'.
> [11/12/18 17:13:57] sync-mgr.c(1553): Removing blocks for repo 
> Screenshots(f8845120).
> [11/15/18 04:07:12] seaf-daemon.c(491): starting seafile client 6.2.5
> [11/15/18 04:07:12] seafile-session.c(382): client id = 
> d20353391d2779a8e28d611e130a87813f73e67b, client_name = ��$@V
> [11/15/18 04:07:12] seaf-daemon.c(518): rpc server started.
> [11/15/18 04:07:14] seaf-daemon.c(491): starting seafile client 6.2.5
> [11/15/18 04:07:14] seafile-session.c(382): client id = 
> d20353391d2779a8e28d611e130a87813f73e67b, client_name = orfetheo@debial
> [11/15/18 04:07:14] seaf-daemon.c(518): rpc server started.
> [11/15/18 04:24:52] seaf-daemon.c(491): starting seafile client 6.2.5
> [11/15/18 04:24:52] seafile-session.c(382): client id = 
> d20353391d2779a8e28d611e130a87813f73e67b, client_name = orfetheo@debial
> [11/15/18 04:24:52] seaf-daemon.c(518): rpc server started.
> The 2 last runs are by running a simple seaf-daemon command, without 
> configuration or the applet.
> On the 1st run, you can see a messed up client name, which might be the 
> culprit.
> Did something change with the encoding in the 6.2.5-2 update?
> Also interesting is that the seafile-gui is left behind in 6.1.8-1.
> 
> System information: Debian Buster with 4.18.0-2-amd64 kernel.
> 
> The server is on 6.3.3 and fully functional via the web gui.
> Output of "reportbug -q --template -T none -s none -S normal -b 
> --list-cc none -q libseafile0"
> Warning: no reportbug configuration found.  Proceeding in novice mode.
> Detected character set: UTF-8
> Please change your locale if this is incorrect.
> 
> Using 'Orfeas Theofanis ' as your from address.
> Getting status for libseafile0...
> Will send report to Debian (per lsb_release).
> Maintainer for libseafile0 is 'Debian Seafile Team 
> '.
> Looking up dependencies of libseafile0...
> 
> Rewriting subject to 'libseafile0: none'
> Saving a backup of the report at 
> /tmp/reportbug-libseafile0-backup-20181115-30943-cymw3hsc
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
>  From: Orfeas Theofanis 
> To: Debian Bug Tracking System 
> Subject: libseafile0: none
> X-Debbugs-Cc: none

Bug#913555: libsearpc: seaf-cli from seafile-cli fails with pysearpc.errors.NetworkError

[Moritz Schlarb]

Source: libsearpc
Version: 3.1.0-2
Severity: important

Control: affects -1 seafile-cli

Using seaf-cli list (with seaf-daemon running, either from seafile-applet or
standalone) leads to:

Traceback (most recent call last):
  File "/usr/bin/seaf-cli", line 869, in 
main()
  File "/usr/bin/seaf-cli", line 865, in main
args.func(args)
  File "/usr/bin/seaf-cli", line 360, in seaf_list
repos = seafile_rpc.get_repo_list(-1, -1)
  File "/usr/lib/python2.7/dist-packages/pysearpc/client.py", line 110, in
newfunc
ret_str = self.call_remote_func_sync(fcall_str)
  File "/usr/lib/python2.7/dist-packages/pysearpc/named_pipe.py", line 84, in
call_remote_func_sync
return self.transport.send(self.service_name, fcall_str)
  File "/usr/lib/python2.7/dist-packages/pysearpc/named_pipe.py", line 61, in
send
resp_header = recvall(self.pipe_fd, struct.calcsize('I'))
  File "/usr/lib/python2.7/dist-packages/pysearpc/utils.py", line 13, in
recvall
raise NetworkError('Failed to read from socket: %s' % e)
pysearpc.errors.NetworkError: Failed to read from socket: [Errno 104]
Connection reset by peer



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8),
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Bug#913306: RM: ccnet -- ROM; superseded by ccnet-server in upstream, no build-depends anymore

[Moritz Schlarb]

Package: ftp.debian.org
Severity: normal

Hello ftpmaster team,

please remove ccnet from sid.

It is not required anymore by the seafile and seafile-client packages (since
their 6.2 versions) and is not in any other Build-Depends.

Upstream superseded it by ccnet-server which is not currently packaged in
Debian, but will maybe be created by Alexandre Rossi
 sometime.

Best regards,
Moritz

Bug#887361: ccnet: Coordinated Packaging for ccnet and ccnet-server

[Moritz Schlarb]

Hello again,

I've just uploaded working versions of the Seafile Client packages (that
are libsearpc, seafile and seafile-client) that don't require ccnet anymore.

So if anyone wants to continue with packaging ccnet with the
ccnet-server sources, please feel free to do so.

Best regards,
Moritz

On 17.03.18 18:13, Georg Faerber wrote:
> (Sorry for missing References and In-Reply-To.)
> 
> Hi all,
> 
> First of all: Thanks a lot for your work on seafile -- highly
> appreciated!
> 
> Upstream responded in the linked issue of Alexandre Rossi:
> 
> "We're going to deprecate ccnet dependency in the upcoming 6.3 syncing
> client. Ccnet is currently only used for syncing libraries created
> before 3.0 servers. Because it uses TCP sockets to communicate with
> seaf-daemon (the syncing daemon), it prevents users from running
> multiple instances of syncing clients on Windows. So there would be no
> ccnet in the client in the future. By the way, the drive client doesn't
> rely on ccnet already."
> 
> Therefore, once released, this
> 
>> The very best solution of course would be if the two repos were merged
>> again so that we can build ccnet and ccnet-server packages from the
>> same source.
> 
> seems possible then, doesn't it?
> 
> Cheers,
> Georg
> 

-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF
<>

signature.asc
Description: OpenPGP digital signature

Bug#887361: ccnet: Coordinated Packaging for ccnet and ccnet-server

[Moritz Schlarb]

Hi Nicholas,

On 30.08.18 22:19, Nicholas D Steeves wrote:
> P.S. my apologies, I failed to notice that seafile-client was still at
> 6.2.4 :-(  ( https://github.com/haiwen/seafile )
> 
> I guess we still need to wait...

The changes to really remove ccnet came shortly after they tagged 6.2.4
- I hope I will come around to testing the patches shortly.
But it looks like there's not much time to wait for.

Regards,
-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF
<>

signature.asc
Description: OpenPGP digital signature

Bug#871779: Some remote folders missing when mounting a CIFS share using -o vers=2.x option

[Moritz Schlarb]

Control: reassign -1 src:linux
Control: affects -1 cifs-utils
Control: summary -1 30
Control: retitle -1 Missing folders when mounting a SMBv2 share

Hi everyone,

according to the links presented in #30, the bug is actually in the
kernel CIFS code.

Regards,
-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF
<>

signature.asc
Description: OpenPGP digital signature

Bug#902947: seafile-daemon and seafile-cli are unusable in 6.2.0

[Moritz Schlarb]

Source: seafile
Version: 6.2.0-1
Severity: serious
Tags: upstream
Justification: Policy 3.5

This bug is mainly to prevent migration of the 6.2.0 package.

Upstream is working on removing the ccnet dependency, but right now they've
only done that for the non-python parts of the package.



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#902119: unattended-upgrades: when checking for conffile prompts, local diversions are ignored

[Moritz Schlarb]

Package: unattended-upgrades
Version: 0.93.1+nmu1
Severity: important

Dear maintainer,

I have added a local diversion of a conffile:

$ dpkg-divert --list /etc/xinetd.d/*
local diversion of /etc/xinetd.d/check_mk to /etc/xinetd.d/check_mk.distrib

But when unattended-upgrades checks whether the package has a conffile prompt,
it does ignore this diversion:

check_conffile_prompt(/var/cache/apt/archives/check-mk-
agent_1.4.0p33-1_all.deb)
found pkg: check-mk-agent
conffile line: /etc/xinetd.d/check_mk 844b99375e94520e7d04d81e3cdacad9
current md5: f8b18b2afa3416d16d1233723e22014a
pkg_md5sum: 4a114a25ffdbf7a8bc79552041490395
Package check-mk-agent has conffile prompt and needs to be upgraded manually

I know this is kind of a corner case, but it would be nice to fix this.

Regards,
Moritz



-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (700, 'stable-updates'), (700, 'stable'), (60, 'testing'), (50, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-6-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages unattended-upgrades depends on:
ii  apt1.4.8
ii  apt-utils  1.4.8
ii  debconf [debconf-2.0]  1.5.61
ii  init-system-helpers1.48
ii  lsb-base   9.20161125
ii  lsb-release9.20161125
ii  python33.5.3-1
ii  python3-apt1.4.0~beta3
ii  ucf3.0036
ii  xz-utils   5.2.2-1.2+b1

Versions of packages unattended-upgrades recommends:
ii  anacron 2.3-24
ii  cron [cron-daemon]  3.0pl1-128+deb9u1

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx8.1.2-0.20160123cvs-4
ii  needrestart  2.11-3+deb9u1
ii  sendmail-bin [mail-transport-agent]  8.15.2-8

-- Configuration Files:
/etc/apt/apt.conf.d/50unattended-upgrades changed [not included]

-- debconf information excluded

Bug#890907:

[Moritz Schlarb]

Hi Adrian,

yeah, that didn't work out...

If you have time, would you mind looking at our analysis at
https://github.com/cisco/cjose/issues/70 where we gathered our findings?

Best wishes,
Moritz

On 20.05.2018 15:36, Adrian Bunk wrote:
> Control: reopen -1
> 
> On Wed, May 16, 2018 at 08:39:03PM +, Debian Bug Tracking System wrote:
>> ...
>>  cjose (0.6.0+dfsg1-2~exp1) experimental; urgency=medium
>> ...
>>* Test upstream patch from
>>  https://github.com/cisco/cjose/pull/71 (Closes: #890907)
>> ...
> 
> Seems this didn't work:
> https://buildd.debian.org/status/package.php?p=cjose=experimental
> 
> cu
> Adrian
> 

-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF
<>

signature.asc
Description: OpenPGP digital signature

Bug#898165: Regression in [v2] nfs: Fix ugly referral attributes ?

[Moritz Schlarb]

Control: tags -1 + upstream patch
Control: severity -1 grave
Control: summary -1 0
Control: outlook -1 0

3.16.54 introduced a regression by including "nfs: Fix ugly referral
attributes" but not "nfs: Fetch MOUNTED_ON_FILEID when updating an
inode". Please include that other patch, too so NFS referrals work again.

The required patch is
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ea96d1ecbe4fcb1df487d99309d3157b4ff5fc02

Best regards,
Moritz

On 17.05.2018 16:15, Chuck Lever wrote:

> Just a shot in the dark: Wondering if v3.16 needs
> 
> commit ea96d1ecbe4fcb1df487d99309d3157b4ff5fc02
> Author: Anna Schumaker 
> AuthorDate: Fri Apr 3 14:35:59 2015 -0400
> Commit: Trond Myklebust 
> CommitDate: Thu Apr 23 14:43:54 2015 -0400
> 
> nfs: Fetch MOUNTED_ON_FILEID when updating an inode

Bug#898165: Regression in [v2] nfs: Fix ugly referral attributes ?

[Moritz Schlarb]

Hi Chuck,

On 17.05.2018 16:15, Chuck Lever wrote:

> Just a shot in the dark: Wondering if v3.16 needs
> 
> commit ea96d1ecbe4fcb1df487d99309d3157b4ff5fc02
> Author: Anna Schumaker 
> AuthorDate: Fri Apr 3 14:35:59 2015 -0400
> Commit: Trond Myklebust 
> CommitDate: Thu Apr 23 14:43:54 2015 -0400
> 
> nfs: Fetch MOUNTED_ON_FILEID when updating an inode

Gosh, it seems you're right!
When I take that patch and apply it, the referrals are being followed again!

Thanks for your idea!
Now how do we make sure it gets applied soonish?

Regards,
Moritz

Bug#898165: Regression in [v2] nfs: Fix ugly referral attributes ?

[Moritz Schlarb]

Hi everyone,

there might be a regression coming from this patch:
Since it got included in 3.16.54, our clients running a recent 3.16
kernel (like from Debian jessie-security) did not follow NFS 4.1
referrals (issued by nfs-ganesha) anymore.
I have built that exact Debian kernel package with just this patch
reversed and it worked again, so I got pretty confident that this patch
is at least strongly related to the problem.
Pradeep also confirmed the problem happening in 3.16.54 but not in 3.16.51.
Interestingly, this does *not* happen with 4.9 kernels, although the
patch was part of 4.9.80...

I have attached a pcap file of a machine running 3.16.56-1+deb8u1 in
which I try to login as a user where my home directory is
/uni-mainz.de/homes/schlarbm (with nfsrefer.zdv.uni-mainz.de:/ on
/uni-mainz.de) which is then referred to
fs02.uni-mainz.de:/vol/ma17/homes/schlarbm but that referral is not
followed by the client.

Please let me know if you need additional information to reproduce or
have suggestions on what we could try.

Best regards,
Moritz

On 05.11.2017 21:45, Chuck Lever wrote:
> Before traversing a referral and performing a mount, the mounted-on
> directory looks strange:
> 
> dr-xr-xr-x. 2 4294967294 4294967294 0 Dec 31  1969 dir.0
> 
> nfs4_get_referral is wiping out any cached attributes with what was
> returned via GETATTR(fs_locations), but the bit mask for that
> operation does not request any file attributes.
> 
> Retrieve owner and timestamp information so that the memcpy in
> nfs4_get_referral fills in more attributes.
> 
> Changes since v1:
> - Don't request attributes that the client unconditionally replaces
> - Request only MOUNTED_ON_FILEID or FILEID attribute, not both
> - encode_fs_locations() doesn't use the third bitmask word
> 
> Fixes: 6b97fd3da1ea ("NFSv4: Follow a referral")
> Suggested-by: Pradeep Thomas 
> Signed-off-by: Chuck Lever 
> Cc: sta...@vger.kernel.org
> ---
>  fs/nfs/nfs4proc.c |   18 --
>  1 file changed, 8 insertions(+), 10 deletions(-)
> 
> I could send this as an incremental, but that just seems to piss
> off distributors, who will just squash them all together anyway.
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
> index 6c61e2b..2662879 100644
> --- a/fs/nfs/nfs4proc.c
> +++ b/fs/nfs/nfs4proc.c
> @@ -254,15 +254,12 @@ static int nfs4_map_errors(int err)
>  };
>  
>  const u32 nfs4_fs_locations_bitmap[3] = {
> - FATTR4_WORD0_TYPE
> - | FATTR4_WORD0_CHANGE
> + FATTR4_WORD0_CHANGE
>   | FATTR4_WORD0_SIZE
>   | FATTR4_WORD0_FSID
>   | FATTR4_WORD0_FILEID
>   | FATTR4_WORD0_FS_LOCATIONS,
> - FATTR4_WORD1_MODE
> - | FATTR4_WORD1_NUMLINKS
> - | FATTR4_WORD1_OWNER
> + FATTR4_WORD1_OWNER
>   | FATTR4_WORD1_OWNER_GROUP
>   | FATTR4_WORD1_RAWDEV
>   | FATTR4_WORD1_SPACE_USED
> @@ -6763,9 +6760,7 @@ static int _nfs4_proc_fs_locations(struct rpc_clnt 
> *client, struct inode *dir,
>  struct page *page)
>  {
>   struct nfs_server *server = NFS_SERVER(dir);
> - u32 bitmask[3] = {
> - [0] = FATTR4_WORD0_FSID | FATTR4_WORD0_FS_LOCATIONS,
> - };
> + u32 bitmask[3];
>   struct nfs4_fs_locations_arg args = {
>   .dir_fh = NFS_FH(dir),
>   .name = name,
> @@ -6784,12 +6779,15 @@ static int _nfs4_proc_fs_locations(struct rpc_clnt 
> *client, struct inode *dir,
>  
>   dprintk("%s: start\n", __func__);
>  
> + bitmask[0] = nfs4_fattr_bitmap[0] | FATTR4_WORD0_FS_LOCATIONS;
> + bitmask[1] = nfs4_fattr_bitmap[1];
> +
>   /* Ask for the fileid of the absent filesystem if mounted_on_fileid
>* is not supported */
>   if (NFS_SERVER(dir)->attr_bitmask[1] & FATTR4_WORD1_MOUNTED_ON_FILEID)
> - bitmask[1] |= FATTR4_WORD1_MOUNTED_ON_FILEID;
> + bitmask[0] &= ~FATTR4_WORD0_FILEID;
>   else
> - bitmask[0] |= FATTR4_WORD0_FILEID;
> + bitmask[1] &= ~FATTR4_WORD1_MOUNTED_ON_FILEID;
>  
>   nfs_fattr_init(_locations->fattr);
>   fs_locations->server = server;
> 


nfs-referral-broken.pcap
Description: application/vnd.tcpdump.pcap
<>

signature.asc
Description: OpenPGP digital signature

Bug#898683: diffoscope: not installable from stretch-backports because of unmet dependency python3-distutils

[Moritz Schlarb]

Package: diffoscope
Version: 94~bpo9+1
Severity: normal

Hi,

diffoscope 94~bpo9+1 depends on python3-distutils which is not present in
stretch-backports (and it doesn't look like it is just failing to migrate or
stuck in NEW).

Regards,
Moritz

---

schlarb-1:~ # apt -t stretch-backports install diffoscope
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 diffoscope : Depends: python3-distutils but it is not going to be installed
  Recommends: xmlutils but it is not installable
E: Unable to correct problems, you have held broken packages.

schlarb-1:~ # apt policy python3-distutils
python3-distutils:
  Installed: (none)
  Candidate: 3.6.5~rc1-1
  Version table:
 3.6.5-3 50
 50 http://ftp.uni-mainz.de/debian unstable/main amd64 Packages
 50 http://ftp.uni-mainz.de/debian unstable/main i386 Packages
 50 http://ftp.de.debian.org/debian unstable/main amd64 Packages
 50 http://ftp.de.debian.org/debian unstable/main i386 Packages
 3.6.5~rc1-1 60
 60 http://ftp.uni-mainz.de/debian testing/main amd64 Packages
 60 http://ftp.uni-mainz.de/debian testing/main i386 Packages
 60 http://ftp.de.debian.org/debian testing/main amd64 Packages
 60 http://ftp.de.debian.org/debian testing/main i386 Packages




-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (700, 'stable-updates'), (700, 'stable'), (60, 'testing'), (50, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-6-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#898165: linux-image-3.16.0-6-amd64: can't mount NFS shares via nfs referrals

[Moritz Schlarb]

Hi Pradeep,

thanks for your response.

On 14.05.2018 17:48, Pradeep wrote:
> The patch is for NFS client side bug where it was initializing the
> attributes to zero if NFS4ERR_MOVED is returned in LOOKUP; but referral
> was not followed later. This only happens with NFSv4 server and the
> specific error (NFS4ERR_MOVED). 
> 
> It is not related to nfs-ganesha - it can be reproduced with kernel NFS
> as well.
> 
> Are you seeing any regressions with the patch?

I would think so.
Since that patch arrived in Kernel 3.16, it would not even try to follow
the referral as it did before. When I just revert this specific patch
for the kernel, it works.

On the referrer server, we use nfs-ganesha 2.4.5-2 with Christoph's
patch for nfs referral
(https://sources.debian.org/src/nfs-ganesha/2.4.5-2%7Ebpo9+1/debian/patches/nfs-ganesha-nfsrefer.patch).
The actual NFS server is a NetApp cluster.

I'm not so sure right now if it is not maybe a bug in nfs-ganesha (that
maybe even got fixed in the meantime), so I thought, maybe you know.

Thanks,
Moritz



signature.asc
Description: OpenPGP digital signature

Bug#898165: linux-image-3.16.0-6-amd64: can't mount NFS shares via nfs referrals

[Moritz Schlarb]

Hello Frank and Pradeep,

I was hoping that you would have some insight on a possible
bug/regression/incompability between nfs-ganesha and the Linux kernel
with a specific patch to which you reacted (see below) in
https://marc.info/?l=linux-nfs=150998968529002=2.

There is no mail about the results of Pradeep's checking whether that
patch is safe for nfs-ganesha on the server side, or whether there were
additional changes needed. Maybe one of you could shed some light on that.

I've created a tracking Debian bug report for our issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898165

Best regards,
Moritz

On 14.05.2018 11:05, Moritz Schlarb wrote:
> Control: tags -1 + patch upstream
> Control: notfound -1 linux/3.16.51-3+deb8u1
> 
> Hi everyone,
> 
> I have identified the upstream commit that introduced this
> bug/regression for us.
> 
> It is c05cefcc72416a37eba5a2b35f0704ed758a9145 "nfs: Fix ugly referral
> attributes"
> (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c05cefcc72416a37eba5a2b35f0704ed758a9145)
> which seems to have been part of upstream 3.16.54.
> 
> I have manually compiled 3.16.56-1+deb8u1 with that patch reversed and I
> can successfully mount my home directory again.
> 
> Regards,
> 

-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF
<>

signature.asc
Description: OpenPGP digital signature

Bug#898165: linux-image-3.16.0-6-amd64: can't mount NFS shares via nfs referrals

[Moritz Schlarb]

Control: tags -1 + patch upstream
Control: notfound -1 linux/3.16.51-3+deb8u1

Hi everyone,

I have identified the upstream commit that introduced this
bug/regression for us.

It is c05cefcc72416a37eba5a2b35f0704ed758a9145 "nfs: Fix ugly referral
attributes"
(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c05cefcc72416a37eba5a2b35f0704ed758a9145)
which seems to have been part of upstream 3.16.54.

I have manually compiled 3.16.56-1+deb8u1 with that patch reversed and I
can successfully mount my home directory again.

Regards,
-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF
<>

signature.asc
Description: OpenPGP digital signature

Bug#898165: linux-image-3.16.0-6-amd64: can't mount NFS shares via nfs referrals

[Moritz Schlarb]

Hello again,

we tried to get some insight into the issue by wiresharking while trying
to mount.

Although the client first receives NFS4ERR_MOVED and then re-queries for
FS_Locations and receives a correct response for the referred
fs_location, it just does not continue to mount that given fs_location
then like it used to.

Regards,
Moritz
<>

signature.asc
Description: OpenPGP digital signature

Bug#898165: linux-image-3.16.0-6-amd64: can't mount NFS shares via nfs referrals

[Moritz Schlarb]

Hi everyone,

we have performed additional tests that led to the conclusion that this
bug did already exist in 3.16.0-5-amd64, but not in 3.16.0-4-amd64.
Given that, it must have been some change in  3.16.51-3+deb8u1 which
luckily are only few.
I hope its not fallout from the KPTI patch, so the only other thing that
seems relevant (since we're using Kerberos) would be:

>  * KEYS: add missing permission check for request_key() destination
>(CVE-2017-17807)

Does that seem valid?

Regards,
-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF
<>

signature.asc
Description: OpenPGP digital signature

Bug#898165: linux-image-3.16.0-6-amd64: can't mount NFS shares via nfs referrals

[Moritz Schlarb]

Package: src:linux
Version: 3.16.56-1
Severity: important

Control: fixed -1 linux/4.9.88-1~bpo8+1
Control: fixed -1 linux/4.9.88-1

Hello,

after getting the latest stable security kernel version on one of our
NFS clients, said client can't mount our user home directories via our
NFS referer server anymore.

This problem is only similar to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850713
but (for us) far more severe, since *this* bug affects home directories.

Our workaround is to install the latest kernel from jessie-backports,
which does not have this problem.

The logs aren't saying anything at the time of login, where the home
should be mounted.

There are only some patches regarding nfs listed in the package
changelog, maybe if you could point us to a specific one, we could try
to bisect it.

Regards,
Moritz

-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: Dell Inc.
product_name: OptiPlex 7010
product_version: 01
chassis_vendor: Dell Inc.
chassis_version: 
bios_vendor: Dell Inc.
bios_version: A28
board_vendor: Dell Inc.
board_name: 0GY6Y8
board_version: A03

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core 
processor DRAM Controller [8086:0150] (rev 09)
Subsystem: Dell Device [1028:0577]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: ivb_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 v2/3rd 
Gen Core processor Graphics Controller [8086:0162] (rev 09) (prog-if 00 [VGA 
controller])
Subsystem: Dell Device [1028:0577]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915

00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset 
Family USB xHCI Host Controller [8086:1e31] (rev 04) (prog-if 30 [XHCI])
Subsystem: Dell Device [1028:0577]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd

00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C210 Series 
Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
Subsystem: Dell Device [1028:0577]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: mei_me

00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network 
Connection [8086:1502] (rev 04)
Subsystem: Dell Device [1028:052c]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: e1000e

00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset 
Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04) (prog-if 20 [EHCI])
Subsystem: Dell Device [1028:0577]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: ehci-pci

00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C210 Series Chipset 
Family High Definition Audio Controller [8086:1e20] (rev 04)
Subsystem: Dell Device [1028:0577]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snd_hda_intel

00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset 
Family USB Enhanced Host Controller #1 [8086:1e26] (rev 04) (prog-if 20 [EHCI])
Subsystem: Dell Device [1028:0577]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: ehci-pci

00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev 
a4) (prog-if 01 [Subtractive decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- 
Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 

00:1f.0 ISA bridge [0601]: Intel Corporation Q77 Express Chipset LPC 

Bug#873698: Finally a working watch file that also downloads correctly

[Moritz Schlarb]

Control: tags -1 + patch

Hi everyone,

I added some filenamemangle options so that the core and masterfiles
tarball get named correctly after download.

Best wishes,
-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF
diff --git a/debian/watch b/debian/watch
index 714580b..298f059 100644
--- a/debian/watch
+++ b/debian/watch
@@ -1,3 +1,13 @@
 version=4
-https://cfengine.com/product/community/ .*/cfengine-(\d.*).tar.gz
-opts="component=masterfiles" https://cfengine.com/product/community/ .*/cfengine-masterfiles-(\d.*).tar.gz
+# Since the official upstream download page at https://cfengine.com/product/community/
+# is dynamically generated from many layers of JSON files, we instead look at the
+# GitHub releases page to get a list of versions and then construct the URLs for
+# release tarballs from them.
+# Therefore, the following looks pretty ugly. If someone finds a sane way to improve it,
+# please do so!
+opts=downloadurlmangle=s%https://github.com/cfengine/core/archive/(@ANY_VERSION@@ARCHIVE_EXT@)%https://cfengine-package-repos.s3.amazonaws.com/tarballs/cfengine-$1%,\
+		filenamemangle=s%.*/(@ANY_VERSION@)(@ARCHIVE_EXT@)%cfengine-$1$3% \
+	https://github.com/cfengine/core/releases .*/([\.\d]+)@ARCHIVE_EXT@
+opts=component=masterfiles,downloadurlmangle=s%https://github.com/cfengine/masterfiles/archive/(@ANY_VERSION@@ARCHIVE_EXT@)%https://cfengine-package-repos.s3.amazonaws.com/tarballs/cfengine-masterfiles-$1%,\
+		filenamemangle=s%.*/(@ANY_VERSION@)(@ARCHIVE_EXT@)%cfengine-masterfiles-$1$3% \
+	https://github.com/cfengine/masterfiles/releases .*/([\.\d]+)@ARCHIVE_EXT@
<>

signature.asc
Description: OpenPGP digital signature

Bug#897214: Fixed in 6.1.7-1

[Moritz Schlarb]

Control: fixed -1 seafile-cli/6.1.7-1
Control: tags -1 + fixed pending

This will be resolved as soon as src:seafile/6.1.7-1 finally migrates...

-- 
Moritz Schlarb

Bug#893039: libccnet0: contains a python module

[Moritz Schlarb]

Hello Helmut,

On 20.04.2018 20:06, Helmut Grohne wrote:
> I just looked into the package and only then noticed Christoph's upload.
> Let me share a few remarks though:
> 
>  * The new upstream release is a bit "strange". Even github uses the
>same commit id for both 6.1.5 and 6.1.7. That looks like a mistake to
>me.

It is a deliberate decision made by upstream to ensure that the three
components of the Seafile client "suite" always use the same version
number... Therefore they always re-tag ccnet, even if there are no
changes in the meantime. (Strangely, for searpc, they don't do that, but
use an even stranger tagging scheme, where there's currently only a Git
tag v3.1-latest, though the "internal" version is [correctly] set to
3.0.8...).
We decided to just follow along this decision by upstream since just
rebuilding the package with a new version is only minorly inconvenient
and we wanted to not divert too much from their recommendation. Although
I just now thought that if we think this trough, we should also have
strict same-version dependencies between the three components, which we
don't have right now.

>  * Did you consider porting to Python 3? It seems that for searpc, there
>is a patch to support Python 3 at
>https://github.com/haiwen/libsearpc/pull/21.

I noticed the Lintian warning and did not override it to keep it as a
marker to do that soon.

Best regards,
Moritz

Bug#896154: maint-guide: Wrong order of buildflags statements in default rules file (4.4.2.)

[Moritz Schlarb]

Source: maint-guide
Severity: important

Dear Maintainer,

in section "4.4.2. Default rules file", the rules file example (which
also isn't what dh_make actually produces nowadays) probably shows an
incorrect order of the buildflags-related statements:
AFAICS, at least DEB_BUILD_MAINT_OPTIONS needs to be set *before* the
inclusion of /usr/share/dpkg/buildflags.mk (transitively by default.mk)
to have effect.

On the other hand, in https://bugs.debian.org/763535, it was discussed
that these lines should actually not be included in the template rules
file at all, which is probably why dh_make dropped them.

Regards,
Moritz

Bug#893039: libccnet0: contains a python module

[Moritz Schlarb]

Hi Helmut,

I addressed this issue in 6.1.5-2, but since this leads to a new binary
upload, I can't upload it myself since I'm just a DM.
My mentor/sponsor Christoph is currently out of the office, so he can't
do it either.
So I've uploaded it to https://mentors.debian.net/package/ccnet - maybe
you are willing to perform the upload for me (If that went through, I'm
gonna upload the new upstream version myself).

Best regards,
Moritz



signature.asc
Description: OpenPGP digital signature

Bug#895467: libsearpc FTBFS on 64bit big endian: test failure

[Moritz Schlarb]

Hi Adrian and thanks for your response,

On 16.04.2018 15:13, Adrian Bunk wrote:
> Third solution:
> Fix the bugs.

Well that was actually the first solution I meant, but I just didn't
have much hope finding a solution, so thank you very much for your help.

> After fixing the two above bugs, libsearpc builds on s390x.

I've added patches to the package and will send them upstream.

> An en passant finding (not required to fix the FTBFS) is the following 
> that is documented to be unsupported, and might break on any 
> architecture at any time:
> https://sources.debian.org/src/libsearpc/3.0.8-3/lib/searpc-named-pipe-transport.c/#L236

I will report that to upstream, too.

Thx,
Moritz



signature.asc
Description: OpenPGP digital signature

Bug#895467: libsearpc FTBFS on 64bit big endian: test failure

[Moritz Schlarb]

Hi there,

I'm unsure how to handle this.

The current breakage of the package since 3.0.8-2 comes from me
re-enabling the upstream tests, which were previously disabled with a
comment that they were broken upstream (so, at
https://buildd.debian.org/status/logs.php?pkg=libsearpc=3.0.8-1, all
builds ran fine but right now, they fail on some architectures - s390x,
ppc64 and sparc64:
https://buildd.debian.org/status/package.php?p=libsearpc).

Since the package still builds and tests fine on *most* architectures,
I'd beg to differ that the test suite is broken in general.

Now of course myself and upstream can look into the problem, but since
it maybe is specific to an exotic architecture that we might not have
access to, I would not have high hopes in that approach.

Two other "solutions", I can think of would be:
- Using a switch on the current architecture in debian/rules to just
don't test on these arches
- Exclude the arches from Architecture: in debian/control

Would any of those options be appropriate?

Best regards,
Moritz

On 11.04.2018 22:24, Adrian Bunk wrote:
> Source: libsearpc
> Version: 3.0.8-2
> Severity: serious
> 
> https://buildd.debian.org/status/package.php?p=libsearpc=sid
> 
> ...
> FAIL: test-searpc
> =
> 
> Loaded 1 suites: 
> Started
> 
> (process:10121): Searpc-WARNING **: 17:59:21.601: failed to read rpc request: 
> Bad address
> 
> (process:10121): Searpc-WARNING **: 17:59:21.601: failed to read rpc 
> response: Connection reset by peer
> F
> (process:10121): Searpc-WARNING **: 17:59:21.923: failed to read rpc request: 
> Bad address
> 
> (process:10121): Searpc-WARNING **: 17:59:21.923: failed to send rpc call: 
> Broken pipe
> F
> (process:10121): Searpc-WARNING **: 17:59:22.122: failed to read rpc request: 
> Bad address
> 
> (process:10121): Searpc-WARNING **: 17:59:22.125: failed to read rpc 
> response: Connection reset by peer
> F
> 
>   1) Failure:
> searpc::pipe_simple_call [searpc.c:427]
>   Expression is not true: error == NULL
>   Transport Error
> 
>   2) Failure:
> searpc::pipe_large_request [searpc.c:454]
>   Expression is not true: error == NULL
>   Transport Error
> 
>   3) Failure:
> searpc::pipe_concurrent_clients [searpc.c:483]
>   Expression is not true: error == NULL
>   Transport Error
> 
> System error: `fork()` call failed (12) - Cannot allocate memory
> FAIL test-searpc (exit status: 255)
> 
> 
> Testsuite summary for libsearpc 3.0.8
> 
> # TOTAL: 1
> # PASS:  0
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
> 
> See tests/test-suite.log
> Please report to i...@seafile.com
> 
> make[5]: *** [Makefile:687: test-suite.log] Error 1
> 

Bug#889866: nagstamon: crashes under openbox: python tracebacks, SIGSEGV

[Moritz Schlarb]

Control: forwarded -1 https://github.com/HenriWahl/Nagstamon/issues/473

Hi Paul,

this is also reported upstream and there is some work in progress, I think.
A workaround would be to install e.g. "notification-daemon", like
mentioned in
https://github.com/HenriWahl/Nagstamon/issues/357#issuecomment-275418229.

Regards,
Moritz

On 08.02.2018 05:43, Paul Wise wrote:
> Package: nagstamon
> Version: 3.0.2-1
> Severity: normal
> Usertags: crash
> 
> When I try to run nagstamon under openbox I get two Python tracebacks
> and a Python crash (SIGSEGV). It would be nice if nagstamon could
> handle the lack of a notifications mechanism in openbox by just
> updating the nagstamon window with the current status of remote
> servers. If the crash is a problem in Python or Qt, please clone
> and or reassign this bug as appropriate.
> 
> $ gdb -batch -n -ex 'set pagination off' -ex run -ex bt -ex 'thread apply all 
> bt full' --args python3 /usr/bin/nagstamon
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [New Thread 0x7fffe00f0700 (LWP 9886)]
> [New Thread 0x7fffda119700 (LWP 9946)]
> [New Thread 0x7fffd9918700 (LWP 9948)]
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/dbus/bus.py", line 175, in 
> activate_name_owner
> return self.get_name_owner(bus_name)
>   File "/usr/lib/python3/dist-packages/dbus/bus.py", line 361, in 
> get_name_owner
> 's', (bus_name,), **keywords)
>   File "/usr/lib/python3/dist-packages/dbus/connection.py", line 651, in 
> call_blocking
> message, timeout)
> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NameHasNoOwner: 
> Could not get owner of name 'org.freedesktop.Notifications': no such name
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-packages/Nagstamon/QUI/__init__.py", line 6426, 
> in __init__
> '/org/freedesktop/Notifications')
>   File "/usr/lib/python3/dist-packages/dbus/bus.py", line 241, in get_object
> follow_name_owner_changes=follow_name_owner_changes)
>   File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 248, in __init__
> self._named_service = conn.activate_name_owner(bus_name)
>   File "/usr/lib/python3/dist-packages/dbus/bus.py", line 180, in 
> activate_name_owner
> self.start_service_by_name(bus_name)
>   File "/usr/lib/python3/dist-packages/dbus/bus.py", line 278, in 
> start_service_by_name
> 'su', (bus_name, flags)))
>   File "/usr/lib/python3/dist-packages/dbus/connection.py", line 651, in 
> call_blocking
> message, timeout)
> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The 
> name org.freedesktop.Notifications was not provided by any .service files
> [New Thread 0x7fffd4728700 (LWP 10085)]
> [New Thread 0x7fffd33b2700 (LWP 10124)]
> [New Thread 0x7fffd2bb1700 (LWP 10125)]
> [New Thread 0x7fffd23b0700 (LWP 10126)]
> [New Thread 0x7fffd1baf700 (LWP 10127)]
> [Thread 0x7fffd2bb1700 (LWP 10125) exited]
> [Thread 0x7fffd23b0700 (LWP 10126) exited]
> [Thread 0x7fffd33b2700 (LWP 10124) exited]
> QLayout: Attempting to add QLayout "" to StatusWindow "", which already has a 
> layout
> [New Thread 0x7fffd33b2700 (LWP 10142)]
> [New Thread 0x7fffd23b0700 (LWP 10143)]
> [New Thread 0x7fffd2bb1700 (LWP 10210)]
> [Thread 0x7fffd2bb1700 (LWP 10210) exited]
> [New Thread 0x7fffd2bb1700 (LWP 10211)]
> [Thread 0x7fffd2bb1700 (LWP 10211) exited]
> [New Thread 0x7fffd2bb1700 (LWP 10219)]
> 
> Thread 1 "python3" received signal SIGSEGV, Segmentation fault.
> _dbus_counter_get_size_value (counter=0x203a73736572706d) at 
> ../../../dbus/dbus-resources.c:276
> 276   ../../../dbus/dbus-resources.c: No such file or directory.
> #0  0x7fffef9ed3c0 in _dbus_counter_get_size_value 
> (counter=0x203a73736572706d) at ../../../dbus/dbus-resources.c:276
> #1  0x7fffef9f2b82 in _dbus_transport_get_dispatch_status 
> (transport=0x7fffebdb09e0 ) at 
> ../../../dbus/dbus-transport.c:1126
> #2  0x7fffef9f2de6 in _dbus_transport_queue_messages 
> (transport=0x7fffebdb09e0 ) at 
> ../../../dbus/dbus-transport.c:1172
> #3  0x7fffef9d9a81 in _dbus_connection_get_dispatch_status_unlocked 
> (connection=0x16687a0) at ../../../dbus/dbus-connection.c:4257
> #4  0x7fffef9dcf22 in dbus_connection_dispatch (connection=0x16687a0) at 
> ../../../dbus/dbus-connection.c:4590
> #5  0x7fffd4ae02f8 in pyqt5DBusHelper::dispatch() (this=0x166d850) at 
> ../../dbus/dbus.cpp:323
> #6  0x7fffebd338c2 in QObject::event(QEvent*) (this=0x166d850, 
> e=) at kernel/qobject.cpp:1246
> #7  0x7fffeca2059c in QApplicationPrivate::notify_helper(QObject*, 
> QEvent*) (this=this@entry=0xfcce40, receiver=receiver@entry=0x166d850, 
> e=e@entry=0x166a240) at kernel/qapplication.cpp:3722
> #8  0x7fffeca27e64 in QApplication::notify(QObject*, QEvent*) 
> (this=this@entry=0xfd8000, 

Bug#886655: debian-cd: Fails to add EFI Grub menu entries when append gets too long or so

[Moritz Schlarb]

Control: tag 886655 patch

Hi everyone,

I just found the same problem reported and solved in another mail here
(<65b7a7928c7ef2da0ebc597643a3ca5dcfc4d098.1513345492.git.h...@univention.de>,
 https://lists.debian.org/debian-cd/2017/12/msg00018.html):

> Debian added Multi-Arch support to its CD images, where "label" and
> "append" have to be special parsed to distinguish between "ifcpu64" and
> normal "linux" statements.
> 
> That broke "append" parsing, as those lines were no longer passed on for
> further procession:
>> 162: foreach my $line(@lines) {
> ...
>> 239} elsif ($line =~ /append (.*)$/ && $in_kernel) {
>> 240$kernel{"append"} = $1;
> no longer trigger.
> 
> Pass on the line if we are not in "ifcpu64==3" mode.
> ---
>  tools/boot/stretch/parse_isolinux | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/tools/boot/stretch/parse_isolinux 
> b/tools/boot/stretch/parse_isolinux
> index 5ed32cb..a15e52d 100755
> --- a/tools/boot/stretch/parse_isolinux
> +++ b/tools/boot/stretch/parse_isolinux
> @@ -66,6 +66,8 @@ sub parse_file {
>   if ($in_ifcpu == 3) {
>   parse_file($1);
>   $in_ifcpu = 1;
> + } else {
> + push(@lines, $line);
>   }
>   } elsif ($line =~ /append (.*)$/ && $in_ifcpu == 2) {
>   # Parse out the first entry - that's what we want to use

Regards,
-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF
<>

signature.asc
Description: OpenPGP digital signature

Bug#865830: RFP: seafile-server - An online file storage and collaboration tool

[Moritz Schlarb]

Dear Alexandre,

thanks for your lots of work!

First of all, I'd like to reference some discussions in the upstream
support forum:
https://forum.seafile.com/t/what-about-reproducible-builds/3125/11 and
https://forum.seafile.com/t/about-the-future-of-seafile-repository-packages/49/2

I'm adding my two cents on the stuff below:

On 19.10.2017 23:12, Alexandre Rossi wrote:
> Hi,
> 
> I've done some proof of concept packaging which seems to be working.

Thanks for that!

> I'm also pondering moving most binaries out
> of PATH as they feel useless to the user.

I'd say that at least fsck, fuse and gc are quite important for an end
user, so I think those should be kept.

> I also chose to ignore seafile-controller and use systemd instead.

I very much like that! :-D

> So that means that my TODO list consists in the following, in order :
> 1) send patches upstream
> 2) use all this some time in order to fix seahub porting problems and
> see if I want to use seafile myself
> 3) coordinate with ccnet Debian maintainers to see how libccnet should
> be packaged (ccnet or ccnet-server or both).

Therefore, I created a new bug right here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887361
Although I actually just found this forum post:
https://forum.seafile.com/t/seafile-server-and-seafile-client-packaging-guidelines/662/9

> 4) iron out admin scripts and associated documentation, document
> seahub deployment in README.Debian> 5) cleanup seahub lintian errors (the 
> usual embedded or minified, or
> both, js problems)

> 6) fill out ITPs and find a sponsor. I know there is not upstream
> commitment to security patches but I'm doing all this for myself
> anyway so I'll try my best to finish the job. And maybe it won't go in
> the archive but it may be of some interest to others.
> 7) port seahub to python3 (I'v already ported one of my pet projects
> and deps seem to be available so it should not be hard)

Best regards,
-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF
<>

signature.asc
Description: OpenPGP digital signature

Bug#887361: ccnet: Coordinated Packaging for ccnet and ccnet-server

[Moritz Schlarb]

Package: ccnet
Version: 6.1.4-1~bpo9+1
Severity: normal

This bug is a split-off from https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=865830#25 regarding the duplication issues caused by also
packaging ccnet-server.

Effectively, both sources (e.g. repositories) contain pretty much the same
code, with some directories deleted and some fixes applied to one or the
other...

The reason for the whole duplication was to remove the dependency on OpenSSL
for the client stack, so that we could package seafile-client for Debian.

In a bit of historical context, this "fork" was done between August and
December 2016 because we needed them to drop their OpenSSL dependency because
of the widely known license issues it causes.
There was discussion in https://github.com/haiwen/ccnet/issues/7 and
https://github.com/haiwen/seafile/issues/631 and
https://github.com/haiwen/seafile/issues/666 .

The very best solution of course would be if the two repos were merged again so
that we can build ccnet and ccnet-server packages from the same source.



-- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (700, 'stable-updates'), (700, 'stable'), (60, 'testing'), (50, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ccnet depends on:
ii  libc6   2.24-11+deb9u1
ii  libccnet0   6.1.4-1~bpo9+1
ii  libevent-2.0-5  2.0.21-stable-3
ii  libglib2.0-02.50.3-2
ii  libjansson4 2.9-1
ii  libsearpc1  3.0.8-1
ii  libsqlite3-03.16.2-5+deb9u1
ii  libssl1.1   1.1.0f-3+deb9u1
ii  libuuid12.29.2-1

ccnet recommends no packages.

ccnet suggests no packages.

-- no debconf information

Bug#886655: debian-cd: Fails to add EFI Grub menu entries when append gets too long or so

[Moritz Schlarb]

Package: debian-cd
Version: 3.1.20
Severity: important

Hi everyone,

I've used simple-cdd to create a Debian Installer CD which would result in
having a pretty complex append line::

kernel /install.amd/vmlinuz
append auto url=bootimage-01.zdv.uni-mainz.de/d-i/stretch/scvmm.cfg
language=en country=DE locale=en_US.UTF-8 keymap=de hostname=unassigned-
hostname domain=unassigned-domain preseed/file=/cdrom/simple-
cdd/default.preseed debian-installer/locale=en_US console-keymaps-at/keymap=de
keyboard-configuration/xkb-keymap=de keyboard-configuration/layout=de simple-
cdd/profiles=zdv,scvmm vga=788 initrd=/install.amd/initrd.gz --- quiet

The first parameters, up to domain= are mine, the others are added by simple-
cdd.

This seems to work fine for the isolinux part, but generating the Grub efi menu
entries using parse_isolinux generates almost linux and initrd lines::

linux/install.amd/vmlinuz
initrd

The respective logfile of debian-cd says::

stdout:   Adding EFI boot code for amd64 on CD1
stderr: Use of uninitialized value $k{"append"} in substitution (s///) at
/data/schlarbm/simple-cdd/tmp/debian-cd/tools/boot/stretch/parse_isolinux line
105.
stderr: Use of uninitialized value $k{"append"} in concatenation (.) or string
at /data/schlarbm/simple-cdd/tmp/debian-cd/tools/boot/stretch/parse_isolinux
line 111.
stderr: Use of uninitialized value $initrd in concatenation (.) or string at
/data/schlarbm/simple-cdd/tmp/debian-cd/tools/boot/stretch/parse_isolinux line
112.
[...]

Now I don't know whether the problem lies in the sheer length of the line or in
any of the characters in it.

Regards,
Moritz



-- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (700, 'stable-updates'), (700, 'stable'), (60, 'testing'), (50, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debian-cd depends on:
ii  apt   1.4.8
ii  bc1.06.95-9+b3
ii  bzip2 1.0.6-8.1
ii  cpp   4:6.3.0-4
ii  curl  7.52.1-5+deb9u3
ii  dctrl-tools [grep-dctrl]  2.24-2+b1
ii  dpkg-dev  1.18.24
ii  genisoimage   9:1.1.11-3+b2
pn  libcompress-zlib-perl 
pn  libdigest-md5-perl
ii  libdpkg-perl  1.18.24
ii  libperl5.24 [libdigest-sha-perl]  5.24.1-3+deb9u2
ii  lynx  2.8.9dev11-1
ii  lynx-cur  2.8.9dev11-1
ii  make  4.1-9.1
ii  perl  5.24.1-3+deb9u2
ii  tofrodos  1.7.13+ds-2
ii  xorriso   1.4.6-1+b1

Versions of packages debian-cd recommends:
ii  dosfstools   4.1-1
ii  hfsutils 3.2.6-13+b1
ii  isolinux 3:6.03+dfsg-14.1+deb9u1
ii  mtools   4.0.18-2+b1
ii  netpbm   2:10.0-15.3+b2
ii  syslinux-common  3:6.03+dfsg-14.1+deb9u1
ii  syslinux-utils   3:6.03+dfsg-14.1+deb9u1
ii  wget 1.18-5+deb9u1

debian-cd suggests no packages.

-- no debconf information

Bug#884932: ufw: cannot preseed package configuration in debian-installer

[Moritz Schlarb]

Package: ufw
Version: 0.35-4
Severity: important
Tags: d-i

Hi,

based on the README.Debian
(https://sources.debian.org/src/ufw/0.35-4/debian/README.Debian/#L23), I tried
to preseed ufw to be enabled and allowing SSH while also being installed
directly in d-i.

Basically this comes down to the following three lines in preseed.cfg:

d-i pkgsel/include string ufw
ufw ufw/enable boolean true
ufw ufw/allow_known_ports multiselect SSH

But this leads to the following errors in the installer syslog:

Dec 21 12:47:16 in-target: Setting up ufw (0.35-4) ...^M
Dec 21 12:47:16 in-target: ^M
Dec 21 12:47:16 in-target: Creating config file /etc/ufw/before.rules with new
version^M
Dec 21 12:47:16 in-target: ^M
Dec 21 12:47:16 in-target: Creating config file /etc/ufw/before6.rules with new
version^M
Dec 21 12:47:16 in-target: ^M
Dec 21 12:47:16 in-target: Creating config file /etc/ufw/after.rules with new
version^M
Dec 21 12:47:16 in-target: ^M
Dec 21 12:47:16 in-target: Creating config file /etc/ufw/after6.rules with new
version^M
Dec 21 12:47:16 kernel: [  674.133042] ip_tables: (C) 2000-2006 Netfilter Core
Team
Dec 21 12:47:16 in-target: ERROR: initcaps^M
Dec 21 12:47:16 in-target: [Errno 2] iptables v1.6.0: can't initialize iptables
table `filter': Table does not exist (do you need to insmod?)^M
Dec 21 12:47:16 in-target: Perhaps iptables or your kernel needs to be
upgraded.^M
Dec 21 12:47:16 in-target: ^M

And after rebooting, ufw is enabled, but the allow rules for SSH are missing.
:(

Regards,
Moritz Schlarb
--
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF



-- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (700, 'stable-updates'), (700, 'stable'), (60, 'testing'), (50, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages ufw depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  init-system-helpers1.48
ii  iptables   1.6.0+snapshot20161117-6
ii  lsb-base   9.20161125
ii  python33.5.3-1
ii  ucf3.0036

ufw recommends no packages.

Versions of packages ufw suggests:
ii  rsyslog  8.24.0-1

-- debconf information excluded

Bug#882981: ValueError: error while getting hash (not enough entropy?)

[Moritz Schlarb]

Hi Chris,

thanks, I can confirm that the error doesn't occur anymore.

Regards,
-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF
<>

signature.asc
Description: OpenPGP digital signature

Bug#882981: ValueError: error while getting hash (not enough entropy?)

[Moritz Schlarb]

Hi Chris,

On 28.11.2017 14:53, Chris Lamb wrote:
> Hi Moritz,
> 
> Thank you for the bug report. I just went to reproduce this,
> but:
> 
>   $ curl -I http://repos.s3.amazonaws.com/tarballs/cfengine-3.10.2.tar.gz
>   HTTP/1.1 403 Forbidden
>   x-amz-request-id: 8C7916BA9F5E9381
>   x-amz-id-2: 
> 8yBN+i0wVQwUBR1r2A8mfPJFi2k+lDnyEUtjk3sPUGtYP2mRnVCBqqHMqRN4PHhmdGLz4Q1Pebc=
>   Content-Type: application/xml
>   Transfer-Encoding: chunked
>   Date: Tue, 28 Nov 2017 13:52:27 GMT
>   Server: AmazonS3

Ah, apparently that link got line-broken badly - you are missing a
prefix of "cfengine-package-" on that URL. ;)

> I then went to the download page for cfengine:
> 
>  https://cfengine.com/product/cfengine-enterprise-free-25/
> 
> .. but can't quite find the corresponding file! There is a tarball
> labelled "masterfiles" but I think that is something different.

Yes, their whole download/releases page is basically another bug
(regarding the debian/watch file:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873698). You can find
the link on https://cfengine.com/product/community/ (given a browser
that does JavaScript).

Incidentally, I stumbled upon this issue in diffoscope when I wanted to
point out the differences between these two tarballs in my response to
Christoph at Message #20 in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873698#20 .

Best regards,
-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF
<>

Bug#873698: Proposal for a working watch file

[Moritz Schlarb]

Hi Christoph,

On 28.11.2017 11:02, Christoph Martin wrote:
> Hi Moritz,
> 
> if the files are on github you can easily use the following lines:

The problem is that the Github "releases" are actually just plain Git
tags so the downloadable archives that Github offers are just snapshots
of the Git repository at the point of these tags.

Their content differs from the actual "source code release tarballs" -
e.g. not having run autogen.

Regards,
-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF
<>

signature.asc
Description: OpenPGP digital signature

Bug#873698: Proposal for a working watch file

[Moritz Schlarb]

Hi everyone,

I fiddled around with the CFEngine releases page and gave up on trying
to parse the nested JSON stuff because it doesn't seem to be possible
anyway, but I resorted to the releases page on GitHub to get release
version numbers and then mangling the download URL to their S3 bucket
that stores the final release tarballs:

> version=4
> opts=downloadurlmangle=s%https://github.com/cfengine/core/archive/(@ANY_VERSION@@ARCHIVE_EXT@)%https://cfengine-package-repos.s3.amazonaws.com/tarballs/cfengine-$1%
>  \
> https://github.com/cfengine/core/releases .*/([\.\d]+)@ARCHIVE_EXT@
> opts=component=masterfiles,downloadurlmangle=s%https://github.com/cfengine/core/archive/(@ANY_VERSION@@ARCHIVE_EXT@)%https://cfengine-package-repos.s3.amazonaws.com/tarballs/cfengine-masterfiles-$1%
>  \
> https://github.com/cfengine/core/releases .*/([\.\d]+)@ARCHIVE_EXT@

Now this *works*, but it doesn't really look and feel very elegant...

Regards,
-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF
version=4
opts=downloadurlmangle=s%https://github.com/cfengine/core/archive/(@ANY_VERSION@@ARCHIVE_EXT@)%https://cfengine-package-repos.s3.amazonaws.com/tarballs/cfengine-$1%
 \
https://github.com/cfengine/core/releases .*/([\.\d]+)@ARCHIVE_EXT@
opts=component=masterfiles,downloadurlmangle=s%https://github.com/cfengine/core/archive/(@ANY_VERSION@@ARCHIVE_EXT@)%https://cfengine-package-repos.s3.amazonaws.com/tarballs/cfengine-masterfiles-$1%
 \
https://github.com/cfengine/core/releases .*/([\.\d]+)@ARCHIVE_EXT@
<>

Bug#859716: Patch from upstream commit

[Moritz Schlarb]

Upstream has just committed the following, which we could probably use
as a patch in the meantime:

> From 3a547b8ab392e0419488eb4aa633f9b31f0ccaf4 Mon Sep 17 00:00:00 2001
> From: Jonathan Xu <jonathan...@seafile.com>
> Date: Tue, 21 Nov 2017 19:56:31 +0800
> Subject: [PATCH] Replace deprecated generate_rsa_key() with
>  generate_rsa_key_ex().
> 
> ---
>  src/utils/rsa.cpp | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/src/utils/rsa.cpp b/src/utils/rsa.cpp
> index 4f923add0..cbaefbe11 100644
> --- a/src/utils/rsa.cpp
> +++ b/src/utils/rsa.cpp
> @@ -177,8 +177,12 @@ id_from_pubkey (RSA *pubkey)
>  RSA *
>  generate_private_key(u_int bits)
>  {
> - RSA *priv = NULL;
> +RSA *priv = RSA_new ();
> +BIGNUM *e = BN_new ();
>  
> - priv = RSA_generate_key(bits, 35, NULL, NULL);
> - return priv;
> +BN_set_word (e, 35);
> +RSA_generate_key_ex (priv, bits, e, NULL);
> +
> +BN_free (e);
> +return priv;
>  }
> 

Best regards,

-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF
>From 3a547b8ab392e0419488eb4aa633f9b31f0ccaf4 Mon Sep 17 00:00:00 2001
From: Jonathan Xu <jonathan...@seafile.com>
Date: Tue, 21 Nov 2017 19:56:31 +0800
Subject: [PATCH] Replace deprecated generate_rsa_key() with
 generate_rsa_key_ex().

---
 src/utils/rsa.cpp | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/utils/rsa.cpp b/src/utils/rsa.cpp
index 4f923add0..cbaefbe11 100644
--- a/src/utils/rsa.cpp
+++ b/src/utils/rsa.cpp
@@ -177,8 +177,12 @@ id_from_pubkey (RSA *pubkey)
 RSA *
 generate_private_key(u_int bits)
 {
-	RSA *priv = NULL;
+RSA *priv = RSA_new ();
+BIGNUM *e = BN_new ();
 
-	priv = RSA_generate_key(bits, 35, NULL, NULL);
-	return priv;
+BN_set_word (e, 35);
+RSA_generate_key_ex (priv, bits, e, NULL);
+
+BN_free (e);
+return priv;
 }
<>

Bug#869939: [Hyper-V] Feature request: pick up PTP Hyper-V timesync source from upstream 4.12

[Moritz Schlarb]

Control: found -1 linux/4.9.30-2
Control: found 85 linux/4.9.30-2
Control: block 85 by -1

I want to heavily second this request!
In stretch-backports, we have 4.12 now, but as we are having quite a lot
of Jessie machines, we are hoping for a solution for jessie, too (even
if it were having 4.12 in jessie-backports-sloppy).

FWIW, here is the same request from Josh in Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1676635
and that had already been closed some time ago.

ATM, Debian is not listed as supporting "Windows Server 2016 Accurate
Time" on
https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/supported-debian-virtual-machines-on-hyper-v,
whereas Ubuntu is on
https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/supported-ubuntu-virtual-machines-on-hyper-v

Hope there's something that can be done here ;-)

-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-331 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF
<>

Bug#873700: cfengine3: include stuff from contrib/ in upstream git

[Moritz Schlarb]

Package: cfengine3
Version: 3.6.2-4
Severity: wishlist

In the upstream git repository, the contrib/ directory contains some nicities
like code style configuration files for different editors and a script
reindent.pl for automatically formatting CFEngine policy files:
https://github.com/cfengine/core/tree/3.9.x/contrib

I think it would be nice to package them in any way.
But apparently, even upstream doesn't include the contrib/ directory at all in
their source and binary tarballs...



-- System Information:
Debian Release: 8.9
  APT prefers oldstable-updates
  APT policy: (700, 'oldstable-updates'), (700, 'oldstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-0.bpo.3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cfengine3 depends on:
ii  libacl1   2.2.52-2
ii  libc6 2.19-18+deb8u10
ii  liblmdb0  0.9.14-1
ii  libmysqlclient18  5.5.57-0+deb8u1
ii  libpam0g  1.1.8-3.1+deb8u2+b1
ii  libpcre3  2:8.35-3.3+deb8u4
ii  libpq59.4.13-0+deb8u1
ii  libpromises3  3.6.2-4
ii  libssl1.0.0   1.0.2l-1~bpo8+1
ii  libvirt0  3.0.0-4~bpo8+1
ii  libxml2   2.9.1+dfsg1-5+deb8u5

cfengine3 recommends no packages.

cfengine3 suggests no packages.

-- Configuration Files:
/etc/default/cfengine3 changed [not included]

-- debconf-show failed

Bug#873699: cfengine3: use upstream configure support for FHS file layout

[Moritz Schlarb]

Package: cfengine3
Version: 3.6.2-4
Severity: wishlist

I just discovered that upstream has support for using the FHS filesystem layout
in their build systems:
https://anonscm.debian.org/cgit/collab-maint/cfengine3.git/tree/INSTALL#n95
Therefore, I think we should try to use it instead of setting these paths on
our own.



-- System Information:
Debian Release: 8.9
  APT prefers oldstable-updates
  APT policy: (700, 'oldstable-updates'), (700, 'oldstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-0.bpo.3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cfengine3 depends on:
ii  libacl1   2.2.52-2
ii  libc6 2.19-18+deb8u10
ii  liblmdb0  0.9.14-1
ii  libmysqlclient18  5.5.57-0+deb8u1
ii  libpam0g  1.1.8-3.1+deb8u2+b1
ii  libpcre3  2:8.35-3.3+deb8u4
ii  libpq59.4.13-0+deb8u1
ii  libpromises3  3.6.2-4
ii  libssl1.0.0   1.0.2l-1~bpo8+1
ii  libvirt0  3.0.0-4~bpo8+1
ii  libxml2   2.9.1+dfsg1-5+deb8u5

cfengine3 recommends no packages.

cfengine3 suggests no packages.

-- Configuration Files:
/etc/default/cfengine3 changed [not included]

-- debconf-show failed

Bug#873698: cfengine3: debian/watch is not working anymore

[Moritz Schlarb]

Package: cfengine3
Version: 3.6.2-4
Severity: minor

The releases page of CFEngine upstream is not a static HTML site anymore that
can be easily parsed by uscan.

The site (https://cfengine.com/product/community/) now loads various JSON files
(https://cfengine.com/release-data/community/releases.json,
https://cfengine.com/release-data/community/3.10.2.json, ...) that contain the
actual information about release versions and respective downloads.
In principle, it is quite nice that they try to give out this information in a
well defined, machine readable format, but I suppose it is a little bit of work
to get uscan to understand it.
I don't know when I have time to investigate it further, therefore I am
reporting my findings here.



-- System Information:
Debian Release: 8.9
  APT prefers oldstable-updates
  APT policy: (700, 'oldstable-updates'), (700, 'oldstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-0.bpo.3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cfengine3 depends on:
ii  libacl1   2.2.52-2
ii  libc6 2.19-18+deb8u10
ii  liblmdb0  0.9.14-1
ii  libmysqlclient18  5.5.57-0+deb8u1
ii  libpam0g  1.1.8-3.1+deb8u2+b1
ii  libpcre3  2:8.35-3.3+deb8u4
ii  libpq59.4.13-0+deb8u1
ii  libpromises3  3.6.2-4
ii  libssl1.0.0   1.0.2l-1~bpo8+1
ii  libvirt0  3.0.0-4~bpo8+1
ii  libxml2   2.9.1+dfsg1-5+deb8u5

cfengine3 recommends no packages.

cfengine3 suggests no packages.

-- Configuration Files:
/etc/default/cfengine3 changed [not included]

-- debconf-show failed

Bug#873482: makedumpfile from jessie-backports does not work with linux-image-amd64 from jessie-backports

[Moritz Schlarb]

Package: makedumpfile
Version: 1:1.5.9-3~bpo8+1
Severity: important

Dear Maintainer,

I have installed linux-image-amd64 and makedumpfile (and k{dump,exec}-tools
from jessie-backports, and it seems that makedumpfile has a hardcoded upper
limit on the kernel version it supports (4.8.1 [1]).
Since the kernel version actually in backports is greater, makedumpfile
will always say "the kernel version is not supported" and not do anything.

[1]:
https://anonscm.debian.org/cgit/collab-maint/makedumpfile.git/tree/makedumpfile.h#n475

Thanks,
Moritz

-- System Information:
Debian Release: 8.9
  APT prefers oldstable-updates
  APT policy: (700, 'oldstable-updates'), (700, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-0.bpo.3-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages makedumpfile depends on:
ii  libbz2-1.0  1.0.6-7+b3
ii  libc6   2.19-18+deb8u10
ii  libdw1  0.159-4.2
ii  libelf1 0.159-4.2
ii  perl5.20.2-3+deb8u8
ii  zlib1g  1:1.2.8.dfsg-2+b1

Versions of packages makedumpfile recommends:
ii  crash7.1.8-1~bpo8+1
ii  kexec-tools  1:2.0.10-2~bpo8+1

makedumpfile suggests no packages.

-- no debconf information

-- 
Moritz Schlarb
Unix-Gruppe | Systembetreuung
Zentrum für Datenverarbeitung
Johannes Gutenberg-Universität Mainz
Raum 01-321 - Tel. +49 6131 39-29441
OpenPGP Fingerprint: DF01 2247 BFC6
5501 AFF2 8445 0C24 B841 C7DD BAAF
<>