Bug#1074019: bullseye-pu: package ngircd/26.1-1+deb11u1

[Christoph Biedl]

Package: release.debian.org
Severity: normal
Tags: bullseye
X-Debbugs-Cc: ngi...@packages.debian.org, debian.a...@manchmal.in-ulm.de
Control: affects -1 + src:ngircd
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
Fix one major and two more "Oh, that's not good" issues. It was agreed
upon with security team to handle them via SPU.

1. In a TLS-based server-server connection, the server certificate is
not validated.

github issue: https://github.com/ngircd/ngircd/issues/120

For reasons neither upstream or I understand, a CVE number request was rejected.

2. In a server-server connection, a connection may still use
plain text despite the connection ought to be TLS-based.

Fix: 
https://github.com/ngircd/ngircd/commit/21c1751b045b0be49e584a4ba191a330e0c381bb
Debian bug: https://bugs.debian.org/1067237

3. Some IRC services might send an empty string for the hostname to
implement the "uncloak host" functionality, leading to a protocol
violation in subsequent "WHOIS" or other commands against the ngircd
server.

Fix: 
https://github.com/ngircd/ngircd/commit/1118b0e77ca961a7b082f90cb124210eca8fb6bd

[ Impact ]
1. Server-server links are prone to MITM attacks even when using TLS.

2. Downgrade attacks.

3. Client confusion, possibly crash.

[ Tests ]
1. The unstable version of ngircd now has an autopkgtest for that
situation. For a test, it was manually backported, and it passed.
It's not included however to keep the change small.
2./3. No test in particular, but the change is small.

Also, a private IRC network using ngircd with Debian bookworm was
already upgraded in April, using a preliminary release. No technical
issues were found, only documentation needed a little clarification
(included).

[ Risks ]
1. This might break flawed configurations, most notably if the peer's
   certificate has expired and/or cannot be verified against the configured
   trust store. The ngircd.NEWS and ngircd.README.Debian files have been
   updated.
2./3. No risks are to be expected.

[ 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
  (27~rc1-1, 2024-04-13)

[ Changes ]
All the changes were cherry-pick from upstream.
1. Whopping 19 patches, prefixed "S2S-TLS"
2. patch Respect-SSLConnect-option
3. patch METADATA-Fix-unsetting-cloakhost

Also the mentioned changes to documentation in debian/


[ Other info ]
The same story will follow for bookworm in a moment. In fact,
bullseye and bookworm have the same version of ngircd at the moment.

Regards,

Christoph

diff -Nru ngircd-26.1/debian/changelog ngircd-26.1/debian/changelog
--- ngircd-26.1/debian/changelog2021-01-02 23:17:19.0 +0100
+++ ngircd-26.1/debian/changelog2024-05-01 11:00:00.0 +0200
@@ -1,3 +1,13 @@
+ngircd (26.1-1+deb11u1) bullseye; urgency=high
+
+  * Cherry-pick "Respect "SSLConnect" option for incoming
+connections". Closes: #1067237
+  * Cherry-pick "Support for server certificate validation on server
+links [S2S-TLS]"
+  * Cherry-pick "METADATA: Fix unsetting "cloakhost""
+
+ -- Christoph Biedl   Wed, 01 May 2024 
11:00:00 +0200
+
 ngircd (26.1-1) unstable; urgency=medium
 
   * New upstream version 26.1
diff -Nru ngircd-26.1/debian/ngircd.conf ngircd-26.1/debian/ngircd.conf
--- ngircd-26.1/debian/ngircd.conf  2021-01-02 23:17:19.0 +0100
+++ ngircd-26.1/debian/ngircd.conf  2024-05-01 11:00:00.0 +0200
@@ -273,6 +273,14 @@
# is only available when ngIRCd is compiled with support for SSL!
# So don't forget to remove the ";" above if this is the case ...
 
+   # SSL Trusted CA Certificates File for verifying peer certificates.
+   # (Default: not set; so no certificates are trusted)
+   ;CAFile = /etc/ssl/certs/ca-certificates.crt
+
+   # Certificate Revocation File (for marking otherwise valid
+   # certficates as invalid)
+   ;CRLFile = /etc/ssl/CA/crl.pem
+
# SSL Server Key Certificate
;CertFile = /etc/ssl/certs/server.crt
 
@@ -366,6 +374,10 @@
# Connect to the remote server using TLS/SSL (Default: false)
;SSLConnect = yes
 
+   # Verify the TLS certificate presented by the remote server
+   # (Default: yes)
+   ;SSLVerify = yes
+
# Define a (case insensitive) list of masks matching nicknames that
# should be treated as IRC services when introduced via this remote
# server, separated by commas (",").
diff -Nru ngircd-26.1/debian/ngircd.NEWS ngircd-26.1/debian/ngircd.NEWS
--- ngircd-26.1/debian/ngircd.NEWS  1970-01-01 01:00:00.0 +0100
+++ ngircd-26.1/debian/ngircd.NEWS  2024-05-01 11:00:00.0 +0200
@@ -0,0 +1,8 @@
+ngircd (26.1-1+deb11u1) bullseye; urgency=h

Bug#1074018: bookworm-pu: package ngircd/26.1-1+deb12u1

[Christoph Biedl]

Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: ngi...@packages.debian.org, debian.a...@manchmal.in-ulm.de
Control: affects -1 + src:ngircd
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
Fix one major and two more "Oh, that's not good" issues. It was agreed
upon with security team to handle them via SPU.

1. In a TLS-based server-server connection, the server certificate is
not validated.

github issue: https://github.com/ngircd/ngircd/issues/120

For reasons neither upstream or I understand, a CVE number request was rejected.

2. In a server-server connection, a connection may still use
plain text despite the connection ought to be TLS-based.

Fix: 
https://github.com/ngircd/ngircd/commit/21c1751b045b0be49e584a4ba191a330e0c381bb
Debian bug: https://bugs.debian.org/1067237

3. Some IRC services might send an empty string for the hostname to
implement the "uncloak host" functionality, leading to a protocol
violation in subsequent "WHOIS" or other commands against the ngircd
server.

Fix: 
https://github.com/ngircd/ngircd/commit/1118b0e77ca961a7b082f90cb124210eca8fb6bd

[ Impact ]
1. Server-server links are prone to MITM attacks even when using TLS.

2. Downgrade attacks.

3. Client confusion, possibly crash.

[ Tests ]
1. The unstable version of ngircd now has an autopkgtest for that
situation. For a test, it was manually backported, and it passed.
It's not included however to keep the change small.
2./3. No test in particular, but the change is small.

Also, a private IRC network using ngircd with Debian bookworm was
already upgraded in April, using a preliminary release. No technical
issues were found, only documentation needed a little clarification
(included).

[ Risks ]
1. This might break flawed configurations, most notably if the peer's
   certificate has expired and/or cannot be verified against the configured
   trust store. The ngircd.NEWS and ngircd.README.Debian files have been
   updated.
2./3. No risks are to be expected.

[ 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
  (27~rc1-1, 2024-04-13)

[ Changes ]
All the changes were cherry-pick from upstream.
1. Whopping 19 patches, prefixed "S2S-TLS"
2. patch Respect-SSLConnect-option
3. patch METADATA-Fix-unsetting-cloakhost

Also the mentioned changes to documentation in debian/


[ Other info ]
n/a

Regards,

Christoph

diff -Nru ngircd-26.1/debian/changelog ngircd-26.1/debian/changelog
--- ngircd-26.1/debian/changelog2021-01-02 23:17:19.0 +0100
+++ ngircd-26.1/debian/changelog2024-05-01 12:00:00.0 +0200
@@ -1,3 +1,13 @@
+ngircd (26.1-1+deb12u1) bookworm; urgency=high
+
+  * Cherry-pick "Respect "SSLConnect" option for incoming
+connections". Closes: #1067237
+  * Cherry-pick "Support for server certificate validation on server
+links [S2S-TLS]"
+  * Cherry-pick "METADATA: Fix unsetting "cloakhost""
+
+ -- Christoph Biedl   Wed, 01 May 2024 
12:00:00 +0200
+
 ngircd (26.1-1) unstable; urgency=medium
 
   * New upstream version 26.1
diff -Nru ngircd-26.1/debian/ngircd.conf ngircd-26.1/debian/ngircd.conf
--- ngircd-26.1/debian/ngircd.conf  2021-01-02 23:17:19.0 +0100
+++ ngircd-26.1/debian/ngircd.conf  2024-05-01 12:00:00.0 +0200
@@ -273,6 +273,14 @@
# is only available when ngIRCd is compiled with support for SSL!
# So don't forget to remove the ";" above if this is the case ...
 
+   # SSL Trusted CA Certificates File for verifying peer certificates.
+   # (Default: not set; so no certificates are trusted)
+   ;CAFile = /etc/ssl/certs/ca-certificates.crt
+
+   # Certificate Revocation File (for marking otherwise valid
+   # certficates as invalid)
+   ;CRLFile = /etc/ssl/CA/crl.pem
+
# SSL Server Key Certificate
;CertFile = /etc/ssl/certs/server.crt
 
@@ -366,6 +374,10 @@
# Connect to the remote server using TLS/SSL (Default: false)
;SSLConnect = yes
 
+   # Verify the TLS certificate presented by the remote server
+   # (Default: yes)
+   ;SSLVerify = yes
+
# Define a (case insensitive) list of masks matching nicknames that
# should be treated as IRC services when introduced via this remote
# server, separated by commas (",").
diff -Nru ngircd-26.1/debian/ngircd.NEWS ngircd-26.1/debian/ngircd.NEWS
--- ngircd-26.1/debian/ngircd.NEWS  1970-01-01 01:00:00.0 +0100
+++ ngircd-26.1/debian/ngircd.NEWS  2024-05-01 12:00:00.0 +0200
@@ -0,0 +1,8 @@
+ngircd (26.1-1+deb12u1) bookworm; urgency=high
+
+  * This version introduces x509 certificate validation on TLS-based
+server-server links. Existing configurations will likel

Bug#1073967: bookworm-pu: package jose/11-2+deb12u1

[Christoph Biedl]

Christoph Biedl wrote...

>   [x] attach debdiff against the package in (old)stable

Now for real.
diff -Nru jose-11/debian/changelog jose-11/debian/changelog
--- jose-11/debian/changelog2021-12-01 20:33:13.0 +0100
+++ jose-11/debian/changelog2024-04-04 15:11:36.0 +0200
@@ -1,3 +1,10 @@
+jose (11-2+deb12u1) bookworm; urgency=high
+
+  * Cherry-pick "Fix potential DoS issue with p2c header". Closes:
+#1067457 [CVE-2023-50967]
+
+ -- Christoph Biedl   Thu, 04 Apr 2024 
18:12:00 +0200
+
 jose (11-2) unstable; urgency=medium
 
   * Replace usage of which(1)
diff -Nru 
jose-11/debian/patches/1711969854.v12-3-g4ee7708.fix-potential-dos-issue-with-p2c-header.patch
 
jose-11/debian/patches/1711969854.v12-3-g4ee7708.fix-potential-dos-issue-with-p2c-header.patch
--- 
jose-11/debian/patches/1711969854.v12-3-g4ee7708.fix-potential-dos-issue-with-p2c-header.patch
  1970-01-01 01:00:00.0 +0100
+++ 
jose-11/debian/patches/1711969854.v12-3-g4ee7708.fix-potential-dos-issue-with-p2c-header.patch
  2024-04-04 12:36:46.0 +0200
@@ -0,0 +1,85 @@
+Subject: Fix potential DoS issue with p2c header
+ID: CVE-2023-50967
+Origin: v12-3-g4ee7708 <https://github.com/latchset/jose/commit/v12-3-g4ee7708>
+Upstream-Author: Sergio Correia 
+Date: Mon Apr 1 12:10:54 2024 +0100
+
+Unbounded p2c headers may be used to cause an application that accept
+PBES algorithms to spend a lot of resources running PBKDF2 with a very
+high number of iterations.
+
+Limit the maximum number of iterations to to 32768.
+
+Fixes: CVE-2023-50967
+
+Signed-off-by: Sergio Correia 
+
+--- a/lib/openssl/pbes2.c
 b/lib/openssl/pbes2.c
+@@ -25,6 +25,8 @@
+ #include 
+ 
+ #define NAMES "PBES2-HS256+A128KW", "PBES2-HS384+A192KW", "PBES2-HS512+A256KW"
++#define P2C_MIN_ITERATIONS 1000
++#define P2C_MAX_ITERATIONS 32768
+ 
+ static json_t *
+ pbkdf2(const char *alg, jose_cfg_t *cfg, const json_t *jwk, int iter,
+@@ -193,7 +195,7 @@
+ json_auto_t *hdr = NULL;
+ const char *aes = NULL;
+ json_t *h = NULL;
+-int p2c = 1;
++int p2c = P2C_MAX_ITERATIONS;
+ size_t stl = 0;
+ 
+ if (!json_object_get(cek, "k") && !jose_jwk_gen(cfg, cek))
+@@ -226,7 +228,7 @@
+ json_object_set_new(h, "p2c", json_integer(p2c)) < 0)
+ return false;
+ 
+-if (p2c < 1000)
++if (p2c < P2C_MIN_ITERATIONS || p2c > P2C_MAX_ITERATIONS)
+ return false;
+ 
+ if (json_object_set_new(h, "p2s", jose_b64_enc(st, stl)) == -1)
+@@ -268,6 +270,9 @@
+ if (json_unpack(hdr, "{s:I}", "p2c", ) == -1)
+ return false;
+ 
++if (p2c > P2C_MAX_ITERATIONS)
++return false;
++
+ stl = jose_b64_dec(json_object_get(hdr, "p2s"), NULL, 0);
+ if (stl < 8 || stl > sizeof(st))
+ return false;
+--- /dev/null
 b/tests/cve-2023-50967/cve-2023-50967.jwe
+@@ -0,0 +1 @@
++{"ciphertext":"aaPb-JYGACs-loPwJkZewg","encrypted_key":"P1h8q8wLVxqYsZUuw6iEQTzgXVZHCsu8Eik-oqbE4AJGIDto3gb3SA","header":{"alg":"PBES2-HS256+A128KW","p2c":10,"p2s":"qUQQWWkyyIqculSiC93mlg"},"iv":"Clg3JX9oNl_ck3sLSGrlgg","protected":"eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0","tag":"i7vga9tJkwRswFd7HlyD_A"}
+--- /dev/null
 b/tests/cve-2023-50967/cve-2023-50967.jwk
+@@ -0,0 +1 @@
++{"alg":"PBES2-HS256+A128KW","k":"VHBLJ4-PmnqELoKbQoXuRA","key_ops":["wrapKey","unwrapKey"],"kty":"oct"}
+--- a/tests/jose-jwe-dec
 b/tests/jose-jwe-dec
+@@ -53,3 +53,8 @@
+ test "`jose jwe dec -i $prfx.13.jweg -k $prfx.13.1.jwk`" = "`cat $prfx.13.pt`"
+ test "`jose jwe dec -i $prfx.13.jweg -k $prfx.13.2.jwk`" = "`cat $prfx.13.pt`"
+ test "`jose jwe dec -i $prfx.13.jweg -k $prfx.13.3.jwk`" = "`cat $prfx.13.pt`"
++
++# CVE-2023-50967 - test originally from 
https://github.com/P3ngu1nW/CVE_Request/blob/main/latch-jose.md
++# This test is expected to fail quickly on patched systems.
++prfx="${CVE_2023_50967}/cve-2023-50967"
++! test "$(jose jwe dec -i $prfx.jwe -k $prfx.jwk)"
+--- a/tests/meson.build
 b/tests/meson.build
+@@ -31,6 +31,8 @@
+ e = environment()
+ e.prepend('PATH', meson.current_build_dir() + '/../cmd', separator: ':')
+ e.set('VECTORS', meson.current_source_dir() + '/vectors')
++e.set('CVE_2023_50967', meson.current_source_dir() + '/cve-2023-50967')
++
+ 
+ foreach p: progs
+   exe = executable(p, p + '.c', dependencies: jansson, link_with: libjose)
diff -Nru jose-11/debian/patches/series jose-11/debian/patches/series
--- jose-11/debian/patches/series   2021-12-01 19:56:42.0 +0100
+++ jose-11/debian/patches/series   2024-04-04 12:32:29.0 +0200
@@ -1,5 +1,6 @@
 
 # cherry-picked commits. Keep in upstream's chronological order
+1711969854.v12-3-g4ee7708.fix-potential-dos-issue-with-p2c-header.patch
 
 # patches for upstream
 for-upstream/2021-12-01.replace-usage-of-which.patch


signature.asc
Description: PGP signature

Bug#1073966: bullseye-pu: package jose/10-3+deb11u1

[Christoph Biedl]

Christoph Biedl wrote...

>   [x] attach debdiff against the package in (old)stable
diff -Nru jose-10/debian/changelog jose-10/debian/changelog
--- jose-10/debian/changelog2020-05-25 22:11:30.0 +0200
+++ jose-10/debian/changelog2024-04-04 15:54:12.0 +0200
@@ -1,3 +1,10 @@
+jose (10-3+deb11u1) bullseye; urgency=high
+
+  * Cherry-pick "Fix potential DoS issue with p2c header". Closes:
+#1067457 [CVE-2023-50967]
+
+ -- Christoph Biedl   Thu, 04 Apr 2024 
18:11:00 +0200
+
 jose (10-3) unstable; urgency=medium
 
   * Cherry-pick commits:
diff -Nru 
jose-10/debian/patches/1711969854.v12-3-g4ee7708.fix-potential-dos-issue-with-p2c-header.patch
 
jose-10/debian/patches/1711969854.v12-3-g4ee7708.fix-potential-dos-issue-with-p2c-header.patch
--- 
jose-10/debian/patches/1711969854.v12-3-g4ee7708.fix-potential-dos-issue-with-p2c-header.patch
  1970-01-01 01:00:00.0 +0100
+++ 
jose-10/debian/patches/1711969854.v12-3-g4ee7708.fix-potential-dos-issue-with-p2c-header.patch
  2024-04-04 13:50:48.0 +0200
@@ -0,0 +1,86 @@
+Subject: Fix potential DoS issue with p2c header
+ID: CVE-2023-50967
+Origin: v12-3-g4ee7708 <https://github.com/latchset/jose/commit/v12-3-g4ee7708>
+Upstream-Author: Sergio Correia 
+Date: Mon Apr 1 12:10:54 2024 +0100
+
+Unbounded p2c headers may be used to cause an application that accept
+PBES algorithms to spend a lot of resources running PBKDF2 with a very
+high number of iterations.
+
+Limit the maximum number of iterations to to 32768.
+
+Fixes: CVE-2023-50967
+
+Signed-off-by: Sergio Correia 
+
+--- a/lib/openssl/pbes2.c
 b/lib/openssl/pbes2.c
+@@ -25,6 +25,8 @@
+ #include 
+ 
+ #define NAMES "PBES2-HS256+A128KW", "PBES2-HS384+A192KW", "PBES2-HS512+A256KW"
++#define P2C_MIN_ITERATIONS 1000
++#define P2C_MAX_ITERATIONS 32768
+ 
+ static json_t *
+ pbkdf2(const char *alg, jose_cfg_t *cfg, const json_t *jwk, int iter,
+@@ -170,7 +172,7 @@
+ json_auto_t *hdr = NULL;
+ const char *aes = NULL;
+ json_t *h = NULL;
+-int p2c = 1;
++int p2c = P2C_MAX_ITERATIONS;
+ size_t stl = 0;
+ 
+ if (!json_object_get(cek, "k") && !jose_jwk_gen(cfg, cek))
+@@ -203,7 +205,7 @@
+ json_object_set_new(h, "p2c", json_integer(p2c)) < 0)
+ return false;
+ 
+-if (p2c < 1000)
++if (p2c < P2C_MIN_ITERATIONS || p2c > P2C_MAX_ITERATIONS)
+ return false;
+ 
+ if (json_object_set_new(h, "p2s", jose_b64_enc(st, stl)) == -1)
+@@ -245,6 +247,9 @@
+ if (json_unpack(hdr, "{s:I}", "p2c", ) == -1)
+ return false;
+ 
++if (p2c > P2C_MAX_ITERATIONS)
++return false;
++
+ stl = jose_b64_dec(json_object_get(hdr, "p2s"), NULL, 0);
+ if (stl < 8 || stl > sizeof(st))
+ return false;
+--- /dev/null
 b/tests/cve-2023-50967/cve-2023-50967.jwe
+@@ -0,0 +1 @@
++{"ciphertext":"aaPb-JYGACs-loPwJkZewg","encrypted_key":"P1h8q8wLVxqYsZUuw6iEQTzgXVZHCsu8Eik-oqbE4AJGIDto3gb3SA","header":{"alg":"PBES2-HS256+A128KW","p2c":10,"p2s":"qUQQWWkyyIqculSiC93mlg"},"iv":"Clg3JX9oNl_ck3sLSGrlgg","protected":"eyJlbmMiOiJBMTI4Q0JDLUhTMjU2In0","tag":"i7vga9tJkwRswFd7HlyD_A"}
+--- /dev/null
 b/tests/cve-2023-50967/cve-2023-50967.jwk
+@@ -0,0 +1 @@
++{"alg":"PBES2-HS256+A128KW","k":"VHBLJ4-PmnqELoKbQoXuRA","key_ops":["wrapKey","unwrapKey"],"kty":"oct"}
+--- a/tests/jose-jwe-dec
 b/tests/jose-jwe-dec
+@@ -53,3 +53,8 @@
+ test "`jose jwe dec -i $prfx.13.jweg -k $prfx.13.1.jwk`" == "`cat 
$prfx.13.pt`"
+ test "`jose jwe dec -i $prfx.13.jweg -k $prfx.13.2.jwk`" == "`cat 
$prfx.13.pt`"
+ test "`jose jwe dec -i $prfx.13.jweg -k $prfx.13.3.jwk`" == "`cat 
$prfx.13.pt`"
++
++# CVE-2023-50967 - test originally from 
https://github.com/P3ngu1nW/CVE_Request/blob/main/latch-jose.md
++# This test is expected to fail quickly on patched systems.
++prfx="${CVE_2023_50967}/cve-2023-50967"
++! test "$(jose jwe dec -i $prfx.jwe -k $prfx.jwk)"
+--- a/tests/Makefile.am
 b/tests/Makefile.am
+@@ -2,7 +2,8 @@
+ LDFLAGS += $(top_builddir)/lib/libjose.la @jansson_LIBS@
+ EXTRA_DIST = vectors
+ 
+-AM_TESTS_ENVIRONMENT=PATH=$(top_builddir)/cmd:$(PATH) 
VECTORS=$(top_srcdir)/tests/vectors
++AM_TESTS_ENVIRONMENT=PATH=$(top_builddir)/cmd:$(PATH) 
VECTORS=$(top_srcdir)/tests/vectors 
CVE_2023_50967=$(top_srcdir)/tests/cve-2023-50967
++
+ TESTS = $(dist_check_SCRIPTS) $(check_PROGRAMS)
+ 
+ check_PROGRAMS = \
diff -Nru jose-10/debian/patches/series jose-10/debian/patches/series
--- jose-10/debian/patches/series   2020-05-25 22:

Bug#1073967: bookworm-pu: package jose/11-2+deb12u1

[Christoph Biedl]

Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: j...@packages.debian.org, debian.a...@manchmal.in-ulm.de
Control: affects -1 + src:jose
User: release.debian@packages.debian.org
Usertags: pu

[ Note: Same text as for the bullseye upload ]

[ Reason ]
"Fix potential DoS issue with p2c header" [CVE-2023-50967]

[ Impact ]
Users become susceptible for a DoS attack.

[ Tests ]
Upstream enhanced the test suite accordingly, this is included
in this upload.

[ Risks ]
The fix is rather simple so there shouldn't be any risks.

[ 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 (13-1, uploaded 2024-04-04)

[ Changes ]
Just cherry-pick the fix from upstream. The DEP-3 header has all
the details.

[ Other info ]
Fix via SPU after coordination with the Debian security team.

Regards,

Christoph



signature.asc
Description: PGP signature

Bug#1073966: bullseye-pu: package jose/10-3+deb11u1

[Christoph Biedl]

Package: release.debian.org
Severity: normal
Tags: bullseye
X-Debbugs-Cc: j...@packages.debian.org, debian.a...@manchmal.in-ulm.de
Control: affects -1 + src:jose
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
"Fix potential DoS issue with p2c header" [CVE-2023-50967]

[ Impact ]
Users become susceptible for a DoS attack.

[ Tests ]
Upstream enhanced the test suite accordingly, this is included
in this upload.

[ Risks ]
The fix is rather simple so there shouldn't be any risks.

[ 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 (13-1, uploaded 2024-04-04)

[ Changes ]
Just cherry-pick the fix from upstream. The DEP-3 header has all
the details.

[ Other info ]
Fix via SPU after coordination with the Debian security team.

Regards,

Christoph

PS: Version numbers might be confusing. This is fixing jose 10 in
Debian 11 - fixing jose 11 in Debian 12 will follow in a moment ...



signature.asc
Description: PGP signature

Re: What to do with d-i on armel?

[Christoph Biedl]

Emanuele Rocca wrote...

> Any armel users out there? :-)

Fairly late, but just to avoid the impression there aren't any left:
Yes, here.

But that's not an objection against plans in Debian kernel and/or d-i,
I'm using my own kernel, and should I ever have the need of a new
installation, I know how to debootstrap and the rest.

Besides, the hardware is a Seagate DockStar, so

Architecture:   armv5tel
  Byte Order:   Little Endian
CPU(s): 1
  On-line CPU(s) list:  0
Vendor ID:  Marvell
  Model name:   Feroceon-88FR131

and 128 Mbytes of RAM. Running Debian stable already requires some hacks
to not end up in thrashing, I might do a presentation "Running Debian on
small systems" some day about it.

In summary, I'm glad Debian keeps supporting this device - but I'm
aware the good times are in the past and it will very likely become
e-waste before the hardware dies. If not Debian ends the support, the
Linux kernel will.

Christoph


signature.asc
Description: PGP signature

Bug#1040668: bullseye-pu: package tang/8-3+deb11u1

[Christoph Biedl]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: t...@packages.debian.org
Control: affects -1 + src:tang

This is the bullseye version of #1040646

[ Reason ]
Fix https://security-tracker.debian.org/tracker/CVE-2023-1672 for
Debian 11 ("bullseye"), tagged "no-dsa (minor)" by the security team.

The problem of creating key material without restrictive file
permissions probably existed upstream since always. Up to and including
Debian 10 ("buster") however, this situation was caught by enforcing
restrictive permissions on the key directory.

With Debian 11 ("bullseye") a change in the creation of that directory
caused it to be created with a too permissive mode.

[ Impact ]
Without the change being accepted, the directory that holds the private
key would stay world-readable. Also this would continue to put users at
risk who configured a different key directory but did not enforce
restrictive access permissions.

[ Tests ]
No automated tests I'm aware of. Of course I did a manual test, and the
outcome matched the expectations.

[ Risks ]
The changes are small and rather straight-forward. I'd be surprised if
they introduce problems.

[ 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 oldstable
  [x] the issue is verified as fixed in unstable (14.1)

[ Changes ]
* Assert restrictive permissions of the key directory in Debian's
  postinst.
  For regular users and new instaaltions.
* Upstream's change to create the key file with restrictive
  permissions.
  Mostly for users who configure a different key directory.
* Recommend a key rotation in setups where this seems wise, add
  some details in NEWS.Debian.
* Make the key rotation program executable as it should always
  have been.

Regards,

Christoph

diff -Nru tang-8/debian/changelog tang-8/debian/changelog
--- tang-8/debian/changelog 2021-12-16 20:47:10.0 +0100
+++ tang-8/debian/changelog 2023-07-08 12:41:29.0 +0200
@@ -1,3 +1,14 @@
+tang (8-3+deb11u2) bullseye; urgency=high
+
+  * Fix CVE-2023-1672:
+- Cherry-pick "Fix race condition when creating/rotating keys"
+- Assert restrictive permissions on tang's key directory
+In existing multi-user bullseye installations, rotating the keys
+is suggested.
+  * Make the tangd-rotate-keys program executable
+
+ -- Christoph Biedl   Sat, 08 Jul 2023 
12:41:29 +0200
+
 tang (8-3+deb11u1) bullseye-security; urgency=high
 
   * Fix data leak [CVE-2021-4076]
diff -Nru 
tang-8/debian/patches/bullseye/1686750800.v13-3-g8dbbed1.fix-race-condition-when-creating-rotating-keys-123.patch
 
tang-8/debian/patches/bullseye/1686750800.v13-3-g8dbbed1.fix-race-condition-when-creating-rotating-keys-123.patch
--- 
tang-8/debian/patches/bullseye/1686750800.v13-3-g8dbbed1.fix-race-condition-when-creating-rotating-keys-123.patch
   1970-01-01 01:00:00.0 +0100
+++ 
tang-8/debian/patches/bullseye/1686750800.v13-3-g8dbbed1.fix-race-condition-when-creating-rotating-keys-123.patch
   2023-07-08 12:41:29.0 +0200
@@ -0,0 +1,73 @@
+Subject: Fix race condition when creating/rotating keys (#123)
+Origin: v13-3-g8dbbed1 <https://github.com/latchset/tang/commit/v13-3-g8dbbed1>
+Upstream-Author: Sergio Correia 
+Date: Wed Jun 14 10:53:20 2023 -0300
+
+When we create/rotate keys using either the tangd-keygen and
+tangd-rotate-keys helpers, there is a small window between the
+keys being created and then the proper ownership permissions being
+set. This also happens when there are no keys and tang creates a
+pair of keys itself.
+
+In certain situations, such as the keys directory having wide open
+permissions, a user with local access could exploit this race
+condition and read the keys before they are set to more restrictive
+permissions.
+
+To prevent this issue, we now set the default umask to 0337 before
+creating the files, so that they are already created with restrictive
+permissions; afterwards, we set the proper ownership as usual.
+
+Issue reported by Brian McDermott of CENSUS labs.
+
+Fixes CVE-2023-1672
+
+
+Reviewed-by: Sergio Arroutbi 
+Signed-off-by: Sergio Correia 
+
+--- a/src/keys.c
 b/src/keys.c
+@@ -17,6 +17,7 @@
+  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
+  */
+ 
++#include 
+ #include 
+ #include 
+ #include 
+@@ -304,6 +305,9 @@
+ const char** hashes = supported_hashes();
+ const char* alg[] = {"ES512", "ECMR", NULL};
+ char path[PATH_MAX];
++
++/* Set default umask for file creation. */
++umask(0337);
+ for (int i = 0; alg[i] != NULL; i++) {
+ json_auto_t* jwk = jwk_generate(alg[i]);
+ if (!jwk) {
+--- a/src/tangd-keygen
 b/src/tangd-keygen
+@@ -27,6 +27,9 @

Bug#1040646: bookworm-pu: package tang/11-2

[Christoph Biedl]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: t...@packages.debian.org
Control: affects -1 + src:tang

[ Reason ]
Fix https://security-tracker.debian.org/tracker/CVE-2023-1672 for
Debian 12 ("bookworm"), tagged "no-dsa (minor)" by the security team.

The problem of creating key material without restrictive file
permissions probably existed upstream since always. Up to and including
Debian 10 ("buster") however, this situation was caught by enforcing
restrictive permissions on the key directory.

With Debian 11 ("bullseye") a change in the creation of that directory
caused it to be created with a too permissive mode. That will be
addressed in a separature upload that requires more testing.

For Debian 12 ("bookworm"), this request here, stricter permissions were
already implemented and they are enforced during upgrade, however with a
small window during installation of the package.

[ Impact ]
The small time window as mentioned above will stay. Also this would
continue to put users at risk who configured a different key directory
but did not enforce restrictive access permissions.

[ Tests ]
None that I'm aware of.

[ Risks ]
The changes are small and rather straight-forward. I'd be surprised if
they introduce problems.

[ 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 stable
  [x] the issue is verified as fixed in unstable (14.1)

[ Changes ]
* Assert restrictive permissions of the key directory in Debian's
  postinst.
  For regular users and new instaaltions.
* Upstream's change to create the key file with restrictive
  permissions.
  Mostly for users who configure a different key directory.

Regards,

Christoph

diff -Nru tang-11/debian/changelog tang-11/debian/changelog
--- tang-11/debian/changelog2022-10-15 15:00:56.0 +0200
+++ tang-11/debian/changelog2023-07-08 12:49:07.0 +0200
@@ -1,3 +1,11 @@
+tang (11-2+deb12u1) bookworm; urgency=medium
+
+  * Fix CVE-2023-1672. Closes: #1038119
+- Cherry-pick "Fix race condition when creating/rotating keys"
+- Assert restrictive permissions on tang's key directory
+
+ -- Christoph Biedl   Sat, 08 Jul 2023 
12:49:07 +0200
+
 tang (11-2) unstable; urgency=medium
 
   * Tighten access permissions of the key directory
diff -Nru 
tang-11/debian/patches/bookworm/1686750800.v13-3-g8dbbed1.fix-race-condition-when-creating-rotating-keys-123.patch
 
tang-11/debian/patches/bookworm/1686750800.v13-3-g8dbbed1.fix-race-condition-when-creating-rotating-keys-123.patch
--- 
tang-11/debian/patches/bookworm/1686750800.v13-3-g8dbbed1.fix-race-condition-when-creating-rotating-keys-123.patch
  1970-01-01 01:00:00.0 +0100
+++ 
tang-11/debian/patches/bookworm/1686750800.v13-3-g8dbbed1.fix-race-condition-when-creating-rotating-keys-123.patch
  2023-07-08 12:49:07.0 +0200
@@ -0,0 +1,66 @@
+Subject: Fix race condition when creating/rotating keys (#123)
+Origin: v13-3-g8dbbed1 <https://github.com/latchset/tang/commit/v13-3-g8dbbed1>
+Upstream-Author: Sergio Correia 
+Date: Wed Jun 14 10:53:20 2023 -0300
+
+When we create/rotate keys using either the tangd-keygen and
+tangd-rotate-keys helpers, there is a small window between the
+keys being created and then the proper ownership permissions being
+set. This also happens when there are no keys and tang creates a
+pair of keys itself.
+
+In certain situations, such as the keys directory having wide open
+permissions, a user with local access could exploit this race
+condition and read the keys before they are set to more restrictive
+permissions.
+
+To prevent this issue, we now set the default umask to 0337 before
+creating the files, so that they are already created with restrictive
+permissions; afterwards, we set the proper ownership as usual.
+
+Issue reported by Brian McDermott of CENSUS labs.
+
+Fixes CVE-2023-1672
+
+
+Reviewed-by: Sergio Arroutbi 
+Signed-off-by: Sergio Correia 
+
+--- a/src/keys.c
 b/src/keys.c
+@@ -307,6 +307,9 @@
+ {
+ const char* alg[] = {"ES512", "ECMR", NULL};
+ char path[PATH_MAX];
++
++/* Set default umask for file creation. */
++umask(0337);
+ for (int i = 0; alg[i] != NULL; i++) {
+ json_auto_t* jwk = jwk_generate(alg[i]);
+ if (!jwk) {
+--- a/src/tangd-keygen.in
 b/src/tangd-keygen.in
+@@ -38,6 +38,10 @@
+ [ $# -eq 3 ] && sig=$2 && exc=$3
+ 
+ THP_DEFAULT_HASH=S256 # SHA-256.
++
++# Set default umask for file creation.
++umask 0337
++
+ jwe=$(jose jwk gen -i '{"alg":"ES512"}')
+ [ -z "$sig" ] && sig=$(echo "$jwe" | jose jwk thp -i- -a 
"${THP_DEFAULT_HASH}")
+ echo "$jwe" > "

Bug#1027424: transition: libppd

[Christoph Biedl]

Paul Gevers wrote...

> On 31-12-2022 10:06, Christoph Biedl wrote:
>
> > So src:libppd has been renamed to src:libppd-legacy, and has entered
> > experimental yesterday. While doing so, I've fixed a longstanding
> > mismatch in the soname version, hence the new number libppd-legacy*1*.
>
> I'm wondering what this means for users of the library that don't have
> packages in the Debian archive. If some downstream (including the non
> publicly published ones) (build) depend on the old library, they suddenly
> get weird failures, right?

Correct.

Install-dependencies will fail for a missing libppd.so.1.0.1, just like
after any other transition (Till's libppd will use a different
soversion).

Build-dependencies will fail to build as the new libppd is not a drop-in
replacement. Till did some investigation in that direction, result boils
down to "Providing a compatability layer was possible but is some work",
while odds are low anyone will benefit from this, see below.

So, in the case of a failing re-build, users will need to learn about
the reason and how to deal with it. I've asked Till to embed an
according pointer in the packages' descriptions (debian/control) so
they'll have a clue.

However, I would be fairly surprised if that ever happens. This is very
old software and it is mostly unmaintained - last (legacy) libppd
upstream release was in 2005. Therefore I assume any third-party package
switched to something different in the meantime. I am not aware of any,
and a little research didn't show anything in that direction. Looking
for "libppd" usually just points to the new version, provided by
OpenPrinting.

Our alternative would have been to make the new libppd somehow fit
around the old one, stupid work, and with constant risk people will pick
the wrong one - something I consider way more likely to happen than
failing builds of some rather hypothetical third-party packages based
on legacy libppd.

> At the extreme bare minimum, this needs documentation in the release notes,
> but I wonder if we consider this enough.

Release notes will never hurt, thanks for reminding me about those. And
in the particular situation I'm confident this is enough. If you can
think of more safety nets I could provide, let me know.

Regards,

Christoph


signature.asc
Description: PGP signature

Bug#1027424: transition: libppd

[Christoph Biedl]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: lib...@packages.debian.org, Till Kamppeter 

Control: affects -1 + src:libppd

Greetings,

possible this is not a regular transition, but in exchange I guess it
should be pretty smooth and simple ...

So some background: There are major changes coming in the area of
printing using CUPS, driven by Till Kamppeter (Cc'd), and among other
things this will introduce a library "libppd" to interact with PPD
(PostScript Printer Description) files. That one however will clash with
an existing libppd, maintained by yours truly, and after some discussion
with Till we figured the sane way was to move that old library out of
the way, name-wise.

So src:libppd has been renamed to src:libppd-legacy, and has entered
experimental yesterday. While doing so, I've fixed a longstanding
mismatch in the soname version, hence the new number libppd-legacy*1*.


Now about the formal transition procedure: There is exactly one reverse
build-dependency, src:gpr, I've already filed #1027408 for the
required changes. Taking care of this is on my list.

That should be all - if you need more information, just let me know.

Kind regards,

Christoph

Ben file:

title = "libppd";
is_affected = .depends ~ "libppd0" | .depends ~ "libppd-legacy1";
is_good = .depends ~ "libppd-legacy1";
is_bad = .depends ~ "libppd0";



signature.asc
Description: PGP signature

Bug#1017502: bullseye-pu: package http-parser/2.9.4-4+deb11u1

[Christoph Biedl]

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

Hello stable release team,

for the next upcoming bullseye stable point release, I've just uploaded
src:http-parser ("parser for HTTP messages written in C") as version
2.9.4-4+deb11u1.

This fixes a "no-dsa" security issue.

* Handle duplicate "Transfer-Encoding" header properly

Type: upstream bug
Debian bug: https://bugs.debian.org/1016690
Security tracker: https://security-tracker.debian.org/tracker/CVE-2020-8287
Fixed in in unstable and testing in 2.9.4-5 around ten days ago.

Regards,

Christoph

diff -Nru http-parser-2.9.4/debian/changelog http-parser-2.9.4/debian/changelog
--- http-parser-2.9.4/debian/changelog  2021-01-02 17:07:49.0 +0100
+++ http-parser-2.9.4/debian/changelog  2022-08-05 20:33:28.0 +0200
@@ -1,3 +1,10 @@
+http-parser (2.9.4-4+deb11u1) bullseye; urgency=medium
+
+  * unset F_CHUNKED on new Transfer-Encoding.
+Closes: #1016690 [CVE-2020-8287]
+
+ -- Christoph Biedl   Fri, 05 Aug 2022 
20:33:28 +0200
+
 http-parser (2.9.4-4) unstable; urgency=medium
 
   * Packaging cleanup
diff -Nru http-parser-2.9.4/debian/patches/CVE-2020-8287.patch 
http-parser-2.9.4/debian/patches/CVE-2020-8287.patch
--- http-parser-2.9.4/debian/patches/CVE-2020-8287.patch1970-01-01 
01:00:00.0 +0100
+++ http-parser-2.9.4/debian/patches/CVE-2020-8287.patch2022-08-05 
20:33:28.0 +0200
@@ -0,0 +1,67 @@
+Subject: [PATCH] http: unset `F_CHUNKED` on new `Transfer-Encoding`
+Origin: Upstream PR (from nodejs) 
https://github.com/nodejs/http-parser/pull/530
+From: Fedor Indutny 
+Date: Wed, 18 Nov 2020 20:50:21 -0800
+Date: 2022-08-05
+
+Duplicate `Transfer-Encoding` header should be a treated as a single,
+but with original header values concatenated with a comma separator. In
+the light of this, even if the past `Transfer-Encoding` ended with
+`chunked`, we should be not let the `F_CHUNKED` to leak into the next
+header, because mere presence of another header indicates that `chunked`
+is not the last transfer-encoding token.
+
+CVE-ID: CVE-2020-8287
+PR-URL: https://github.com/nodejs-private/node-private/pull/235
+Reviewed-By: Fedor Indutny 
+--- a/http_parser.c
 b/http_parser.c
+@@ -1344,6 +1344,13 @@
+   } else if (parser->index == sizeof(TRANSFER_ENCODING)-2) {
+ parser->header_state = h_transfer_encoding;
+ parser->uses_transfer_encoding = 1;
++
++/* Multiple `Transfer-Encoding` headers should be treated as
++ * one, but with values separate by a comma.
++ *
++ * See: https://tools.ietf.org/html/rfc7230#section-3.2.2
++ */
++parser->flags &= ~F_CHUNKED;
+   }
+   break;
+ 
+--- a/test.c
 b/test.c
+@@ -2154,6 +2154,32 @@
+   ,.body= "2\r\nOK\r\n0\r\n\r\n"
+   ,.num_chunks_complete= 0
+   }
++#define HTTP_200_DUPLICATE_TE_NOT_LAST_CHUNKED 30
++, {.name= "HTTP 200 response with `chunked` and duplicate Transfer-Encoding"
++  ,.type= HTTP_RESPONSE
++  ,.raw= "HTTP/1.1 200 OK\r\n"
++ "Transfer-Encoding: chunked\r\n"
++ "Transfer-Encoding: identity\r\n"
++ "\r\n"
++ "2\r\n"
++ "OK\r\n"
++ "0\r\n"
++ "\r\n"
++  ,.should_keep_alive= FALSE
++  ,.message_complete_on_eof= TRUE
++  ,.http_major= 1
++  ,.http_minor= 1
++  ,.status_code= 200
++  ,.response_status= "OK"
++  ,.content_length= -1
++  ,.num_headers= 2
++  ,.headers=
++{ { "Transfer-Encoding", "chunked" }
++, { "Transfer-Encoding", "identity" }
++}
++  ,.body= "2\r\nOK\r\n0\r\n\r\n"
++  ,.num_chunks_complete= 0
++  }
+ };
+ 
+ /* strnlen() is a POSIX.2008 addition. Can't rely on it being available so
diff -Nru http-parser-2.9.4/debian/patches/series 
http-parser-2.9.4/debian/patches/series
--- http-parser-2.9.4/debian/patches/series 2020-12-20 10:29:46.0 
+0100
+++ http-parser-2.9.4/debian/patches/series 2022-08-05 20:33:28.0 
+0200
@@ -4,6 +4,7 @@
 cherry-pick.v2.9.4-7-g4b99e42.test-content-length-header-parsing.patch
 
cherry-pick.v2.9.4-8-ge13b274.allow-content-length-and-transfer-encoding-chunked.patch
 cherry-pick.v2.9.4-9-g4f15b7d.fix-sizeof-http-parser-assert.patch
+CVE-2020-8287.patch
 
 # Debian-specific
 debian.improve-installation.patch


signature.asc
Description: PGP signature

Bug#996997: marked as done (buster-pu: Cleaning up the http-parser ABI breakage in Debian 10 ("buster"))

[Christoph Biedl]

[ Thanks for pinging ]

Adam D. Barratt wrote...

> How does this sound as text for an SUA?

To me, it seems worth a idea describing the impact a bit more in detail,
so ...

> "
> http-parser is a parser for HTTP messages, designed to be used in high
> performance HTTP applications.
> 
> The update to http-parser included in the 10.10 point release introduced
> a regression affecting dependent applications

, possibly leading to a crash.

> This update resolves that
> regression.
> 
> If you use http-parser, we strongly recommend that you install this
> update.

But perhaps that's just too much fuzz, I leave the decision to you.

Otherwise it's good.

Regards,

Christoph



signature.asc
Description: PGP signature

Bug#996997: marked as done (buster-pu: Cleaning up the http-parser ABI breakage in Debian 10 ("buster"))

[Christoph Biedl]

Adam D. Barratt wrote...

> Apparently we missed this on review, but please don't close release.d.o
> bugs in your uploads.
> 
> The bug will get closed once the fix is actually released, which for
> (old)stable updates is once the package is in (old)stable.

ACK. Sorry for disturbing that.

Christoph


signature.asc
Description: PGP signature

Bug#996997: buster-pu: Cleaning up the http-parser ABI breakage in Debian 10 ("buster")

[Christoph Biedl]

Christoph Biedl wrote...

> About next steps, I would do the upload in the next days. Let me know if
> you prefer other things to happen first or instead.

To avoid this gets lost I've just uploaded http-parser 2.8.1-1+deb10u2.
Updated debiff attached, only editorial changes since the previous mail.

Regards,

Christoph

diff -Nru http-parser-2.8.1/debian/changelog http-parser-2.8.1/debian/changelog
--- http-parser-2.8.1/debian/changelog  2021-06-04 20:59:56.0 +0200
+++ http-parser-2.8.1/debian/changelog  2021-10-31 23:50:09.0 +0100
@@ -1,3 +1,11 @@
+http-parser (2.8.1-1+deb10u2) buster; urgency=medium
+
+  * Fix ABI breakage introduced by accident in 2.8.1-1+deb10u1.
+Many thanks to Hilko Bengen.
+Closes: #996460, #996939, #996997
+
+ -- Christoph Biedl   Sun, 31 Oct 2021 
23:50:09 +0100
+
 http-parser (2.8.1-1+deb10u1) buster; urgency=medium
 
   * Cherry-pick "Support multi-coding Transfer-Encoding".
diff -Nru http-parser-2.8.1/debian/patches/fix-ABI-breakage.patch 
http-parser-2.8.1/debian/patches/fix-ABI-breakage.patch
--- http-parser-2.8.1/debian/patches/fix-ABI-breakage.patch 1970-01-01 
01:00:00.0 +0100
+++ http-parser-2.8.1/debian/patches/fix-ABI-breakage.patch 2021-10-31 
23:50:09.0 +0100
@@ -0,0 +1,224 @@
+Subject: Fix ABI breakage introduced by accident in 2.8.1-1+deb10u1
+Author: Hilko Bengen 
+Date: 2021-10-22
+Bug-Debian:
+https://bugs.debian.org/996460
+https://bugs.debian.org/996939
+https://bugs.debian.org/996997
+Comment: (by the http-parser maintainer)
+
+  # Problem
+
+  The fix for CVE-2019-15605 introduced an ABI break by changing the
+  layout of struct http_parser - a change that was needed to store a
+  ninth bit in the "flags" field. However, this affected offsets of
+  fields declared as public, causing applications to break.
+
+  # Workaround
+
+  To restore the previous layout while still implementing the fix: Steal
+  one bit from the (private) content_length field (the remaining 63
+  are more than enough) to store the newly introduced flag.
+
+  Also rename the related constant as a safeguard against applications
+  that use it (they must not, see below).
+
+  # Possible regressions
+
+  A lot of work was done to avoid damage for well-behaving applications.
+  It seems all applications in Debian built against http-parser fall
+  into that category.
+
+  Applications however that access fields in struct http_parser that are
+  in the section marked "/** PRIVATE **/" may face issues. Such a
+  behaviour is inacceptable anyway.
+
+  If such a mis-behaving application ...
+
+  * was built using an earlier version of http-parser, the code will
+assume content_length is a 64 bit value. Depending on endianess and
+status of the F_TRANSFER_ENCODING bit, things may work. Possibly
+they will not.
+
+  * uses the private F_TRANSFER_ENCODING constant and was built using
+http-parser 2.8.1-1+deb10u1, it will not see the information it
+expects to see.
+Additionally, and re-build will fail. This is by design.
+
+  Again, applications must not access fields declared private, and their
+  authors should not expect pity if they encounter breakage any anything
+  changes there.
+
+  # Acknowledgments
+
+  Thanks a lot to Hilko Bengen for the idea, implementation, a first
+  round of tests and many suggestions.
+
+--- a/http_parser.c
 b/http_parser.c
+@@ -25,9 +25,7 @@
+ #include 
+ #include 
+ 
+-#ifndef ULLONG_MAX
+-# define ULLONG_MAX ((uint64_t) -1) /* 2^64-1 */
+-#endif
++#define CONTENT_LENGTH_MAX (((uint64_t)-1) >> 1)
+ 
+ #ifndef MIN
+ # define MIN(a,b) ((a) < (b) ? (a) : (b))
+@@ -724,7 +722,8 @@
+ if (ch == CR || ch == LF)
+   break;
+ parser->flags = 0;
+-parser->content_length = ULLONG_MAX;
++parser->flags2 = 0;
++parser->content_length = CONTENT_LENGTH_MAX;
+ 
+ if (ch == 'H') {
+   UPDATE_STATE(s_res_or_resp_H);
+@@ -759,7 +758,8 @@
+   case s_start_res:
+   {
+ parser->flags = 0;
+-parser->content_length = ULLONG_MAX;
++parser->flags2 = 0;
++parser->content_length = CONTENT_LENGTH_MAX;
+ 
+ switch (ch) {
+   case 'H':
+@@ -923,7 +923,8 @@
+ if (ch == CR || ch == LF)
+   break;
+ parser->flags = 0;
+-parser->content_length = ULLONG_MAX;
++parser->flags2 = 0;
++parser->content_length = CONTENT_LENGTH_MAX;
+ 
+ if (UNLIKELY(!IS_ALPHA(ch))) {
+   SET_ERRNO(HPE_INVALID_METHOD);
+@@ -1314,7 +1315,7 @@
+ parser->header_state = h_general;
+   } else if (parser->index == sizeof(TRANSFER_ENCODING)-2) {
+ parser->header_state = h_transfer_encoding;
+-parser->flags |= F_TRANSFER_ENCODING;
++parser->flags2 |= F_TRANSFER_ENCODING2;

Bug#996997: buster-pu: Cleaning up the http-parser ABI breakage in Debian 10 ("buster")

[Christoph Biedl]

Julien Cristau wrote...

> Would you mind providing the old/new/proposed versions of http_parser.h?
> (this is me being lazy, sorry, if I'm being too much of a pain I can go
> and figure them out for myself, just let me know).

Not that much on my side, so find the files attached. The name for the
first (old version) might be a bit odd but this way tools meld "meld
*.h" will pick them in chronological order.

Christoph
/* Copyright Joyent, Inc. and other Node contributors. All rights reserved.
 *
 * Permission is hereby granted, free of charge, to any person obtaining a copy
 * of this software and associated documentation files (the "Software"), to
 * deal in the Software without restriction, including without limitation the
 * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
 * sell copies of the Software, and to permit persons to whom the Software is
 * furnished to do so, subject to the following conditions:
 *
 * The above copyright notice and this permission notice shall be included in
 * all copies or substantial portions of the Software.
 *
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
 * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
 * IN THE SOFTWARE.
 */
#ifndef http_parser_h
#define http_parser_h
#ifdef __cplusplus
extern "C" {
#endif

/* Also update SONAME in the Makefile whenever you change these. */
#define HTTP_PARSER_VERSION_MAJOR 2
#define HTTP_PARSER_VERSION_MINOR 8
#define HTTP_PARSER_VERSION_PATCH 1

#include 
#if defined(_WIN32) && !defined(__MINGW32__) && \
  (!defined(_MSC_VER) || _MSC_VER<1600) && !defined(__WINE__)
#include 
typedef __int8 int8_t;
typedef unsigned __int8 uint8_t;
typedef __int16 int16_t;
typedef unsigned __int16 uint16_t;
typedef __int32 int32_t;
typedef unsigned __int32 uint32_t;
typedef __int64 int64_t;
typedef unsigned __int64 uint64_t;
#else
#include 
#endif

/* Compile with -DHTTP_PARSER_STRICT=0 to make less checks, but run
 * faster
 */
#ifndef HTTP_PARSER_STRICT
# define HTTP_PARSER_STRICT 1
#endif

/* Maximium header size allowed. If the macro is not defined
 * before including this header then the default is used. To
 * change the maximum header size, define the macro in the build
 * environment (e.g. -DHTTP_MAX_HEADER_SIZE=). To remove
 * the effective limit on the size of the header, define the macro
 * to a very large number (e.g. -DHTTP_MAX_HEADER_SIZE=0x7fff)
 */
#ifndef HTTP_MAX_HEADER_SIZE
# define HTTP_MAX_HEADER_SIZE (80*1024)
#endif

typedef struct http_parser http_parser;
typedef struct http_parser_settings http_parser_settings;


/* Callbacks should return non-zero to indicate an error. The parser will
 * then halt execution.
 *
 * The one exception is on_headers_complete. In a HTTP_RESPONSE parser
 * returning '1' from on_headers_complete will tell the parser that it
 * should not expect a body. This is used when receiving a response to a
 * HEAD request which may contain 'Content-Length' or 'Transfer-Encoding:
 * chunked' headers that indicate the presence of a body.
 *
 * Returning `2` from on_headers_complete will tell parser that it should not
 * expect neither a body nor any futher responses on this connection. This is
 * useful for handling responses to a CONNECT request which may not contain
 * `Upgrade` or `Connection: upgrade` headers.
 *
 * http_data_cb does not return data chunks. It will be called arbitrarily
 * many times for each string. E.G. you might get 10 callbacks for "on_url"
 * each providing just a few characters more data.
 */
typedef int (*http_data_cb) (http_parser*, const char *at, size_t length);
typedef int (*http_cb) (http_parser*);


/* Status Codes */
#define HTTP_STATUS_MAP(XX) \
  XX(100, CONTINUE,Continue)\
  XX(101, SWITCHING_PROTOCOLS, Switching Protocols) \
  XX(102, PROCESSING,  Processing)  \
  XX(200, OK,  OK)  \
  XX(201, CREATED, Created) \
  XX(202, ACCEPTED,Accepted)\
  XX(203, NON_AUTHORITATIVE_INFORMATION,   Non-Authoritative Information)   \
  XX(204, NO_CONTENT,  No Content)  \
  XX(205, RESET_CONTENT,   Reset Content)   \
  XX(206, PARTIAL_CONTENT, Partial Content) \
  XX(207, MULTI_STATUS,Multi-Status)\
  XX(208, ALREADY_REPORTED,

Bug#996997: buster-pu: Cleaning up the http-parser ABI breakage in Debian 10 ("buster")

[Christoph Biedl]

Adam D. Barratt wrote...

> Do you already have a proposed new upload / debdiff?

After many more tests and some more discussion with Hilko, find attached
a debdiff that in my opinion is ready for upload. The patch itself is
unmodified, I just enhanced the description for posterity.

About next steps, I would do the upload in the next days. Let me know if
you prefer other things to happen first or instead.

Regards,

Christoph
diff -Nru http-parser-2.8.1/debian/changelog http-parser-2.8.1/debian/changelog
--- http-parser-2.8.1/debian/changelog  2021-06-04 20:59:56.0 +0200
+++ http-parser-2.8.1/debian/changelog  2021-10-31 23:50:09.0 +0100
@@ -1,3 +1,10 @@
+http-parser (2.8.1-1+deb10u2) buster; urgency=medium
+
+  * Fix ABI breakage introduced by accident in 2.8.1-1+deb10u1.
+Closes: #996460, #996939, #996997
+
+ -- Christoph Biedl   Sun, 31 Oct 2021 
23:50:09 +0100
+
 http-parser (2.8.1-1+deb10u1) buster; urgency=medium
 
   * Cherry-pick "Support multi-coding Transfer-Encoding".
diff -Nru http-parser-2.8.1/debian/patches/fix-ABI-breakage.patch 
http-parser-2.8.1/debian/patches/fix-ABI-breakage.patch
--- http-parser-2.8.1/debian/patches/fix-ABI-breakage.patch 1970-01-01 
01:00:00.0 +0100
+++ http-parser-2.8.1/debian/patches/fix-ABI-breakage.patch 2021-10-31 
23:49:47.0 +0100
@@ -0,0 +1,224 @@
+Subject: Fix ABI breakage introduced by accident in 2.8.1-1+deb10u1
+Author: Hilko Bengen 
+Date: 2021-10-22
+Bug-Debian:
+https://bugs.debian.org/996460
+https://bugs.debian.org/996939
+https://bugs.debian.org/996997
+Comment: (by the http-parser maintainer)
+
+  # Problem
+
+  The fix for CVE-2019-15605 introduced an ABI break by changing the
+  layout of struct http_parser - a change that was needed to store a
+  ninth bit in the "flags" field. However, this affected offsets of
+  fields declared as public, causing applications to break.
+
+  # Workaround
+
+  To restore the previous layout while still implementing the fix: Steal
+  one bit from the (private) content_length field (the remaining 63
+  are more than enough) to store the newly introduced flag.
+
+  Also rename the related constant as a safeguard against applications
+  that use it (they must not, see below).
+
+  # Possible regressions
+
+  A lot of work was done to avoid damage for well-behaving applications.
+  It seems all applications in Debian built against http-parser fall
+  into that category.
+
+  Applications however that access fields in struct http_parser that are
+  in the section marked "/** PRIVATE **/" may face issues. Such a
+  behaviour is inacceptable anyway.
+
+  If such a mis-behaving application ...
+
+  * was built using an earlier version of http-parser, the code will
+assume content_length is a 64 bit value. Depending on endianess and
+status of the F_TRANSFER_ENCODING bit, things may work. Possibly
+they will not.
+
+  * uses the private F_TRANSFER_ENCODING constant and was built using
+http-parser 2.8.1-1+deb10u1, it will not see the information it
+expects to see.
+Additionally, and re-build will fail. This is by design.
+
+  Again, applications must not access fields declared private, and their
+  authors should not expect pity if they encounter breakage any anything
+  changes there.
+
+  # Acknowledgments
+
+  Thanks a lot to Hilko Bengen for the idea, implementation, a first
+  round of tests and many suggestions.
+
+--- a/http_parser.c
 b/http_parser.c
+@@ -25,9 +25,7 @@
+ #include 
+ #include 
+ 
+-#ifndef ULLONG_MAX
+-# define ULLONG_MAX ((uint64_t) -1) /* 2^64-1 */
+-#endif
++#define CONTENT_LENGTH_MAX (((uint64_t)-1) >> 1)
+ 
+ #ifndef MIN
+ # define MIN(a,b) ((a) < (b) ? (a) : (b))
+@@ -724,7 +722,8 @@
+ if (ch == CR || ch == LF)
+   break;
+ parser->flags = 0;
+-parser->content_length = ULLONG_MAX;
++parser->flags2 = 0;
++parser->content_length = CONTENT_LENGTH_MAX;
+ 
+ if (ch == 'H') {
+   UPDATE_STATE(s_res_or_resp_H);
+@@ -759,7 +758,8 @@
+   case s_start_res:
+   {
+ parser->flags = 0;
+-parser->content_length = ULLONG_MAX;
++parser->flags2 = 0;
++parser->content_length = CONTENT_LENGTH_MAX;
+ 
+ switch (ch) {
+   case 'H':
+@@ -923,7 +923,8 @@
+ if (ch == CR || ch == LF)
+   break;
+ parser->flags = 0;
+-parser->content_length = ULLONG_MAX;
++parser->flags2 = 0;
++parser->content_length = CONTENT_LENGTH_MAX;
+ 
+ if (UNLIKELY(!IS_ALPHA(ch))) {
+   SET_ERRNO(HPE_INVALID_METHOD);
+@@ -1314,7 +1315,7 @@
+ parser->header_state = h_general;
+   } else if (parser->index == sizeof(TRANSFER_ENCODING)-2) {
+ parser->header_state = h_transfer_encoding;
+-parser->flags |= F_TRANSFER_ENCODING;
++ 

Bug#996997: buster-pu: Cleaning up the http-parser ABI breakage in Debian 10 ("buster")

[Christoph Biedl]

Thanks for your swift and kind response.

Adam D. Barratt wrote...

> On Fri, 2021-10-22 at 09:18 +0200, Christoph Biedl wrote:

> > ## Rework the patch
> > 
> > Revert the ABI break by reworking the patch to restore the previous
> > struct layout - while maintaining the purpose of the change: Storing
> > a ninth status bit. Hilko Bengen did a great job implementing this,
> > and also reported success with several tests.
> > 
> This seems like the best option if we can, although I realise it does
> break from our usual desire to use a patch as-implemented in later
> versions.
> 
> Do you already have a proposed new upload / debdiff?

Find a debdiff attached, there is a lengthy explanation in the patch.

Still open on my side is a *huge* round of tests, preferably all
archtectures supported in buster, especially big-endian. This may take
major parts of the weekend.

> > PS: Related, do you check autopkgtest (...)
> 
> We did discuss this on IRC briefly, but for the record - there's a
> britney instance that produces "excuses" for p-u and o-p-u, including
> scheduling autopkgtests via ci.d.n. The results show up on our tracking
> pages and we (mainly Paul; thanks!) investigate any failures raised to
> determine if they resulted from the proposed update and, if so, what to
> do about that.

Follow-up question, I might have asked that before or it has already
been answered: In case a package gets an update via a stable point
release ... I think it makes sense to take this as a chance to add an
autopkgtest if not present yet?

Rationale: The tang package I maintain as well was updated via a stable
point release in January. If I had included a backported autopkgtest, we
would have learned about the current issue in http-parser in time.

Christoph
diff -Nru http-parser-2.8.1/debian/changelog http-parser-2.8.1/debian/changelog
--- http-parser-2.8.1/debian/changelog  2021-06-04 20:59:56.0 +0200
+++ http-parser-2.8.1/debian/changelog  2021-10-22 19:02:29.0 +0200
@@ -1,3 +1,11 @@
+http-parser (2.8.1-1+deb10u2) NOT-FOR-RELEASE; urgency=medium
+
+  + NOT FOR RELEASE: This is only for review and testing.
+  * Fix ABI breakage introduced by accident in 2.8.1-1+deb10u1.
+Closes: #996460, #996939, #996997
+
+ -- Christoph Biedl   Fri, 22 Oct 2021 
19:02:29 +0200
+
 http-parser (2.8.1-1+deb10u1) buster; urgency=medium
 
   * Cherry-pick "Support multi-coding Transfer-Encoding".
diff -Nru http-parser-2.8.1/debian/patches/fix-ABI-breakage.patch 
http-parser-2.8.1/debian/patches/fix-ABI-breakage.patch
--- http-parser-2.8.1/debian/patches/fix-ABI-breakage.patch 1970-01-01 
01:00:00.0 +0100
+++ http-parser-2.8.1/debian/patches/fix-ABI-breakage.patch 2021-10-22 
19:02:29.0 +0200
@@ -0,0 +1,191 @@
+Subject: Fix ABI breakage introduced by accident in 2.8.1-1+deb10u1
+Author: Hilko Bengen 
+Date: 2021-10-22
+Bug-Debian:
+https://bugs.debian.org/996460
+https://bugs.debian.org/996939
+https://bugs.debian.org/996997
+Comment: (by the http-parser maintainer)
+   The fix for CVE-2019-15605 introduced an ABI break by changing the
+   layout of struct http_parser - a change that was needed to store a
+   ninth bit in the "flags" field. However, this affected offsets of
+   fields declared as public, causing applications to break.
+
+   To restore the previous layout while stil implementing the fix: Steal
+   one bit from the content_length element (the remaining 63 are more
+   than enough) to store the newly introduced F_TRANSFER_ENCODING flag.
+   Also rename the constant to F_TRANSFER_ENCODING2 as a safeguard
+   against applications that try to manipulate information that is by
+   definition private.
+
+   Thanks a lot to Hilko Bengen for the idea, implementation, a first
+   round of tests and many suggestions. -CB
+
+--- a/http_parser.c
 b/http_parser.c
+@@ -25,9 +25,7 @@
+ #include 
+ #include 
+ 
+-#ifndef ULLONG_MAX
+-# define ULLONG_MAX ((uint64_t) -1) /* 2^64-1 */
+-#endif
++#define CONTENT_LENGTH_MAX (((uint64_t)-1) >> 1)
+ 
+ #ifndef MIN
+ # define MIN(a,b) ((a) < (b) ? (a) : (b))
+@@ -724,7 +722,8 @@
+ if (ch == CR || ch == LF)
+   break;
+ parser->flags = 0;
+-parser->content_length = ULLONG_MAX;
++parser->flags2 = 0;
++parser->content_length = CONTENT_LENGTH_MAX;
+ 
+ if (ch == 'H') {
+   UPDATE_STATE(s_res_or_resp_H);
+@@ -759,7 +758,8 @@
+   case s_start_res:
+   {
+ parser->flags = 0;
+-parser->content_length = ULLONG_MAX;
++parser->flags2 = 0;
++parser->content_length = CONTENT_LENGTH_MAX;
+ 
+ switch (ch) {
+   case 'H':
+@@ -923,7 +923,8 @@
+ if (ch == CR || ch == LF)
+   break;
+ parser->flags = 0;
+-parser->content_length = ULLONG

Bug#996997: buster-pu: Cleaning up the http-parser ABI breakage in Debian 10 ("buster")

[Christoph Biedl]

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

Folks,

perhaps I should start with an outright confession: When doing
http-parser version 2.8.1-1+deb10u1 for a buster point release,
I messed up things horribly. Nobody noticed in time, it's in stable
now, and all I can do now is bringing things back in order.


# Problem

As described in #996939: The fix for CVE-2019-15605 changed, among
other things, the layout of "struct http_parser", by increasing the
size of the "flag" field and also its position¹ within the struct.

The latter ought not to do harm as the fields affected are marked as
private. But since that is not enforced in C, applications still might
access them.

The size change however is way worse, it caused the following elements,
especially "public" ones like "data" to change their offset.
Subsequently, applications built using the old header file will access
the wrong offset, and possibly segfault. This has been reported for the
tang package in #996460, and I have reason to assume *all* nine²
packages that use http-parser are affected.


# Solutions

After some discussion with Hilko Bengen (Cc:'ed) I can see two ways out
of this:

## Rebuild rdeps

In buster, re-build all packages that were built against http-parser.
So more or less a binNMU, but in a rather unusual area. Tightening the
install dependency to something like "libhttp-parser2.8 (>=
2.8.1-1+deb10u1~)" was nice to have.

Pros:
* If you have a process/automation for that, it should be little work
  and therefore the risk of mistakes rather low.

Cons:
* Several packages are affected.
* If this has to be done manually, co-ordination with package
  maintainers is needed, yada-yada.
* The ruby-http-parser.rb will FTBFS as mentioned in #989494. My old
  patch for unstable should apply. That would be my job.

## Rework the patch

Revert the ABI break by reworking the patch to restore the previous
struct layout - while maintaining the purpose of the change: Storing a
ninth status bit. Hilko Bengen did a great job implementing this, and
also reported success with several tests.

Pros:
* Only http-parser needs an upload.
* External applications (built using Debian but not shipped by Debian)
  continue to work. While this is not within our scope, it provides a
  good service.

Cons:
* Requires testing on all architectures supported in buster. My job.
* Applications that access private fields still might break. Highly
  unlikely to happen, and I have little mercy here.
* Applications and packages built *since* the ABI break will require
  a rebuild since technically this is a second ABI break. For Debian,
  the intersection with
  https://release.debian.org/proposed-updates/oldstable.html
  seems to be empty.

## Or ...

Still I am open for other ideas - my main goal is to find a sensible
fix for this issue.


Please advise how to proceed. I would like to see this handled as soon
as possible - knowing users out there encounter problems and will do so
until the next oldstable point release is not quite a pleasant
situation.

Personally I have a slight preference for the second ("rework the
patch") way, but that's not put in stone.

Kind regards,

Christoph

PS: Related, do you check autopkgtest of reverse dependencies as part
of a stable point release procedure? If not, please consider doing
so - although this time it would not have avoided the situation: Of
the list of packages, only libgit2 has an autopkgtest in buster,
and it still passes.

Related (not so) fun fact: Out of curiosity, I backported the
autopkgtest of the tang package locally, and it failed due to the
ABI breakage. Lesson learned: Do more autopkgtests!


¹ See

  
https://sources.debian.org/src/http-parser/2.8.1-1+deb10u1/debian/patches/1580760635.v2.9.2-2-g7d5c99d.support-multi-coding-transfer-encoding.patch/#L223

  and line 228

² Affected packages should be:

  cargo
  jabberd2
  libgit2
  libgit-raw-perl
  ocserv
  python-httptools
  ruby-http-parser.rb
  sssd
  tang
  tcpflow



signature.asc
Description: PGP signature

Bug#989494: buster-pu: package http-parser/2.8.1-1

[Christoph Biedl]

Christoph Biedl wrote...

> there is a minor (non-DSA) security issue open in the Debian 10
> ("buster") version of http-parser, and I'd like to fix that in a stable
> point release. This is #977467 [CVE-2019-15605].

Now uploaded in the hope it will help to resolve the issue.

Christoph



signature.asc
Description: PGP signature

Bug#989494: buster-pu: package http-parser/2.8.1-1

[Christoph Biedl]

Christoph Biedl wrote...

> there is a minor (non-DSA) security issue open in the Debian 10
> ("buster") version of http-parser, and I'd like to fix that in a stable
> point release. This is #977467 [CVE-2019-15605].

Gentle ping? Should I upload right away?

Christoph


signature.asc
Description: PGP signature

Bug#990237: unblock: aoetools/36-5

[Christoph Biedl]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: Adi Kriegisch 

Hello release team,

Please unblock package aoetools (as of 36-5)

To be honest, I feel bad about having to ask you for a manual unblock:
When uploading aoetools 36-4 and -5, I was not aware I had not created
an autopkgtest for that package - not yet. There is a reason for this
situation but that's no excuse, and resolving this is on the agenda for
the first post-release upload.

Enough disclaimers, here's why I'd like to see aoetools 36-5 in the
bullseye release, and why I think the risk is low and therefore
acceptable:

[ Reason ]
There are two major changes, commits cherry-picked from upstream. They
affect two userland programs shipped with but not used by aoetools,
called "aoeping" and "aoe-sancheck"

* (aoeping) "Check amount of data read from network before using it"

  Upstream: https://github.com/OpenAoE/aoetools/commit/aoetools-36-2-ge50247f

  This seems to have some security impact (reading undefined data)
  so it's wise to have it. Exploiting requires local network access,
  though.

* commit "Aoe-sancheck: Refine interface probing"

  Upstream: https://github.com/OpenAoE/aoetools/commit/aoetools-36-11-g4a3ee18
  Debian: https://bugs.debian.org/986671

  Fixes: The aoe-sancheck program assumes interface names start
  with "eth", and probes the first 16 interfaces by index only.

  Both the commit and the bug report have some more details on this.

Some other changes are minor or plain cosmetic:

* aoe-sancheck: Raise the number of supported interfaces.
  Upstream: https://github.com/OpenAoE/aoetools/commit/aoetools-36-12-gc80b1be

* Don't abort installation if the aoe kernel module cannot be loaded.
  For a discussion, see
  https://git.in-ulm.de/cbiedl/aoetools/commit/5b4c995

* Replace some upstreamed patches with the version cherry-picked
  from upstream. This makes the debdiff a bit hard to read but it's
  about manpages only anyway.

[ Impact ]
(What is the impact for the user if the unblock isn't granted?)
* aoeping: Possibly security issue (not very likely to happen, though).
* aoe-sancheck: Missing functionality, see the Debian bug report
  mentioned above.

[ Tests ]
Both programs were tested manually.

[ Risks ]
The changes are small. Quite frankly, I find it hard to believe they
will introduce breakage. And even if, this will not affect pure Debian
installations since AFAICT none of the programs are used by any package.

Kind regards,

Christoph

unblock aoetools/36-5
diff -Nru aoetools-36/debian/aoetools.postinst 
aoetools-36/debian/aoetools.postinst
--- aoetools-36/debian/aoetools.postinst2016-07-04 19:29:07.0 
+0200
+++ aoetools-36/debian/aoetools.postinst2021-05-24 12:08:35.0 
+0200
@@ -9,7 +9,7 @@
 fi
 # load the kernel module (as opposed to letting the init script do it)
 if [ -d /run/systemd/system ] ; then
-/lib/systemd/systemd-modules-load aoetools.conf
+/lib/systemd/systemd-modules-load aoetools.conf || true
 fi
 ;;
 abort-upgrade|abort-remove|abort-deconfigure)
diff -Nru aoetools-36/debian/changelog aoetools-36/debian/changelog
--- aoetools-36/debian/changelog2019-02-26 01:05:45.0 +0100
+++ aoetools-36/debian/changelog2021-05-24 12:40:31.0 +0200
@@ -1,3 +1,17 @@
+aoetools (36-5) unstable; urgency=medium
+
+  * postinst: Don't abort from failing module load
+
+ -- Christoph Biedl   Mon, 24 May 2021 
12:40:31 +0200
+
+aoetools (36-4) unstable; urgency=medium
+
+  * Cherry-pick (aoeping:) "Check amount of data read from network
+before using it"
+  * aoe-sancheck: Probe interfaces not named eth*. Closes: #986671
+
+ -- Christoph Biedl   Sat, 22 May 2021 
21:50:11 +0200
+
 aoetools (36-3) unstable; urgency=medium
 
   * Update package description. Closes: #862843
diff -Nru aoetools-36/debian/control aoetools-36/debian/control
--- aoetools-36/debian/control  2019-02-26 01:05:40.0 +0100
+++ aoetools-36/debian/control  2021-05-24 12:08:20.0 +0200
@@ -3,6 +3,8 @@
 Homepage: http://aoetools.sf.net
 Standards-Version: 4.3.0
 Build-Depends: debhelper (>> 10~),
+Vcs-Browser: https://git.in-ulm.de/cbiedl/aoetools
+Vcs-Git: https://git.in-ulm.de/cbiedl/aoetools.git
 Priority: optional
 Section: admin
 
diff -Nru aoetools-36/debian/patches/02_no_hyphen_in_manpages.patch 
aoetools-36/debian/patches/02_no_hyphen_in_manpages.patch
--- aoetools-36/debian/patches/02_no_hyphen_in_manpages.patch   2014-01-13 
22:54:59.0 +0100
+++ aoetools-36/debian/patches/02_no_hyphen_in_manpages.patch   1970-01-01 
01:00:00.0 +0100
@@ -1,95 +0,0 @@
-Description: Patch hyphens in manpages.
- Patched all the manpages in order to avoid usual hyphen->minus confusion.
- Also fixed a typo.
-Author: David Martínez Moreno 
-Forwarded: no
-Last-Update: 2014-01-12
-
 a

Bug#989701: buster-pu: package clevis/11-2+deb10u2

[Christoph Biedl]

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

Hello stable release team,

for the upcoming stable point release, I've just uploaded src:clevis
("automated encryption framework") as version 11-2+deb10u2. There is
one change related to the TPM integration:

* Fix handling of TPM chips that support sha256 only

Type: upstream bug
Debian bug: https://bugs.debian.org/989648
Fixed in in stable and testing: 12-1 (February 2020)

Problem: Possibly due to a typo, the clevis-encrypt-tpm2 backend cannot
handle TPM chips that support sha256 only.

Regards,

Christoph
diff -Nru clevis-11/debian/changelog clevis-11/debian/changelog
--- clevis-11/debian/changelog  2021-01-25 20:03:26.0 +0100
+++ clevis-11/debian/changelog  2021-06-09 15:59:00.0 +0200
@@ -1,3 +1,10 @@
+clevis (11-2+deb10u2) buster; urgency=medium
+
+  * Cherry-pick "Bugfix: set pcr_bank from pcr_bank not pcr_hash
+field". Closes: #989648
+
+ -- Christoph Biedl   Wed, 09 Jun 2021 
19:58:50 +0200
+
 clevis (11-2+deb10u1) buster; urgency=medium
 
   * Cherry-pick two comments to fix initramfs creation: Closes: #969361
diff -Nru 
clevis-11/debian/patches/cherry-pick/1551971881.v11-5-g67fc67c.bugfix-set-pcr-bank-from-pcr-bank-not-pcr-hash-field.patch
 
clevis-11/debian/patches/cherry-pick/1551971881.v11-5-g67fc67c.bugfix-set-pcr-bank-from-pcr-bank-not-pcr-hash-field.patch
--- 
clevis-11/debian/patches/cherry-pick/1551971881.v11-5-g67fc67c.bugfix-set-pcr-bank-from-pcr-bank-not-pcr-hash-field.patch
   1970-01-01 01:00:00.0 +0100
+++ 
clevis-11/debian/patches/cherry-pick/1551971881.v11-5-g67fc67c.bugfix-set-pcr-bank-from-pcr-bank-not-pcr-hash-field.patch
   2021-06-09 15:55:44.0 +0200
@@ -0,0 +1,16 @@
+Subject: Bugfix: set pcr_bank from pcr_bank not pcr_hash field
+Origin: v11-5-g67fc67c 
<https://github.com/latchset/clevis/commit/v11-5-g67fc67c>
+Upstream-Author: Markus Linnala 
+Date: Thu Mar 7 17:18:01 2019 +0200
+
+--- a/src/pins/tpm2/clevis-encrypt-tpm2
 b/src/pins/tpm2/clevis-encrypt-tpm2
+@@ -88,7 +88,7 @@
+ 
+ key=`jose fmt -j- -Og key -u- <<< "$cfg"` || key="ecc"
+ 
+-pcr_bank=`jose fmt -j- -Og pcr_hash -u- <<< "$cfg"` || pcr_bank="sha1"
++pcr_bank=`jose fmt -j- -Og pcr_bank -u- <<< "$cfg"` || pcr_bank="sha1"
+ 
+ pcr_ids=`jose fmt -j- -Og pcr_ids -u- <<< "$cfg"` || true
+ 
diff -Nru clevis-11/debian/patches/series clevis-11/debian/patches/series
--- clevis-11/debian/patches/series 2021-01-25 20:03:26.0 +0100
+++ clevis-11/debian/patches/series 2021-06-09 15:55:55.0 +0200
@@ -2,6 +2,7 @@
 # cherry-picked commits. Keep in upstream's chronological order
 
cherry-pick/1541598788.v11-1-g1e344db.delete-remaining-references-to-the-removed-http-pin.patch
 
cherry-pick/1541599937.v11-2-g3465859.install-cryptsetup-and-tpm2-pcrlist-in-the-initramfs.patch
+cherry-pick/1551971881.v11-5-g67fc67c.bugfix-set-pcr-bank-from-pcr-bank-not-pcr-hash-field.patch
 
 # local modifications
 debian.use-socat.patch


signature.asc
Description: PGP signature

Bug#989494: buster-pu: package http-parser/2.8.1-1

[Christoph Biedl]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbug-CC: ruby-http-parser...@packages.debian.org

Hello release team,

there is a minor (non-DSA) security issue open in the Debian 10
("buster") version of http-parser, and I'd like to fix that in a stable
point release. This is #977467 [CVE-2019-15605].

Usually I'd just upload such a change change without asking for prior
authorizsation, but there's a complication: The updated version will
break the test suite of the ruby-http-parser.rb package. See my article
in debian-devel about that story in unstable and the NMU for further
details.[1][2]

Please advise how to proceed. If you think that situation is acceptable,
just let that package pass or ask me to upload it. If however you think,
the ruby-http-parser.rb maintainers (Cc'd) should provide an updated
version first, let us know and I'll try to get things coordinated.

Another idea was to postpone this story until after the upcoming 10.10
point release so there will be more time to learn about regressions and
to thandle them.

Kind regards,

Christoph

[1] https://lists.debian.org/msgid-search/1609286...@msgid.manchmal.in-ulm.de
[2] 
https://packages.qa.debian.org/r/ruby-http-parser.rb/news/20201227T111838Z.html

diff -Nru http-parser-2.8.1/debian/changelog http-parser-2.8.1/debian/changelog
--- http-parser-2.8.1/debian/changelog  2018-04-12 22:15:13.0 +0200
+++ http-parser-2.8.1/debian/changelog  2021-06-04 20:59:56.0 +0200
@@ -1,3 +1,10 @@
+http-parser (2.8.1-1+deb10u1) buster; urgency=medium
+
+  * Cherry-pick "Support multi-coding Transfer-Encoding".
+Closes: #977467 [CVE-2019-15605]
+
+ -- Christoph Biedl   Fri, 04 Jun 2021 
20:59:56 +0200
+
 http-parser (2.8.1-1) unstable; urgency=medium
 
   * Upload to unstable
diff -Nru 
http-parser-2.8.1/debian/patches/1580760635.v2.9.2-2-g7d5c99d.support-multi-coding-transfer-encoding.patch
 
http-parser-2.8.1/debian/patches/1580760635.v2.9.2-2-g7d5c99d.support-multi-coding-transfer-encoding.patch
--- 
http-parser-2.8.1/debian/patches/1580760635.v2.9.2-2-g7d5c99d.support-multi-coding-transfer-encoding.patch
  1970-01-01 01:00:00.0 +0100
+++ 
http-parser-2.8.1/debian/patches/1580760635.v2.9.2-2-g7d5c99d.support-multi-coding-transfer-encoding.patch
  2021-06-04 20:59:56.0 +0200
@@ -0,0 +1,366 @@
+Subject: Support multi-coding Transfer-Encoding
+Origin: v2.9.2-2-g7d5c99d 
<https://github.com/nodejs/http-parser/commit/7d5c99d09f6743b055d53fc3f642746d9801479b>
+Upstream-Author: Fedor Indutny 
+Date: Mon Feb 3 21:10:35 2020 +0100
+
+`Transfer-Encoding` header might have multiple codings in it. Even
+though llhttp cares only about `chunked`, it must check that `chunked`
+is the last coding (if present).
+
+ABNF from RFC 7230:
+
+```
+Transfer-Encoding = *( "," OWS ) transfer-coding *( OWS "," [ OWS
+transfer-coding ] )
+transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
+transfer-extension
+   transfer-extension = token *( OWS ";" OWS transfer-parameter )
+   transfer-parameter = token BWS "=" BWS ( token / quoted-string )
+```
+
+However, if `chunked` is not last - llhttp must assume that the encoding
+and size of the body is unknown (according to 3.3.3 of RFC 7230) and
+read the response until EOF. For request - the error must be raised for
+an unknown `Transfer-Encoding`.
+
+Furthermore, 3.3.3 of RFC 7230 explicitly states that presence of both
+`Transfer-Encoding` and `Content-Length` indicates the smuggling attack
+and "ought to be handled as an error".
+
+For the lenient mode:
+
+* Unknown `Transfer-Encoding` in requests is not an error and request
+  body is simply read until EOF (end of connection)
+* Only `Transfer-Encoding: chunked` together with `Content-Length` would
+  result an error (just like before the patch)
+
+PR-URL: https://github.com/nodejs-private/http-parser-private/pull/4
+Reviewed-By: Matteo Collina 
+Reviewed-By: Sam Roberts 
+Reviewed-By: James M Snell 
+
+--- a/http_parser.c
 b/http_parser.c
+@@ -375,7 +375,10 @@
+   , h_transfer_encoding
+   , h_upgrade
+ 
++  , h_matching_transfer_encoding_token_start
+   , h_matching_transfer_encoding_chunked
++  , h_matching_transfer_encoding_token
++
+   , h_matching_connection_token_start
+   , h_matching_connection_keep_alive
+   , h_matching_connection_close
+@@ -1311,6 +1314,7 @@
+ parser->header_state = h_general;
+   } else if (parser->index == sizeof(TRANSFER_ENCODING)-2) {
+ parser->header_state = h_transfer_encoding;
++parser->flags |= F_TRANSFER_ENCODING;
+   }
+   break;
+ 
+@@ -1391,10 +1395,14 @@
+ if ('c' == c) {
+   

Bug#987838: unblock: gnupg2/2.2.27-2

[Christoph Biedl]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: pkg-gnupg-ma...@lists.alioth.debian.org

Please unblock package gnupg2

Being fully aware about the signifiance of the gnupg2 package and the
advanced progress of the bullseye release, I am asking to unblock
gnupg2/2.2.27-2. As there are no changes to the code, just a
documentation update, there shouldn't be any risk of introducing
regressions.

[ Reason ]
Document the fact the gnupg suite no longer reads a configuration file
at "~/.gnupg/options".

This fixes Debian bug is <https://bugs.debian.org/985158>. Related,
mentioning this in the release notes has been requested in
<https://bugs.debian.org/987440>.

[ Impact ]
Without that information, users have less chance to learn about that
change, and might more likely experience regressions or breakage in
their GnuPG-based workflows.

[ Risks ]
There shouldn't be any risks as no code was changed.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  (did not mention I'd added myself to uploaders, though)
  [X] I reviewed all changes and I approve them
  (TBH, they were done by yours truly)
  [X] attach debdiff against the package in testing

unblock gnupg2/2.2.27-2

diff -Nru gnupg2-2.2.27/debian/changelog gnupg2-2.2.27/debian/changelog
--- gnupg2-2.2.27/debian/changelog  2021-02-08 23:57:00.0 +0100
+++ gnupg2-2.2.27/debian/changelog  2021-04-22 20:40:36.0 +0200
@@ -1,3 +1,10 @@
+gnupg2 (2.2.27-2) unstable; urgency=medium
+
+  * Add a NEWS entry about the end of support for ~/.gnupg/options.
+Closes: #985158
+
+ -- Christoph Biedl   Thu, 22 Apr 2021 
20:40:36 +0200
+
 gnupg2 (2.2.27-1) unstable; urgency=medium
 
   [ NIIBE Yutaka ]
diff -Nru gnupg2-2.2.27/debian/control gnupg2-2.2.27/debian/control
--- gnupg2-2.2.27/debian/control2021-02-08 23:56:55.0 +0100
+++ gnupg2-2.2.27/debian/control2021-04-22 20:40:36.0 +0200
@@ -5,6 +5,7 @@
 Uploaders:
  Eric Dorland ,
  Daniel Kahn Gillmor ,
+ Christoph Biedl ,
 Standards-Version: 4.5.1
 Build-Depends:
  automake,
diff -Nru gnupg2-2.2.27/debian/NEWS gnupg2-2.2.27/debian/NEWS
--- gnupg2-2.2.27/debian/NEWS   2021-02-08 20:38:26.0 +0100
+++ gnupg2-2.2.27/debian/NEWS   2021-04-22 20:40:36.0 +0200
@@ -1,3 +1,12 @@
+gnupg2 (2.2.27-2) unstable; urgency=medium
+
+  Starting with version 2.2.27-1, per-user configuration of the GnuPG
+  suite has completely moved to ~/.gnupg/gpg.conf, and ~/.gnupg/options
+  is no longer in use.  Please rename the file if necessary, or move
+  its contents to the new location.
+
+ -- Christoph Biedl   Thu, 22 Apr 2021 
20:37:45 +0200
+
 gnupg2 (2.2.17-1) unstable; urgency=medium
 
   Upstream GnuPG now defaults to not accepting third-party certifications


signature.asc
Description: PGP signature

Re: Don't ship gnupg1 with bullseye

[Christoph Biedl]

Dominic Hargreaves wrote...

> Do the gnupg1 maintainers agree that it should be removed from bullseye?

IMnsHO it's a bad idea to remove gnupg1 any time soon. While it
certainly should not be used for encryption, it's still needed when
dealing with older keys. Quoting the package description: "It is
provided mainly for people with the need to use archaic cryptographic
objects like PGPv3 keys to access archived messages."

So unless it's really broken or likewise RC, it should be kept.

Christoph


signature.asc
Description: PGP signature

Bug#981096: buster-pu: package file/1:5.35-4+deb10u1

[Christoph Biedl]

Christoph Biedl wrote...

> for the upcoming stable point release, I've just uploaded src:file
> ("Recognize the type of data in a file using "magic" numbers") as
> version 1:5.35-4+deb10u2.

Forgot to sign, to this followup to confirm.

Christoph


signature.asc
Description: PGP signature

Bug#981096: buster-pu: package file/1:5.35-4+deb10u1

[Christoph Biedl]

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

Hello stable release team,

for the upcoming stable point release, I've just uploaded src:file
("Recognize the type of data in a file using "magic" numbers") as
version 1:5.35-4+deb10u2.

Content:

* Change default for name/use to 50.

Type: limitation relaxed upstream
Debian bug: https://bugs.debian.org/928009
Fixed in in stable and testing: 1:5.38-5 (May 2020)

Problem: The old limit turned out to be too strict, and instead of
avoiding DoS this broke legitimate use of that feature. Also, Paul
Wise (Cc:'ed), asked me repeatedly to backport this to buster, I
trust he has good reason to to so.

Regards,

Christoph


-- System Information:
Debian Release: 10.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.10 (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 /bin/dash
Init: systemd (via /run/systemd/system)

diff -Nru file-5.35/debian/changelog file-5.35/debian/changelog
--- file-5.35/debian/changelog  2019-10-22 21:57:17.0 +0200
+++ file-5.35/debian/changelog  2021-01-25 22:40:17.0 +0100
@@ -1,3 +1,9 @@
+file (1:5.35-4+deb10u2) buster; urgency=medium
+
+  * Change default for name/use to 50. Closes: #928009
+
+ -- Christoph Biedl   Mon, 25 Jan 2021 
22:40:17 +0100
+
 file (1:5.35-4+deb10u1) buster-security; urgency=high
 
   * Cherry-pick commit to restrict the number of CDF_VECTOR elements.
diff -Nru file-5.35/debian/patches/increase.number.use.magic.limit.patch 
file-5.35/debian/patches/increase.number.use.magic.limit.patch
--- file-5.35/debian/patches/increase.number.use.magic.limit.patch  
1970-01-01 01:00:00.0 +0100
+++ file-5.35/debian/patches/increase.number.use.magic.limit.patch  
2021-01-25 22:40:17.0 +0100
@@ -0,0 +1,17 @@
+Subject: Change default for name/use to 50
+Origin: Part of FILE5_38-65-gdf476c81 
<https://github.com/file/file/commit/FILE5_38-65-gdf476c81>
+Upstream-Author: Christos Zoulas 
+Date: Thu Mar 19 20:41:11 2020 +
+Bug-Debian: https://bugs.debian.org/928009
+
+--- a/src/file.h
 b/src/file.h
+@@ -437,7 +437,7 @@
+   uint16_t regex_max;
+   size_t bytes_max;   /* number of bytes to read from file */
+ #define   FILE_INDIR_MAX  50
+-#define   FILE_NAME_MAX   30
++#define   FILE_NAME_MAX   50
+ #define   FILE_ELF_SHNUM_MAX  32768
+ #define   FILE_ELF_PHNUM_MAX  2048
+ #define   FILE_ELF_NOTES_MAX  256
diff -Nru file-5.35/debian/patches/series file-5.35/debian/patches/series
--- file-5.35/debian/patches/series 2019-10-22 20:57:20.0 +0200
+++ file-5.35/debian/patches/series 2021-01-25 22:40:17.0 +0100
@@ -18,6 +18,8 @@
 
cherry-pick.FILE5_36-1-gecca6e54.fix-casts-and-bounds-check-found-by-oss-fuzz.patch
 
cherry-pick.FILE5_36-24-g9b2f9d6a.cast-to-unsigned-first-to-appease-ubsan-oss-fuzz.patch
 
cherry-pick.FILE5_37-67-g46a8443f.limit-the-number-of-elements-in-a-vector-found-by-oss-fuzz.patch
+# part of FILE5_38-65-gdf476c81
+increase.number.use.magic.limit.patch
 
 # patches that should go upstream
 

Bug#981059: buster-pu: package clevis/11-2

[Christoph Biedl]

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

Hello stable release team,

for the upcoming stable point release, I've just uploaded src:clevis
("automated encryption framework") as version 11-2+deb10u1. There are
three changes related to the dracut integration:

* No longer try to install the clevis-drcrypt-http unlocker

Type: upstream bug
Debian bug: https://bugs.debian.org/969361
Fixed in in stable and testing: 12-1 (February 2020)

Problem: The "module-setup.sh" sniplet tries to install a script that
no longer exists, resulting in am initramfs that no longer can
automatically unlock the root device.

Remark: The upstream commit also includes documentation cleanup,
hence it got a little bigger. Actual code change is just one line
removed.


* Install cryptsetup and tpm2_pcrlist

Type: upstream bug
Debian bug: https://bugs.debian.org/969361
Fixed in in stable and testing: 12-1 (February 2020)

Problem: Under certain circumstances the cryptsetup program ist not installed
in the initramfs, resulting in a system that cannot be unlocked at all, not
even manually.

Remark: The upstream commit also addresses tpm support, it seemed wise
to not touch this.


* Trigger dracut initramfs re-creation

Type: convenience/missing feature
Fixed in in stable and testing: 15-1 (December 2020)

Problem: Upon installation or upgrade, a re-creation of the initramfs
should be triggered to make sure new features are included.

Remark: As a disgression to unstable, the dependency on dracut (where
the trigger is handled) has been lowered to a recommendation. This is a
safeguard against possible installation problems since dracut conflicts
with a few other packages. Let's better play safe although I doubt
there exist users of clevis-dracut who do *not* have dracut itself
installed *but still* want to use a dracut initramfs.

Regards,

Christoph

-- System Information:
Debian Release: 10.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.10 (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 /bin/dash
Init: systemd (via /run/systemd/system)

diff -Nru clevis-11/debian/changelog clevis-11/debian/changelog
--- clevis-11/debian/changelog  2019-03-01 11:37:24.0 +0100
+++ clevis-11/debian/changelog  2021-01-25 20:03:26.0 +0100
@@ -1,3 +1,14 @@
+clevis (11-2+deb10u1) buster; urgency=medium
+
+  * Cherry-pick two comments to fix initramfs creation: Closes: #969361
+- "Delete remaining references to the removed http pin" to unbreak
+  initramfs generation in dracut. 
+- "Install cryptsetup and tpm2_pcrlist in the initramfs" to assert
+  cryptsetup is available in the initramfs
+  * clevis-dracut: Trigger initramfs creation upon installation
+
+ -- Christoph Biedl   Mon, 25 Jan 2021 
20:03:26 +0100
+
 clevis (11-2) unstable; urgency=medium
 
   * Use cryptsetup-bin as dependency, following the cryptsetup
diff -Nru clevis-11/debian/clevis-dracut.triggers 
clevis-11/debian/clevis-dracut.triggers
--- clevis-11/debian/clevis-dracut.triggers 1970-01-01 01:00:00.0 
+0100
+++ clevis-11/debian/clevis-dracut.triggers 2021-01-25 20:03:26.0 
+0100
@@ -0,0 +1 @@
+activate-noawait update-initramfs
diff -Nru clevis-11/debian/control clevis-11/debian/control
--- clevis-11/debian/control2019-03-01 11:32:32.0 +0100
+++ clevis-11/debian/control2021-01-25 20:03:26.0 +0100
@@ -60,6 +60,8 @@
 Depends: ${misc:Depends},
 clevis-systemd,
 dracut-network,
+Recommends:
+dracut,
 Description: Dracut integration for clevis
  Clevis is a plugable framework for automated decryption. This package
  provides integration for the dracut initramfs to automatically unlock
diff -Nru 
clevis-11/debian/patches/cherry-pick/1541598788.v11-1-g1e344db.delete-remaining-references-to-the-removed-http-pin.patch
 
clevis-11/debian/patches/cherry-pick/1541598788.v11-1-g1e344db.delete-remaining-references-to-the-removed-http-pin.patch
--- 
clevis-11/debian/patches/cherry-pick/1541598788.v11-1-g1e344db.delete-remaining-references-to-the-removed-http-pin.patch
1970-01-01 01:00:00.0 +0100
+++ 
clevis-11/debian/patches/cherry-pick/1541598788.v11-1-g1e344db.delete-remaining-references-to-the-removed-http-pin.patch
2021-01-25 19:54:44.0 +0100
@@ -0,0 +1,113 @@
+Subject: Delete remaining references to the removed http pin
+Origin: v11-1-g1e344db 
<https://github.com/latchset/clevis/commit/v11-1-g1e344db>
+Upstream-Author: Javier Martinez Canillas 
+Date: Wed Nov 7 14:53:08 2018 +0100
+Bug-Debian: https://bugs.debian.org/bug=969361
+
+Commit 800d73185d7f ("Remove HTTP pin") removed the clevis http pin, but
+there are still

Bug#981047: buster-pu: package tang/7-1

[Christoph Biedl]

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

Hello stable release team,

for the upcoming stable point release, I've just uploaded src:tang
("network-based cryptographic binding server") as version 7-1+deb10u1.
There is just one change:

* Avoid race condition between keygen and update, resulting in "Key
  derivation key not available!".

Type: upstream bug
Debian bug: https://bugs.debian.org/975343
Upstream bug: https://github.com/latchset/tang/issues/52
Fixed in in stable and testing: 7-3 (Januar 2020)

Problem: There is a race condition between two processes in the tang
ecosystem that manifests on slower hardware, resulting in an unusable
tang server.

Remark: The solution provided here and initially proposed in the
upstream bug report differs from the solution upstream and
unstable/testing - since upstream's fix came together with a massive
change of the infrastructure, and cherry-picking all this would have
been huge and rather a backport.

The new version was successfully tested on both a fast system (no
regression) and on a slow one (problem no longer manifests, broken
condition is healed upon upgrade).

Regards,

Christoph

-- System Information:
Debian Release: 10.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.10 (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 /bin/dash
Init: systemd (via /run/systemd/system)

diff -Nru tang-7/debian/changelog tang-7/debian/changelog
--- tang-7/debian/changelog 2018-08-12 00:57:45.0 +0200
+++ tang-7/debian/changelog 2021-01-25 18:37:46.0 +0100
@@ -1,3 +1,10 @@
+tang (7-1+deb10u1) buster; urgency=medium
+
+  * Avoid race condition between keygen and update, resulting in "Key
+derivation key not available!". Closees: #975343
+
+ -- Christoph Biedl   Mon, 25 Jan 2021 
18:37:46 +0100
+
 tang (7-1) unstable; urgency=medium
 
   * New upstream version 7
diff -Nru tang-7/debian/patches/local.avoid-keygen-race.patch 
tang-7/debian/patches/local.avoid-keygen-race.patch
--- tang-7/debian/patches/local.avoid-keygen-race.patch 1970-01-01 
01:00:00.0 +0100
+++ tang-7/debian/patches/local.avoid-keygen-race.patch 2021-01-25 
18:05:30.0 +0100
@@ -0,0 +1,28 @@
+Description: Avoid race condition between keygen and update, resulting in "Key 
derivation key not available!"
+Author: Christoph Biedl 
+Bug: https://github.com/latchset/tang/issues/52
+Bug-Debian: https://bugs.debian.org/975343
+Last-Update: 2021-01-25
+
+--- a/units/tangd-update.service.in
 b/units/tangd-update.service.in
+@@ -1,5 +1,7 @@
+ [Unit]
+ Description=Tang Server key update script
++Requires=tangd-keygen.service
++After=tangd-keygen.service
+ 
+ [Service]
+ Type=oneshot
+--- a/units/tangd.socket.in
 b/units/tangd.socket.in
+@@ -1,9 +1,7 @@
+ [Unit]
+ Description=Tang Server socket
+-Requires=tangd-keygen.service
+ Requires=tangd-update.service
+ Requires=tangd-update.path
+-After=tangd-keygen.service
+ After=tangd-update.service
+ 
+ [Socket]
diff -Nru tang-7/debian/patches/series tang-7/debian/patches/series
--- tang-7/debian/patches/series2018-08-12 00:57:45.0 +0200
+++ tang-7/debian/patches/series2021-01-25 18:00:51.0 +0100
@@ -1,2 +1,3 @@
 local.use-asciidoctor-to-build-manpages.patch
 local.add-systemd-documentation-key.patch
+local.avoid-keygen-race.patch


signature.asc
Description: PGP signature

Bug#977720: transition: http-parser

[Christoph Biedl]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hello,

the http-parser library should see an update from 2.9.2 (unstable) and
2.9.3 (experimental) to 2.9.4. Now I am unsure whether this requires a
transition - at least the 2.9.3 upload did not lead to an auto- entry in
the transition page.

So please advise. If I may upload to unstable right away, just let me
know and close this bug. Else I'd follow-up with all the details needed.

In case the following sheds some light on the: The name of the binary
package ("libhttp-parser2.9") does not change.

Aside, I am aware 2.9.4-1 FTB in i386, fix ist already in the queue.

Kind regards,

Christoph


signature.asc
Description: PGP signature

Bug#951399: buster-pu: package softflowd/0.9.9-5

[Christoph Biedl]

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

Hello release team,

a nasty bug made it into the Debian 10 ("buster") version of softflowd,
and I'd like to fix that in a stable point release.

Due to a broken flow aggregation, the flow table might overflow,
resulting in forced flow expiration. Which, as I was told, can lead to
constant 100% CPU usage of the softflowd process. Another effect is the
resulting flow files captured by nfcapd(1) (from the nfdump package)
are way bigger then before the upgrade, and nfcapd creating a lot of
noise in the syslog as well.

This was fixed upstream although not quite in an obvious way - thanks
to bisecting this wasn't a big problem anyway. According to tests done
by the reporter the fix ended the massive CPU usage, for the other
effects I can confirm the desired behaviour as seen in the previous
Debian 9 ("stretch") version is restored as well.

For the next stable point release, version 0.9.9-5+deb10u1 was already
uploaded to the applicable queue.

Suggested one-line description: Fix broken netflow aggregation

Regards,

Christoph

-- System Information:
Debian Release: 10.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.4.19 (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 /bin/dash
Init: unable to detect

diff -Nru softflowd-0.9.9/debian/changelog softflowd-0.9.9/debian/changelog
--- softflowd-0.9.9/debian/changelog2018-10-26 17:10:09.0 +0200
+++ softflowd-0.9.9/debian/changelog2019-12-05 00:21:02.0 +0100
@@ -1,3 +1,10 @@
+softflowd (0.9.9-5+deb10u1) buster; urgency=medium
+
+  * Fix roken flow aggregation which might result in flow table overflow
+and 100% CPU usage.
+
+ -- Christoph Biedl   Thu, 05 Dec 2019 
00:21:02 +0100
+
 softflowd (0.9.9-5) unstable; urgency=high
 
   * Don't migrate legacy config if it wasn't modified. Closes: #910214
diff -Nru 
softflowd-0.9.9/debian/patches/cherry-pick.softflowd-0.9.9-22-ge6d29a1.fix-some-bugs.patch
 
softflowd-0.9.9/debian/patches/cherry-pick.softflowd-0.9.9-22-ge6d29a1.fix-some-bugs.patch
--- 
softflowd-0.9.9/debian/patches/cherry-pick.softflowd-0.9.9-22-ge6d29a1.fix-some-bugs.patch
  1970-01-01 01:00:00.0 +0100
+++ 
softflowd-0.9.9/debian/patches/cherry-pick.softflowd-0.9.9-22-ge6d29a1.fix-some-bugs.patch
  2019-12-05 00:21:02.0 +0100
@@ -0,0 +1,68 @@
+Subject: [ Add option "-a" for reading pcap file and ] fix some bugs
+Origin: softflowd-0.9.9-22-ge6d29a1 
<https://github.com/irino/softflowd/commit/e6d29a1>
+Upstream-Author: Hitoshi Irino 
+Date: Sun May 26 23:00:41 2019 +0900
+Comment: Fixes a regression introduced in buster: The flow aggregation
+ is broken, causing a new flow to generated for virtually each packet.
+ If the daemon sees a lot of traffic, the flow table might overflow,
+ resulting in forced expiration and 100% CPU usage.
+ .
+ Thanks Johanna Jerzembeck for reporting and testing.
+
+- fix flow_compare for comparing vlan and ether
+[ - fix missing sequence in netflow v9 ]
+
+
+--- a/softflowd.c
 b/softflowd.c
+@@ -55,6 +55,8 @@
+ static int verbose_flag = 0;  /* Debugging flag */
+ static u_int16_t if_index = 0;/* "manual" interface index */
+ 
++static int track_level;
++
+ /* Signal handler flags */
+ static volatile sig_atomic_t graceful_shutdown_request = 0;   
+ 
+@@ -144,15 +146,21 @@
+ {
+   /* Be careful to avoid signed vs unsigned issues here */
+   int r;
++  if (track_level == TRACK_FULL_VLAN || track_level == 
TRACK_FULL_VLAN_ETHER) {
++  if (a->vlanid[0] != b->vlanid[0])
++  return (a->vlanid[0] > b->vlanid[0] ? 1 : -1);
++
++  if (a->vlanid[1] != b->vlanid[1])
++  return (a->vlanid[1] > b->vlanid[1] ? 1 : -1);
++}
+ 
+-  if (a->vlanid != b->vlanid)
+-  return (a->vlanid > b->vlanid ? 1 : -1);
+-
++  if (track_level == TRACK_FULL_VLAN_ETHER) {
+   if ((r = memcmp(>ethermac[0], >ethermac[0], 6)) != 0)
+   return (r > 0 ? 1 : -1);
+ 
+   if ((r = memcmp(>ethermac[1], >ethermac[1], 6)) != 0)
+   return (r > 0 ? 1 : -1);
++  }
+ 
+   if (a->af != b->af)
+   return (a->af > b->af ? 1 : -1);
+@@ -1526,7 +1534,7 @@
+ 
+   ft->param.max_flows = DEFAULT_MAX_FLOWS;
+ 
+-  ft->param.track_level = TRACK_FULL;
++  track_level = ft->param.track_level = TRACK_FULL;
+ 
+   ft->param.tcp_timeout = DEFAULT_TCP_TIMEOUT;
+   ft->param.tcp_rst_timeout = DEFAULT_TCP_RST_TIMEOUT;
+@@ -1882,6 +1890,7 @@
+   us

Bug#877258: stretch-pu: package busybox/1:1.22.0-19+deb9u1

[Christoph Biedl]

Salvatore Bonaccorso wrote...

> Is this still something we should try to get into stretch (now to late
> for 9.12 but might be possible for 9.13)?

For me, I would like to, so I'll re-visit the scenary and will try to
eventually get this done.

Christoph


signature.asc
Description: PGP signature

Bug#925251: stretch-pu: package file/1:5.30-1+deb9u2

[Christoph Biedl]

Salvatore Bonaccorso wrote...

> Is this still something it is worth to pursue and adress those two
> CVEs pending for stretch or is the regression risk to high?

In my opinion it is worth to pursue it - so let me rebase upon the
latest releas in Debian 9 ("stretch") and upload to (old)s-p-u soon,
just after another round of regression tests. Then there's a lot of time
to let things mature.

Adam (for the stable release team), can I just go ahead, or would you
like to see an updated patch first?

From the neverending story departement,

Christoph


signature.asc
Description: PGP signature

Bug#948589: nmu: file_1:5.38-3

[Christoph Biedl]

clone 948589 -1
reassign -1 file
retitle -1 file: When building the file package, use the just-built file 
program in debhelper
thanks

Andreas Beckmann wrote...

> File lists identical (after any substitutions)
> 
> Control files: lines which differ (wdiff format)
> 
> Depends: {+libbz2-1.0, libc6 (>= 2.15), liblzma5 (>= 5.1.1alpha+20120614), 
> zlib1g (>= 1:1.1.4),+} libmagic-mgc (= [-1:5.38-3.bad)-] {+1:5.38-3.good)+}
> Version: [-1:5.38-3.bad-] {+1:5.38-3.good+}
> 
> The bad one was done with 1:5.38-2, the good one with 1:5.38-3 installed.

Thanks a lot, that bit of information helped me to understand the
situation. So src:file has indeed a circular build dependency, and
while this probably does not really do harm - at least no one bothered
to report issues with that in the past (at least) twelve years -, it is
not sound.

> Attached patch is a hack to prepend a 'file' wrapper script in the path
> that uses the freshly built one (I hope I did the call right?), this allows
> for a correct libmagic1 package to be built even in the presence of the buggy
> 1:5.38-2 in the system by using the new file command during the later stages
> of the build process.

That's a good point to start at anyway. I will have to add some more
bits, like overriding dh_strip (which calls the file binary as well).

> It's probably not cross-build safe, though.

Looks like it. Possibly I can find a solution for that as well.

Christoph, now having an even longer "lessons learned" list


signature.asc
Description: PGP signature

Bug#948589: nmu: file_1:5.38-3

[Christoph Biedl]

Helmut Grohne wrote...

> The file package was built with a broken version file wrt #948269. As
> such libmagic1 lacks shared library dependencies. A simple rebuild fixes
> the problem.

This leaves me somewhat confused since I understand your rationale
the file package needs itself to be built, in other words, a circular
build dependency. This should not happen, and I'd like to eliminate
that.

Mind to shed some light on this? How was libmagic wrongly built, how did
this manifest?

(You might have noted the file build overrides dh_shlibdeps -
appearently this is not enough?)

Christoph


signature.asc
Description: PGP signature

Bug#945965: buster-pu: package bgpdump/1.6.0-1

[Christoph Biedl]

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

Hello release team,

the bgpdump package has an embarrasing bug, starting the program
results in an immediate segmentation fault, that's #945881

Luckily, a fix was fairly simple. For unstable, version 1.6.0-2 was
accepted an hour ago, for Debian 10 ("buster") I've prepared
1.6.0-1+deb10u1 to fix this via a point relase. Some extra tests
were done to make sure the program is now working as intended.

Assuming that change will be accepted I'll upload the new version in a
few moments.

Regards,

Christoph

-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)



signature.asc
Description: PGP signature

Bug#943606: stretch-pu: package libdate-holidays-de-perl/1.9-1+deb9u3

[Christoph Biedl]

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

Hello release team,

due to yet another regional holiday introduced in Thuringia, Germany,
the libdate-holidays-de-perl package needs an update in stretch.

Find the debdff attached, fix in unstable is in 2.03-1.

Some quick testing showed the expected behaviour. Assuming that change
would be accepted I'll upload the new version in a few minutes.

Regards,

Christoph

-- System Information:
Debian Release: 9.11
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-proposed-updates'), 
(500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.80 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

diff -Nru libdate-holidays-de-perl-1.9/debian/changelog 
libdate-holidays-de-perl-1.9/debian/changelog
--- libdate-holidays-de-perl-1.9/debian/changelog   2019-03-09 
22:06:42.0 +0100
+++ libdate-holidays-de-perl-1.9/debian/changelog   2019-10-27 
08:11:30.0 +0100
@@ -1,3 +1,10 @@
+libdate-holidays-de-perl (1.9-1+deb9u4) stretch; urgency=medium
+
+  * Mark International Childrens Day (Sep 20th) as a holiday in
+Thuringia from 2019 on
+
+ -- Christoph Biedl   Sun, 27 Oct 2019 
08:11:30 +0100
+
 libdate-holidays-de-perl (1.9-1+deb9u3) stretch; urgency=medium
 
   * Mark Mar 8th (from 2019) and May 8th (only 2020) as public
diff -Nru 
libdate-holidays-de-perl-1.9/debian/patches/cherry-pick.RELEASE_2.00-3-g48cbadf.add-international-childrens-day-weltkindertag-for-thuringia.patch
 
libdate-holidays-de-perl-1.9/debian/patches/cherry-pick.RELEASE_2.00-3-g48cbadf.add-international-childrens-day-weltkindertag-for-thuringia.patch
--- 
libdate-holidays-de-perl-1.9/debian/patches/cherry-pick.RELEASE_2.00-3-g48cbadf.add-international-childrens-day-weltkindertag-for-thuringia.patch
   1970-01-01 01:00:00.0 +0100
+++ 
libdate-holidays-de-perl-1.9/debian/patches/cherry-pick.RELEASE_2.00-3-g48cbadf.add-international-childrens-day-weltkindertag-for-thuringia.patch
   2019-10-27 08:11:30.0 +0100
@@ -0,0 +1,43 @@
+Subject: Add International Childrens Day (Weltkindertag) for Thuringia
+Origin: 48cbadf <https://github.com/mschmitt/Date-Holidays-DE/commit/48cbadf>
+Upstream-Author: Tobias Leich 
+Date: Mon Sep 16 11:16:07 2019 +0200
+
+--- a/DE.pm
 b/DE.pm
+@@ -51,6 +51,7 @@
+   # 17ju  = Tag der deutschen Einheit (>= 1954, <= 1990)
+   # frie  = Augsburger Friedensfest
+   # mari  = Mariae Himmelfahrt
++  # kind  = Weltkindertag
+   # 3okt  = Tag der deutschen Einheit (>= 1990)
+   # refo  = Reformationstag
+   # alhe  = Allerheiligen
+@@ -172,6 +173,9 @@
+ 
+   # Extras for Thueringen
+   @{$holidays{'th'}} = qw(refo);
++  if ($year >= 2019) {
++  push @{$holidays{'th'}}, qw(kind);
++  }
+ 
+   # Fixed-date holidays
+   #
+@@ -202,6 +206,9 @@
+   # Assumption day Aug 15
+   $holiday{'mari'} = _date2timestamp($year,  8, 15);
+ 
++  # International Childrens Day
++  $holiday{'kind'} = _date2timestamp($year,  9, 20);
++
+   # Reunion day Jun 17 (1954-1990)
+   if (($year <= 1990) and ($year >= 1954)){
+   $holiday{'17ju'} = _date2timestamp($year, 6,  17);
+@@ -426,6 +433,7 @@
+   17ju  Tag der deutschen Einheit   Reunion day (>= 1954, <= 1990)
+   frie  Augsburger Friedensfest Augsburg peace day
+   mari  Mariae Himmelfahrt  Assumption day
++  kind  Weltkindertag   International Childrens Day
+   3okt  Tag der deutschen Einheit   Reunion day (>= 1990)
+   refo  Reformationstag Reformation day
+   alhe  Allerheiligen   All hallows day
diff -Nru libdate-holidays-de-perl-1.9/debian/patches/series 
libdate-holidays-de-perl-1.9/debian/patches/series
--- libdate-holidays-de-perl-1.9/debian/patches/series  2019-03-09 
22:00:07.0 +0100
+++ libdate-holidays-de-perl-1.9/debian/patches/series  2019-10-27 
08:11:30.0 +0100
@@ -1,3 +1,7 @@
+# patches that should go upstream
 fix-typo-in-manpage.patch
 refo.patch
 mar8-may8.patch
+
+# cherry-picked commits. Keep in upstream's chronological order
+cherry-pick.RELEASE_2.00-3-g48cbadf.add-international-childrens-day-weltkindertag-for-thuringia.patch


signature.asc
Description: PGP signature

Bug#943605: buster-pu: package libdate-holidays-de-perl/2.00-2

[Christoph Biedl]

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

Hello release team,

same as in -1: libdate-holidays-de-perl needs an update in buster as well.

Christoph

-- System Information:
Debian Release: 10.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.80 (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 /bin/dash
Init: sysvinit (via /sbin/init)

diff -Nru libdate-holidays-de-perl-2.00/debian/changelog 
libdate-holidays-de-perl-2.00/debian/changelog
--- libdate-holidays-de-perl-2.00/debian/changelog  2019-02-10 
22:35:46.0 +0100
+++ libdate-holidays-de-perl-2.00/debian/changelog  2019-10-27 
08:22:21.0 +0100
@@ -1,3 +1,10 @@
+libdate-holidays-de-perl (2.00-2+deb10u1) buster; urgency=medium
+
+  * Mark International Childrens Day (Sep 20th) as a holiday in
+Thuringia from 2019 on
+
+ -- Christoph Biedl   Sun, 27 Oct 2019 
08:22:21 +0100
+
 libdate-holidays-de-perl (2.00-2) unstable; urgency=medium
 
   * Mark Mar 8th (from 2019) and May 8th (only 2020) as public
diff -Nru 
libdate-holidays-de-perl-2.00/debian/patches/cherry-pick.RELEASE_2.00-3-g48cbadf.add-international-childrens-day-weltkindertag-for-thuringia.patch
 
libdate-holidays-de-perl-2.00/debian/patches/cherry-pick.RELEASE_2.00-3-g48cbadf.add-international-childrens-day-weltkindertag-for-thuringia.patch
--- 
libdate-holidays-de-perl-2.00/debian/patches/cherry-pick.RELEASE_2.00-3-g48cbadf.add-international-childrens-day-weltkindertag-for-thuringia.patch
  1970-01-01 01:00:00.0 +0100
+++ 
libdate-holidays-de-perl-2.00/debian/patches/cherry-pick.RELEASE_2.00-3-g48cbadf.add-international-childrens-day-weltkindertag-for-thuringia.patch
  2019-10-27 08:11:57.0 +0100
@@ -0,0 +1,43 @@
+Subject: Add International Childrens Day (Weltkindertag) for Thuringia
+Origin: 48cbadf <https://github.com/mschmitt/Date-Holidays-DE/commit/48cbadf>
+Upstream-Author: Tobias Leich 
+Date: Mon Sep 16 11:16:07 2019 +0200
+
+--- a/DE.pm
 b/DE.pm
+@@ -51,6 +51,7 @@
+   # 17ju  = Tag der deutschen Einheit (>= 1954, <= 1990)
+   # frie  = Augsburger Friedensfest
+   # mari  = Mariae Himmelfahrt
++  # kind  = Weltkindertag
+   # 3okt  = Tag der deutschen Einheit (>= 1990)
+   # refo  = Reformationstag
+   # alhe  = Allerheiligen
+@@ -172,6 +173,9 @@
+ 
+   # Extras for Thueringen
+   @{$holidays{'th'}} = qw(refo);
++  if ($year >= 2019) {
++  push @{$holidays{'th'}}, qw(kind);
++  }
+ 
+   # Fixed-date holidays
+   #
+@@ -202,6 +206,9 @@
+   # Assumption day Aug 15
+   $holiday{'mari'} = _date2timestamp($year,  8, 15);
+ 
++  # International Childrens Day
++  $holiday{'kind'} = _date2timestamp($year,  9, 20);
++
+   # Reunion day Jun 17 (1954-1990)
+   if (($year <= 1990) and ($year >= 1954)){
+   $holiday{'17ju'} = _date2timestamp($year, 6,  17);
+@@ -426,6 +433,7 @@
+   17ju  Tag der deutschen Einheit   Reunion day (>= 1954, <= 1990)
+   frie  Augsburger Friedensfest Augsburg peace day
+   mari  Mariae Himmelfahrt  Assumption day
++  kind  Weltkindertag   International Childrens Day
+   3okt  Tag der deutschen Einheit   Reunion day (>= 1990)
+   refo  Reformationstag Reformation day
+   alhe  Allerheiligen   All hallows day
diff -Nru libdate-holidays-de-perl-2.00/debian/patches/series 
libdate-holidays-de-perl-2.00/debian/patches/series
--- libdate-holidays-de-perl-2.00/debian/patches/series 2019-02-10 
22:23:02.0 +0100
+++ libdate-holidays-de-perl-2.00/debian/patches/series 2019-10-27 
08:22:21.0 +0100
@@ -1 +1,5 @@
+# patches that should go upstream
 mar8-may8.patch
+
+# cherry-picked commits. Keep in upstream's chronological order
+cherry-pick.RELEASE_2.00-3-g48cbadf.add-international-childrens-day-weltkindertag-for-thuringia.patch


signature.asc
Description: PGP signature

Bug#933685: transition: http-parser

[Christoph Biedl]

Jonathan Wiltshire wrote...

> On Mon, Aug 05, 2019 at 12:12:46AM +0200, Christoph Biedl wrote:

> > Thanks, now uploaded to unstable.
>
> Just one failure, in python-httptools
> https://buildd.debian.org/status/package.php?p=python-httptools

Yep, Bug report with upstream fix filed as #933684

My plan is to NMU at the weekend.

Christoph



signature.asc
Description: PGP signature

Bug#933685: transition: http-parser

[Christoph Biedl]

Jonathan Wiltshire wrote...

> Control: tag -1 confirmed
> 
> On Thu, Aug 01, 2019 at 10:12:08PM +0200, Christoph Biedl wrote:
> > following the procedures as written in the Debian wiki, I am requesting
> > a transition slot for the http-parser library 2.9.2, accepted in
> > experimental earlier today.
> 
> Please go ahead in unstable.

Thanks, now uploaded to unstable.

Christoph


signature.asc
Description: PGP signature

Bug#881629: transition: http-parser

[Christoph Biedl]

Christoph Biedl wrote...

> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition

Hm, while checking the BTS for the http-parser transition filed
yesterday I noticed this one here - from an earlier transition - is
still open for no apparent reason.

So, just for cleanliness, what to do? It it's expected the package
maintainer closes the bug: I'll happy to do so, but please leave an
according note in the Wiki, then.

All the best,

Christoph


signature.asc
Description: PGP signature

Bug#933685: transition: http-parser

[Christoph Biedl]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hello,

following the procedures as written in the Debian wiki, I am requesting
a transition slot for the http-parser library 2.9.2, accepted in
experimental earlier today.

A test rebuild of all the the packages listed at the transition page¹
result in one failure:

* python-httptools 0.0.11-1
  Bug report with upstream fix filed as #933684

All other packages passed:

* jabberd2 2.7.0-1
* libgit2 0.27.7+dfsg.1-0.2
* ocserv 0.12.2-3
* purple-matrix 0.0.0+git20180325-1
* ruby-http-parser.rb 0.6.0-4
* tang 7-1
* tcpflow 1.5.2+repack1-1

Kind regards,

Christoph

¹ https://release.debian.org/transitions/html/auto-http-parser.html


Ben file:

title = "http-parser";
is_affected = .depends ~ /\b(libhttp\-parser2\.8)\b/ | .depends ~ 
/\b(libhttp\-parser2\.9)\b/;
is_good = .depends ~ /\b(libhttp\-parser2\.9)\b/;
is_bad = .depends ~ /\b(libhttp\-parser2\.8)\b/;



signature.asc
Description: PGP signature

Bug#925251: stretch-pu: package file/1:5.30-1+deb9u2

[Christoph Biedl]

Adam D. Barratt wrote...

> Assuming I count correctly, your mail was from approximately 6 weeks
> before the date of the upcoming 9.9 point release.

This story has a tendency to fall off radar repeatedly. Perhaps we can
eventually find a solution for this in the next days?

Christoph


signature.asc
Description: PGP signature

Bug#925251: stretch-pu: package file/1:5.30-1+deb9u2

[Christoph Biedl]

Adam D. Barratt wrote...

> On Thu, 2019-03-21 at 20:28 +0100, Christoph Biedl wrote:
> > for an upcoming stretch point release, I'd like to contribute a new
> > version of the file package. This got a bit bigger so I'm using the
> > old style of seeking approval before uploading.
> [...]
> > So this escalated at little, and instead of picking a single commit,
> > I ended with the number of 26 ... But I am certain it's worth it.
> >
> > Still there is an increased risk of introducing regressions,
> > therefore I'd like to give that package some time to mature. Hence no
> > security release, and if there are major concerns I might agree to
> > wait until the second-next point release if the next one is less then
> > four weeks in the future.
>
> Apologies for not getting back to you sooner.

Umm, well, same here.

> > For my side, I did my usual checks, they all passed: The output of
> > file on a huge collection (>> 100k) of various files, diffing the
> > buildlogs, checking some packages that heavily depend on
> > file/libmagic. So I'm optimistic there is no change for worse.
>
> That sounds promising. Has the package been tested on any further
> systems in the meantime?

Just a little - to be honest, I'm out of ideas what else to test.

Christoph


signature.asc
Description: PGP signature

Bug#925251: stretch-pu: package file/1:5.30-1+deb9u2

[Christoph Biedl]

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

Hello release team,

for an upcoming stretch point release, I'd like to contribute a new
version of the file package. This got a bit bigger so I'm using the old
style of seeking approval before uploading.

Initially, there were two bugs I wanted to fix:

* #902796: /usr/lib/python2.7/dist-packages/magic.py: Aborts; too many 
arguments to str()
Some Python 2.7 code croaks over a bug in the Python bindings.

* #922968: CVE-2019-8905 CVE-2019-8907
After some discussion with the security team (Cc:) I decided to
address this in a point release.

However, while checking the latter, I realized upstream did a lot of
changes in the code since the 5.30 release which the stretch version is
based on. Changes that fix several issues of the (at least) "oh, that's
not good" category: Commit messages like "found by oss-fuzz", "found by
coverity" or "out of boundary read" suggest they are worth to pick even
if there's not an exploit around (I'm not aware of any TBH).

Additionally, some commits introduce changes that should ease applying
future fixes while not changing actual functionality, like switching to
an abstraction of type casting (CAST, RCAST).

So this escalated at little, and instead of picking a single commit, I
ended with the number of 26 ... But I am certain it's worth it.

Still there is an increased risk of introducing regressions, therefore
I'd like to give that package some time to mature. Hence no security
release, and if there are major concerns I might agree to wait until
the second-next point release if the next one is less then four weeks
in the future.

For my side, I did my usual checks, they all passed: The output of file
on a huge collection (>> 100k) of various files, diffing the buildlogs,
checking some packages that heavily depend on file/libmagic. So I'm
optimistic there is no change for worse.

Additionally, and without changing code, I've updated the description
of patches cherry-picked earlier: Adding a URL to the Origin:
information aims to ease the job of reviewers downstream and anywhere
else.

Regards,

Christoph

diff -Nru file-5.30/debian/changelog file-5.30/debian/changelog
--- file-5.30/debian/changelog  2018-06-11 23:16:09.0 +0200
+++ file-5.30/debian/changelog  2019-03-18 22:15:18.0 +0100
@@ -1,3 +1,12 @@
+file (1:5.30-1+deb9u3) stable; urgency=high
+
+  * Cherry-pick upstream commit FILE5_30-37-g8a942980 "Retain python 2
+compatibility". Closes: #902796
+  * Cherry-pick a lot of patches that fix obvious issues or seem wise
+to include. Also: Closes: #922968 [CVE-2019-8905 CVE-2019-8907]
+
+ -- Christoph Biedl   Mon, 18 Mar 2019 
22:15:18 +0100
+
 file (1:5.30-1+deb9u2) stable; urgency=high
 
   * Avoid reading past the end of buffer. Closes: #901351
diff -Nru 
file-5.30/debian/patches/cherry-pick.FILE5_30-01-g64e45647.more-cast-stuff.patch
 
file-5.30/debian/patches/cherry-pick.FILE5_30-01-g64e45647.more-cast-stuff.patch
--- 
file-5.30/debian/patches/cherry-pick.FILE5_30-01-g64e45647.more-cast-stuff.patch
2018-06-11 23:14:41.0 +0200
+++ 
file-5.30/debian/patches/cherry-pick.FILE5_30-01-g64e45647.more-cast-stuff.patch
2019-03-18 22:15:18.0 +0100
@@ -1,5 +1,5 @@
 Subject: More cast stuff
-Origin: FILE5_30-1-g64e45647
+Origin: FILE5_30-1-g64e45647 
<https://github.com/file/file/commit/FILE5_30-1-g64e45647>
 Upstream-Author: Christos Zoulas 
 Date: Fri Feb 10 18:14:01 2017 +
 
diff -Nru 
file-5.30/debian/patches/cherry-pick.FILE5_30-11-gb1b4efea.pr-598-off-by-one.patch
 
file-5.30/debian/patches/cherry-pick.FILE5_30-11-gb1b4efea.pr-598-off-by-one.patch
--- 
file-5.30/debian/patches/cherry-pick.FILE5_30-11-gb1b4efea.pr-598-off-by-one.patch
  2018-06-11 23:14:41.0 +0200
+++ 
file-5.30/debian/patches/cherry-pick.FILE5_30-11-gb1b4efea.pr-598-off-by-one.patch
  2019-03-18 22:15:18.0 +0100
@@ -1,5 +1,5 @@
 Subject: PR/598: Off-by-one
-Origin: FILE5_30-11-gb1b4efea
+Origin: FILE5_30-11-gb1b4efea 
<https://github.com/file/file/commit/FILE5_30-11-gb1b4efea>
 Upstream-Author: Christos Zoulas 
 Date: Tue Mar 7 22:36:10 2017 +
 
diff -Nru 
file-5.30/debian/patches/cherry-pick.FILE5_30-12-g77a7041f.prevent-reading-beyond-our-buffer-when-compacting-whitespace-oss-fuzz.patch
 
file-5.30/debian/patches/cherry-pick.FILE5_30-12-g77a7041f.prevent-reading-beyond-our-buffer-when-compacting-whitespace-oss-fuzz.patch
--- 
file-5.30/debian/patches/cherry-pick.FILE5_30-12-g77a7041f.prevent-reading-beyond-our-buffer-when-compacting-whitespace-oss-fuzz.patch
  2018-06-11 23:14:41.0 +0200
+++ 
file-5.30/debian/patches/cherry-pick.FILE5_30-12-g77a7041f.prevent-reading-beyond-our-buffer-when-compacting-whitespace-oss-fuzz.patch
  2019-03-18 22:15:18.0 +0100
@@ -1,5 +1,5 @@
 Subject: Prevent reading beyond our buffer w

Bug#877258: stretch-pu: package busybox/1:1.22.0-19+deb9u1

[Christoph Biedl]

Cyril Brulebois wrote...

> p-u NEW usually gets frozen a week before the point release. Having the
> package to review/test a week before that (so 2 weeks before the point
> release date) would be awesome. Depending on external things, I could
> still make time if that's only a few days before the freeze, but a full
> week should help ensure reviewing/testing happens in time.

Okay, I'll try to get this finally done within the next week.

Christoph


signature.asc
Description: PGP signature

Bug#877258: stretch-pu: package busybox/1:1.22.0-19+deb9u1

[Christoph Biedl]

Adam D. Barratt wrote...

> Folks, what's the current status here?

It's not forgotten, but now quite outdated. There are several more fixes
that should go into the stretch version of busybox. I will take care of
this in the next days.

Cyril, you previously mentioned the submission was too close to the
deadline to check before granting approval from the installer team
side. Can you give me an idea how much time you need for review before
a future point release, so I can plan accordingly?

Christoph


signature.asc
Description: PGP signature

Bug#924150: stretch-pu: package libdate-holidays-de-perl/1.9-1+deb9u3

[Christoph Biedl]

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

As I wrote in #902042:

> FWIW, there are currently no further plans to change holidays in
> Germany, so this is hopefully the last update for a long time.

This did not hold. So another round: This time Berlin introduced two
more public holidays, March 8th from 2019 on (first one already passed),
and May 8th one time in 2020.

To keep libdate-holidays-de-perl in sync, I've prepared 1.9-1+deb9u3.
The related upload for sid (2.00-2) happened already a few weeks ago and
has migrated to testing in the meantime. Upload to 9/stretch/stable will
follow in a moment, following the stable release policy change last
year.

Kind regards,

Christoph


signature.asc
Description: PGP signature

Contradicting mails from "testing autoremoval watch" and "testing watch"

[Christoph Biedl]

Hi,

at first: No offense taken. Just a bit confused, and I think the
underlying processes could use an improvement.

This morning, I found two mails in my box:

| From: Debian testing autoremoval watch 
+ Subject: clevis is marked for autoremoval from testing
| To: cle...@packages.debian.org
| Message-Id: 
| Date: Mon, 05 Nov 2018 04:39:06 +
|
| clevis 10-2 is marked for autoremoval from testing on 2018-11-26

and a few seconds later:

| From: Debian testing watch 
+ Subject: clevis 11-1 MIGRATED to testing
| To: cle...@packages.debian.org
| Message-Id: 
| Date: Mon, 05 Nov 2018 04:39:16 +

Checking testing, the migration actually happened. So I cannot see any
reason why the first message was generated at all. Mind to check?

Kind regards,

Christoph


signature.asc
Description: PGP signature

Re: Building armel on arm64

[Christoph Biedl]

Adrian Bunk wrote...

> I'd like to get a clear picture regarding the situation of building 
> armel for buster on arm64, ideally moving it to arm64 hardwre soon.

JFTR, I'd appreciate if armel/armhf could continue to be part of a
release.

> 1. What issues are considered possible problems for moving building
>armel from 32bit v7 hardware to 64bit v8 hardware?

Perhaps just babble and FUD: There was (and probably still is) an issue
in powerpc: In a certain package, upstream's compile options for ppc had
higher CPU requirements than what Debian uses for that architecture. As
a result, the buildd (some big IBM POWER box) happily built the package,
but out there on a G4 the code would crash for SIGILL, same when
rebuilding on such a hardware.

Now I'm somewhat afraid this might happen again when packages for
armel/armhf are built on more recent hardware. At the same time, I'd
like to see continued support for these architectures.

If this is a concern, how to solve it? Have some native non-DSA
armel/armhf boxes where volunteers rebuild the archive and hope test
suites will catch such issues?

My 2¢

Christoph


signature.asc
Description: PGP signature

Bug#902042: stretch-pu: package libdate-holidays-de-perl/1.9-1+deb9u1

[Christoph Biedl]

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

Hello release team,

in continuation of #891807: Two more states in Germany made Reformation
Day (Oct 31st) a holiday. To keep libdate-holidays-de-perl in sync,
I've prepared 1.9-1+deb9u2. The related upload for sid (1.9-3) has been
accepted a few minutes ago. Upload to 9/stretch/stable will follow in a
moment, following the new stable release policy.

FWIW, there are currently no further plans to change holidays in
Germany, so this is hopefully the last update for a long time.

Kind regards,

Christoph

-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.48 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

diff -Nru libdate-holidays-de-perl-1.9/debian/changelog 
libdate-holidays-de-perl-1.9/debian/changelog
--- libdate-holidays-de-perl-1.9/debian/changelog   2018-03-01 
00:06:15.0 +0100
+++ libdate-holidays-de-perl-1.9/debian/changelog   2018-06-21 
20:40:29.0 +0200
@@ -1,3 +1,10 @@
+libdate-holidays-de-perl (1.9-1+deb9u2) stretch; urgency=medium
+
+  * Mark Reformation Day as a holiday in Niedersachsen and Bremen
+from 2018 on
+
+ -- Christoph Biedl   Thu, 21 Jun 2018 
20:40:29 +0200
+
 libdate-holidays-de-perl (1.9-1+deb9u1) stretch; urgency=low
 
   * Mark Reformation Day as a holiday in Hamburg and
diff -Nru libdate-holidays-de-perl-1.9/debian/patches/refo.patch 
libdate-holidays-de-perl-1.9/debian/patches/refo.patch
--- libdate-holidays-de-perl-1.9/debian/patches/refo.patch  2018-03-01 
00:06:05.0 +0100
+++ libdate-holidays-de-perl-1.9/debian/patches/refo.patch  2018-06-21 
20:40:21.0 +0200
@@ -1,17 +1,20 @@
 Subject: Add new regional holidays from 2018 on
 Author: Christoph Biedl 
 Forwarded: https://rt.cpan.org/Ticket/Display.html?id=124559
-Last-Update: 2018-02-28
+Last-Update: 2018-06-21
 
-Sources (in German):
-Schleswig-Holstein:
-
http://www.spiegel.de/karriere/reformationstag-wird-in-schleswig-holstein-neuer-feiertag-a-1195092.html
-Hamburg:
-
http://www.spiegel.de/karriere/hamburg-reformationstag-wird-feiertag-a-1195881.html
+Source (in German):
+https://de.wikipedia.org/wiki/Reformationstag#Deutschland
 
 --- a/DE.pm
 +++ b/DE.pm
-@@ -121,6 +121,9 @@
+@@ -118,9 +118,15 @@
+ 
+   # Extras for Bremen
+   @{$holidays{'hb'}} = qw();
++  if ($year >= 2018) {
++  push @{$holidays{'hb'}}, qw(refo);
++  }
  
# Extras for Hamburg
@{$holidays{'hh'}} = qw();
@@ -21,7 +24,17 @@
  
# Extras for Hessen
@{$holidays{'he'}} = qw(fron);
-@@ -148,6 +151,9 @@
+@@ -130,6 +136,9 @@
+ 
+   # Extras for Niedersachsen
+   @{$holidays{'ni'}} = qw();
++  if ($year >= 2018) {
++  push @{$holidays{'ni'}}, qw(refo);
++  }
+ 
+   # Extras for Nordrhein-Westfalen
+   @{$holidays{'nw'}} = qw(fron alhe);
+@@ -148,6 +157,9 @@
  
# Extras for Schleswig-Holstein
@{$holidays{'sh'}} = qw();


signature.asc
Description: PGP signature

Bug#901425: jessie-pu: package file/1:5.22+15-2+deb8u3

[Christoph Biedl]

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

Hello release team,

yet another security issue was found in file/libmagic: "The do_core_note
function in readelf.c in libmagic.a in file 5.33 allows remote attackers
to cause a denial of service (out-of-bounds read and application crash)
via a crafted ELF file" (CVE-2018-10360)

https://security-tracker.debian.org/tracker/CVE-2018-10360
https://bugs.debian.org/901351

After a brief discussion with the security team we agreed this should be
addressed in the upcoming point release, so here we go.

Following the new policy, I've already uploaded file_5.22+15-2+deb8u4 to
oldstable.

Kind regards,

    Christoph Biedl

-- System Information:
Debian Release: 8.10
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-proposed-updates'), 
(500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.48 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

diff -Nru file-5.22+15/debian/changelog file-5.22+15/debian/changelog
--- file-5.22+15/debian/changelog   2016-12-04 10:00:07.0 +0100
+++ file-5.22+15/debian/changelog   2018-06-11 23:24:19.0 +0200
@@ -1,3 +1,10 @@
+file (1:5.22+15-2+deb8u4) oldstable; urgency=high
+
+  * Avoid reading past the end of buffer. Closes: #901351
+[CVE-2018-10360]
+
+ -- Christoph Biedl   Mon, 11 Jun 2018 
23:24:19 +0200
+
 file (1:5.22+15-2+deb8u3) stable; urgency=medium
 
   * Fix memory leak in magic loader. Closes: #840754
diff -Nru 
file-5.22+15/debian/patches/cherry-pick.FILE5_33-31-ga642587a.avoid-reading-past-the-end-of-buffer.patch
 
file-5.22+15/debian/patches/cherry-pick.FILE5_33-31-ga642587a.avoid-reading-past-the-end-of-buffer.patch
--- 
file-5.22+15/debian/patches/cherry-pick.FILE5_33-31-ga642587a.avoid-reading-past-the-end-of-buffer.patch
1970-01-01 01:00:00.0 +0100
+++ 
file-5.22+15/debian/patches/cherry-pick.FILE5_33-31-ga642587a.avoid-reading-past-the-end-of-buffer.patch
2018-06-11 23:24:19.0 +0200
@@ -0,0 +1,19 @@
+Subject: Avoid reading past the end of buffer (Rui Reis)
+ID: CVE-2018-10360
+Origin: FILE5_33-31-ga642587a
+Upstream-Author: Christos Zoulas 
+Date: Sat Jun 9 16:00:06 2018 +
+Bug-Debian: https://bugs.debian.org/901351
+
+--- a/src/readelf.c
 b/src/readelf.c
+@@ -789,7 +789,8 @@
+ 
+   cname = (unsigned char *)
+   [doff + prpsoffsets(i)];
+-  for (cp = cname; *cp && isprint(*cp); cp++)
++  for (cp = cname; cp < nbuf + size && *cp
++  && isprint(*cp); cp++)
+   continue;
+   /*
+* Linux apparently appends a space at the end
diff -Nru file-5.22+15/debian/patches/series file-5.22+15/debian/patches/series
--- file-5.22+15/debian/patches/series  2016-12-04 09:50:30.0 +0100
+++ file-5.22+15/debian/patches/series  2018-06-11 23:23:32.0 +0200
@@ -15,3 +15,4 @@
 CVE-2015-8865.6713ca4.patch
 
cherry-pick.FILE5_24-31-g3aa35aa.dont-leak-memory-when-loading-non-compiled-files.patch
 cherry-pick.FILE5_28-42-g10ee4ec.pr-569-shi-yin-fix-memory-leak.patch
+cherry-pick.FILE5_33-31-ga642587a.avoid-reading-past-the-end-of-buffer.patch


signature.asc
Description: PGP signature

Bug#901426: stretch-pu: package file/1:5.30-1+deb9u1

[Christoph Biedl]

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

Hello release team,

[ same as for jessie in #-1, so just for completeness ]

yet another security issue was found in file/libmagic: "The do_core_note 
function in readelf.c in libmagic.a in file 5.33 allows remote attackers
to cause a denial of service (out-of-bounds read and application crash)
via a crafted ELF file" (CVE-2018-10360)

https://security-tracker.debian.org/tracker/CVE-2018-10360
https://bugs.debian.org/901351

After a brief discussion with the security team we agreed this should be
addressed in the upcoming point release, so here we go.

Following the new policy, I've already uploaded file_5.30-1+deb9u2 to
stable.

Kind regards,

    Christoph Biedl

-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.48 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

diff -Nru file-5.30/debian/changelog file-5.30/debian/changelog
--- file-5.30/debian/changelog  2017-09-01 21:23:02.0 +0200
+++ file-5.30/debian/changelog  2018-06-11 23:16:09.0 +0200
@@ -1,3 +1,10 @@
+file (1:5.30-1+deb9u2) stable; urgency=high
+
+  * Avoid reading past the end of buffer. Closes: #901351
+[CVE-2018-10360]
+
+ -- Christoph Biedl   Mon, 11 Jun 2018 
23:16:09 +0200
+
 file (1:5.30-1+deb9u1) stretch-security; urgency=high
 
   * Non-maintainer upload by the Security Team.
diff -Nru 
file-5.30/debian/patches/cherry-pick.FILE5_33-31-ga642587a.avoid-reading-past-the-end-of-buffer.patch
 
file-5.30/debian/patches/cherry-pick.FILE5_33-31-ga642587a.avoid-reading-past-the-end-of-buffer.patch
--- 
file-5.30/debian/patches/cherry-pick.FILE5_33-31-ga642587a.avoid-reading-past-the-end-of-buffer.patch
   1970-01-01 01:00:00.0 +0100
+++ 
file-5.30/debian/patches/cherry-pick.FILE5_33-31-ga642587a.avoid-reading-past-the-end-of-buffer.patch
   2018-06-11 23:16:09.0 +0200
@@ -0,0 +1,19 @@
+Subject: Avoid reading past the end of buffer (Rui Reis)
+ID: CVE-2018-10360
+Origin: FILE5_33-31-ga642587a
+Upstream-Author: Christos Zoulas 
+Date: Sat Jun 9 16:00:06 2018 +
+Bug-Debian: https://bugs.debian.org/901351
+
+--- a/src/readelf.c
 b/src/readelf.c
+@@ -824,7 +824,8 @@
+ 
+   cname = (unsigned char *)
+   [doff + prpsoffsets(i)];
+-  for (cp = cname; *cp && isprint(*cp); cp++)
++  for (cp = cname; cp < nbuf + size && *cp
++  && isprint(*cp); cp++)
+   continue;
+   /*
+* Linux apparently appends a space at the end
diff -Nru file-5.30/debian/patches/series file-5.30/debian/patches/series
--- file-5.30/debian/patches/series 2017-09-01 21:23:02.0 +0200
+++ file-5.30/debian/patches/series 2018-06-11 23:15:30.0 +0200
@@ -25,6 +25,7 @@
 cherry-pick.FILE5_30-49-gbf90083a.fix-memory-handling.patch
 cherry-pick.FILE5_30-52-gd8233d09.check-one-more-read-found-by-oss-fuzz.patch
 
cherry-pick.FILE5_31-36-g35c94dc6.Fix-always-true-condition-Thomas-Jarosch.patch
+cherry-pick.FILE5_33-31-ga642587a.avoid-reading-past-the-end-of-buffer.patch
 
 # local modifications
 local.support-local-definitions-in-etc-magic.patch


signature.asc
Description: PGP signature

Bug#895571: transition: http-parser

[Christoph Biedl]

Emilio Pozuelo Monfort wrote...

> Go ahead.

Thanks for the swift response, much appreciated. Now uploaded to
unstable.

Christoph


signature.asc
Description: PGP signature

Bug#895571: transition: http-parser

[Christoph Biedl]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hello release team,

the http-parser library saw another soname bump, so I'm hereby asking
for a transition.

The new version 2.8.1-1~exp1 was uploaded to experimental a few days
ago, rebuild for the dependencies as below was successful:

jabberd22.6.1-3
libgit2 0.26.0+dfsg.1-1.1
nodejs  (*)
ocserv  0.11.9-1
purple-matrix   0.0.0+git20180325-1
ruby-http-parser.rb 0.6.0-4
sssd1.16.1-1
tang6-1
tcpflow 1.4.5+repack1-4

(*) This was tested by the nodejs maintainer, build logs are here:
https://buildd.debian.org/status/fetch.php?pkg=nodejs=amd64=8.11.1~dfsg-1=1523420093=0

Ben file (as created by reportbug):

title = "http-parser";
is_affected = .depends ~ "libhttp-parser2.7.1" | .depends ~ "libhttp-parser2.8";
is_good = .depends ~ "libhttp-parser2.8";
is_bad = .depends ~ "libhttp-parser2.7.1";


If you need more information, just drop a line.

Regards,

Christoph



signature.asc
Description: PGP signature

Bug#891807: stretch-pu: package libdate-holidays-de-perl/1.9-1

[Christoph Biedl]

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

Hello release team,

some states in Germany are about to make Reformation Day (Oct 31st) a
new holiday. So far, Hamburg and Schleswig-Holstein have passed
according laws, see the patch below for details. In order to avoid
confusion, I'd like to update libdate-holidays-de-perl in stretch, a
module to determine German holiday dates.

The debdiff is attached.

Regards,

Christoph
diff -Nru libdate-holidays-de-perl-1.9/debian/changelog 
libdate-holidays-de-perl-1.9/debian/changelog
--- libdate-holidays-de-perl-1.9/debian/changelog   2016-12-04 
16:59:55.0 +0100
+++ libdate-holidays-de-perl-1.9/debian/changelog   2018-03-01 
00:06:15.0 +0100
@@ -1,3 +1,10 @@
+libdate-holidays-de-perl (1.9-1+deb9u1) stretch; urgency=low
+
+  * Mark Reformation Day as a holiday in Hamburg and
+Schleswig-Holstein from 2018 on
+
+ -- Christoph Biedl <debian.a...@manchmal.in-ulm.de>  Thu, 01 Mar 2018 
00:06:15 +0100
+
 libdate-holidays-de-perl (1.9-1) unstable; urgency=low
 
   * Initial Release. Closes: #829833
diff -Nru libdate-holidays-de-perl-1.9/debian/patches/refo.patch 
libdate-holidays-de-perl-1.9/debian/patches/refo.patch
--- libdate-holidays-de-perl-1.9/debian/patches/refo.patch  1970-01-01 
01:00:00.0 +0100
+++ libdate-holidays-de-perl-1.9/debian/patches/refo.patch  2018-03-01 
00:06:05.0 +0100
@@ -0,0 +1,33 @@
+Subject: Add new regional holidays from 2018 on
+Author: Christoph Biedl <debian.a...@manchmal.in-ulm.de>
+Forwarded: https://rt.cpan.org/Ticket/Display.html?id=124559
+Last-Update: 2018-02-28
+
+Sources (in German):
+Schleswig-Holstein:
+
http://www.spiegel.de/karriere/reformationstag-wird-in-schleswig-holstein-neuer-feiertag-a-1195092.html
+Hamburg:
+
http://www.spiegel.de/karriere/hamburg-reformationstag-wird-feiertag-a-1195881.html
+
+--- a/DE.pm
 b/DE.pm
+@@ -121,6 +121,9 @@
+ 
+   # Extras for Hamburg
+   @{$holidays{'hh'}} = qw();
++  if ($year >= 2018) {
++  push @{$holidays{'hh'}}, qw(refo);
++  }
+ 
+   # Extras for Hessen
+   @{$holidays{'he'}} = qw(fron);
+@@ -148,6 +151,9 @@
+ 
+   # Extras for Schleswig-Holstein
+   @{$holidays{'sh'}} = qw();
++  if ($year >= 2018) {
++  push @{$holidays{'sh'}}, qw(refo);
++  }
+ 
+   # Extras for Thueringen
+   @{$holidays{'th'}} = qw(refo);
diff -Nru libdate-holidays-de-perl-1.9/debian/patches/series 
libdate-holidays-de-perl-1.9/debian/patches/series
--- libdate-holidays-de-perl-1.9/debian/patches/series  2016-12-04 
16:59:55.0 +0100
+++ libdate-holidays-de-perl-1.9/debian/patches/series  2018-03-01 
00:06:05.0 +0100
@@ -1 +1,2 @@
 fix-typo-in-manpage.patch
+refo.patch


signature.asc
Description: PGP signature

Bug#891285: stretch-pu: package inputlirc/23-2+b2

[Christoph Biedl]

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

Hello release team,

with maintainer's permission (Cc'd, see #879458) I'd like to fix the
inputlirc package in the upcoming stretch point release, see debdiff
below.

Some background if I understood correctly: During build, inputlirc picks
some information from a kernel header file. However, that header file
was split in linux kernel commit v4.3-rc4-49-gf902dd893427, subsequently
some definitions were no longer found. Obviously, the binNMU leading to
23-2+b2 was already done after the kernel header package in Debian
was updated, resulting the the described behaviour.

Kind regards,

Christoph
diff -u inputlirc-23/debian/changelog inputlirc-23/debian/changelog
--- inputlirc-23/debian/changelog
+++ inputlirc-23/debian/changelog
@@ -1,3 +1,10 @@
+inputlirc (23-2+deb9u1) stretch; urgency=medium
+
+  * Include input-event-codes.h instead of input.h. Closes: #879458
+Thanks to Ingo Schneider for reporting the bug and providing the fix.
+
+ -- Christoph Biedl <debian.a...@manchmal.in-ulm.de>  Sat, 24 Feb 2018 
09:25:27 +0100
+
 inputlirc (23-2) unstable; urgency=medium
 
   * Set Architecture: linux-any, since inputlirc depends on the Linux input
only in patch2:
unchanged:
--- inputlirc-23.orig/Makefile
+++ inputlirc-23/Makefile
@@ -27,7 +27,7 @@
 
 all: $(SBIN)
 
-names.h: /usr/include/linux/input.h gennames
+names.h: /usr/include/linux/input-event-codes.h gennames
./gennames $< > $@
 
 inputlircd: inputlircd.c /usr/include/linux/input.h names.h


signature.asc
Description: PGP signature

Upcoming source transition of python-magic

[Christoph Biedl]

Hello release team,

there is a python-magic (here and always: also python3-magic) package,
in the archive, currently built from src:file. For reasons I plan to
switch to another implementation which is provided by src:python-magic
(ITP was #877849, and it has all the gory details).

So two binary packages will have a change in the source they were built
from. Is this something I should inform you beforehand, or are there
other gotchas I should be aware of?

My plan is as follows:

Current situation:

   In sid, python-magic is built from src:file (currently 1:5.32-1)
   In experimental, python-magic is built from src:python-magic
   (2:0.4.15-1~exp2)

After a lot of testing (see the call for tests in debian-devel):

   Upload of python-magic to sid
   This will supersede the binary packages built from src:file

Wait until src:python-magic has migrated to testing.

   Upload of a new file version to sid
   This new version will no longer ship python-magic packages.

So if you see a problem with this, wish to schedule this around some
transitions, or anything else like that, let me know.

Kind regards,

Christoph


signature.asc
Description: Digital signature

Bug#877258: stretch-pu: package busybox/1:1.22.0-19+deb9u1

[Christoph Biedl]

Second attempt, updated debdiff attached.

Changes:

also address:

+  * Fix integer overflow in bzip2 decompresson.
+Closes: #879732 [CVE-2017-15873]
+  * Filter out terminal escape sequence filtering in autocompletion.
+Closes: #882258 [CVE-2017-16544]

A call for tests was sent to debian-boot three days ago¹, no
reaction though.

Assuming your

> I'd be happy with this in general, but the udeb means we need an
> explicit d-i RM ack; CCing appropriately.

still applies, Cc: is set accordingly.

Regards,

Christoph

¹ https://lists.debian.org/debian-boot/2017/11/msg00379.html
diff -Nru busybox-1.22.0/debian/changelog busybox-1.22.0/debian/changelog
--- busybox-1.22.0/debian/changelog 2016-04-17 17:37:25.0 +0200
+++ busybox-1.22.0/debian/changelog 2017-09-25 22:42:41.0 +0200
@@ -1,3 +1,19 @@
+busybox (1:1.22.0-19+deb9u1) stretch; urgency=medium
+
+  * Fix pointer misuse unziping files. Closes: #803097
+  * Fix Heap-based buffer overflow in the DHCP client.
+Closes: #818497 [CVE-2016-2148]
+  * Fix integer overflow in the DHCP client (udhcpc).
+Closes: #818499 [CVE-2016-2147]
+  * Fix directory traversal vulnerability in tar implementation.
+Closes: #802702 [CVE-2011-5325]
+  * Fix integer overflow in bzip2 decompresson.
+Closes: #879732 [CVE-2017-15873]
+  * Filter out terminal escape sequence filtering in autocompletion.
+Closes: #882258 [CVE-2017-16544]
+
+ -- Christoph Biedl <debian.a...@manchmal.in-ulm.de>  Mon, 25 Sep 2017 
22:42:41 +0200
+
 busybox (1:1.22.0-19) unstable; urgency=medium
 
   * busybox-udeb, udhcpc: Remove /udhcpc/usr/share/udhcpc/default.script,
diff -Nru 
busybox-1.22.0/debian/patches/cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch
 
busybox-1.22.0/debian/patches/cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch
--- 
busybox-1.22.0/debian/patches/cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch
1970-01-01 01:00:00.0 +0100
+++ 
busybox-1.22.0/debian/patches/cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch
2017-09-25 22:42:41.0 +0200
@@ -0,0 +1,58 @@
+Subject: Udhcpc: fix OPTION_6RD parsing (could overflow its malloced buffer)
+ID: CVE-2016-2148
+Origin: 1_24_0-139-g352f79a
+Upstream-Author: Denys Vlasenko <vda.li...@googlemail.com>
+Date: Fri Feb 26 15:54:56 2016 +0100
+Bug-Debian: https://bugs.debian.org/818497 
+
+--- a/networking/udhcp/common.c
 b/networking/udhcp/common.c
+@@ -140,7 +140,7 @@
+  * udhcp_str2optset: to determine how many bytes to allocate.
+  * xmalloc_optname_optval: to estimate string length
+  * from binary option length: (option[LEN] / dhcp_option_lengths[opt_type])
+- * is the number of elements, multiply in by one element's string width
++ * is the number of elements, multiply it by one element's string width
+  * (len_of_option_as_string[opt_type]) and you know how wide string you need.
+  */
+ const uint8_t dhcp_option_lengths[] ALIGN1 = {
+@@ -160,7 +160,18 @@
+   [OPTION_S32] = 4,
+   /* Just like OPTION_STRING, we use minimum length here */
+   [OPTION_STATIC_ROUTES] = 5,
+-  [OPTION_6RD] =22,  /* ignored by udhcp_str2optset */
++  [OPTION_6RD] =12,  /* ignored by udhcp_str2optset */
++  /* The above value was chosen as follows:
++   * len_of_option_as_string[] for this option is >60: it's a string of 
the form
++   * "32 128 ::::::: 255.255.255.255 ".
++   * Each additional ipv4 address takes 4 bytes in binary option and 
appends
++   * another "255.255.255.255 " 16-byte string. We can set [OPTION_6RD] = 
4
++   * but this severely overestimates string length: instead of 16 bytes,
++   * it adds >60 for every 4 bytes in binary option.
++   * We cheat and declare here that option is in units of 12 bytes.
++   * This adds more than 60 bytes for every three ipv4 addresses - more 
than enough.
++   * (Even 16 instead of 12 should work, but let's be paranoid).
++   */
+ };
+ 
+ 
+--- a/networking/udhcp/dhcpc.c
 b/networking/udhcp/dhcpc.c
+@@ -99,7 +99,7 @@
+   [OPTION_IP  ] = sizeof("255.255.255.255 "),
+   [OPTION_IP_PAIR ] = sizeof("255.255.255.255 ") * 2,
+   [OPTION_STATIC_ROUTES   ] = sizeof("255.255.255.255/32 255.255.255.255 
"),
+-  [OPTION_6RD ] = sizeof("32 128 
::::::: 255.255.255.255 "),
++  [OPTION_6RD ] = sizeof("132 128 
::::::: 255.255.255.255 "),
+   [OPTION_STRING  ] = 1,
+   [OPTION_STRING_HOST ] = 1,
+ #if ENABLE_FEATURE_UDHCP_RFC3397
+@@ -206,7 +206,7 @@
+   type = optfl

Bug#877260: jessie-pu: package busybox/1:1.22.0-9+deb8u2

[Christoph Biedl]

Second attempt, updated debdiff attached.

Changes:

also address:

+  * Fix integer overflow in bzip2 decompresson.
+Closes: #879732 [CVE-2017-15873]
+  * Filter out terminal escape sequence filtering in autocompletion.
+Closes: #882258 [CVE-2017-16544]

A call for tests was sent to debian-boot three days ago¹, no
reaction though.

Assuming your

> I'd be happy with this in general, but the udeb means we need an
> explicit d-i RM ack; CCing appropriately.

still applies, Cc: is set accordingly.

Christoph

¹ https://lists.debian.org/debian-boot/2017/11/msg00379.html
diff -Nru busybox-1.22.0/debian/changelog busybox-1.22.0/debian/changelog
--- busybox-1.22.0/debian/changelog 2015-02-17 18:30:02.0 +0100
+++ busybox-1.22.0/debian/changelog 2017-11-30 19:41:31.0 +0100
@@ -1,3 +1,20 @@
+busybox (1:1.22.0-9+deb8u2) jessie; urgency=medium
+
+  * Reject module names with slashes. Closes: #776186 [CVE-2014-9645]
+  * Fix pointer misuse unziping files. Closes: #803097
+  * Fix Heap-based buffer overflow in the DHCP client.
+Closes: #818497 [CVE-2016-2148]
+  * Fix integer overflow in the DHCP client (udhcpc).
+Closes: #818499 [CVE-2016-2147]
+  * Fix directory traversal vulnerability in tar implementation.
+Closes: #802702 [CVE-2011-5325]
+  * Fix integer overflow in bzip2 decompresson.
+Closes: #879732 [CVE-2017-15873]
+  * Filter out terminal escape sequence filtering in autocompletion.
+Closes: #882258 [CVE-2017-16544]
+
+ -- Christoph Biedl <debian.a...@manchmal.in-ulm.de>  Thu, 30 Nov 2017 
19:41:31 +0100
+
 busybox (1:1.22.0-9+deb8u1) jessie; urgency=medium
 
   * Non-maintainer upload.
diff -Nru 
busybox-1.22.0/debian/patches/cherry-pick.1_22_0-220-g4e314fa.modprobe-rmmod-reject-module-names-with-slashes.patch
 
busybox-1.22.0/debian/patches/cherry-pick.1_22_0-220-g4e314fa.modprobe-rmmod-reject-module-names-with-slashes.patch
--- 
busybox-1.22.0/debian/patches/cherry-pick.1_22_0-220-g4e314fa.modprobe-rmmod-reject-module-names-with-slashes.patch
 1970-01-01 01:00:00.0 +0100
+++ 
busybox-1.22.0/debian/patches/cherry-pick.1_22_0-220-g4e314fa.modprobe-rmmod-reject-module-names-with-slashes.patch
 2017-11-30 19:41:23.0 +0100
@@ -0,0 +1,27 @@
+Subject: Modprobe,rmmod: reject module names with slashes
+ID: CVE-2014-9645
+Origin: 1_22_0-220-g4e314fa
+Upstream-Author: Denys Vlasenko <vda.li...@googlemail.com>
+Date: Thu Nov 20 18:24:33 2014 +0100
+Bug-Debian: https://bugs.debian.org/776186
+
+--- a/modutils/modprobe.c
 b/modutils/modprobe.c
+@@ -239,6 +239,17 @@
+ {
+   struct module_entry *m;
+ 
++  /*
++   * get_or_add_modentry() strips path from name and works
++   * on remaining basename.
++   * This would make "rmmod dir/name" and "modprobe dir/name"
++   * to work like "rmmod name" and "modprobe name",
++   * which is wrong, and can be abused via implicit modprobing:
++   * "ifconfig /usbserial up" tries to modprobe netdev-/usbserial.
++   */
++  if (strchr(name, '/'))
++  bb_error_msg_and_die("malformed module name '%s'", name);
++
+   m = get_or_add_modentry(name);
+   if (!(option_mask32 & (OPT_REMOVE | OPT_SHOW_DEPS))
+&& (m->flags & (MODULE_FLAG_LOADED | MODULE_FLAG_BUILTIN))
diff -Nru 
busybox-1.22.0/debian/patches/cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch
 
busybox-1.22.0/debian/patches/cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch
--- 
busybox-1.22.0/debian/patches/cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch
1970-01-01 01:00:00.0 +0100
+++ 
busybox-1.22.0/debian/patches/cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch
2017-11-28 16:44:39.0 +0100
@@ -0,0 +1,58 @@
+Subject: Udhcpc: fix OPTION_6RD parsing (could overflow its malloced buffer)
+ID: CVE-2016-2148
+Origin: 1_24_0-139-g352f79a
+Upstream-Author: Denys Vlasenko <vda.li...@googlemail.com>
+Date: Fri Feb 26 15:54:56 2016 +0100
+Bug-Debian: https://bugs.debian.org/818497 
+
+--- a/networking/udhcp/common.c
 b/networking/udhcp/common.c
+@@ -140,7 +140,7 @@
+  * udhcp_str2optset: to determine how many bytes to allocate.
+  * xmalloc_optname_optval: to estimate string length
+  * from binary option length: (option[LEN] / dhcp_option_lengths[opt_type])
+- * is the number of elements, multiply in by one element's string width
++ * is the number of elements, multiply it by one element's string width
+  * (len_of_option_as_string[opt_type]) and you know how wide string you need.
+  */
+ const uint8_t dhcp_option_lengths[] ALIGN1 = {
+@@ -160,7 +160,18 @@
+   [OPTION_S32] = 4,
+   /* Just like OPTION_STRING, we use minimum length he

Bug#881629: transition: http-parser

[Christoph Biedl]

Emilio Pozuelo Monfort wrote...

> No need to revert to the previous version, this looks to be in a good shape 
> and
> there are no clashing transitions. I'll get to the binnmus soon.

Thanks a lot for your swift and helping reaction.

As far as I can see, the failing builds on hurd and kbsd for libgit2 and
purple-matrix are older issues, so this is no regression. About
ruby-http-parser.rb, I'm waiting for the maintainers to react and will
otherwise do a NMU.

Regards,
Christoph


signature.asc
Description: Digital signature

Bug#881629: transition: http-parser

[Christoph Biedl]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hello,

this is not a regular transition because I screwed up: The upload of
http-parser (soname 2.7.1) last night hit unstable instead of
experimental as suggested by the transition wiki, and also as intended.

My primary objective is to keep the damage as low as possible.

So I'm asking for your advice how to proceed. I can revert the upload
although I'd prefer to go forward.

Before uploading, I already had identified the following build
dependencies:

cargo_0.22.0-1~exp1
jabberd2_2.6.1-1
libgit2_0.26.0+dfsg.1-1.1
ocserv_0.11.9-1
purple-matrix_0.0.0+git20170530-1
ruby-http-parser.rb_0.6.0-3
sssd_1.15.3-3
tcpflow_1.4.5+repack1-4

With ruby-http-parser.rb as exception, all these built fine. I've filed
#881627 to discuss the failing one.

Additionally, I've filed an RC bug #881628 against http-parser to prevent
testing migration until things are sorted out.

Also as a measure against another failure of that kind I've switched
to dput-ng that warns about a Distribution: discrepancy between
.changes and debian/changelog. That would have prevented the current
mess.

For completeness, here is what reportbug suggested about the transition:

Ben file:

title = "http-parser";
is_affected = .depends ~ "libhttp-parser2.1" | .depends ~ "libhttp-parser2.7.1";
is_good = .depends ~ "libhttp-parser2.7.1";
is_bad = .depends ~ "libhttp-parser2.1";


Sorry for the hazzle, and looking forward for a solution everybody can
live with.

Christoph


signature.asc
Description: Digital signature

Bug#877258: stretch-pu: package busybox/1:1.22.0-19+deb9u1

[Christoph Biedl]

Adam D. Barratt wrote...

> I'd be happy with this in general, but the udeb means we need an
> explicit d-i RM ack; CCing appropriately.

Okay, lesson learned: For such packages, don't proscrastinate the
request until close to the deadline that has passed now. There'll be
another point relase, I'll take the delay as an opportunity to handle
some of the "important" bugs after some more checking as well,
especially.

#801850: readlink gets shadowed by busybox causing debconf to possibly fail
#854923: busybox: "sed -i nonexistent" creates bogus files

Same for jessie-pu.

So just stay tuned, Ai'll be bach.

Christoph


signature.asc
Description: Digital signature

Bug#877260: jessie-pu: package busybox/1:1.22.0-9+deb8u2

[Christoph Biedl]

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

Hello release team,

as mentioned in #-1, I'd like to fix the existing non-dsa
issues in busybox.

For *jessie*, https://security-tracker.debian.org/busybox lists the
following issues I'd like to fix in an upcoming point release.
Those marked "#" are the same as for stretch (#877258).

# TEMP-0803097-A74121, #803097
  busybox: pointer misuse unziping files

  Fix: 
https://git.busybox.net/busybox/commit/?id=1de25a6e87e0e627aa34298105a3d17c60a1f44e
  Patch: cherry-pick.1_24_0-68-g1de25a6.unzip-test-for-bad-archive-segving.patch

# CVE-2016-2148, #818497
  Heap-based buffer overflow in the DHCP client (udhcpc) in BusyBox
  before 1.25.0 allows remote attackers to have unspecified impact via
  vectors involving OPTION_6RD parsing.

  Fix: 
https://git.busybox.net/busybox/commit/?id=352f79acbd759c14399e39baef21fc4ffe180ac2
  Patch: 
cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch

# CVE-2016-2147, #818499
  Integer overflow in the DHCP client (udhcpc) in BusyBox before 1.25.0
  allows remote attackers to cause a denial of service (crash) via a
  malformed RFC1035-encoded domain name, which triggers an
  out-of-bounds heap write.

  Fix: 
https://git.busybox.net/busybox/commit/?id=d474ffc68290e0a83651c4432eeabfa62cd51e87
  Patch: 
cherry-pick.1_24_0-152-gd474ffc.udhcp-fix-a-segv-on-malformed-rfc1035-encoded-domain-name.patch

* CVE-2014-9645, #776186
  The add_probe function in modutils/modprobe.c in BusyBox before
  1.23.0 allows local users to bypass intended restrictions on loading
  kernel modules via a / (slash) character in a module name, as
  demonstrated by an "ifconfig /usbserial up" command or a "mount -t
  /snd_pcm none /" command.

  Fix: 
https://git.busybox.net/busybox/commit/?id=4e314faa0aecb66717418e9a47a4451aec59262b
  Patch: 
cherry-pick.1_22_0-220-g4e314fa.modprobe-rmmod-reject-module-names-with-slashes.patch

# CVE-2011-5325, #802702
  Directory traversal vulnerability in the BusyBox implementation of
  tar before 1.22.0 v5 allows remote attackers to point to files
  outside the current working directory via a symlink.

  Fix: 
https://git.busybox.net/busybox/commit/?id=b920a38dc0a87f588d4731a8b887b5e16018
  Patch: 
cherry-pick.1_27_0-148-gb920a38dc.tar-postpone-creation-of-symlinks-with-suspicious-targets.patch
  Also the following was needed as a prerequisite for the tests:
  
cherry-pick.1_24_0-44-ga960748.tar-add-a-test-that-we-dont-write-into-symlinks.patch

Find the debdiff attached.

Cheers,

Christoph

-- System Information:
Debian Release: 8.9
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-proposed-updates'), 
(500, 'oldstable')
Architecture: amd64 (x86_64)
diff -Nru busybox-1.22.0/debian/changelog busybox-1.22.0/debian/changelog
--- busybox-1.22.0/debian/changelog 2015-02-17 18:30:02.0 +0100
+++ busybox-1.22.0/debian/changelog 2017-09-25 22:57:20.0 +0200
@@ -1,3 +1,17 @@
+busybox (1:1.22.0-9+deb8u2) jessie; urgency=medium
+
+  * Reject module names with slashes.
+Closes: #776186 [CVE-2014-9645]
+  * Fix pointer misuse unziping files. Closes: #803097
+  * Fix Heap-based buffer overflow in the DHCP client.
+Closes: #818497 [CVE-2016-2148]
+  * Fix integer overflow in the DHCP client (udhcpc).
+Closes: #818499 [CVE-2016-2147]
+  * Fix directory traversal vulnerability in tar implementation.
+Closes: #802702 [CVE-2011-5325]
+
+ -- Christoph Biedl <debian.a...@manchmal.in-ulm.de>  Mon, 25 Sep 2017 
22:57:20 +0200
+
 busybox (1:1.22.0-9+deb8u1) jessie; urgency=medium
 
   * Non-maintainer upload.
diff -Nru 
busybox-1.22.0/debian/patches/cherry-pick.1_22_0-220-g4e314fa.modprobe-rmmod-reject-module-names-with-slashes.patch
 
busybox-1.22.0/debian/patches/cherry-pick.1_22_0-220-g4e314fa.modprobe-rmmod-reject-module-names-with-slashes.patch
--- 
busybox-1.22.0/debian/patches/cherry-pick.1_22_0-220-g4e314fa.modprobe-rmmod-reject-module-names-with-slashes.patch
 1970-01-01 01:00:00.0 +0100
+++ 
busybox-1.22.0/debian/patches/cherry-pick.1_22_0-220-g4e314fa.modprobe-rmmod-reject-module-names-with-slashes.patch
 2017-09-25 22:57:20.0 +0200
@@ -0,0 +1,27 @@
+Subject: Modprobe,rmmod: reject module names with slashes
+ID: CVE-2014-9645
+Origin: 1_22_0-220-g4e314fa
+Upstream-Author: Denys Vlasenko <vda.li...@googlemail.com>
+Date: Thu Nov 20 18:24:33 2014 +0100
+Bug-Debian: https://bugs.debian.org/776186
+
+--- a/modutils/modprobe.c
 b/modutils/modprobe.c
+@@ -239,6 +239,17 @@
+ {
+   struct module_entry *m;
+ 
++  /*
++   * get_or_add_modentry() strips path from name and works
++   * on remaining basename.
++   * This would make "rmmod dir/name" and "modprobe dir/name"
++   * to work like "rmmod name" and "modprob

Bug#877258: stretch-pu: package busybox/1:1.22.0-19+deb9u1

[Christoph Biedl]

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

Hello release team,

there are several non-dsa issues open for busybox. Now wearing the
maintainer's hat (together with Chris Boot, cc'd), I'd like to fix
them in an upcoming point release, for both jessie and stretch. I'll
file two separate request for these distributions, assuming this eases
handling on your side.

So for *stretch*, https://security-tracker.debian.org/busybox lists
the following issues.

* TEMP-0803097-A74121, #803097
  busybox: pointer misuse unziping files

  Fix: 
https://git.busybox.net/busybox/commit/?id=1de25a6e87e0e627aa34298105a3d17c60a1f44e
  Patch: cherry-pick.1_24_0-68-g1de25a6.unzip-test-for-bad-archive-segving.patch

* CVE-2016-2148, #818497
  Heap-based buffer overflow in the DHCP client (udhcpc) in BusyBox
  before 1.25.0 allows remote attackers to have unspecified impact via
  vectors involving OPTION_6RD parsing.

  Fix: 
https://git.busybox.net/busybox/commit/?id=352f79acbd759c14399e39baef21fc4ffe180ac2
  Patch: 
cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch

* CVE-2016-2147, #818499
  Integer overflow in the DHCP client (udhcpc) in BusyBox before 1.25.0
  allows remote attackers to cause a denial of service (crash) via a
  malformed RFC1035-encoded domain name, which triggers an
  out-of-bounds heap write.

  Fix: 
https://git.busybox.net/busybox/commit/?id=d474ffc68290e0a83651c4432eeabfa62cd51e87
  Patch: 
cherry-pick.1_24_0-152-gd474ffc.udhcp-fix-a-segv-on-malformed-rfc1035-encoded-domain-name.patch

* CVE-2011-5325, #802702
  Directory traversal vulnerability in the BusyBox implementation of
  tar before 1.22.0 v5 allows remote attackers to point to files
  outside the current working directory via a symlink.

  Fix: 
https://git.busybox.net/busybox/commit/?id=b920a38dc0a87f588d4731a8b887b5e16018
  Patch: 
cherry-pick.1_27_0-148-gb920a38dc.tar-postpone-creation-of-symlinks-with-suspicious-targets.patch
  Also the following was needed as a prerequisite for the tests:
  
cherry-pick.1_24_0-44-ga960748.tar-add-a-test-that-we-dont-write-into-symlinks.patch

Find the debdiff attached.

Cheers,
Christoph

-- System Information:
Debian Release: 9.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

diff -Nru busybox-1.22.0/debian/changelog busybox-1.22.0/debian/changelog
--- busybox-1.22.0/debian/changelog 2016-04-17 17:37:25.0 +0200
+++ busybox-1.22.0/debian/changelog 2017-09-25 22:04:05.0 +0200
@@ -1,3 +1,15 @@
+busybox (1:1.22.0-19+deb9u1) stretch; urgency=medium
+
+  * Fix pointer misuse unziping files. Closes: #803097
+  * Fix Heap-based buffer overflow in the DHCP client.
+Closes: #818497 [CVE-2016-2148]
+  * Fix integer overflow in the DHCP client (udhcpc).
+Closes: #818499 [CVE-2016-2147]
+  * Fix directory traversal vulnerability in tar implementation.
+Closes: #802702 [CVE-2011-5325]
+
+ -- Christoph Biedl <debian.a...@manchmal.in-ulm.de>  Mon, 25 Sep 2017 
22:04:05 +0200
+
 busybox (1:1.22.0-19) unstable; urgency=medium
 
   * busybox-udeb, udhcpc: Remove /udhcpc/usr/share/udhcpc/default.script,
diff -Nru 
busybox-1.22.0/debian/patches/cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch
 
busybox-1.22.0/debian/patches/cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch
--- 
busybox-1.22.0/debian/patches/cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch
1970-01-01 01:00:00.0 +0100
+++ 
busybox-1.22.0/debian/patches/cherry-pick.1_24_0-139-g352f79a.udhcpc-fix-option-6rd-parsing-could-overflow-its-malloced-buffer.patch
2017-09-25 22:04:05.0 +0200
@@ -0,0 +1,58 @@
+Subject: Udhcpc: fix OPTION_6RD parsing (could overflow its malloced buffer)
+ID: CVE-2016-2148
+Origin: 1_24_0-139-g352f79a
+Upstream-Author: Denys Vlasenko <vda.li...@googlemail.com>
+Date: Fri Feb 26 15:54:56 2016 +0100
+Bug-Debian: https://bugs.debian.org/818497 
+
+--- a/networking/udhcp/common.c
 b/networking/udhcp/common.c
+@@ -140,7 +140,7 @@
+  * udhcp_str2optset: to determine how many bytes to allocate.
+  * xmalloc_optname_optval: to estimate string length
+  * from binary option length: (option[LEN] / dhcp_option_lengths[opt_type])
+- * is the number of elements, multiply in by one element's string width
++ * is the number of elements, multiply it by one element's string width
+  * (len_of_option_as_string[opt_type]) and you know how wide string you need.
+  */
+ const uint8_t dhcp_option_lengths[] ALIGN1 = {
+@@ -160,7 +160,18 @@
+   [OPTION_S32] = 4,
+   /* Just like OPTION_STRING, we use minimum length here */
+   [OPTION_STATIC_ROUTES] = 5,
+-  [OPTION_6RD] =22,

Bug#876633: nmu: libselinux_2.6-3+b2

[Christoph Biedl]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

Hello,

a few days ago, a binNMU for the src:libselinux Debian package hit
stretch-proposed-updates, providing among others a file named
libselinux1_2.6-3+b2_amd64.deb - unfortunately such a file name has been
in use at the very same place for another upload that took place in
June[2]. As a result, there is a duplicate.

TTBOMK, such duplicates are not forbidden but fairly confusing. Also,
the apt-cacher-ng proxy appearently does not take such re-usal into
account and serves the old copy if still in the cache, subsequently
triggering a "Hash Sum mismatch" error from apt:

E: Failed to fetch 
http://ftp.de.debian.org/debian/pool/main/libs/libselinux/libselinux1_2.6-3+b2_amd64.deb
  Hash Sum mismatch
   Hashes of expected file:
- SHA256:afe008cdd2ca9d9de483ecada93459b33cf40f0d7c61f4652c4839651515725e
- MD5Sum:b8ddc8ad9229d17a6fb900538e5c45cb [weak]
- Filesize:101394 [weak]
   Hashes of received file:
- SHA256:06434e32a91558ecae41dab74d3ffd0cce90f9868cff82bb4ddfe15f9a66e740
- MD5Sum:9e47c78ec70f36d03fd85f8775326d21 [weak]
- Filesize:101302 [weak]
   Last modification reported: Fri, 30 Jun 2017 00:12:30 +

diffoscope shows for debian/changelog:

│ │ │ │ -libselinux (2.6-3+b2) sid; urgency=low, binary-only=yes
│ │ │ │ +libselinux (2.6-3+b2) stretch; urgency=low, binary-only=yes
│ │ │ │  
│ │ │ │* Binary-only non-maintainer upload for amd64; no source changes.
│ │ │ │ -  * Rebuild with python3.6 as a supported python3.
│ │ │ │ +  * Rebuild with current sbuild to fix changelog date
│ │ │ │  
│ │ │ │ - -- amd64 / i386 Build Daemon (x86-ubc-01) 
  Thu, 29 Jun 2017 23:57:24 +
│ │ │ │ + -- amd64 / i386 Build Daemon (x86-ubc-01) 
  Wed, 20 Sep 2017 03:33:46 +



Long story short, while I can purge the files in my cache to unbreak my
private buildd, please still consider another binNMU for src:libselinux
to resolve this situation in a sane way.

This is the line as proposed by reportbug. Please double-check:

nmu libselinux_2.6-3+b2 . ANY . stretch . -m "Resolve version number collision"

Regards,
Christoph

[1] http://ftp.debian.org/debian/pool/main/libs/libselinux/
[2] 
http://snapshot.debian.org/archive/debian/20170630T033759Z/pool/main/libs/libselinux/


-- System Information:
Debian Release: 9.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.51 (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 /bin/dash
Init: unable to detect



signature.asc
Description: Digital signature

Bug#864233: unblock: linux/4.9.30-1

[Christoph Biedl]

Ben Hutchings wrote...

> radvd's autoconf test for  has probably failed at least
> since Linux 2.6.32 when I made sure the kernel headers would never
> define struct sockaddr for userland:
> 
> 
> But the conflict between  and  is far
> older than that, so if the test ever passed it should have resulted in
> this build failure.  I think that's a clear bug in radvd.  It should
> use either one or the other, and I think the sensible thing is to use
>  as it has been doing up until now.

Certainly I'm not going to advocate radvd's build system - my only
concern is your change will break more packages out there, mere ten days
prior to the scheduled release.

So to me it seems wiser to revert the changes to linux-libc-dev for
stretch. Else, someone(tm) would have to test-rebuild all the packages
that build-depend on linux-libc-dev to check for damage, and provide
help how to deal with something that technically is a library
transition.

Christoph


signature.asc
Description: Digital signature

Re: Bug#852962: ycmd FTBFS on mipsel: test failures

[Christoph Biedl]

James Cowgill wrote...

> On Thu, 1 Jun 2017 00:15:28 +0200 Christoph Biedl

> > Did so, but failed to reproduce the issue on the mipsel porter box.
> > However, the bug seems to manifest when building in a qemu-static
> > chroot. In that scenario however, diagnostic tools like strace
> > fail.
> > 
> > Updates will follow as I get them.
> 
> I've tried this on various mips hardware and I can only seems to fail on
> Loongsons (where is reliably fails 100% of the time). Blacklisting it on
> those machines could be an option given how close to the release we are.

Thanks for looking into this, James. Personally, if such a blacklisting
was acceptable for the release team (Cc:'ed), I was happy to spend the
remaining time on other issues in stretch. Since I still haven't figured
out what actually goes wrong during the test suite, I'd just like to
avoid this package (and its reverse dependencies) fall out of stretch.

Christoph


signature.asc
Description: Digital signature

Bug#861535: unblock: file/1:5.30-1 (was: Seeking pre-approval to upload new file upstream version for stretch)

[Christoph Biedl]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal

Hello,

please unblock file 1:5.30-1 I've uploaded to unstable.

Short version:

This upload

* fixes several issues in 1:5.29-3, including an assertion failure
  triggerable from certain files,
* includes more than twenty(!) commits from the upstream git since the
  5.30 release that, by their description, seem prudent to include
  security-wise, and
* otherwise tries hard to not change the detection of files.


A bit longer:

There are a few issues in the stretch version of file (1:5.29-3) that
in my opinion make it unfit for release. The most important one is an
easily triggerable crash (assertion failure) I found a while ago,
upstream was alerted in private. This issue was introduced in version
1:5.29-1 and is not public yet, at least not from my side.

The delta between 1:5.29-3 and upstream's 5.30 release is pretty small:
These are bug fixes like for the one mentioned above, several changes
that seem to address issues, some documentation and/or not affecting the
execution. There are two changes that introduce new features, I've
reverted them to reduce the impact (also, they looked somewhat fishy).
Initially, forwarding to 5.30 promised a smaller and better arranged
debian/patches/.

Since upstream's 5.30 release however, there have been a lot of commits
that address more issues, usually they contain a remark "oss-fuzz", so
appearently somebody has spent quite some time searching for flawed
code. One commit contains a remark "Although I can't reproduce it"
which implies at least some of the other commits fix an exploitable
issue. So I decided the cherry-pick *all* of them plus prerequisites in
the hope this will avoid some security uploads during the stretch life
cycle. They all can be found in debian/patches/, one patch per commit.


As with every upload of file, I ran a test on a huge collection of
files in order to detect unexpected changes. I have to admit there are
some minor ones: For some files not all the gory details are shown any
longer, basic detection still works. These were introduced by the
changes that should fix issues in the code.

Additional details, like discussion of every single change between
1:5.29-3 and 1:5.30-1 available upon request.

Regards,

Christoph


signature.asc
Description: Digital signature

Seeking pre-approval to upload new file upstream version for stretch

[Christoph Biedl]

Hello,

while preparing an upload and an unblock request for file 1:5.29-4 to
address two important/serious issues, upstream surprised me with a new
release (5.30) today.

So I'd like to take the opportunity to ship that one in stretch since
there are just a few changes besides those mentioned above, and it would
give Debian the chance to start stretch with a clean and a rather simple
patch queue - something I consider desirable to handle future updates
(and unfortunately, we can be certain there will be some).

Please tell me if this is at all acceptable for you. To ease your
decision, I can provide an explanation for all the 13 upstream commits
that describe the difference from 1:5.29-4. Also, I will do a major test
run to find any regressions, will take a few hours. And I will not
hesitate to disable the two commits that actually introduce new features
in case they cause trouble. Still, this seems a better solution to me
than cherry-picking.

Kind regards,

Christoph


signature.asc
Description: Digital signature

Bug#848610: jessie-pu: package pgpdump/0.28-1+deb8u1

[Christoph Biedl]

Christoph "I had a cold" Biedl wrote...

> CVE-2016-4021[1] hasn't been handled in jessie yet. The security team
> suggested to use an upcoming point release for this, this got ACKed
> by the stable security team.

Well, you guess: The security team ACKed to use an upcoming point
release for this.

Christoph


signature.asc
Description: Digital signature

Bug#848908: jessie-pu: package shutter/0.92-0.1+deb8u1

[Christoph Biedl]

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

Hello release team,

CVE-2015-0854[1] hasn't been handled in jessie yet. The security team
ACKed to use an upcoming point release for this. The shutter maintainer
Ryan Niebur is in Cc:.

Find attached a debdiff based on the fixed stretch version 0.93.1-1,
the original patch triggered a Perl error.

Testing confirmed the described exploit no longer works then.

Regards,

Christoph

[1] https://security-tracker.debian.org/tracker/CVE-2015-0854

diff -Nru shutter-0.92/debian/changelog shutter-0.92/debian/changelog
--- shutter-0.92/debian/changelog   2014-08-10 17:51:22.0 +0200
+++ shutter-0.92/debian/changelog   2016-12-20 19:00:20.0 +0100
@@ -1,3 +1,9 @@
+shutter (0.92-0.1+deb8u1) jessie; urgency=high
+
+  * Fix insecure usage of system(). Closes: #798862 [CVE-2015-0854]
+
+ -- Christoph Biedl <debian.a...@manchmal.in-ulm.de>  Tue, 20 Dec 2016 
19:00:20 +0100
+
 shutter (0.92-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru shutter-0.92/debian/patches/CVE-2015-0854.patch 
shutter-0.92/debian/patches/CVE-2015-0854.patch
--- shutter-0.92/debian/patches/CVE-2015-0854.patch 1970-01-01 
01:00:00.0 +0100
+++ shutter-0.92/debian/patches/CVE-2015-0854.patch 2016-12-20 
18:59:57.0 +0100
@@ -0,0 +1,18 @@
+Description: Fix insecure use of system()
+Author: Luke Faraone <lfara...@debian.org>
+ID: CVE-2015-0854
+Bug: https://bugs.launchpad.net/shutter/+bug/1495163
+Debian-Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798862
+
+--- a/share/shutter/resources/modules/Shutter/App/HelperFunctions.pm
 b/share/shutter/resources/modules/Shutter/App/HelperFunctions.pm
+@@ -53,7 +53,8 @@
+ 
+ sub xdg_open {
+   my ( $self, $dialog, $link, $user_data ) = @_;
+-  system("xdg-open $link");
++  my @args = ("xdg-open", $link);
++  system(@args);
+   if($?){
+   my $response = $self->{_dialogs}->dlg_error_message( 
+   sprintf( $self->{_d}->get("Error while executing %s."), 
"'xdg-open'"),
diff -Nru shutter-0.92/debian/patches/series shutter-0.92/debian/patches/series
--- shutter-0.92/debian/patches/series  1970-01-01 01:00:00.0 +0100
+++ shutter-0.92/debian/patches/series  2016-12-20 18:40:00.0 +0100
@@ -0,0 +1 @@
+CVE-2015-0854.patch


signature.asc
Description: Digital signature

Bug#848610: jessie-pu: package pgpdump/0.28-1+deb8u1

[Christoph Biedl]

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

Hello release team,

CVE-2016-4021[1] hasn't been handled in jessie yet. The security team
suggested to use an upcoming point release for this, this got ACKed
by the stable security team. The pgpdump maintainer Jose Luis Rivas
(CC'd) has agreed to this procedure.

Find attached a debdiff based on the data in the tracker and upstream
git, and can confirm the fix mitigates the issue.

You might notice it's not the original patch, instead it includes a
follow-up commit from upstream.[2] And while preparing the diff I
realized it's probably a good idea to include commit 6e15953: "fixing
a buffer overrun" that was found using the American fuzzy lop as well.

Regards,

Christoph

[1] https://security-tracker.debian.org/tracker/CVE-2016-4021
[2] See https://github.com/kazu-yamamoto/pgpdump/commits/master/buffer.c
for the commit history.
diff -u pgpdump-0.28/debian/changelog pgpdump-0.28/debian/changelog
--- pgpdump-0.28/debian/changelog
+++ pgpdump-0.28/debian/changelog
@@ -1,3 +1,11 @@
+pgpdump (0.28-1+deb8u1) jessie; urgency=high
+
+  * Fix endless loop parsing specially crafted input in read_binary.
+Upstream commits ece39dd and 0c306f4. Closes: #773747 [CVE-2016-4021]
+  * Fix a buffer overrun in read_radix64. Upstream commit 6e15953
+
+ -- Christoph Biedl <debian.a...@manchmal.in-ulm.de>  Thu, 15 Dec 2016 
23:30:21 +0100
+
 pgpdump (0.28-1) unstable; urgency=low
 
   * New upstream version.
only in patch2:
unchanged:
--- pgpdump-0.28.orig/buffer.c
+++ pgpdump-0.28/buffer.c
@@ -80,8 +80,17 @@
 private int
 read_binary(byte *p, unsigned int max)
 {
-   /* errno */
-   return fread(p, sizeof(byte), max, stdin);
+   if (feof(stdin)) {
+   exit(EXIT_SUCCESS);
+   }
+
+   size_t ret = fread(p, sizeof(byte), max, stdin);
+
+   if (ferror(stdin)) {
+   warn_exit("error in read_binary");
+   }
+
+   return ret;
 }
 
 private int
@@ -117,6 +126,9 @@
done = YES;
return out;
}
+   if (c >= 128) {
+ continue;
+   }
d = base256[c];
switch (d) {
case OOB:


signature.asc
Description: Digital signature

Bug#846948: jessie-pu: package file/1:5.22+15-2+deb8u3

[Christoph Biedl]

Adam D. Barratt wrote...

> Please go ahead.

Thanks, now uploaded.

Christoph


signature.asc
Description: Digital signature

Bug#846948: jessie-pu: package file/1:5.22+15-2+deb8u3

[Christoph Biedl]

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

Hello release team,

A memory leak was found in in libmagic's (src:file) loader of magic
files, appearently independently by Shi Yin in PR/569[1] and Arnaud
Quette in #840754[2]. This was fixed upstream in version 5.29 which is
in testing and unstable (as 1:5.29-1), oldstable/wheezy doesn't seem to
have this problem.

For stable/jessie I'd like to handle this in the next point release.

The actual fix is commit FILE5_28-42-g10ee4ec[3] where commit
FILE5_24-31-g3aa35aa[4] is needed as a prerequisite. I've dropped a
hunk from that fix which AFAICS is not relevant for Debian and would
otherwise require the inclusion FILE5_25-3-gb0ccffd[5] as another
prerequisite: According to its description, that third commit is needed
on systems without mmap only.

Find attached:

* A debdiff for 1:5.22+15-2+deb8u3
* A commulative patch about the code changes to ease review.

After applying the patch, the valgrind check as described in the BTS
no longer reports leaks.

Regards,

Christoph

[1] https://bugs.gw.com/view.php?id=569
[2] https://bugs.debian.org/840754
[3] https://github.com/file/file/commit/FILE5_28-42-g10ee4ec
[4] https://github.com/file/file/commit/FILE5_24-31-g3aa35aa
[5] https://github.com/file/file/commit/FILE5_25-3-gb0ccffd
diff -Nru file-5.22+15/debian/changelog file-5.22+15/debian/changelog
--- file-5.22+15/debian/changelog   2016-05-09 08:23:30.0 +0200
+++ file-5.22+15/debian/changelog   2016-12-04 10:00:07.0 +0100
@@ -1,3 +1,9 @@
+file (1:5.22+15-2+deb8u3) stable; urgency=medium
+
+  * Fix memory leak in magic loader. Closes: #840754
+
+ -- Christoph Biedl <debian.a...@manchmal.in-ulm.de>  Sun, 04 Dec 2016 
10:00:07 +0100
+
 file (1:5.22+15-2+deb8u2) stable; urgency=high
 
   * Fix CVE-2015-8865:
diff -Nru 
file-5.22+15/debian/patches/cherry-pick.FILE5_24-31-g3aa35aa.dont-leak-memory-when-loading-non-compiled-files.patch
 
file-5.22+15/debian/patches/cherry-pick.FILE5_24-31-g3aa35aa.dont-leak-memory-when-loading-non-compiled-files.patch
--- 
file-5.22+15/debian/patches/cherry-pick.FILE5_24-31-g3aa35aa.dont-leak-memory-when-loading-non-compiled-files.patch
 1970-01-01 01:00:00.0 +0100
+++ 
file-5.22+15/debian/patches/cherry-pick.FILE5_24-31-g3aa35aa.dont-leak-memory-when-loading-non-compiled-files.patch
 2016-12-02 00:00:46.0 +0100
@@ -0,0 +1,32 @@
+Subject: Don't leak memory when loading non-compiled files
+Origin: FILE5_24-31-g3aa35aa
+Upstream-Author: Christos Zoulas <chris...@zoulas.com>
+Date: Thu Sep 10 13:59:47 2015 +
+
+--- a/src/apprentice.c
 b/src/apprentice.c
+@@ -538,6 +538,7 @@
+ private void
+ apprentice_unmap(struct magic_map *map)
+ {
++  size_t i;
+   if (map == NULL)
+   return;
+ 
+@@ -550,6 +551,8 @@
+ #endif
+   case MAP_TYPE_MALLOC:
+   free(map->p);
++  for (i = 0; i < MAGIC_SETS; i++)
++  free(map->magic[i]);
+   break;
+   case MAP_TYPE_USER:
+   break;
+@@ -1285,6 +1288,7 @@
+   file_oomem(ms, sizeof(*map));
+   return NULL;
+   }
++  map->type = MAP_TYPE_MALLOC;
+ 
+   /* print silly verbose header for USG compat. */
+   if (action == FILE_CHECK)
diff -Nru 
file-5.22+15/debian/patches/cherry-pick.FILE5_28-42-g10ee4ec.pr-569-shi-yin-fix-memory-leak.patch
 
file-5.22+15/debian/patches/cherry-pick.FILE5_28-42-g10ee4ec.pr-569-shi-yin-fix-memory-leak.patch
--- 
file-5.22+15/debian/patches/cherry-pick.FILE5_28-42-g10ee4ec.pr-569-shi-yin-fix-memory-leak.patch
   1970-01-01 01:00:00.0 +0100
+++ 
file-5.22+15/debian/patches/cherry-pick.FILE5_28-42-g10ee4ec.pr-569-shi-yin-fix-memory-leak.patch
   2016-12-04 09:36:35.0 +0100
@@ -0,0 +1,22 @@
+Subject: PR/569: Shi Yin: Fix memory leak
+Origin: FILE5_28-42-g10ee4ec
+Upstream-Author: Christos Zoulas <chris...@zoulas.com>
+Date: Sun Sep 11 13:53:02 2016 +
+Comment: Only relevant parts of that commit were used
+
+--- a/src/apprentice.c
 b/src/apprentice.c
+@@ -404,11 +404,11 @@
+ {
+   struct mlist *ml;
+ 
+-  mlp->map = idx == 0 ? map : NULL;
++  mlp->map = NULL;
+   if ((ml = CAST(struct mlist *, malloc(sizeof(*ml == NULL)
+   return -1;
+ 
+-  ml->map = NULL;
++  ml->map = idx == 0 ? map : NULL;
+   ml->magic = map->magic[idx];
+   ml->nmagic = map->nmagic[idx];
+ 
diff -Nru file-5.22+15/debian/patches/series file-5.22+15/debian/patches/series
--- file-5.22+15/debian/patches/series  2016-05-09 08:10:53.0 +0200
+++ file-5.22+15/debian/patches/series  2016-12-04 09:50:30.0 +0100
@@ -13,3 +13,5 @@
 cherry-pick.FILE5_24-22-g27b4e34.parameter-1.patch
 cherry-pick.FILE5_24-23-g4ddb783.parameter-2.patch
 CVE-2015-8865.6713ca4.patch
+cherry-pick.FILE5_24-31-g3aa35aa.dont-leak-memory-when-loading-non-compile

Re: Porter roll call for Debian Stretch

[Christoph Biedl]

John Paul Adrian Glaubitz wrote...

> On 09/20/2016 11:16 PM, Niels Thykier wrote:
> >- powerpc: No porter (RM blocker)
> 
> I'd be happy to pick up powerpc to keep it for Stretch. I'm already
> maintaining powerpcspe which is very similar to powerpc.

For somewhat personal reasons I'm interested in keeping powerpc in
stretch as well. I certainly cannot take the entire role as a porter,
especially since I don't know what amount of work this implies. But I
am willing to help.

There are two powerpc boxes in my collection, used regulary. One runs
on stable, the other on testing. I haven't done d-i tests but
certainly could do.

Christoph



signature.asc
Description: Digital signature

Bug#830221: jessie-pu: package tcpreplay/3.4.4-2

[Christoph Biedl]

Salvatore Bonaccorso wrote...

> On Thu, Jul 07, 2016 at 05:41:12PM +0200, Adam D. Barratt wrote:
>
> > Please go ahead.
> 
> I uploaded Christoph's package.

Thanks to you both for your work on this issue.

Christoph


signature.asc
Description: Digital signature

Bug#830221: jessie-pu: package tcpreplay/3.4.4-2

[Christoph Biedl]

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

Hello release team,

there is a way to trigger a segfault in the tcprewrite program,
part of the tcpreplay package. This has been assigned 
CVE-2016-6160, BTS#829350.

Security team has suggested to fix this in a point release, the
debdiff for 3.4.4-2+deb8u1 is attached.

For the records, I'm not the package maintainer but the maintainer has
acknowledged this procedure.

Regards,

Christoph

-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.13 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
diff -Nru tcpreplay-3.4.4/debian/changelog tcpreplay-3.4.4/debian/changelog
--- tcpreplay-3.4.4/debian/changelog2012-07-07 16:20:40.0 +0200
+++ tcpreplay-3.4.4/debian/changelog2016-07-07 10:54:50.0 +0200
@@ -1,3 +1,10 @@
+tcpreplay (3.4.4-2+deb8u1) stable; urgency=low
+
+  * tcprewrite: Handle frames of 65535 octets size, add a
+size check [CVE-2016-6160]. Closes: #829350 
+
+ -- Christoph Biedl <debian.a...@manchmal.in-ulm.de>  Thu, 07 Jul 2016 
10:53:56 +0200
+
 tcpreplay (3.4.4-2) unstable; urgency=low
 
   * debian/control fixed lintian error
diff -Nru tcpreplay-3.4.4/debian/patches/enforce-maxpacket.patch 
tcpreplay-3.4.4/debian/patches/enforce-maxpacket.patch
--- tcpreplay-3.4.4/debian/patches/enforce-maxpacket.patch  1970-01-01 
01:00:00.0 +0100
+++ tcpreplay-3.4.4/debian/patches/enforce-maxpacket.patch  2016-07-07 
10:54:41.0 +0200
@@ -0,0 +1,33 @@
+Subject: tcprewrite: Handle frames of 65535 octets size
+ID: CVE-2016-6160
+Author: Christoph Biedl <debian.a...@manchmal.in-ulm.de>
+Date: Mon Jun 29 17:08:24 2015 +0200
+Bug-Debian: https://bugs.debian.org/829350
+Last-Update: 2016-07-06
+
+diff --git a/src/defines.h.in b/src/defines.h.in
+index 3a1bf1e..5468d14 100644
+--- a/src/defines.h.in
 b/src/defines.h.in
+@@ -104,7 +104,7 @@ typedef struct tcpr_speed_s tcpr_speed_t;
+ #define DEFAULT_MTU 1500/* Max Transmission Unit of standard ethernet
+  * don't forget *frames* are MTU + L2 header! 
*/
+ 
+-#define MAXPACKET 65535 /* was 16436 linux loopback, but maybe 
something is bigger then 
++#define MAXPACKET 65549 /* was 16436 linux loopback, but maybe 
something is bigger then 
+linux loopback */
+ 
+ #define MAX_SNAPLEN 65535   /* tell libpcap to capture the entire packet 
*/
+diff --git a/src/tcprewrite.c b/src/tcprewrite.c
+index 90a6f2e..9c32a5e 100644
+--- a/src/tcprewrite.c
 b/src/tcprewrite.c
+@@ -253,6 +253,8 @@ rewrite_packets(tcpedit_t *tcpedit, pcap_t *pin, 
pcap_dumper_t *pout)
+ packetnum++;
+ dbgx(2, "packet " COUNTER_SPEC " caplen %d", packetnum, 
pkthdr.caplen);
+ 
++if (pkthdr.caplen > MAXPACKET)
++errx(-1, "Frame too big, caplen %d exceeds %d", pkthdr.caplen, 
MAXPACKET);
+ /* 
+  * copy over the packet so we can pad it out if necessary and
+  * because pcap_next() returns a const ptr
diff -Nru tcpreplay-3.4.4/debian/patches/series 
tcpreplay-3.4.4/debian/patches/series
--- tcpreplay-3.4.4/debian/patches/series   2012-07-06 23:32:50.0 
+0200
+++ tcpreplay-3.4.4/debian/patches/series   2015-07-08 00:46:22.0 
+0200
@@ -1 +1,2 @@
 configure-pcap.patch
+enforce-maxpacket.patch


signature.asc
Description: Digital signature

Bug#823794: jessie-pu: package file/1:5.22+15-2+deb8u2

[Christoph Biedl]

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

Hello release team,

the stable security team suggested to fix CVE-2015-8865¹ in the
file package via a point relase.

Description: "Buffer over-write in finfo_open with malformed magic
file". If a magic file is unter attacker's control, this can be abused
to crash file.

The debdiff is attached.

Regards,

Christoph

¹https://security-tracker.debian.org/tracker/CVE-2015-8865

-- System Information:
Debian Release: 8.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.9 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

diff -Nru file-5.22+15/debian/changelog file-5.22+15/debian/changelog
--- file-5.22+15/debian/changelog   2015-09-13 18:27:47.0 +0200
+++ file-5.22+15/debian/changelog   2016-05-09 08:23:30.0 +0200
@@ -1,3 +1,10 @@
+file (1:5.22+15-2+deb8u2) stable; urgency=high
+
+  * Fix CVE-2015-8865:
+Buffer over-write in finfo_open with malformed magic file.
+
+ -- Christoph Biedl <debian.a...@manchmal.in-ulm.de>  Mon, 09 May 2016 
08:18:53 +0200
+
 file (1:5.22+15-2+deb8u1) stable; urgency=medium
 
   * Fix handling of file's --parameter option. Closes: #798410
diff -Nru file-5.22+15/debian/patches/CVE-2015-8865.6713ca4.patch 
file-5.22+15/debian/patches/CVE-2015-8865.6713ca4.patch
--- file-5.22+15/debian/patches/CVE-2015-8865.6713ca4.patch 1970-01-01 
01:00:00.0 +0100
+++ file-5.22+15/debian/patches/CVE-2015-8865.6713ca4.patch 2016-05-09 
08:17:17.0 +0200
@@ -0,0 +1,24 @@
+Subject: Buffer over-write in finfo_open with malformed magic file
+ID: CVE-2015-8865
+Upstream-Author: Christos Zoulas <chris...@zoulas.com>
+Author: Christos Zoulas <chris...@zoulas.com>
+Date: Wed Jun 3 18:01:20 2015 +
+Origin: FILE5_22-75-g6713ca4
+Origin: https://bugs.php.net/bug.php?id=71527 (Original bug report)
+Origin: http://bugs.gw.com/view.php?id=522 (bug report for file)
+
+[ Original description: ]
+PR/454: Fix memory corruption when the continuation level jumps by more 
than
+20 in a single step.
+
+--- a/src/funcs.c
 b/src/funcs.c
+@@ -401,7 +401,7 @@
+   size_t len;
+ 
+   if (level >= ms->c.len) {
+-  len = (ms->c.len += 20) * sizeof(*ms->c.li);
++  len = (ms->c.len = 20 + level) * sizeof(*ms->c.li);
+   ms->c.li = CAST(struct level_info *, (ms->c.li == NULL) ?
+   malloc(len) :
+   realloc(ms->c.li, len));
diff -Nru file-5.22+15/debian/patches/series file-5.22+15/debian/patches/series
--- file-5.22+15/debian/patches/series  2015-09-13 18:26:26.0 +0200
+++ file-5.22+15/debian/patches/series  2016-05-09 08:10:53.0 +0200
@@ -12,3 +12,4 @@
 0013-jpeg.c5d7f4d.patch
 cherry-pick.FILE5_24-22-g27b4e34.parameter-1.patch
 cherry-pick.FILE5_24-23-g4ddb783.parameter-2.patch
+CVE-2015-8865.6713ca4.patch


signature.asc
Description: Digital signature

Bug#799033: jessie-pu: package file/1:5.22+15-2+deb8u1

[Christoph Biedl]

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

Hello release team,

for the next jessie point relase, I'd like to upload a new version
of the file package, in order to fix the bug described in

https://bugs.debian.org/798410
http://mx.gw.com/pipermail/file/2015/001777.html

Short version: The handling of file's --parameter command line option
is broken, the program segfaults upon every usage. Additionally,
--parameter has no effect when used with --files-from.

Triggering the first issue is as simple as running "file --parameter";
for the second one I have a no public reproducer so far but can provide
a file in private upon request.

Both issues have been fixed upstream recently, my proposed upload adds
the cherry-picked commits, two one-liners. The debdiff is attached.

Regards,

Christoph

-- System Information:
Debian Release: 8.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.1.6 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

diff -Nru file-5.22+15/debian/changelog file-5.22+15/debian/changelog
--- file-5.22+15/debian/changelog   2015-03-10 22:13:50.0 +0100
+++ file-5.22+15/debian/changelog   2015-09-13 18:33:51.0 +0200
@@ -1,3 +1,13 @@
+file (1:5.22+15-2+deb8u1) stable; urgency=medium
+
+  * Fix handling of file's --parameter option. Closes: #798410
+- The file program segfaults after processing the --parameter
+  parameter. [commit FILE5_24-22-g27b4e34]
+- Any --parameter values have no effect if used with
+  --files-from. [commit FILE5_24-23-g4ddb783]
+
+ -- Christoph Biedl <debian.a...@manchmal.in-ulm.de>  Sun, 13 Sep 2015 
18:27:47 +0200
+
 file (1:5.22+15-2) unstable; urgency=medium
 
   * Restore detection of some jpeg files. Closes: #780095
diff -Nru 
file-5.22+15/debian/patches/cherry-pick.FILE5_24-22-g27b4e34.parameter-1.patch 
file-5.22+15/debian/patches/cherry-pick.FILE5_24-22-g27b4e34.parameter-1.patch
--- 
file-5.22+15/debian/patches/cherry-pick.FILE5_24-22-g27b4e34.parameter-1.patch  
1970-01-01 01:00:00.0 +0100
+++ 
file-5.22+15/debian/patches/cherry-pick.FILE5_24-22-g27b4e34.parameter-1.patch  
2015-09-13 18:25:31.0 +0200
@@ -0,0 +1,16 @@
+Subject: --parameter takes a parameter
+Origin: FILE5_24-22-g27b4e34
+Upstream-Author: Christos Zoulas <chris...@zoulas.com>
+Date: Tue Sep 8 13:46:01 2015 +
+
+--- a/src/file_opts.h
 b/src/file_opts.h
+@@ -43,7 +43,7 @@
+ #if defined(HAVE_UTIME) || defined(HAVE_UTIMES)
+ OPT('p', "preserve-date", 0, "preserve access times on files\n")
+ #endif
+-OPT('P', "parameter", 0, "set file engine parameter limits\n"
++OPT('P', "parameter", 1, "set file engine parameter limits\n"
+ "   indir15 recursion limit for 
indirection\n"
+ "   name 30 use limit for name/use 
magic\n"
+ "   elf_notes   256 max ELF notes processed\n"
diff -Nru 
file-5.22+15/debian/patches/cherry-pick.FILE5_24-23-g4ddb783.parameter-2.patch 
file-5.22+15/debian/patches/cherry-pick.FILE5_24-23-g4ddb783.parameter-2.patch
--- 
file-5.22+15/debian/patches/cherry-pick.FILE5_24-23-g4ddb783.parameter-2.patch  
1970-01-01 01:00:00.0 +0100
+++ 
file-5.22+15/debian/patches/cherry-pick.FILE5_24-23-g4ddb783.parameter-2.patch  
2015-09-13 18:25:32.0 +0200
@@ -0,0 +1,15 @@
+Subject: apply parameters before unwrapping() the list of files
+Origin: FILE5_24-23-g4ddb783
+Upstream-Author: Christos Zoulas <chris...@zoulas.com>
+Date: Tue Sep 8 13:46:49 2015 +
+
+--- a/src/file.c
 b/src/file.c
+@@ -233,6 +233,7 @@
+   if (magic == NULL)
+   if ((magic = load(magicfile, flags)) == NULL)
+   return 1;
++  applyparam(magic);
+   e |= unwrap(magic, optarg);
+   ++didsomefiles;
+   break;
diff -Nru file-5.22+15/debian/patches/series file-5.22+15/debian/patches/series
--- file-5.22+15/debian/patches/series  2015-03-10 20:56:19.0 +0100
+++ file-5.22+15/debian/patches/series  2015-09-13 18:25:10.0 +0200
@@ -10,3 +10,5 @@
 0011-btrfs.patch
 0012-lxt.patch
 0013-jpeg.c5d7f4d.patch
+cherry-pick.FILE5_24-22-g27b4e34.parameter-1.patch
+cherry-pick.FILE5_24-23-g4ddb783.parameter-2.patch


signature.asc
Description: Digital signature

Bug#780248: unblock: file/1:5.22+15-2

[Christoph Biedl]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock file 1:5.22+15-2

The actual change (full debdiff attached) is a one-liner and fixes bug
#780095 where certain jpeg files are no longer detected as such, the
output DOS/MBR boot sector is completely bogus. This bug is also a
regression compared to the wheezy version of file.

A check against a huge collection of test files - something I do
before every upload, including security fixes - showed no other
changes.

And just in case: The regression is rather old (upstream commit
FILE5_11-63-g51ceb2b, October 2012) but just hadn't been noticed
before. In other words, this was *not* introduced by the recent
unblock of file 1:5.22+15-1.

Kind regards,

Christoph
diff -Nru file-5.22+15/debian/changelog file-5.22+15/debian/changelog
--- file-5.22+15/debian/changelog   2015-01-09 08:01:00.0 +0100
+++ file-5.22+15/debian/changelog   2015-03-10 22:13:50.0 +0100
@@ -1,3 +1,9 @@
+file (1:5.22+15-2) unstable; urgency=medium
+
+  * Restore detection of some jpeg files. Closes: #780095
+
+ -- Christoph Biedl debian.a...@manchmal.in-ulm.de  Tue, 10 Mar 2015 
20:41:54 +0100
+
 file (1:5.22+15-1) unstable; urgency=high
 
   * Use upstream commit FILE5_22-11-ge452600 to include yet another
diff -Nru file-5.22+15/debian/patches/0013-jpeg.c5d7f4d.patch 
file-5.22+15/debian/patches/0013-jpeg.c5d7f4d.patch
--- file-5.22+15/debian/patches/0013-jpeg.c5d7f4d.patch 1970-01-01 
01:00:00.0 +0100
+++ file-5.22+15/debian/patches/0013-jpeg.c5d7f4d.patch 2015-03-10 
20:56:19.0 +0100
@@ -0,0 +1,17 @@
+Subject: bump jpeg to beat DOS/MBR
+Upstream-Author: Christos Zoulas chris...@zoulas.com
+Date: Fri Feb 6 17:08:31 2015 +
+Origin: FILE5_22-27-gc5d7f4d
+Last-Update: 2015-03-10
+
+--- a/magic/Magdir/jpeg
 b/magic/Magdir/jpeg
+@@ -12,7 +12,7 @@
+ 0 beshort 0xffd8  JPEG image data
+ !:mimeimage/jpeg
+ !:apple   8BIMJPEG
+-!:strength +2
++!:strength *3
+ 6string  JFIF\b, JFIF standard
+ # The following added by Erik Rossen ros...@freesurf.ch 1999-09-06
+ # in a vain attempt to add image size reporting for JFIF.  Note that these
diff -Nru file-5.22+15/debian/patches/series file-5.22+15/debian/patches/series
--- file-5.22+15/debian/patches/series  2014-12-21 23:19:33.0 +0100
+++ file-5.22+15/debian/patches/series  2015-03-10 20:56:19.0 +0100
@@ -9,3 +9,4 @@
 0010-mdadm.patch
 0011-btrfs.patch
 0012-lxt.patch
+0013-jpeg.c5d7f4d.patch


signature.asc
Description: Digital signature

Bug#778338: unblock: file/1:5.22+15-1

[Christoph Biedl]

Hi there,

while finally preparing an answer I noticed somebody unblocked the
file package for jessie without further discussion. Whoever pulled the
strings, thanks a lot. And I hope this will not end in regressions or
other annoyances.

Just one more thing:

   Not to mention, in the previous release, an upload of file (for
 unstable) broke dpkg's dpkg-shlibs.  I know it was not you, who uploaded
 that and I suspect this version of file is unlikely to be that bad given
 it has been in unstable for 1½ months.

I'd like to learn more about that but my search was unsuccessful for
lack of proper search term. Could you provide a pointer, bug# or the
like?

Thanks again.

Christoph


signature.asc
Description: Digital signature

Bug#778338: unblock: file/1:5.22+15-1

[Christoph Biedl]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Short version: Please unblock file 1:5.22+15-1

It entered unstable a few weeks ago, I did extensive testing before
upoading and no issues have been reported. However, switching to a new
upstream version still requires a longer explanation.


Since the latest version in jessie (1:5.20-2), at least six¹ security
issues were fixed upstream. The usual way to handle this in Debian was
to cherry-pick the relevant commits from upstream. Together with the
required prerequsites, this would have resulted in some 18 commits to
add to the patch queue, creating a complex start for file in jessie.

My decision to forward to a new upstream version (plus some more
commits) instead was also driven by the experience of backporting
fixes for wheezy and squeeze-lts which became quite complex, always
carrying the risk of introducing new bugs. For jessie, I'd like to
start at a late point so fixing future security bugs will be easier.

Note, I have not attached the debdiff as it's rather huge, some
69k lines. I will hand it in later upon request.

Kind regards,

Christoph

¹ https://security-tracker.debian.org/tracker/source-package/file
  Unless noted in the tracker, the sid version of file does
  contain the fix for CVE-2014-9653. Upstream fix is commit 445c8fb
  (FILE5_21-10-g445c8fb) which is included in 5.22.


signature.asc
Description: Digital signature

Bug#772103: unblock: ngircd/19.2-2

[Christoph Biedl]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package ngircd 22-2

Compared to jessie version 22-1, there is no change in the code so I'm
highly confident this will not break anything. Still I'd like to see
that version in jessie since the a the test suite was modified so the
build no longer fails on systems with a certain configuration that
might happen in the wild, more precisely: The order of the lines in
/etc/hosts affects the outcome of the test suite run during build.

This was fixed upstream recently, ngircd 22-2 contains the
cherry-picked commit. Having this version in jessie would help all
kinds of porters, backporters, or downstream.

Examples for failed builds:

http://buildd.debian-ports.org/status/fetch.php?pkg=ngircdarch=hppaver=22-1stamp=1413444136
http://buildd.debian-ports.org/status/fetch.php?pkg=ngircdarch=ppc64ver=22-1stamp=1413440124
http://buildd.raspbian.org/status/fetch.php?pkg=ngircdarch=armhfver=21-1stamp=1385321803

Regards,

Christoph

unblock ngircd/22-2

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

Kernel: Linux 3.17.4 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
diff -Nru ngircd-22/debian/changelog ngircd-22/debian/changelog
--- ngircd-22/debian/changelog  2014-10-15 20:47:12.0 +0200
+++ ngircd-22/debian/changelog  2014-11-04 22:27:19.0 +0100
@@ -1,3 +1,11 @@
+ngircd (22-2) unstable; urgency=low
+
+  * Re-enable whois-test
+  * Cherry-pick upstream commit rel-22-6-g31b3c83: Test suite: Don't
+use DNS lookups.
+
+ -- Christoph Biedl debian.a...@manchmal.in-ulm.de  Tue, 04 Nov 2014 
22:26:00 +0100
+
 ngircd (22-1) unstable; urgency=low
 
   * New upstream version 22
diff -Nru ngircd-22/debian/patches/disable-whois-test.patch 
ngircd-22/debian/patches/disable-whois-test.patch
--- ngircd-22/debian/patches/disable-whois-test.patch   2014-10-15 
20:46:12.0 +0200
+++ ngircd-22/debian/patches/disable-whois-test.patch   1970-01-01 
01:00:00.0 +0100
@@ -1,18 +0,0 @@
-Subject: Disable whois test in build
-Author: Christoph Biedl debian.a...@manchmal.in-ulm.de
-Date: Sun Nov 6 21:42:21 2011 +0100
-Last-Update: 2014-10-15
-
-This test relies on a certain format of /etc/hosts, something that
-is not assured in every build system.
-
 a/src/testsuite/Makefile.in
-+++ b/src/testsuite/Makefile.in
-@@ -202,7 +202,6 @@ TESTS = start-server1 \
-   mode-test \
-   opless-channel-test \
-   who-test \
--  whois-test \
-   server-link-test \
-   stop-server2 \
-   stress-server.sh \
diff -Nru ngircd-22/debian/patches/series ngircd-22/debian/patches/series
--- ngircd-22/debian/patches/series 2014-10-15 20:46:12.0 +0200
+++ ngircd-22/debian/patches/series 2014-11-04 22:25:26.0 +0100
@@ -1 +1 @@
-disable-whois-test.patch
+test-suite-dont-use-dns-lookups.patch
diff -Nru ngircd-22/debian/patches/test-suite-dont-use-dns-lookups.patch 
ngircd-22/debian/patches/test-suite-dont-use-dns-lookups.patch
--- ngircd-22/debian/patches/test-suite-dont-use-dns-lookups.patch  
1970-01-01 01:00:00.0 +0100
+++ ngircd-22/debian/patches/test-suite-dont-use-dns-lookups.patch  
2014-11-04 22:25:26.0 +0100
@@ -0,0 +1,319 @@
+Subject: Test suite: Don't use DNS lookups
+Author: Alexander Barton a...@barton.de
+Date: Thu Apr 17 23:57:38 2014 +0200
+Origin:
+commit 3f807e104572b38143a1015be57d875088ceaebb
+Last-Update: 2014-11-01
+
+Test suite: Don't use DNS lookups
+
+Different operating systems do behave quite differently when doing DNS
+lookups, for example 127.0.0.1 sometimes resolves to localhost and
+sometimes to localhost.localdomain (for example OpenBSD). And other
+systems resolve localhost to the real host name (for example Cygwin).
+
+So not using DNS at all makes the test site much more portable.
+
+--- a/src/testsuite/channel-test.e
 b/src/testsuite/channel-test.e
+@@ -1,7 +1,7 @@
+ # ngIRCd test suite
+ # Channel test
+ 
+-spawn telnet localhost 6789
++spawn telnet 127.0.0.1 6789
+ expect {
+   timeout { exit 1 }
+   Connected
+--- a/src/testsuite/check-idle.e
 b/src/testsuite/check-idle.e
+@@ -1,7 +1,7 @@
+ # ngIRCd test suite
+ # Idle test
+ 
+-spawn telnet localhost 6789
++spawn telnet 127.0.0.1 6789
+ expect {
+   timeout { exit 1 }
+   Connected
+--- a/src/testsuite/connect-test.e
 b/src/testsuite/connect-test.e
+@@ -1,7 +1,7 @@
+ # ngIRCd test suite
+ # Server connect test
+ 
+-spawn telnet localhost 6789
++spawn telnet 127.0.0.1 6789
+ expect {
+   timeout { exit 1 }
+   Connected
+--- a/src/testsuite/invite-test.e
 b/src/testsuite/invite-test.e
+@@ -1,7 +1,7 @@
+ # ngIRCd test suite
+ # INVITE test
+ 
+-spawn telnet localhost 6789
++spawn telnet 127.0.0.1 6789
+ expect

Bug#772103: unblock: ngircd/19.2-2

[Christoph Biedl]

retitle -1 unblock: ngircd/22-2
thanks

Fixing bug title.

Christoph



signature.asc
Description: Digital signature

Requesting permission to upload certificatepatrol 2.0.14-4+deb7u1 to s-p-u

[Christoph Biedl]

Hello release team,

hereby I'm asking for permission to upload the testing/sid version
2.0.14-4 of src:certificatepatrol to stable-proprosed-updates as in
the attached debdiff.

Rationale:

Today's upgrade of iceweasel in wheezy through [DSA 2858-1] increased
the version number from 17 to 24, breaking the wheezy version 2.0.14-3
of xul-ext-certificatepatrol due to upper limit in the acceptable
firefox/iceweasel version number in that package, a limit originally
inherited from upstream. This was fixed in unstable (2.0.14-4) about a
year ago but is now also needed in wheezy.

Two more things:

* Not a bit was changed in the actual code of certificatepatrol. The
  delta is about the xul-internal dependencies, and a small upgrade in
  the build options.

* While testing, I could not reproduce #705569, will double-check that
  later in sid. In other words, the stable user should not see any
  difference after the upgrade.

Regards,

Christoph
diff -u certificatepatrol-2.0.14/install.rdf certificatepatrol-2.0.14/install.rdf
--- certificatepatrol-2.0.14/install.rdf
+++ certificatepatrol-2.0.14/install.rdf
@@ -41,7 +41,7 @@
   Description
 em:id{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/em:id !-- Firefox, Iceweasel, Flock --
 em:minVersion3.5/em:minVersion
-em:maxVersion19.0/em:maxVersion
+em:maxVersion4687/em:maxVersion
   /Description
 /em:targetApplication
 
@@ -57,7 +57,7 @@
   Description
 	em:id{3550f703-e582-4d05-9a08-453d09bdfdc6}/em:id !-- Thunderbird --
 	em:minVersion3.0/em:minVersion
-	em:maxVersion19.0/em:maxVersion
+	em:maxVersion4687/em:maxVersion
   /Description
 /em:targetApplication
 
@@ -75,7 +75,7 @@
   Description
 em:id{92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a}/em:id !-- SeaMonkey --
 em:minVersion2.0/em:minVersion
-em:maxVersion2.7a1/em:maxVersion
+em:maxVersion4687/em:maxVersion
   /Description
 /em:targetApplication
 
diff -u certificatepatrol-2.0.14/debian/compat certificatepatrol-2.0.14/debian/compat
--- certificatepatrol-2.0.14/debian/compat
+++ certificatepatrol-2.0.14/debian/compat
@@ -1 +1 @@
-7
+9
diff -u certificatepatrol-2.0.14/debian/rules certificatepatrol-2.0.14/debian/rules
--- certificatepatrol-2.0.14/debian/rules
+++ certificatepatrol-2.0.14/debian/rules
@@ -4 +4 @@
-	dh --with xul-ext --buildsystem=xul_ext $@
+	dh $@ --with xul-ext --buildsystem=xul_ext
diff -u certificatepatrol-2.0.14/debian/changelog certificatepatrol-2.0.14/debian/changelog
--- certificatepatrol-2.0.14/debian/changelog
+++ certificatepatrol-2.0.14/debian/changelog
@@ -1,3 +1,17 @@
+certificatepatrol (2.0.14-4+deb7u1) wheezy; urgency=medium
+
+  * Upload to proposed-stable-updates to make certificatepatrol
+usable with iceweasel 24. Closes: #738560
+
+ -- Christoph Biedl debian.a...@manchmal.in-ulm.de  Mon, 10 Feb 2014 17:13:36 +
+
+certificatepatrol (2.0.14-4) unstable; urgency=low
+
+  * Raise upper version limit again, to a value so that we're
+hopefully not bothered again this century. Closes: #702836
+
+ -- Christoph Biedl debian.a...@manchmal.in-ulm.de  Tue, 12 Mar 2013 11:31:24 +0100
+
 certificatepatrol (2.0.14-3) unstable; urgency=low
 
   * Raise upper version limit for iceweasel and icedove to 19. This
diff -u certificatepatrol-2.0.14/debian/control certificatepatrol-2.0.14/debian/control
--- certificatepatrol-2.0.14/debian/control
+++ certificatepatrol-2.0.14/debian/control
@@ -2,9 +2,9 @@
 Section: web
 Priority: optional
 Maintainer: Christoph Biedl debian.a...@manchmal.in-ulm.de
-Build-Depends: debhelper (= 7.0.50~),
+Build-Depends: debhelper (= 9~),
 mozilla-devscripts (= 0.22~),
-Standards-Version: 3.9.2
+Standards-Version: 3.9.4
 Homepage: http://patrol.psyced.org/
 
 Package: xul-ext-certificatepatrol


signature.asc
Description: Digital signature

Re: Requesting permission to upload certificatepatrol 2.0.14-4+deb7u1 to s-p-u

[Christoph Biedl]

Adam D. Barratt wrote...

 On 2014-02-10 17:36, Christoph Biedl wrote:
 hereby I'm asking for permission to upload the testing/sid version
 2.0.14-4 of src:certificatepatrol to stable-proprosed-updates as in
 the attached debdiff.

 Thanks for looking at fixing this in stable.

 For future reference, please file such requests as p-u bugs
 against the release.debian.org pseudopackage (e.g. via reportbug
 release.debian.org).

Noted. I tried to follow the procedures as described in
http://www.debian.org/releases/proposed-updates, does that page give
bad advice?

(...)

 None of the above changes are appropriate for a stable update, nor
 are they required to fix the iceweasel issue; please remove them.
 (As such, it may actually be easier and cleaner to start from
 stable's 2.0.14-3 and produce a -3+deb7u1.)

... and solving the version number problem on the fly. See the updated
patch attached.

Christoph
diff -u certificatepatrol-2.0.14/install.rdf certificatepatrol-2.0.14/install.rdf
--- certificatepatrol-2.0.14/install.rdf
+++ certificatepatrol-2.0.14/install.rdf
@@ -41,7 +41,7 @@
   Description
 em:id{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/em:id !-- Firefox, Iceweasel, Flock --
 em:minVersion3.5/em:minVersion
-em:maxVersion19.0/em:maxVersion
+em:maxVersion4687/em:maxVersion
   /Description
 /em:targetApplication
 
@@ -57,7 +57,7 @@
   Description
 	em:id{3550f703-e582-4d05-9a08-453d09bdfdc6}/em:id !-- Thunderbird --
 	em:minVersion3.0/em:minVersion
-	em:maxVersion19.0/em:maxVersion
+	em:maxVersion4687/em:maxVersion
   /Description
 /em:targetApplication
 
@@ -75,7 +75,7 @@
   Description
 em:id{92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a}/em:id !-- SeaMonkey --
 em:minVersion2.0/em:minVersion
-em:maxVersion2.7a1/em:maxVersion
+em:maxVersion4687/em:maxVersion
   /Description
 /em:targetApplication
 
diff -u certificatepatrol-2.0.14/debian/changelog certificatepatrol-2.0.14/debian/changelog
--- certificatepatrol-2.0.14/debian/changelog
+++ certificatepatrol-2.0.14/debian/changelog
@@ -1,3 +1,11 @@
+certificatepatrol (2.0.14-3+deb7u1) wheezy; urgency=medium
+
+  * Cherry-pick from 2.0.14-4: Raise upper version limit again to
+make certificatepatrol usable with iceweasel 24.
+Closes: #702836, #738560
+
+ -- Christoph Biedl debian.a...@manchmal.in-ulm.de  Mon, 10 Feb 2014 18:13:18 +
+
 certificatepatrol (2.0.14-3) unstable; urgency=low
 
   * Raise upper version limit for iceweasel and icedove to 19. This


signature.asc
Description: Digital signature

Re: Requesting permission to upload certificatepatrol 2.0.14-4+deb7u1 to s-p-u

[Christoph Biedl]

Adam D. Barratt wrote...

 Please feel free to upload that version; thanks.

Thanks, now uploaded.

Christoph


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1392069...@msgid.manchmal.in-ulm.de

Bug#692594: unblock: ngircd/19.2-2

[Christoph Biedl]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package ngircd

The only change between 19.2-1 (in wheezy) and 19.2-2 uploaded to unstable a
few hours ago: The japanese translation was added, taken from

Subject: Bug#692479: ngircd: [INTL:ja] New Japanese translation

The debdiff output is attached.

Regards,

Christoph

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)

Kernel: Linux 3.4.17 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

diff -u ngircd-19.2/debian/changelog ngircd-19.2/debian/changelog
--- ngircd-19.2/debian/changelog
+++ ngircd-19.2/debian/changelog
@@ -1,3 +1,9 @@
+ngircd (19.2-2) unstable; urgency=low
+
+  * Debconf translation: Japanese (victory). Closes: #692479
+
+ -- Christoph Biedl debian.a...@manchmal.in-ulm.de  Tue, 06 Nov 2012 
23:26:40 +0100
+
 ngircd (19.2-1) unstable; urgency=low
 
   * New upstream version 19.2
only in patch2:
unchanged:
--- ngircd-19.2.orig/debian/po/ja.po
+++ ngircd-19.2/debian/po/ja.po
@@ -0,0 +1,90 @@
+# SOME DESCRIPTIVE TITLE.
+# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
+# This file is distributed under the same license as the PACKAGE package.
+# victory victory@gmail.com, 2012.
+#
+msgid 
+msgstr 
+Project-Id-Version: ngircd\n
+Report-Msgid-Bugs-To: ngi...@packages.debian.org\n
+POT-Creation-Date: 2012-06-20 17:34+\n
+PO-Revision-Date: 2012-06-21 02:34+0900\n
+Last-Translator: victory victory@gmail.com\n
+Language-Team: Japanese debian-japan...@lists.debian.org\n
+Language: ja\n
+MIME-Version: 1.0\n
+Content-Type: text/plain; charset=UTF-8\n
+Content-Transfer-Encoding: 8bit\n
+
+#. Type: boolean
+#. Description
+#: ../ngircd.templates:2001
+msgid Convert ngIRCd configuration?
+msgstr ngIRCd の設定ファイルを変換しますか?
+
+#. Type: boolean
+#. Description
+#: ../ngircd.templates:2001
+msgid In version 18, the ngIRCd configuration file format has changed.
+msgstr バージョン 18 で ngIRCd 設定ファイルの形式が変わりました。
+
+#. Type: boolean
+#. Description
+#: ../ngircd.templates:2001
+msgid 
+You can choose to update the existing configuration or leave it unmodified. 
+The former configuration file format is still supported.
+msgstr 
+既存の設定ファイルを更新するかそのままにしておくかは選択できます。
+前の形式の設定ファイルもまだサポートしています。
+
+#. Type: text
+#. Description
+#: ../ngircd.templates:3001
+msgid Configuration conversion failure
+msgstr 設定ファイルの変換に失敗しました
+
+#. Type: text
+#. Description
+#: ../ngircd.templates:3001
+msgid The current configuration file contains errors and cannot be converted.
+msgstr 現在の設定ファイルに誤りがあるため変換ができません。
+
+#. Type: text
+#. Description
+#: ../ngircd.templates:3001
+msgid 
+You should check the configuration file by running \ngircd --configtest\, 
+fix any errors, and run \dpkg-reconfigure ngircd\ to retry the conversion 
+process.
+msgstr 
+「ngircd --configtest」を実行して設定ファイルを確認し、誤りをすべて修正してか
+ら「dpkg-reconfigure ngircd」を実行して変換の再試行を続けてください。
+
+#. Type: text
+#. Description
+#: ../ngircd.templates:4001
+msgid Converted configuration file error
+msgstr 変換後の設定ファイルに誤りがあります
+
+#. Type: text
+#. Description
+#: ../ngircd.templates:4001
+msgid The converted configuration failed validation checks.
+msgstr 変換後の設定ファイルが検証に引っかかりました。
+
+#. Type: text
+#. Description
+#: ../ngircd.templates:4001
+msgid 
+This should not happen and should therefore be reported as a bug. Please 
+include the configuration file in the bug report with passwords removed.
+msgstr 
+これは起こることがないはずなので、バグとして報告してください。
+設定ファイルを、パスワードの除去した上でバグ報告に含めてください。
+
+#. Type: text
+#. Description
+#: ../ngircd.templates:4001
+msgid The following difference file may help tracking this issue:
+msgstr 以下の差分ファイルがこの問題の追跡に役立つかもしれません:


signature.asc
Description: Digital signature

Re: Bug#373854: libtiff-tools: DSA 1091-1 broke tiffsplit

[Christoph Biedl]

Christoph Biedl wrote...

 Package: libtiff-tools
 Version: 3.7.2-5
 Severity: important

Let me elaborate on that.

How to repeat:

Use tiffsplit to split an arbitrary .tiff file:
| tiffsplit foo.tif foo.
This should result in a file name foo.aaa.tif (and foo.aab.tif and so on
if the .tiff contains more than one page). Since DSA 1091-1 a single
file D is created instead.

What goes wrong:

tiffsplit composes the name of the created file using the submitted
prefix with the serial appened (this is in fname) and the extension
.tif. The resulting name is written to path.

Prior to DSA 1091-1 the vulnerable code was
| strcpy(path, fname);
| strcat(path, .tif);

This was changed to
| snprintf(fname, sizeof(fname), %s.tif, fname);
but should obviously be
| snprintf(path, sizeof(path), %s.tif, fname);
and was discussed so in #369819.

Currently, in the subsequent
| out = TIFFOpen(path, TIFFIsBigEndian(in)?wb:wl);
path is not defined, the file name is whatever is in the stack at the
time of path's creation.

How to fix:
Exchange the according line in debian/patches/CVE-2006-2656.patch
Works for me.

Christoph


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]