Bug#1071552: [pkg-gnupg-maint] Bug#1071552: Bug#1071552: gnupg: Please upgrade GnuPG >= 2.4.4, current GnuPG break Emacs's EasyPG
On Thu 2024-05-30 18:34:13 +0200, Andreas Metzler wrote:
> the issue report refers to two patches, one of these is already part of
> 2.2.43. The other one[1] seemed pretty straightforward to backport
> (functions moved to other files and cipher_filter_ocb instead of
> cipher_filter_aead). I would appreciate a second pair of eyes.
I wish the patch wasn't so large, even if it appears to backport
cleanly!
I confess i don't fully understand the logic around iobufs and
I'm also more than a little distressed that the bulk of this logic and
buffer fiddling seems to be about deciding whether to compress the input
stream or not, on the basis of whether it's using SEPIDv1 (or LibrePGP's
non-standard OCB mode) vs. the deprecated, obsolete SED.
Nothing should be generating SED packets today, in 2024. The idea that
the compression layer is going to defend against chosen ciphertext
attacks is… lacking in cryptographic rigor.
Furthermore, the idea that GnuPG will (or will not) add a compression
layer depending on the first 5 bytes of the input stream is pretty
strange. Consider this deeply weird comparison, where depending on the
input data, the same GnuPG pipeline will compress or not compress:
```
0 dkg@alice:~$ packetlist() { printf '%s\n' "$1" | gpg --compress-algo=ZIP
--encrypt -r "$PGPID" | gpg --unwrap --decrypt | gpg --list-packets; }
0 dkg@alice:~$ diff -u <(packetlist %PDFx) <(packetlist %PDF-)
gpg: encrypted with 255-bit ECDH key, ID 38024D718ABA3F3B, created 2023-12-06
"Daniel Kahn Gillmor"
gpg: encrypted with 255-bit ECDH key, ID 38024D718ABA3F3B, created 2023-12-06
"Daniel Kahn Gillmor"
--- /dev/fd/63 2024-05-31 17:08:37.339457042 -0400
+++ /dev/fd/62 2024-05-31 17:08:37.339457042 -0400
@@ -1,6 +1,4 @@
-# off=0 ctb=a3 tag=8 hlen=1 plen=0 indeterminate
-:compressed packet: algo=1
-# off=2 ctb=cb tag=11 hlen=2 plen=12 new-ctb
+# off=0 ctb=cb tag=11 hlen=2 plen=12 new-ctb
:literal data packet:
mode b (62), created 1717189717, name="",
raw data: 6 bytes
1 dkg@alice:~$
```
Seems to me like the approach that would reduce the overall amount of
complexity is to have an explicit default that does not vary choice of
compression algorithm, based on the choice of incoming cleartext, and
then to actually respect any user-specified --compress-algo, which
doesn't seem to be happening when the first five octets of the input
stream match this magic list.
Of course, i'd be happy to just rip compression out of the OpenPGP
specification entirely anyway -- people who want to compress before
encrypting have many different ways of doing it irrespective of the
OpenPGP spec.
I think we should include an autopkgtest for the gnupg2 source package
as well that explicitly ensures that future updates don't break epg.el.
I'm including it here, but i'll also put it in the autopkgtests to
ensure we don't hit this regression again.
I propose to push this test plus your patch into salsa later today and
if it passes cleanly, i'll go ahead with the upload.
--dkg
#!/bin/sh
set -e
# Author: Daniel Kahn Gillmor
# Emacs has epg mode, which expects a certain behavior from GnuPG.
#
# GnuPG upstream doesn't think that it is a bug to break those
# expectations (see https://dev.gnupg.org/T6481) but we want to avoid
# having those problems in debian. (see
# https://bugs.debian.org/1071552)
# This test ensures that a simple attempt to send signed, encrypted
# PGP/MIME mail with emacs doesn't break with the current version of
# GnuPG.
WORKDIR="$(mktemp -d)"
mkdir -m 0700 "$WORKDIR/a" "$WORKDIR/b" "$WORKDIR/out"
OUTDIR="${AUTOPKGTEST_ARTIFACTS:-$WORKDIR/out}"
cleanup() {
find "$WORKDIR/out" -type f -print0 | xargs --null --no-run-if-empty -- head -v -n100
printf "Cleaning up working directory '%s'\n" "$WORKDIR"
rm -rf "$WORKDIR"
}
trap cleanup EXIT
GPG() {
home=$1
shift
gpg --quiet --homedir "$WORKDIR/$home" --batch --pinentry-mode=loopback --passphrase='' --no-tty --status-file="$WORKDIR/status" "$@"
}
GPG a --quick-gen-key "Alice "
ALICE_FPR=$(grep KEY_CREATED "$WORKDIR/status" | cut -f4 -d\ )
GPG b --quick-gen-key "Bob "
BOB_FPR=$(grep KEY_CREATED "$WORKDIR/status" | cut -f4 -d\ )
GPG b --export "Bob " | GPG a --import
# Alice certifies Bob's certificate locally so that her GnuPG installation knows it is valid:
GPG a --quick-lsign-key "$BOB_FPR" "Bob "
cat > "$WORKDIR/mailscript.el" <" "this is a test")
(message-goto-body)
(insert "we need to see whether easypg can handle encryption (see https://dev.gnupg.org/T6481)")
(mml-secure-message-sign-encrypt)
(let ((mml-secure-openpgp-sign-with-sender t)
(message-send-mail-function (lambda () (write-region nil nil
Bug#1069686: libsequoia-octopus-librnp: postinst script Syntax error: "fi" unexpected
On Mon 2024-04-22 20:17:54 +, Holger Levsen wrote: > fixed in git. thanks! I've just uninstalled the octopus, but i'll consider reinstalling it later if this and some of the performance issues can be ironed out (or maybe to help iron out the performance issues, visible upstream at https://gitlab.com/sequoia-pgp/sequoia-octopus-librnp/-/issues/102) > the change seems innocent enough... (I just wasnt expected the different > formatting styles...) i hear you, and i've made this exact mistake myself more times than i can count :P > the irony is: the autopkg tests for the package had failed which I blamed > on unstables unstableness these days, so I reviewed the diff once more, > (again) didnt notice the introduced bug and did a source only upload, > because the change were tiny... :/ urgh, yeah, unstable breakage makes everything harder. I'm still thinking about what kinds of autopkgtests might be useful in terms of ensuring that thunderbird actually works with librnp, though. that's different from the autopkgtests generated by debcargo. I'll report that in a different bug report, though, maybe we can brainstorm there. --dkg signature.asc Description: PGP signature
Bug#1069686: libsequoia-octopus-librnp: postinst script Syntax error: "fi" unexpected
Package: libsequoia-octopus-librnp Version: 1.8.1-3 Severity: grave X-Debbugs-Cc: Daniel Kahn Gillmor Trying to install libsequoia-octopus-librnp: /var/lib/dpkg/tmp.ci/preinst: 12: Syntax error: "fi" unexpected (expecting "then") dpkg: error processing archive /tmp/apt-dpkg-install-aFNmwO/1-libsequoia-octopus-librnp_1.8.1-3_amd64.deb (--unpack): new libsequoia-octopus-librnp package pre-installation script subprocess returned error exit status 2 Please try at least installing and uninstalling the package before pushing it into unstable! This also makes me wonder whether we should be doing anything in an autopkgtest kind of way for this package. It'd be great to get some more automated confirmation that the things are working as expected before we inflict them on the rest of the debian ecosystem :P --dkg -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages libsequoia-octopus-librnp depends on: ii libbz2-1.0 1.0.8-5.1 ii libc6 2.37-15 ii libgcc-s1 14-20240201-3 ii libgmp102:6.3.0+dfsg-2+b1 ii libhogweed6t64 3.9.1-2.2 ii libnettle8t64 3.9.1-2.2 ii libsqlite3-03.45.1-1 ii libssl3t64 3.2.1-3 Versions of packages libsequoia-octopus-librnp recommends: ii zenity 4.0.1-1 Versions of packages libsequoia-octopus-librnp suggests: ii thunderbird 1:115.10.1-1 -- no debconf information signature.asc Description: PGP signature
Bug#1069202: closed by Debian FTP Masters (reply to Holger Levsen ) (Bug#1069202: fixed in rust-sequoia-chameleon-gnupg 0.8.0-3)
Control: reopen 1069202 Control: found 1069202 0.8.0-3 The symlinks in the gpg-from-sq and gpgv-from-sq packages appear to point in the wrong direction. That is, gpg-from-sq installs a symlink at /usr/bin/gpg-sq, which refers to gpg. Instead, gpg-from-sq should install a symlink at /usr/bin/gpg, which should refer to gpg-sq. This makes it impossible to install either *-from-sq package alongside its *-sq partner. --dkg signature.asc Description: PGP signature
Bug#1069202: gpg-sq: gpg-from-sq diverts /usr/bin/gpg but doesn't place a symlink pointing to gpg-sq
Package: gpg-from-sq Version: 0.8.0-1 Severity: grave X-Debbugs-Cc: Daniel Kahn Gillmor I did: apt install gpg-from-sq and i expected to run `gpg --version` and see the resultant info from the chameleon. Instead, i see: bash: gpg: command not found I'm seeing the same issue with gpg-from-sq version 0.8.0-1 --dkg -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages gpg-sq depends on: ii libbz2-1.0 1.0.8-5.1 ii libc6 2.37-15 ii libgcc-s1 14-20240201-3 ii libgmp102:6.3.0+dfsg-2+b1 ii libhogweed6t64 3.9.1-2.2 ii libnettle8t64 3.9.1-2.2 ii libsqlite3-03.45.1-1 ii libssl3t64 3.2.1-3 Versions of packages gpg-sq recommends: ii sq 0.33.0-3 gpg-sq suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#1069201: src:rust-sequoia-chameleon-gnupg: gpg-sq and gpgv-sq from 0.8.0 conflict with sequoia-chameleon-gnupg 0.5.1
Source: rust-sequoia-chameleon-gnupg Version: 0.8.0-1 Severity: grave X-Debbugs-Cc: Daniel Kahn Gillmor trying to upgrade from sequoia-chameleon-gnupg 0.5.1-1 to sequoia-chameleon-gnupg 0.8.0-1, i see this: ``` Selecting previously unselected package gpg-sq. Preparing to unpack .../gpg-sq_0.8.0-1_amd64.deb ... Unpacking gpg-sq (0.8.0-1) ... dpkg: error processing archive /var/cache/apt/archives/gpg-sq_0.8.0-1_amd64.deb (--unpack): trying to overwrite '/usr/bin/gpg-sq', which is also in package sequoia-chameleon-gnupg 0.5.1-2 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Selecting previously unselected package gpgv-sq. Preparing to unpack .../gpgv-sq_0.8.0-1_amd64.deb ... Unpacking gpgv-sq (0.8.0-1) ... dpkg: error processing archive /var/cache/apt/archives/gpgv-sq_0.8.0-1_amd64.deb (--unpack): trying to overwrite '/usr/bin/gpgv-sq', which is also in package sequoia-chameleon-gnupg 0.5.1-2 Preparing to unpack .../sequoia-chameleon-gnupg_0.8.0-1_all.deb ... Unpacking sequoia-chameleon-gnupg (0.8.0-1) over (0.5.1-2) ... Errors were encountered while processing: /var/cache/apt/archives/gpg-sq_0.8.0-1_amd64.deb /var/cache/apt/archives/gpgv-sq_0.8.0-1_amd64.deb ``` I think this is just missing some Replaces/Breaks annotations, as per: https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-in-other-packages This is probably worth fixing before it migrates into testing. --dkg -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) signature.asc Description: PGP signature
Bug#1067796: mailscripts: FTBFS: email-print-mime-structure:51: error: Unused "type: ignore" comment
On Sat 2024-04-06 16:20:33 +0800, Sean Whitton wrote: > Thanks! Just to note that I also had to add python3-gssapi as a b-d. That sounds reasonable. thanks for taking care of that, Sean! --dkg signature.asc Description: PGP signature
Bug#1067796: mailscripts: FTBFS: email-print-mime-structure:51: error: Unused "type: ignore" comment
On Sat 2024-04-06 11:40:14 +0800, Sean Whitton wrote:
> On Thu 04 Apr 2024 at 06:37pm -04, Daniel Kahn Gillmor wrote:
>
>> On Wed 2024-04-03 13:03:19 +0800, Sean Whitton wrote:
>>> Thanks, but can you sign this off? Ty!
>>
>> Sure, attached. Let me know if you need anything different.
>
> Thanks. Unfortunately, it doesn't seem to fix the FTBFS, on sid.
Here is a replacement patch, tested now against mypy 1.9.0-4. It also
updates the typechecking for imap-dl for the same version of mypy.
--dkg
From 6d27aa566d64a3e8cbc6afa4e61f5f8178edb14e Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor
Date: Tue, 30 Jan 2024 15:40:58 -0500
Subject: [PATCH] email-print-mime-structure, imap-dl: clean types with mypy
1.9.0
(and, update copyright years)
Signed-off-by: Daniel Kahn Gillmor
---
email-print-mime-structure | 22 ++
imap-dl| 14 +-
2 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/email-print-mime-structure b/email-print-mime-structure
index b7646e0..3263da9 100755
--- a/email-print-mime-structure
+++ b/email-print-mime-structure
@@ -2,7 +2,7 @@
# PYTHON_ARGCOMPLETE_OK
# -*- coding: utf-8 -*-
-# Copyright (C) 2019 Daniel Kahn Gillmor
+# Copyright (C) 2019-2024 Daniel Kahn Gillmor
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -39,6 +39,7 @@ import subprocess
from argparse import ArgumentParser, Namespace
from typing import Optional, Union, List, Tuple, Any
+from types import ModuleType
from email.charset import Charset
from email.message import Message
@@ -47,8 +48,9 @@ try:
except ImportError:
pgpy = None
+argcomplete:Optional[ModuleType]
try:
-import argcomplete #type: ignore
+import argcomplete
except ImportError:
argcomplete = None
@@ -74,7 +76,7 @@ class MimePrinter(object):
# FIXME: it looks like we are counting chars here, not bytes:
nbytes = len(z.as_string())
else:
-payload:Union[List[Message], str, bytes, None] = z.get_payload()
+payload = z.get_payload()
if not isinstance(payload, (str,bytes)):
raise TypeError(f'expected payload to be either str or bytes, got {type(payload)}')
# FIXME: it looks like we are counting chars here, not bytes:
@@ -106,7 +108,7 @@ class MimePrinter(object):
else:
if z.get_content_type().lower() == 'application/pkcs7-mime' and \
str(z.get_param('smime-type')).lower() == 'signed-data':
-bodypart:Union[List[Message],str,bytes,None] = z.get_payload(decode=True)
+bodypart = z.get_payload(decode=True)
if isinstance(bodypart, bytes):
unwrapped = self.pipe_transform(bodypart, ['certtool', '--p7-show-data', '--p7-info', '--inder'])
if unwrapped:
@@ -118,7 +120,7 @@ class MimePrinter(object):
def decrypt_part(self, msg:Message, flavor:EncType) -> Optional[Message]:
-ciphertext:Union[List[Message],str,bytes,None] = msg.get_payload(decode=True)
+ciphertext = msg.get_payload(decode=True)
cryptopayload:Optional[Message] = None
if not isinstance(ciphertext, bytes):
logging.warning('encrypted part was not a leaf mime part somehow')
@@ -178,14 +180,18 @@ class MimePrinter(object):
prefix = prefix.rpartition('└')[0] + ' '
if prefix.endswith('├'):
prefix = prefix.rpartition('├')[0] + '│'
-parts:Union[List[Message], str, bytes, None] = z.get_payload()
+parts = z.get_payload()
if not isinstance(parts, list):
raise TypeError(f'parts was {type(parts)}, expected List[Message]')
i = 0
while (i < len(parts)-1):
-self.print_tree(parts[i], prefix + '├', z, i+1)
+msg = parts[i]
+if isinstance(msg, Message):
+self.print_tree(msg, prefix + '├', z, i+1)
i += 1
-self.print_tree(parts[i], prefix + '└', z, i+1)
+msg = parts[i]
+if isinstance(msg, Message):
+self.print_tree(msg, prefix + '└', z, i+1)
# FIXME: show epilogue?
else:
self.print_part(z, prefix+'─╴', parent, num)
diff --git a/imap-dl b/imap-dl
index fac7487..824c21d 100755
--- a/imap-dl
+++ b/imap-dl
@@ -2,7 +2,7 @@
# PYTHON_ARGCOMPLETE_OK
# -*- coding: utf-8 -*-
-# Copyright (C) 2019-2020 Daniel Kahn Gillmor
+# Copyright (C) 2019-2024 Daniel Kahn Gillmor
# Copyright (C) 2020 Red Hat, Inc.
#
# This program is free software: you can redistribute it and/or modify
@@ -52,14 +52,17 @@ import statistics
import configparser
from typing import Dict, List, Optional, Tuple, Union
+from types import
Bug#1067796: mailscripts: FTBFS: email-print-mime-structure:51: error: Unused "type: ignore" comment
On Wed 2024-04-03 13:03:19 +0800, Sean Whitton wrote: > Thanks, but can you sign this off? Ty! Sure, attached. Let me know if you need anything different. --dkg From b522c1cc6201f75ab6103954016bbb719d4dd2fa Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor Date: Tue, 30 Jan 2024 15:40:58 -0500 Subject: [PATCH] email-print-mime-structure: clean up typechecking (argcomplete types are known) (and, update copyright years) Signed-off-by: Daniel Kahn Gillmor --- email-print-mime-structure | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/email-print-mime-structure b/email-print-mime-structure index b7646e0..7635f53 100755 --- a/email-print-mime-structure +++ b/email-print-mime-structure @@ -2,7 +2,7 @@ # PYTHON_ARGCOMPLETE_OK # -*- coding: utf-8 -*- -# Copyright (C) 2019 Daniel Kahn Gillmor +# Copyright (C) 2019-2024 Daniel Kahn Gillmor # # This program is free software: you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by @@ -39,6 +39,7 @@ import subprocess from argparse import ArgumentParser, Namespace from typing import Optional, Union, List, Tuple, Any +from types import ModuleType from email.charset import Charset from email.message import Message @@ -47,8 +48,9 @@ try: except ImportError: pgpy = None +argcomplete:Optional[ModuleType] try: -import argcomplete #type: ignore +import argcomplete except ImportError: argcomplete = None -- 2.43.0 signature.asc Description: PGP signature
Bug#1067796: mailscripts: FTBFS: email-print-mime-structure:51: error: Unused "type: ignore" comment
Control: tags 1067796 + patch On Thu 2024-03-28 13:09:48 +0800, Sean Whitton wrote: > Please take a look into this test suite failure for your script. The attached patch should clean things up now that argcomplete is annotated. in my local tests, the script runs and exits cleanly. This patch is worth applying generally, but given the flux around mypy typing, i would also be fine with just recording the output of mypy --strict instead of failing hard on it. --dkg From b522c1cc6201f75ab6103954016bbb719d4dd2fa Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor Date: Tue, 30 Jan 2024 15:40:58 -0500 Subject: [PATCH] email-print-mime-structure: clean up typechecking (argcomplete types are known) (and, update copyright years) --- email-print-mime-structure | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/email-print-mime-structure b/email-print-mime-structure index b7646e0..7635f53 100755 --- a/email-print-mime-structure +++ b/email-print-mime-structure @@ -2,7 +2,7 @@ # PYTHON_ARGCOMPLETE_OK # -*- coding: utf-8 -*- -# Copyright (C) 2019 Daniel Kahn Gillmor +# Copyright (C) 2019-2024 Daniel Kahn Gillmor # # This program is free software: you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by @@ -39,6 +39,7 @@ import subprocess from argparse import ArgumentParser, Namespace from typing import Optional, Union, List, Tuple, Any +from types import ModuleType from email.charset import Charset from email.message import Message @@ -47,8 +48,9 @@ try: except ImportError: pgpy = None +argcomplete:Optional[ModuleType] try: -import argcomplete #type: ignore +import argcomplete except ImportError: argcomplete = None -- 2.43.0 signature.asc Description: PGP signature
Bug#1035542: libreswan: CVE-2023-30570: Incorrect aggressive mode interaction causes the pluto daemon to crash
Hi Salvatore-- On Fri 2023-06-02 21:20:50 +0200, Salvatore Bonaccorso wrote: > Thanks for having a closer look and for your assessment. Then I > believe we can have a fix scheduled via respective point releases, I > do not see an urgency for it requiring a DSA. Initially I was not > completely sure about it. i'm fine with a fix in the point release approach. I've gone ahead and uploaded 4.11-1 to unstable, and 4.3-1+deb11u4 to bullseye for proposed-updates (#1037054). And I've uploaded 4.10-1+deb12u1 to bookworm's proposed-updates too (#1037056). I recognize that i missed the window for bookworm, and i'm bummed about that, but i think this approach should reach users with reasonable speed (and most users shouldn't have IKEv1 enabled at all on bookworm anyway). Please don't hesitate to nudge here if there's more that needs doing. --dkg signature.asc Description: PGP signature
Bug#1035542: libreswan: CVE-2023-30570: Incorrect aggressive mode interaction causes the pluto daemon to crash
Control: found 1035542 4.3-1+deb11u3
Control: tags 1035542 + patch
Thanks for the documentation of CVE-2023-30570 on
https://bugs.debian.org/1035542, Salvatore.
fwiw, i don't think this is particularly serious -- the vulnerability
only appears to be dangerous if the libreswan endpoint is configured to
allow IKEv1 in aggressive mode.
Since 4.5-2, libreswan's ikev1-policy has defaulted to "drop", and we've
heard no complaints from users that this has been an impediment, so i
have my doubts about how many people have such a configuration.
That said, in bullseye, it is still a plausible choice.
I'm attaching the patch here for bullseye (against v4.3), which i can
upload to bullseye-security whenever you you think is appropriate.
For v4.10 (which is in bookworm, about to be stable) i think the best
move is to just ship v4.11 directly. I'm also attaching here the diff
between upstream's v4.10 and v4.11 -- it is a narrowly-targeted bugfix
release. i think it makes more sense to just ship v4.11 as a security
update to bookworm (since i missed the freeze cutoff, apologies) rather
than to try to ship v4.10 plus basically the same patch.
Here's the patch against v4.3 that i intend to send to
bullseye-security:
From: Daniel Kahn Gillmor
Date: Thu, 1 Jun 2023 16:12:50 -0400
Subject: Resolve CVE-2023-30570
see https://libreswan.org/security/CVE-2023-30570/CVE-2023-30570.txt
This patch was ported from
https://libreswan.org/security/CVE-2023-30570/CVE-2023-30570-libreswan-4.x.patch
---
programs/pluto/ikev1.c | 60 ++---
programs/pluto/ikev1_aggr.c | 5 ++--
2 files changed, 60 insertions(+), 5 deletions(-)
diff --git a/programs/pluto/ikev1.c b/programs/pluto/ikev1.c
index 2a06c2c..bb6c7be 100644
--- a/programs/pluto/ikev1.c
+++ b/programs/pluto/ikev1.c
@@ -1249,10 +1249,20 @@ void process_v1_packet(struct msg_digest *md)
struct state *st = NULL;
enum state_kind from_state = STATE_UNDEFINED; /* state we started in */
+ /*
+ * For the initial responses, don't leak the responder's SPI.
+ * Hence the use of send_v1_notification_from_md().
+ *
+ * AGGR mode is a mess in that the R0->R1 transition happens
+ * well before the transition succeeds.
+ */
#define SEND_NOTIFICATION(t) \
{\
pstats(ikev1_sent_notifies_e, t); \
- if (st != NULL) \
+ if (st != NULL && \
+ st->st_state->kind != STATE_AGGR_R0 && \
+ st->st_state->kind != STATE_AGGR_R1 && \
+ st->st_state->kind != STATE_MAIN_R0) \
send_notification_from_state(st, from_state, t); \
else \
send_notification_from_md(md, t); \
@@ -1322,17 +1332,26 @@ void process_v1_packet(struct msg_digest *md)
from_state = (md->hdr.isa_xchg == ISAKMP_XCHG_IDPROT ?
STATE_MAIN_R0 : STATE_AGGR_R0);
} else {
- /* not an initial message */
+ /*
+ * Possibly not an initial message. Possibly
+ * from initiator. Possibly from responder.
+ *
+ * Possibly. Which is probably hopeless.
+ */
st = find_state_ikev1(>hdr.isa_ike_spis,
md->hdr.isa_msgid);
if (st == NULL) {
/*
- * perhaps this is a first message
+ * Perhaps this is a first message
* from the responder and contains a
* responder cookie that we've not yet
* seen.
+ *
+ * Perhaps this is a random message
+ * with a bogus non-zero responder IKE
+ * SPI.
*/
st = find_state_ikev1_init(>hdr.isa_ike_initiator_spi,
md->hdr.isa_msgid);
@@ -1343,6 +1362,21 @@ void process_v1_packet(struct msg_digest *md)
/* XXX Could send notification back */
return;
}
+if (st->st_state->kind == STATE_AGGR_R0) {
+ /*
+ * The only way for this to
+ * happen is for the attacker
+ * to guess the responder's
+ * IKE SPI that hasn't been
+ * sent over the wire?
+ *
+ * Well that or played 1/2^32
+ * odds.
+ */
+ log_pexpect(HERE,
+ "phase 1 message matching AGGR_R0 state");
+ return;
+}
}
from_state = st->st_state->kind;
}
@@ -3027,6 +3061,26 @@ void complete_v1_state_transition(struct state *st, struct msg_digest *md, stf_s
delete_state(st);
/* wipe out dangling pointer to st */
md->st = NULL;
+ } else if (st->st_state->kind == STATE_AGGR_R0 ||
+ st->st_state->kind == STATE_AGGR_R1 ||
+ st->st_state->kind == STATE_MAIN_R0) {
+ /*
+ *
+ * Wipe out the incomplete larval state.
+ *
+ * ARGH! In <=v4.10, the aggr code flipped the
+ * larval state to R1 right at the start of
+ * the transition and not the end, so using
+ * state to figure things out is close to
+ * useless.
+ *
+ * Deleting the state means that pluto has no
+ * way to detect and ignore amplification
+ * attacks.
+ */
+ delete_state(st);
+ /* wipe out dangl
Bug#1034065: sasl-xoauth2: FTBFS: ModuleNotFoundError: No module named 'distutils.core'
Control: clone 1034065 -1 Control: reassign -1 python3-argparse-manpage Control: affects -1 src:sasl-xoauth2 Control: retitle -1 argparse-manpage doesn't run unless python3-setuptools is installed On Fri 2023-04-07 22:14:44 +0200, Andreas Beckmann wrote: > sasl-xoauth2/experimental FTBFS on all architectures: > https://buildd.debian.org/status/package.php?p=sasl-xoauth2=experimental > > ... >debian/rules execute_after_dh_auto_build > make[1]: Entering directory '/<>' > mkdir -p completions manpages > register-python-argcomplete --shell bash sasl-xoauth2-tool > > completions/sasl-xoauth2-tool > argparse-manpage --pyfile obj-x86_64-linux-gnu/scripts/sasl-xoauth2-tool > --object parser \ > --author 'Tarick Bedeir' --author-email 'tar...@bedeir.com' > --project-name sasl-xoauth2 \ > --url https://github.com/tarickb/sasl-xoauth2 --output > manpages/sasl-xoauth2-tool.1 > Traceback (most recent call last): > File "/usr/bin/argparse-manpage", line 5, in > from build_manpages.cli import main > File "/usr/lib/python3/dist-packages/build_manpages/cli/__init__.py", line > 5, in > from build_manpages.build_manpage import ManPageWriter, get_parser > File "/usr/lib/python3/dist-packages/build_manpages/build_manpage.py", line > 10, in > from distutils.core import Command > ModuleNotFoundError: No module named 'distutils.core' > make[1]: *** [debian/rules:11: execute_after_dh_auto_build] Error 1 > make[1]: Leaving directory '/<>' > make: *** [debian/rules:6: binary-arch] Error 2 > ... I think this represents a missing dependency in python3-argparse-manpage, which makes packages that build-depend on python3-argparse-manpage to generate their manpages FTBFS. --dkg signature.asc Description: PGP signature
Bug#1034558: rnp: CVE-2023-29479 VE-2023-29480
On Wed 2023-05-24 07:32:31 +0200, Salvatore Bonaccorso wrote: > Thanks! Note the deadline for unblock requests will be on 28th. So the > unblock needs to be granted by then so we have the fixes in bookworm. The associated unblock request for 1034558 is #1036721 --dkg signature.asc Description: PGP signature
Bug#1034558: rnp: CVE-2023-29479 VE-2023-29480
In https://bugs.debian.org/1034558, Salvatore Bonaccorso wrote: > Source: rnp > Version: 0.16.2-1 > Severity: grave > Tags: security upstream > Justification: user security hole > X-Debbugs-Cc: car...@debian.org, Debian Security Team > Thanks for tracking this in the BTS, Salvatore. I aim to have 0.16.3 (which is a targeted upstream release with a very narrow set of changes) uploaded to unstable in the next day or two. --dkg signature.asc Description: PGP signature
Bug#1033155: [pkg-gnupg-maint] Bug#1033155: migration test fails when EC key present in test keyrings
Hi Andreas-- Thank you for addressing this problem, it is much appreciated! --dkg On Sun 2023-03-26 14:00:17 +0200, Andreas Metzler wrote: > On 2023-03-18 Jonathan Wiltshire wrote: >> Source: gnupg2 >> Version: 2.2.40-1 >> Severity: important >> Tags: patch >> X-Debbugs-Cc: j...@debian.org > >> Hi, > >> The stable release key for bookworm is EC, and this causes gpg1 to bail >> out when it is imported as part of the migration test. Attached patch >> limits the keyrings used to the archive's automatic keys, which are >> still RSA. > [...] > > Hello Jonathan, > > afaict currently all keys are RSA except for > debian-archive-bookworm-stable.gpg. Wouldn't it be better to just skip > this single key? > > cu Andreas > > ___ > pkg-gnupg-maint mailing list > pkg-gnupg-ma...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-gnupg-maint signature.asc Description: PGP signature
Bug#1024417: [pkg-gnupg-maint] Bug#1024417: kgpg FTBFS: Did not find GPGME
On Wed 2022-11-23 16:27:43 +0100, Andreas Metzler wrote: > Unless kgpg maintainers/upstream has a strong opinion against using > pkg-config the obvious choice would be to drop cmake/FindGpgme.cmake > and simply use FindPkgConfig. - Attached patch seems to work for me, > i.e. build including dh_auto_test works. Thanks for this, Andreas. I've proposed this change upstream as well at https://invent.kde.org/utilities/kgpg/-/merge_requests/18 --dkg signature.asc Description: PGP signature
Bug#1023767: neomutt: unable to find gpgme-config
Hi Timo-- On Tue 2022-11-22 15:58:21 +0100, Timo Röhling wrote: > I have built neomutt with your patch and can confirm that the GPGme > integration works as expected. Thanks for confirming! It'd be great to clear the decks for the gpgme transition, so please let me know if you'd like me to NMU neomutt with that patch, or if you have any plans for a release any time soon. all the best, --dkg signature.asc Description: PGP signature
Bug#1023767: neomutt: unable to find gpgme-config
Control: tags 1023767 + patch
On Wed 2022-11-09 22:04:00 +0100, Timo Röhling wrote:
> neomutt fails to build with the recent libgpgme-dev update that dropped
> the gpgme-config executable.
>
> https://github.com/neomutt/neomutt/pull/3555 fixes the problem, but does
> not apply cleanly to the neomutt release in Debian, unfortunately.
The attached patch appears to fix things for me so that neomutt builds
successfully against libgpgme-dev 1.18.0-3, though i don't know enough
about how to adequately test neomutt to be confident in the results (i
don't use neomutt myself).
It's also on salsa at
https://salsa.debian.org/mutt-team/neomutt/-/merge_requests/8 if that's
useful.
Please let me know if you'd like me to NMU it.
--dkg
From a9d3c0fe8c8e678311ad7a4810df6db519abc798 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor
Date: Mon, 21 Nov 2022 19:10:20 -0500
Subject: [PATCH] find modern versions of gpgme (Closes: #1023767)
---
debian/patches/series | 1 +
.../upstream/Use-pkgconf-to-find-GPGMe.patch | 121 ++
2 files changed, 122 insertions(+)
create mode 100644 debian/patches/upstream/Use-pkgconf-to-find-GPGMe.patch
diff --git a/debian/patches/series b/debian/patches/series
index 8c37cf1cc..b0cb4f4fc 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -6,3 +6,4 @@ upstream/964416-manpages-fixes.patch
upstream/1020414-gsasl-support-prereq.patch
upstream/1020414-gsasl-support.patch
upstream/use-pkgconfig-for-libgpg-error.patch
+upstream/Use-pkgconf-to-find-GPGMe.patch
diff --git a/debian/patches/upstream/Use-pkgconf-to-find-GPGMe.patch b/debian/patches/upstream/Use-pkgconf-to-find-GPGMe.patch
new file mode 100644
index 0..f4c583cdb
--- /dev/null
+++ b/debian/patches/upstream/Use-pkgconf-to-find-GPGMe.patch
@@ -0,0 +1,121 @@
+From: Pietro Cerutti
+Date: Mon, 7 Nov 2022 08:41:07 +
+Subject: Use pkgconf to find GPGMe
+
+(cherry-picked from upstream 516568f3f0769fad1c006a6b3a70884e97092a2a)
+---
+ Makefile.autosetup | 2 +-
+ auto.def | 85 --
+ 2 files changed, 6 insertions(+), 81 deletions(-)
+
+diff --git a/Makefile.autosetup b/Makefile.autosetup
+index 3884704..24a2f17 100644
+--- a/Makefile.autosetup
b/Makefile.autosetup
+@@ -572,7 +572,7 @@ $(PWD)/mutt:
+ LIBNCRYPT= libncrypt.a
+ LIBNCRYPTOBJS= ncrypt/config.o ncrypt/crypt.o ncrypt/cryptglue.o \
+ ncrypt/crypt_mod.o
+-@if HAVE_GPGME
++@if HAVE_PKG_GPGME
+ LIBNCRYPTOBJS+= ncrypt/crypt_gpgme.o ncrypt/dlg_gpgme.o \
+ ncrypt/crypt_mod_pgp_gpgme.o ncrypt/crypt_mod_smime_gpgme.o
+ @endif
+diff --git a/auto.def b/auto.def
+index 12dc5d3..e0dcbb5 100644
+--- a/auto.def
b/auto.def
+@@ -480,88 +480,13 @@ if {[get-define want-gpgme]} {
+ define-append CFLAGS -D_FILE_OFFSET_BITS=[get-define _FILE_OFFSET_BITS]
+ }
+
+- msg-checking "Checking for GPGME..."
+- if {1} {
+-# Locate gpgme-config
+-set gpgme_prefix [opt-val with-gpgme $prefix]
+-set gpgme_config_guess [file join $gpgme_prefix bin gpgme-config]
+-if {[file-isexec $gpgme_config_guess]} {
+- define GPGME-CONFIG $gpgme_config_guess
+-} else {
+- if {![cc-check-progs gpgme-config]} {
+-user-error "Unable to find gpgme-config"
+- }
+-}
+-set gpgme_config [get-define GPGME-CONFIG]
+-
+-# Version
+-if {[catch {exec-with-stderr $gpgme_config --version} gpgme_version err]} {
+- user-error "Could not derive --version from $gpgme_config"
+-}
+-if {[scan $gpgme_version "%d.%d.%d" gpgme_maj gpgme_min gpgme_patch] != 3} {
+- user-error "Could not parse GPGME version $gpgme_version"
+-}
+-msg-result $gpgme_version
+-if {[get-define want-autocrypt]} {
+- if {$gpgme_maj < 1 || $gpgme_min < 8} {
+-user-error "Found GPGME version $gpgme_version, need 1.8.0 for AutoCrypt"
+- }
+-} else {
+- if {$gpgme_maj < 1 || $gpgme_min < 4} {
+-user-error "Found GPGME version $gpgme_version, need 1.4.0"
+- }
+-}
+-define GPGME_VERSION_NUMBER [format "0x%02x%02x%02x" $gpgme_maj $gpgme_min $gpgme_patch]
+-
+-# RHEL6 doesn't have this function yet
+-cc-check-function-in-lib gpgme_op_export_keys gpgme
+-
+-# CFLAGS
+-if {[catch {exec-with-stderr $gpgme_config --cflags} res err]} {
+- user-error "Could not derive --cflags from $gpgme_config"
+-}
+-define-append CFLAGS $res
+-
+-# LIBS
+-if {[catch {exec-with-stderr $gpgme_config --libs} res err]} {
+- user-error "Could not derive --libs from $gpgme_config"
+-}
+-define-append LIBS $res
+- }
+- define-feature gpgme
+-
+- if {![get-define want-pkgconf] || ![pkgconf false gpg-error]} {
+-# Locate gpg-error-config
+-msg-checking "Checking for gpg-error..."
+-set gpg_error_confi
Bug#1023601: [pkg-gnupg-maint] Bug#1023601: libgpgme-dev: removal of gpgme-config breaks the build of software relying on it
Control: severity 1023601 important Control: reassign 1023601 src:libgpg-error 1.46-1 Control: affects 1023601 + src:gpgme1.0 src:rust-libgpg-error-sys src:rust-libgpgme-sys Thanks Vincent for identifying the confusing and misdirected documentation upstream, and thanks Andreas for triaging this and for filing both reports upstream related to the missing documentation. I agree that this is annoying, but it seems better to me to rip the band-aid off now, and try to get the ecosystem to move as needed. I'm reassigning the issue to libgpg-error, because upstream gpgme only installs gpgme-config when gpg-error-config is present, so to "fix" the issue in gpgme, we'd need to change how we distribute libgpg-error (to force the non-default shipping of gpg-error-config) and then rebuild gpgme against the updated while shipping the appropriate buildscripts. I'd really prefer to stick with upstream's defaults here: they've moved to pkg-config as the expected/default cross-platform build process, and we should encourage the ecosystem to move with that. I also happen to agree with upstream that commonly shared, declarative packaging practices like pkg-config are a safer and more sensible approach to build configuration than executing arbitrary code for each dependency. Vincent wrote: > So, if I understand correctly, either gpgme-config should be based on > gpgrt-config rather than gpg-error-config (this should be an upstream > change), or gpg-error-config should be re-added as suggested. fwiw, upstream has indicated that gpgrt-config is an "internal" interface, so this is not something that should be used explicitly by external dependencies. Vincent Lefevre wrote: > Remember that libgpgme-dev is not just useful to build Debian > packages, but also to build software that is not part of Debian. Vincent is right about this, but we're doing those downstream projects no favors if we encourage them to use an internal interface that upstream isn't installing by default. If upstream wants users to move to the more modern interface, which has already been supported for years, we should help that happen. > In any case, a decision has to be made: either consider that the > change is too early, and the next Debian release should have this file > (in this case, the RC bug is justified), or consider that it is up to > other software to be updated (or users to find a workaround), in which > case, things should at least properly documented: the GPGME manual > currently says: I've reclassified this bug to severity: important because i think that we should try to go with the upstream default preferences. In the event that a significant amount of unrelated debian-internal software is broken by these change, i'm willing to consider a reversion to the changes in libgpg-error, but at the moment the only remaining packages i've seen are: rust-libgpg-error-sys rust-libgpgme-sys mutt The first two packages are not at all unrelated packages, they're Rust wrappers for libraries that GnuPG wants to expose externally, and have already been fixed upstream with new releases that use GnuPG's expected mechanisms for configuration (iiuc their inclusion into debian is held up by the version of cargo that they rely on, which should be landing shortly). And mutt is already handled thanks to Kevin and Vincent's work on #1023599. This kind of ecosystem simplification and cleanup is exactly the sort of thing that Debian should be putting its weight behind. > BTW, after all, the use of gpgrt-config might not be user-friendly > in an interactive shell (as opposed to a configure.ac file). The most user-friendly solution in an interactive shell is pkg-config, which doesn't require a user to learn a new syntax or convention for each library. pkg-config also happens to make cross-building more straightforward, which is (rightly) a longstanding concern for debian. The more we get reverse dependencies to switch over to this kind of configuration system, the better. All the best, --dkg signature.asc Description: PGP signature
Bug#1022348: [pkg-gnupg-maint] Bug#1022348: gpgme1.0: FTBFS: Could not find gpg-error-config. Please install the libgpg-error development package.
On Wed 2022-10-26 18:17:11 +0200, Andreas Metzler wrote: > On 2022-10-26 Andreas Metzler wrote: > [...] >> Which has been promptly fixed. Find attached debdiffs for a proposed >> upload. - I can also massage this into a mergew-request or push >> directly to https://salsa.debian.org/debian/gpgme Just give me a >> heads-up. > [...] > > https://salsa.debian.org/debian/gpgme/-/merge_requests/7 > > (Sending now since I will not have time tomorrow and on Friday.) > cu Andreas Thanks for this work, Andreas. I'm working on rolling it up into a new release which i hope to land in unstable later today. Of course, this might cause knock-on effects for projects that themselves think they should be dependent on gpgme-config, but i'll try to sort those through as well. --dkg signature.asc Description: PGP signature
Bug#1022289: [pkg-gnupg-maint] Bug#1022289: libassuan: FTBFS: configure: error: libgpg-error was not found
Hi Andreas-- Thanks for this. I'm wrapping this up with a few other lintian fixes and i should have a released version in unstable by later today or tomorrow. Thanks for helping out here! --dkg On Tue 2022-11-01 14:10:36 +0100, Andreas Metzler wrote: > On 2022-10-23 Andreas Metzler wrote: > [...] >> Caused by new gpg-error dropping gpg-error-config, this works for me: > >> --- libassuan-2.5.5/debian/rules2022-04-30 17:47:12.0 +0200 >> +++ patched/libassuan-2.5.5.patched/debian/rules2022-10-23 >> 18:23:40.505849321 +0200 >> @@ -27,7 +27,6 @@ >> for cpu in i686 x86_64; do \ >> mkdir -p build-$$cpu-w64-mingw32 && \ >> cd build-$$cpu-w64-mingw32 && $(WIN_FLAGS) ../configure \ >> - --with-libgpg-error-prefix=/usr/$$cpu-w64-mingw32 \ > > Hello, > > Commited to GIT, please give me a heads up if you want me to make either > a NMU or add myself to Uploaders and make a regular upload. (Although > this is a serious bugreport I do not think it is yet so urgent to > require a upload without maintainer feedback. - Might change, e.g if > libassuan blocked a transition.) > > cu Andreas > -- > `What a good friend you are to him, Dr. Maturin. His other friends are > so grateful to you.' > `I sew his ears on from time to time, sure' > ___ > pkg-gnupg-maint mailing list > pkg-gnupg-ma...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-gnupg-maint signature.asc Description: PGP signature
Bug#1022783: librust-curl-dev: impossible to install
Control: reassign 1022783 librust-spin-dev 0.9.4-1 Control: affects 1022783 + librust-curl-dev On Tue 2022-10-25 21:28:38 +0200, Jonas Smedegaard wrote: > Package is impossible to install: > > # apt install librust-curl-dev > Reading package lists... Done > Building dependency tree... Done > Reading state information... Done > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help to resolve the situation: > > The following packages have unmet dependencies: > librust-spin-dev : Depends: librust-portable-atomic-0.3-dev but it is not > installable > E: Unable to correct problems, you have held broken packages. I'm pretty sure this is about librust-spin-dev 0.9.4-1, not about librust-curl-dev, because when i have librust-spin-dev 0.5.2-1 installed, librust-curl-dev 0.4.44-1 installs just fine. --dkg signature.asc Description: PGP signature
Bug#1021928: libksba8: CVE-2022-3515 - remote code execution in libksba before 1.6.2
On Mon 2022-10-17 22:16:15 +0200, Salvatore Bonaccorso wrote: > Thanks for the offer. Andreas did already handle the bullseye-security > update (DSA was just released) and Markus will handle the LTS upload. great, many thanks to Andreas and Markus for taking care of this, and to you Salvatore for coordinating and communicating about it! --dkg signature.asc Description: PGP signature
Bug#1021928: libksba8: CVE-2022-3515 - remote code execution in libksba before 1.6.2
FWIW, the patch highlighted by Thomas appears to apply cleanly to 1.5.0
(the version in debian stable).
We should apply this on top of 1.5.0-3 for bullseye, and 1.3.5-2 for
buster.
The attached debdiffs do that, and should be able to build properly.
I've also uploaded them to the debian/bullseye and debian/buster
branches at https://salsa.debian.org/dkg/libksba (using DEP-14 naming
conventions), though i don't know how useful extra git branches are to
Andreas, who has capably maintained libksba for many years -- i don't
see what his preferred workflow is for handling security updates, maybe
it's not in git.
If the security team and Andreas are ok with these updates to bullseye
and buster, i can do the upload into bullseye-security and
buster-security.
1.6.2 should migrate into testing shortly, so i'm not sure that we have
anything else to do there.
--dkg
On Mon 2022-10-17 14:34:44 +0200, Thomas Arendsen Hein wrote:
> Package: libksba8
> Version: 1.3.5-2
> Severity: grave
> Tags: security patch upstream
> Justification: user security hole
>
> Dear Maintainer,
>
> https://gnupg.org/blog/20221017-pepe-left-the-ksba.html
> announces an integer overflow that may be used for remote code
> execution in versions of libksba before 1.6.2, i.e.
> in currently in all Debian versions except for unstable, i.e.
> bookwork, bullseye, buster (LTS)
>
> https://security-tracker.debian.org/tracker/CVE-2022-3515
> still shows "Description RESERVED".
>
> Upstream bug report: https://dev.gnupg.org/T6230
>
> A patch is available from
> https://dev.gnupg.org/rK4b7d9cd4a018898d7714ce06f3faf2626c14582b
>
>
> Patch from git://git.gnupg.org/libksba:
>
> commit 4b7d9cd4a018898d7714ce06f3faf2626c14582b
> Author: Werner Koch
> Date: Wed Oct 5 14:19:06 2022 +0200
>
> Detect a possible overflow directly in the TLV parser.
>
> * src/ber-help.c (_ksba_ber_read_tl): Check for overflow of a commonly
> used sum.
> --
>
> It is quite common to have checks like
>
> if (ti.nhdr + ti.length >= DIM(tmpbuf))
>return gpg_error (GPG_ERR_TOO_LARGE);
>
> This patch detects possible integer overflows immmediately when
> creating the TI object.
>
> Reported-by: ZDI-CAN-18927, ZDI-CAN-18928, ZDI-CAN-18929
>
> diff --git a/src/ber-help.c b/src/ber-help.c
> index 81c31ed..56efb6a 100644
> --- a/src/ber-help.c
> +++ b/src/ber-help.c
> @@ -182,6 +182,12 @@ _ksba_ber_read_tl (ksba_reader_t reader, struct tag_info
> *ti)
>ti->length = len;
> }
>
> + if (ti->length > ti->nhdr && (ti->nhdr + ti->length) < ti->length)
> +{
> + ti->err_string = "header+length would overflow";
> + return gpg_error (GPG_ERR_EOVERFLOW);
> +}
> +
>/* Without this kludge some example certs can't be parsed */
>if (ti->class == CLASS_UNIVERSAL && !ti->tag)
> ti->length = 0;
>
>
>
>
> -- System Information:
> Debian Release: 10.13
> APT prefers oldstable-updates
> APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-21-amd64 (SMP w/32 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/bash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages libksba8 depends on:
> ii libc6 2.28-10+deb10u1
> ii libgpg-error0 1.35-1
>
> libksba8 recommends no packages.
>
> libksba8 suggests no packages.
>
> -- no debconf information
>
> --
> Thomas Arendsen Hein | https://intevation.de
> Intevation GmbH, Osnabrueck, DE; Amtsgericht Osnabrueck, HRB 18998
> Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter
>
> --
> Pkg-gnutls-maint mailing list
> pkg-gnutls-ma...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-gnutls-maint
diff -Nru libksba-1.5.0/debian/changelog libksba-1.5.0/debian/changelog
--- libksba-1.5.0/debian/changelog 2020-12-24 02:06:58.0 -0500
+++ libksba-1.5.0/debian/changelog 2022-10-17 14:15:08.0 -0400
@@ -1,3 +1,10 @@
+libksba (1.5.0-3+deb11u1) bullseye-security; urgency=high
+
+ * Non-maintainer upload
+ * fix CVE 2022-3515
+
+ -- Daniel Kahn Gillmor Mon, 17 Oct 2022 14:15:08 -0400
+
libksba (1.5.0-3) unstable; urgency=medium
* Add 10_Fix-a-possible-segv-in-case-of-an-unknown-CMS-object.patch from
diff -Nru libksba-1.5.0/debian/patches/20_Detect-a-possible-overflow-directly-in-the-TLV-parse.patch libksba-1.5.0/debian/patches/20_Detect-a-possible-overflow-directly-in-the-TLV-parse.
Bug#1021043: closed by Debian FTP Masters (reply to Dennis Filder ) (Bug#1021043: fixed in linphone 5.0.37-6)
On Mon 2022-10-03 08:51:05 +, Debian Bug Tracking System wrote: > linphone (5.0.37-6) unstable; urgency=medium > . >* Import upstream fix for crashes on PUBLISH messages without > SIP-Etags (Closes: #1021043). Dennis, thanks for this prompt fix! To confirm: I've upgraded to liblinphone10 5.0.37-6, and linphone-desktop works for me again without any of the crashes i was seeing. With great appreciation, --dkg signature.asc Description: PGP signature
Bug#1021043: linphone-desktop: linphone crashes and is unusable
Hi Dennis-- Thank you very much for the prompt response! On Sat 2022-10-01 09:15:39 +0200, Dennis Filder wrote: > It would help a lot to know the exact time when those crashes started. > Can you try narrowing it down, e.g. by looking at the ctime of > files/directories you created in reaction to the crashes? unfortunately, i saw crashes several days ago when i was in the middle of dealing with other problems and i didn't get around to doing actual debugging until much yesterday. Looking in my backups of ~/.local/share/linphone, it looks like september 21 was the most recent time that linphone.db and zrtp-secrets.db were changed. according to my dpkg logs, i had: 2022-09-27 17:03:49 upgrade libsoci-core4.0:amd64 4.0.1-5 4.0.3-1 so maybe libsoci is the issue? > I also saw one segfault that was not handled by __GI_abort() -- maybe > you had one, too, so it might show up as a message in > /var/log/message* somewhere. i'm using journald, so /var/log/message hasn't been touched in years on my system, but i don't see anything suspicious in the output of "journalctl -k --since '15 days ago'" either. > Also, do you have the impression that > the crashes suddenly became more frequent somehow? If so: When? What > is the output of?: > > stat /usr/share/doc/linphone-desktop/changelog.Debian.gz 0 dkg@alice:~$ stat /usr/share/doc/linphone-desktop/changelog.Debian.gz File: /usr/share/doc/linphone-desktop/changelog.Debian.gz Size: 938 Blocks: 8 IO Block: 4096 regular file Device: fe01h/65025dInode: 523131 Links: 1 Access: (0644/-rw-r--r--) Uid: (0/root) Gid: (0/root) Access: 2022-09-19 11:30:17.0 -0400 Modify: 2022-09-12 14:41:04.0 -0400 Change: 2022-09-19 11:32:11.285343797 -0400 Birth: 2022-09-19 11:32:11.273343755 -0400 0 dkg@alice:~$ > My current suspicion is that soci 4.0.3-1 had an ABI break from > upstream commit 1b1b5621f5abc40bd76a54a779455e8b9c0892ff (adding the > private backendRef_ member changed the layouts of the classes > soci::connection_parameters and soci::session and liblinphone.so.10 > instantiates the latter). Yes, good call! I've installed libsoci-core4.0 and libsoci-sqlite3-4.0 from bullseye, and i was able to start up linphone without an immediate crash. However, after restoring my configuration, and trying to place a single call (to myself, which of course i didn't expect to work) the app crashed again. now, even with libsoci* from bullseye, it is crashing again at startup, with this stderr log and backtrace: [15:11:03:325][0x55d195f0][Info]"Registering shared types..." [15:11:03:325][0x55d195f0][Info]"Registering tool types..." [15:11:03:325][0x55d195f0][Info]"Registering shared tool types..." [15:11:03:546][0x55d195f0][Info]"Loading main view..." [New Thread 0x7fffb79ff640 (LWP 310193)] [Thread 0x7fffb79ff640 (LWP 310193) exited] [15:11:03:673][0x55d195f0][Info]"Launch async core creation." [New Thread 0x7fffb79ff640 (LWP 310194)] [New Thread 0x7fffb71fe640 (LWP 310195)] [Thread 0x7fffb71fe640 (LWP 310195) exited] [New Thread 0x7fffb71fe640 (LWP 310196)] [Thread 0x7fffb71fe640 (LWP 310196) exited] [15:11:04:375][0x55d195f0][Info]Core is starting "Starting up" [15:11:04:424][0x55d195f0][Info]Core is running "On" [15:11:04:424][0x55d195f0][Info]"Set `Friends` path: `/home/dkg/.local/share/linphone/friends.db`" [15:11:04:436][0x55d195f0][Info]"Set `CallLogs` path: `/home/dkg/.local/share/linphone/call-history.db`" [15:11:04:441][0x55d195f0][Info]Using ZrtpSecrets path : "/home/dkg/.local/share/linphone/zidcache" [15:11:04:442][0x55d195f0][Info]Using UserCertificate path : "/home/dkg/.local/share/linphone/usr-crt/" [15:11:04:442][0x55d195f0][Info]Using RootCa path : "/usr/share/linphone/rootca.pem" [15:11:04:442][0x55d195f0][Info]"Start iterate" [15:11:04:473][0x55d195f0][Info]Sip addresses model from Chats : 30 ms. [15:11:04:484][0x55d195f0][Info]Sip addresses model from Calls : 10 ms. [15:11:04:484][0x55d195f0][Info]Sip addresses model from Refs : 0 ms. [15:11:04:484][0x55d195f0][Info]Sip addresses model from Contacts : 0 ms. [15:11:04:484][0x55d195f0][Info]Sip addresses model initialized in: 41 ms. [15:11:04:528][0x55d195f0][Info]"Notify event count: 0." [15:11:04:528][0x55d195f0][Info]"CoreManager initialized" [New Thread 0x7fffb71fe640 (LWP 310197)] [New Thread 0x7fffb69fd640 (LWP 310198)] [Thread 0x7fffb69fd640 (LWP 310198) exited] [15:11:04:738][0x55d195f0][Info]"Open Linphone app." [15:11:04:738][0x55d195f0][Info]"Creating subwindow: `qrc:/ui/views/App/Calls/CallsWindow.qml`." [15:11:04:813][0x55d195f0][Info]"Subwindow status: `1`." [15:11:04:852][0x55d195f0][Info]"Creating subwindow: `qrc:/ui/views/App/Settings/SettingsWindow.qml`." [15:11:04:921][0x55d195f0][Info]"Subwindow status: `1`." [New Thread 0x7fffb69fd640 (LWP 310199)] [New Thread 0x7fffb5dfc640 (LWP 310200)]
Bug#1021043: linphone-desktop: linphone crashes and is unusable
Package: linphone-desktop
Version: 4.3.2-2
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: d...@fifthhorseman.net
I've used linphone for years. Recently (i think with the upgrade to
4.3.2-2) it no longer works for me, crashing with a range of errors.
Working with my longstanding configuration, i see the following on stderr:
0 dkg@alice:~$ linphone
[17:53:37:555][0x562cdf49f5f0][Info]"Starting Linphone (bin: linphone)"
[17:53:37:555][0x562cdf49f5f0][Info]"Use locale: en_US"
[17:53:37:610][0x562cdf49f5f0][Info]Available fonts : ([REDACTED FOR LENGTH])
[17:53:37:611][0x562cdf49f5f0][Info]"Running app..."
[17:53:37:660][0x562cdf49f5f0][Info]"Activated selectors:" ("custom", "en_US",
"unix", "linux", "debian")
[17:53:37:661][0x562cdf49f5f0][Info]"Registering types..."
[17:53:37:662][0x562cdf49f5f0][Info]"Registering shared types..."
[17:53:37:662][0x562cdf49f5f0][Info]"Registering tool types..."
[17:53:37:662][0x562cdf49f5f0][Info]"Registering shared tool types..."
[17:53:37:804][0x562cdf49f5f0][Info]"Loading main view..."
[17:53:37:928][0x562cdf49f5f0][Info]"Launch async core creation."
[17:53:38:078][0x562cdf49f5f0][Info]Core is starting "Starting up"
[17:53:38:123][0x562cdf49f5f0][Info]Core is running "On"
[17:53:38:123][0x562cdf49f5f0][Info]"Set `Friends` path:
`/home/dkg/.local/share/linphone/friends.db`"
[17:53:38:138][0x562cdf49f5f0][Info]"Set `CallLogs` path:
`/home/dkg/.local/share/linphone/call-history.db`"
[17:53:38:144][0x562cdf49f5f0][Info]Using ZrtpSecrets path :
"/home/dkg/.local/share/linphone/zidcache"
[17:53:38:144][0x562cdf49f5f0][Info]Using UserCertificate path :
"/home/dkg/.local/share/linphone/usr-crt/"
[17:53:38:144][0x562cdf49f5f0][Info]Using RootCa path :
"/usr/share/linphone/rootca.pem"
[17:53:38:145][0x562cdf49f5f0][Info]"Start iterate"
[17:53:38:181][0x562cdf49f5f0][Info]Sip addresses model from Chats : 34 ms.
[17:53:38:192][0x562cdf49f5f0][Info]Sip addresses model from Calls : 10 ms.
[17:53:38:192][0x562cdf49f5f0][Info]Sip addresses model from Refs : 0 ms.
[17:53:38:193][0x562cdf49f5f0][Info]Sip addresses model from Contacts : 0 ms.
[17:53:38:193][0x562cdf49f5f0][Info]Sip addresses model initialized in: 45 ms.
[17:53:38:242][0x562cdf49f5f0][Info]"Notify event count: 0."
[17:53:38:242][0x562cdf49f5f0][Info]"CoreManager initialized"
[17:53:38:471][0x562cdf49f5f0][Info]"Open Linphone app."
[17:53:38:471][0x562cdf49f5f0][Info]"Creating subwindow:
`qrc:/ui/views/App/Calls/CallsWindow.qml`."
[17:53:38:534][0x562cdf49f5f0][Info]"Subwindow status: `1`."
[17:53:38:574][0x562cdf49f5f0][Info]"Creating subwindow:
`qrc:/ui/views/App/Settings/SettingsWindow.qml`."
[17:53:38:641][0x562cdf49f5f0][Info]"Subwindow status: `1`."
[17:53:39:708][0x562cdf49f5f0][Info]"Notify event count: 0."
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string: construction from null is not valid
Aborted
134 dkg@alice:~$
I decided that maybe there was something wrong with my configuration,
so i moved ~/.config/linphone, ~/.linphonerc, and
~/.local/share/linphone out of the way to start fresh.
When i did that, and restarted linphone, i got the following error:
0 dkg@alice:~$ linphone
2022-09-30 18:31:09:410 bctbx-error-bctbx_file_open: Error open No such file or
directory
[18:31:09:422][0x564abb71f5f0][Info]"Starting Linphone (bin: linphone)"
[18:31:09:422][0x564abb71f5f0][Info]"Use locale: en_US"
[18:31:09:466][0x564abb71f5f0][Info]Available fonts : ([REDACTED FOR LENGTH])
[18:31:09:467][0x564abb71f5f0][Info]"Running app..."
[18:31:09:500][0x564abb71f5f0][Info]"Activated selectors:" ("custom", "en_US",
"unix", "linux", "debian")
[18:31:09:500][0x564abb71f5f0][Info]"Registering types..."
[18:31:09:501][0x564abb71f5f0][Info]"Registering shared types..."
[18:31:09:501][0x564abb71f5f0][Info]"Registering tool types..."
[18:31:09:501][0x564abb71f5f0][Info]"Registering shared tool types..."
[18:31:09:595][0x564abb71f5f0][Info]"Loading main view..."
[18:31:09:698][0x564abb71f5f0][Info]"Launch async core creation."
[18:31:09:804][0x564abb71f5f0][Info]Core is starting "Starting up"
[18:31:09:853][0x564abb71f5f0][Info]Core is running "On"
[18:31:09:854][0x564abb71f5f0][Info]"Set `Friends` path:
`/home/dkg/.local/share/linphone/friends.db`"
[18:31:09:871][0x564abb71f5f0][Info]"Set `CallLogs` path:
`/home/dkg/.local/share/linphone/call-history.db`"
free(): invalid pointer
Aborted
134 dkg@alice:~$
Running it a second time i get:
0 dkg@alice:~$ linphone
[18:32:24:342][0x55e23f1ba5f0][Info]"Starting Linphone (bin: linphone)"
[18:32:24:342][0x55e23f1ba5f0][Info]"Use locale: en_US"
[18:32:24:383][0x55e23f1ba5f0][Info]Available fonts : ([READACTED FOR LENGTH])
[18:32:24:383][0x55e23f1ba5f0][Info]"Running app..."
[18:32:24:415][0x55e23f1ba5f0][Info]"Activated selectors:" ("custom", "en_US",
"unix", "linux", "debian")
[18:32:24:415][0x55e23f1ba5f0][Info]"Registering types..."
[18:32:24:415][0x55e23f1ba5f0][Info]"Registering shared types..."
Bug#984921: rust-libsqlite3-sys: depends on multiple unavailable packages
Version: 0.25.0-1 On Wed 2021-03-10 10:43:38 +0100, Andreas Beckmann wrote: > the binary packages built from src:rust-libsqlite3-sys depend on several no > longer available packages, e.g. > > The following packages have unmet dependencies: >librust-libsqlite3-sys+bindgen-dev : Depends: > librust-bindgen-0.50+default-dev but it is not installable This has been resolved with rust-libsqlite3-sys 0.25.0-1, as it now Depends: librust-bindgen-0.60+runtime-dev, which is in both testing and unstable. --dkg signature.asc Description: PGP signature
Bug#1010821: pypdf2 breaks xml2rfc autopkgtest: lxml.etree.XMLSyntaxError: PCDATA invalid Char value 1
Control: reassign 1010821 pypdf2/2.4.2-1
Control: forwarded 1010821 https://github.com/py-pdf/PyPDF2/issues/
Control: retitle 1010821 PyPDF2 fails to read a PDF file with a beginbfchar
entry with an empty second element
Control: affects 1010821 + src:xml2rfc src:weasyprint
On Tue 2022-05-10 21:53:30 +0200, Paul Gevers wrote:
> With a recent upload of pypdf2 the autopkgtest of xml2rfc fails in
> testing when that autopkgtest is run with the binary packages of pypdf2
> from unstable. It passes when run with only packages from testing. In
> tabular form:
the problem here is indeed a bug in the latest versions of PyPDF2. I've
traced it back to a failure in how PyPDF2 deals with an empty second
element in a bfchar list:
https://github.com/py-pdf/PyPDF2/issues/
You can replicate the problem with this file (habibi.html):
habibi
حَبيبي habibi
Feed it through weasyprint from the command line:
--
weasyprint habibi.html habibi.pdf
--
and then in python:
---
from PyPDF2 import PdfReader
r = PdfReader('habibi.pdf')
t = r.pages[0].extract_text()
---
This causes a crash in PyPDF2. The crash can be worked around with this
patch:
-
--- a/PyPDF2/_cmap.py
+++ b/PyPDF2/_cmap.py
@@ -245,7 +245,7 @@ def parse_to_unicode(
elif process_char:
lst = [x for x in l.split(b" ") if x]
map_dict[-1] = len(lst[0]) // 2
-while len(lst) > 0:
+while len(lst) > 1:
map_dict[
unhexlify(lst[0]).decode(
"charmap" if map_dict[-1] == 1 else "utf-16-be",
"surrogatepass"
-
But the patch is insufficient, because then the result of extract_text()
("t" in the python above) is wrong. The problem has to do with subtly
wrong parsing in _cmap.py's parse_to_unicode(). it does manual
manipulation by removing angle brackets and then splitting and
recombining strings based on whitespace. When the contents of some of
the angle-brackets are empty, this technique doesn't work.
--dkg
signature.asc
Description: PGP signature
Bug#1008573: [pkg-gnupg-maint] Bug#1008573: gpg-agent -managed SSH keys stored in Yubikeys cannot be used with OpenSSH 8.9
Control: forwarded 1008573 https://dev.gnupg.org/T5935 Control: tags 1008573 + upstream Control: severity 1008573 important This bug report was tagged severity "serious" https://www.debian.org/Bugs/Developer#severities says that severity level means: > is a severe violation of Debian policy (roughly, it violates a > "must" or "required" directive), or, in the package maintainer's or > release manager's opinion, makes the package unsuitable for release. I see no justification for that severity level in the discussion, so i'm changing it to normal. If you think that's wrong, feel free to reset it to "serious" with an explicit justification, thanks! On Fri 2022-04-22 12:04:15 +0900, NIIBE Yutaka wrote: > I found an issue of scdaemon. At upstream development, it is tracked by: > > https://dev.gnupg.org/T5935 > > When the data is not so large (smaller than the buffer size of token), > it works using Gnuk, with the patch of scdaemon. Thanks for tracking this down, gniibe! If there's a specific patch that we should include in the debian release of the 2.2 branch, please let me know. The patch mentioned in https://dev.gnupg.org/T5935 (https://dev.gnupg.org/rGe8fb8e2b3e66d5ea8a3dc90afdc14611abf2c3da) doesn't look like it will apply directly to the 2.2 branch. In the meantime, people with the affected key/hardware combination should be able to continue using the workaround described by vagrant. --dkg signature.asc Description: PGP signature
Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]
Hi Michael and Santiago-- I've now uploaded ldns 1.7.1-3 with the associated fix for 1009385. I'm reviewing Michael's changes for 1.8.1, and they're looking good to me. Thank you for all that work, Michael! I think we should consider uploading 1.8.1 into experimental while we wait for 1.7.1-3 to propagate to testing. I'm assembling a git branch that includes your changes that i've reviewed and i'll push that to salsa as a "debian/experimental" branch later today, if either of you want to take a look at what i'm considering for release. --dkg signature.asc Description: PGP signature
Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]
Thanks both Michael and Santiago for sorting this out! I agree that backporting https://github.com/NLnetLabs/ldns/commit/4d2057f0b5220487882be1b19c302833b84cffe3 to 1.7.1 is the most reasonable/conservative fix. We want that to propagate into testing as soon as possible without risking being blocked by any other surprising regressions. I'll take care of that as part of the debian DNS team right now, which should take care of the NMU as well. --dkg signature.asc Description: PGP signature
Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]
Control: reassign 1009385 libldns3 1.7.1-2.1 Control: retitle 1009385 libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data Control: affects 1009385 + dns-root-data X-Debbugs-Cc: Michael Tokarev Control: tags 1009385 + help Lucas, thanks for flagging this! The build failure below appears to happen when libldns3 1.7.1-2.1 is installed. It does not fail with libldns3 1.7.1-2+b1. The output of ldns-key2ds has changed between these two versions. yikes! Michael, it looks like it was this particular upload for ldns: - ldns (1.7.1-2.1) unstable; urgency=medium * Non-maintainer upload. * add fix-wrong-python-distutils-configure-check.diff to fix the incorrect distutils package check (it should be checking the return code not the emptiness of the output). This fixes FTBFS with new python (3.10) and allows the python3.10 transition to happen, but it is not fixing the actual issiue with ldns using distutils which should be addressed later. Closes: #1008638 -- Michael Tokarev Thu, 07 Apr 2022 16:03:29 +0300 - This doesn't seem like it should be a relevant change to adjust the output of /usr/bin/ldns-key2ds, but it does: here's a narrow transcript that shows what should be a deterministic result varying depending on the version: 0 dkg@alice:~/src/pkg-dns/dns-root-data$ dpkg -l libldns3 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= ii libldns3:amd64 1.7.1-2+b1 amd64ldns library for DNS programming 0 dkg@alice:~/src/pkg-dns/dns-root-data$ /usr/bin/ldns-key2ds -n -2 root.key . 86400 IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d 0 dkg@alice:~/src/pkg-dns/dns-root-data$ dpkg -l libldns3 Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= ii libldns3:amd64 1.7.1-2.1amd64ldns library for DNS programming 0 dkg@alice:~/src/pkg-dns/dns-root-data$ /usr/bin/ldns-key2ds -n -2 root.key . 86400 IN DS 20326 8 2 0ae721f59a19244008217c3d2a646183acef2f17cf4c30929a3f29d09311c05e 0 dkg@alice:~/src/pkg-dns/dns-root-data$ Any idea what's happened here? --dkg On Tue 2022-04-12 20:38:47 +0200, Lucas Nussbaum wrote: > Source: dns-root-data > Version: 2021011101 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20220412 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): >> make[1]: Entering directory '/<>' >> # Verify root-anchors.xml using OpenSSL >> openssl smime -verify -noverify -inform DER -in root-anchors.p7s -content >> root-anchors.xml >> Verification successful >> >> > source="http://data.iana.org/root-anchors/root-anchors.xml;> >> . >> > validUntil="2019-01-11T00:00:00+00:00"> >> 19036 >> 8 >> 2 >> 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5 >> >> >> 20326 >> 8 >> 2 >> E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D >> >> >> # Verify root.hints >> gpgv --keyring /<>/registry-admin.key >> /<>/root.hints.sig /<>/root.hints >> gpgv: Signature made Mon Jan 11 15:55:50 2021 UTC >> gpgv:using DSA key 937BB869E3A238C5 >> gpgv: Good signature from "Registry Administrator " >> # Create key from validated root-anchors.xml >> ./parse-root-anchors.sh < root-anchors.xml | sort -k 4 -n > root-anchors.ds >> Digest 49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5 >> expired on 2019-01-11T00:00:00+00:00 >> # Create key from downloaded root.key >> /usr/bin/ldns-key2ds -n -2 root.key | cut --fields=1,3- --output-delimiter=' >> ' | sort -k 4 -n > root.ds >> # Compare the DS from root.key and from root-anchors.xml >> diff -u root-anchors.ds root.ds >> --- root-anchors.ds 2022-04-12 16:59:11.126351522 + >> +++ root.ds 2022-04-12 16:59:11.130351536 + >> @@ -1 +1 @@ >> -. IN DS 20326 8 2 >> e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d >> +. IN DS 20326 8 2 >> 0ae721f59a19244008217c3d2a646183acef2f17cf4c30929a3f29d09311c05e >> make[1]: *** [debian/rules:23: override_dh_auto_build] Error 1 > > > The full build log is available from: > http://qa-logs.debian.net/2022/04/12/dns-root-data_2021011101_unstable.log > > All bugs filed during this archive rebuild are listed at: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20220412;users=lu...@debian.org > or: >
Bug#1008493: gnome-control-center and gnome-settings-daemon version mismatch makes keyboard shortcuts fail
On Tue 2022-03-29 19:09:50 +0100, Simon McVittie wrote: > Major GNOME components are expected to be upgraded together, except for > when that's unnecessary. That is an unsatisfying answer, but unfortunately > it's the only true answer. Thanks for the clarification, Simon, even if it's unsatisfying. It's disappointing to hear that about GNOME: i'd have expected the project overall to have taken more time to think about API issues given the amount of ecosystem knowledge (and dependency hell scars) that i'm sure exists within the active developers. I do understand the tradeoffs between rigidity and fluidity that you describe, and how you can get unmanageable delays on one end, and hidden breakage on the other. That tradeoff is precisely why i'm inclined to gravitate toward declaring something API-like, even between "internal" components. I tend to think that approach will give the best balance possible on that tradeoff, but i also recognize that getting there requires some significant engineering investment (in both tooling and training) if that's not already established practice. >> GNOME typically does a good job in handling a novice user's behaviors >> well without hassling them with confusing technical arcana, but that >> means that silent and complete crashes like the one observed here just >> look like unrecoverable breakage to the normal user who doesn't know >> anything about stderr or how to launch settings from the terminal. > > Sorry, but that normal user probably should not be using unstable. Agreed, the normal user is most likely to use a released version of Ubuntu, which as you said is shipping a mixed set of packages. Yikes! Thanks very much for your work on GNOME, Simon! --dkg signature.asc Description: PGP signature
Bug#1008493: gnome-control-center and gnome-settings-daemon version mismatch makes keyboard shortcuts fail
On Mon 2022-03-28 21:26:16 -0400, Jeremy Bicha wrote: > This fix is pending Thanks for the pending fix, Jeremy. I can't help noticing that this failure looks like a classic backward-incompatible API change. The API happens to be across a gsettings schema instead of a C library, language-specific module, or network service, but it's still the same thing. As a community, we have decades of hard-won experience in reasoning about and handling API changes: thinking about what kinds of changes are backward-compatible (adding interfaces) or backward-incompatible (removing or changing interfaces), how to signal them (SONAMEs for C shared objects, libtool's current/revision/age, semver in many of the modern language ecosystems, URL prefixes for HTTP REST, etc), and how to declare dependencies on them in ways that are not hard to propagate into downstream package managers. How does GNOME track these API changes across its constitutent projects? I'm too much of a newbie in GNOME to know how that's done, but if there is some sort of API version tracking within gnome, then it seems like either gnome-settings-daemon should have marked a backward-incompatible API bump when it removed the "screenshot" key from the schema or gnome-control-center didn't accurately specify its particular API needs from gnome-settings-daemon. If that signalling is present, and either of those were fixed upstream, that knowledge should be propagated to the debian packaging. If there is no explicit API dependency tracking within GNOME, but version numbers of major GNOME components are supposed to advance in lockstep, then shouldn't the corresponding packages in debian have automated and explicit dependency annotations to enforce that lockstep transition? There are other options too, of course, including: - gnome-settings-daemon could declare that any given key in its schema could go away, and expect callers to deal with such an outage. In that case, gnome-control-center is at fault for aborting when the 'screenshot' key was not found. - gnome-settings-daemon could avoid a backward-incompatible API change by retaining the "screenshot" key, possibly emitting deprecation warnings somewhere when the deprecated key is accessed. Some future version could bundle a collection of schema removals into a larger backward-incompatible API change after a suitable deprecation window. This is a larger general concern about the health of GNOME in Debian going forward: i don't expect the GNOME interdependencies to get simpler over time (what user-facing software does?), so i would like to understand how GNOME and the Debian GNOME team think about handling them in general. GNOME typically does a good job in handling a novice user's behaviors well without hassling them with confusing technical arcana, but that means that silent and complete crashes like the one observed here just look like unrecoverable breakage to the normal user who doesn't know anything about stderr or how to launch settings from the terminal. If you think this is an upstream GNOME issue and no debian-specific at all, I'm happy to move this off the Debian BTS, just tell me where you think the appropriate venue is. Thanks for your work maintaining GNOME in debian! --dkg signature.asc Description: PGP signature
Bug#983770: Acknowledgement (rnp: FTBFS on 32-bit platforms (test suite failures))
Version: 0.15.2-4 rnp upstream version 0.15 fixed the timestamp issues that were causing https://bugs.debian.org/983770 on 32-bit architectures. 0.15.2-4 is the latest version of rnp in debian; if the builds are successful, it should not be prohibited from migration to testing. --dkg signature.asc Description: PGP signature
Bug#993835: rnp FTBFS: rnp_tests.test_key_add_userid (Failed)
Version: 0.15.2-1 The RNP test suite no longer fails on test_key_add_userid as of version 0.15.2-1. There are new failures on armel and armhf with test_sym_encryption__rnp_aead, sigh, but i'll try to diagnose those in a separate bug report. --dkg On Tue 2021-09-07 05:52:14 +0300, Adrian Bunk wrote: > Source: rnp > Version: 0.14.0-6 > Severity: serious > Tags: ftbfs > > https://buildd.debian.org/status/package.php?p=rnp=sid > > ... > test 135 > Start 135: rnp_tests.test_key_add_userid > > 135: Test command: /<>/build/src/tests/rnp_tests > "--gtest_filter=rnp_tests.test_key_add_userid" > "--gtest_also_run_disabled_tests" > 135: Environment variables: > 135: RNP_TEST_DATA=/<>/src/tests/data > 135: Test timeout computed to be: 3000 > 135: Note: Google Test filter = rnp_tests.test_key_add_userid > 135: [==] Running 1 test from 1 test suite. > 135: [--] Global test environment set-up. > 135: [--] 1 test from rnp_tests > 135: [ RUN ] rnp_tests.test_key_add_userid > 135: unknown file: Failure > 135: C++ exception with description "rnp_exception" thrown in the test body. > 135: [ FAILED ] rnp_tests.test_key_add_userid (31 ms) > ... > > 99% tests passed, 1 tests failed out of 213 > > Total Test time (real) = 650.07 sec > > The following tests FAILED: > 135 - rnp_tests.test_key_add_userid (Failed) > Errors while running CTest > make[1]: *** [Makefile:129: test] Error 8 signature.asc Description: PGP signature
Bug#989406: wireguard-dkms makes little sense with the bullseye kernel
Control: severity 989406 normal Control: retitle 989406 wireguard-dkms is unneeded for stock kernels > 5.6 I'm downgrading the severity to keep wireguard-dkms in bullseye -- we can increase it again once bullseye is released to keep wireguard-dkms out of bookworm. Adrian or others, if you would prefer that we handle this differently, please give a bit more detail about the timeline you'd prefer and why. Regards, --dkg signature.asc Description: PGP signature
Bug#989406: wireguard-dkms makes little sense with the bullseye kernel
On Thu 2021-06-03 01:37:25 +0300, Adrian Bunk wrote: > Overall it feels like a package with high CVE risk and 0 users > in bullseye. I agree with Jason that some people may use non-standard, older kernels with bullseye, so there is some value in continuing to provide wireguard-dkms in bullseye to help those folks. (i'm thinking about people running older hardware that has had support dropped in newer kernels, for example). It is not going to be exactly 0 users, but i expect the number to be small. At the same time, a package with a small number of users presents a smaller attack surface if a CVE does come up. The stock kernels already avoid people accidentally pulling in wireguard-dkms by default if they just "apt install wireguard". At some point, though, people who choose to run their own (non-debian) kernel will need to effectively take responsibility for their kernel modules as well, so i do not expect Debian to continue shipping wireguard-dkms indefinitely. I do not expect to ship it in bookworm (bullseye+1), for example. --dkg
Bug#983770: rnp: FTBFS on 32-bit platforms (test suite failures)
Package: rnp Version: 0.14.0-5 Severity: critical Control: forwarded -1 https://github.com/rnpgp/rnp/issues/1436 RNP's test suites are failing on all of the 32-bit platforms in debian. I've reported this upstream so that hopefully it can be resolved. It should not migrate into testing in this current state. --dkg signature.asc Description: PGP signature
Bug#979840: dns-root-data: autopkgtest regression in testing: failed to query server 127.0.0.1@53
Thanks Paul for reviewing this, and Robert for looking into it further. I think my conclusions differ a little bit from Robert's. On Thu 2021-02-11 22:22:18 -0500, Robert Edmonds wrote: > I have investigated this report. The purpose of the dns-root-data > package is to ship, as static content, the list of IANA DNS root > nameserver IP addresses, and the IANA DNSSEC root zone trust anchor. > According to > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation: > > It can be appropriate to file an RC bug against the depended-on > package, if the regression amounts to an RC bug in the depending > package, and to keep it open while the matter is investigated. That > will prevent migration of an RC regression. > > I have confirmed that the current version of the package (2019052802) is > shipping the correct root nameserver hints and root zone trust anchor > content and that no RC regression exists, so I am lowering the severity > of this bug report. > > The problem seems to be that the test depends on the Knot Resolver's > kresd daemon, whose service unit is masked and is not started after > installing the knot-resolver package. I would guess something like the > following would fix the regression in the test: hmm, kresd.service is masked, because kresd is managed via the kresd@.service template (to enable cheap and easily-supervised multi-process parallelism). The problem seems to be that kresd isn't starting up automatically on package installation: Feb 12 20:23:01 alice systemd[1]: Stopping Knot Resolver daemon... Feb 12 20:23:01 alice systemd[382608]: kresd@1.service: Changing to the requested working directory failed: No such file or directory Feb 12 20:23:01 alice systemd[382608]: kresd@1.service: Failed at step CHDIR spawning /usr/bin/env: No such file or directory Feb 12 20:23:01 alice systemd[1]: kresd@1.service: Control process exited, code=exited, status=200/CHDIR Feb 12 20:23:01 alice systemd[1]: kresd@1.service: Failed with result 'exit-code'. Feb 12 20:23:01 alice systemd[1]: Stopped Knot Resolver daemon. Feb 12 20:23:17 alice systemd[1]: /lib/systemd/system/kresd@.service:25: Failed to assign slice system-kresd.slice to unit kresd@1.service, ignoring: Device or resource busy I've updated the autopkgtest script to try to manually ensure that the kresd@1 service is started and released a new version of dns-root-data to try to cover it. Meanwhile, I've also reported #982660 against knot-resolver for this strange startup situation. --dkg signature.asc Description: PGP signature
Bug#975480: rust-bzip2-sys: autopkgtest failure: crate directory not found: /usr/share/cargo/registry/bzip2-sys-0.1.9+1.0.8
Control: affects 975480 debcargo On Sun 2020-11-22 19:21:45 +0100, Paul Gevers wrote: > autopkgtest [09:47:16]: test librust-bzip2-sys-dev: > /usr/share/cargo/bin/cargo-auto-test bzip2-sys 0.1.9+1.0.8 --all-targets > --no-default-features > autopkgtest [09:47:16]: test librust-bzip2-sys-dev: [--- > crate directory not found: /usr/share/cargo/registry/bzip2-sys-0.1.9+1.0.8 > autopkgtest [09:47:16]: test librust-bzip2-sys-dev: ---] This is a bug in debcargo 2.4.3 and earlier. in debcargo 2.4.4, debcargo emits the debian version here, based on commit 293fb88f2156d0db6262349aa4b1c4d3a3b1186a in the debcargo repo. Until debcargo 2.4.4 lands in unstable, i'll just work around it in rust-bzip2-sys. --dkg signature.asc Description: PGP signature
Bug#977421: rust-sha1collisiondetection: FTBFS on architectures with unsigned char
Package: rust-sha1collisiondetection Version: 0.2.2-1 Severity: critical Control: forwarded -1 https://gitlab.com/sequoia-pgp/sha1collisiondetection/-/issues/1 Looks like rust-sha1collisiondetection code isn't as portable as upstream expected it to be. It is failing on platforms with an unsigned char, with errors like: ~~~ error[E0308]: mismatched types --> lib/lib.rs:252:31 | 252 | ... input.as_ptr() as *const i8, | ^^^ expected `u8`, found `i8` | = note: expected raw pointer `*const u8` found raw pointer `*const i8` ~~~ This means that the package fails to build from source on arm, powerpc, riscv, and s390 architectures. This is reported to upstream at https://gitlab.com/sequoia-pgp/sha1collisiondetection/-/issues/1 so hopefully they'll sort it out shortly. --dkg signature.asc Description: PGP signature
Bug#971105: closing 971105
close 971105 thanks sequoia dependencies are all sorted in unstable now that rust-dyn-clone propagated out of NEW. See #971099 and #971717.
Bug#971099: rust-sequoia-openpgp: FTBFS: unsatisfiable build-dependencies: librust-dyn-clone-1+default-dev but it is not installable
On Sun 2020-09-27 20:38:38 +0200, Lucas Nussbaum wrote: > Source: rust-sequoia-openpgp > Version: 0.18.0-1 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20200926 ftbfs-bullseye rust-dyn-clone made it out of NEW on 2020-10-09, so rust-sequoia-openpgp 0.18.0-2 is now building just fine on the buildd network. --dkg signature.asc Description: PGP signature
Bug#971103: rust-sequoia-sqv: FTBFS: build-dependency not installable: librust-sequoia-openpgp-0.18+crypto-nettle-dev
On Sun 2020-09-27 20:38:50 +0200, Lucas Nussbaum wrote: > Source: rust-sequoia-sqv > Version: 0.18.0-2 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20200926 ftbfs-bullseye rust-sequoia-openpgp 0.18.0-1 is now in unstable, and rust-sequoia-sqv 0.18.0-2 is now building just fine on the buildd network. --dkg signature.asc Description: PGP signature
Bug#971119: closing 971119, closing 971124
close 971119 close 971124 thanks These two FTBFS bug reports (for rust-nettle and rust-nettle-sys) were happening because of #971139 on rust-bindgen. When #971139 was resolved by rust-bindgen 0.51.1-5 (Sylvestre patched the depenedencies in Cargo.toml), these other FTBFS bugs got solved as well.
Bug#971140: rust-lalrpop: FTBFS: build-dependency not installable: librust-itertools-0.8+default-dev
Version: 0.17.2-5 On Sun 2020-09-27 20:38:00 +0200, Lucas Nussbaum wrote: >> The following packages have unmet dependencies: >> sbuild-build-depends-main-dummy : Depends: >> librust-itertools-0.8+default-dev but it is not installable >> E: Unable to correct problems, you have held broken packages. >> apt-get failed. looks like lalrpop builds and runs fine with itertools 0.9 as well as 0.8. i've relaxed its build-dependencies for itertools in 0.17.2-5. At some point, we should move to the latest lalrpop (0.19.1), but that is going to require at least one round-trip through NEW (lalrpop-util has a new "lexer" feature), so for now i'm going to just try to get the existing toolchain to migrate to testing, so that the existing sequoia packages (and anything else that depends on lalrpop 0.17) can build and migrate. --dkg signature.asc Description: PGP signature
Bug#963275: rust-structopt-derive: FTBFS: build-dependency not installable: librust-proc-macro-error-1+default-dev
On Sun 2020-06-21 21:50:35 +0200, Lucas Nussbaum wrote: > Source: rust-structopt-derive > Version: 0.4.8-1 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20200620 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. This was missing due to rust-proc-macro-error-attr being held in NEW, which meant that rust-proc-macro-error could not be updated. Now that r-p-m-e-attr is out of NEW, and rust-proc-macro-error 1.0.3 has been uploaded to unstable, rust-structopt-derive should build fine. --dkg signature.asc Description: PGP signature
Bug#963295: rust-structopt: FTBFS: build-dependency not installable: librust-structopt-derive-0.4.8+default-dev
On Sun 2020-06-21 21:50:37 +0200, Lucas Nussbaum wrote: > Source: rust-structopt > Version: 0.3.15-1 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20200620 ftbfs-bullseye […] >> The following packages have unmet dependencies: >> sbuild-build-depends-main-dummy : Depends: >> librust-structopt-derive-0.4.8+default-dev but it is not installable >> E: Unable to correct problems, you have held broken packages. >> apt-get failed. This is blocked waiting on rust-proc-macro-error-attr, which is currently stuck in NEW. Hopefully someone on the FTP team can look at rust-proc-macro-error-attr. --dkg signature.asc Description: PGP signature
Bug#953800: [pkg-gnupg-maint] Bug#953800: gpgme1.0: don't fail checky2106 on 32bit systems
Control: found 953800 1.13.1-6 If checky2106 will always fail on 32-bit systems, that's a clear indication that GnuPG will fail on those systems when it encounters objects that have a timestamp that lands about 86 years out from now. For example, an OpenPGP certificate with a 100-year expiration date issued any time in the last 14 years. Or an OpenPGP certificate with a 75-year expiration date issued 11 years from now. The test should *not* obviously fail on 32-bit systems, but it is a combination of bugs that upstream declines to fix: https://dev.gnupg.org/T4766 https://dev.gnupg.org/T4826 I honestly don't know how to resolve this issue correctly, given upstream's refusal to acknowledge it as a problem worth fixing. To the extent that software on debian depends on these systems going forward while OpenPGP is in use, and they may encounter signatures or certificates with expiration dates later than 2106, our users *will* run into this problem, well before 2106 itself rolls around. i'm working on an update to the gpgme1.0 debian packaging that will permit the package to skip this particular autopkgtest if it is failing on 32-bit platforms as long as a certificate or signature created "today" with an expiration date of 75 years is handled correctly. This is a reprieve of 11 years. Hopefully by then either upstream will have resolved the problem, or either GPGME or platforms with a 32-bit unsigned long will no longer be relevant to Debian. On Fri 2020-03-13 17:42:05 +0100, Gianfranco Costamagna wrote: > also, taking this patch would be so appreciated. > +- debian/patches/0006-PIC-and-shared.patch: Libs are -fPIC and -shared. This is an entirely different matter, and seems related to https://bugs.debian.org/870383 -- it would probably be better dealt with over there or on a new bug report. Has this change been recommended upstream? Why should debian or ubuntu carry it separately? > +- Add in libgpgme-dev a libgpgme-pthread.so pointing to libgpgme.so, this > + will fix the build failures of kf5-kdepim-apps-libs when built against > + this gpgme package. This is also a separate issue, and should probably be dealt with separately. Are you sure this isn't a bug in kf5-kdepim-apps-libs, and not gpgme? where does kf5-kdepim-apps-libs get the idea that it should be looking for libgpgme-pthread.so instead of libgpgme.so during build? --dkg signature.asc Description: PGP signature
Bug#953230: balsa: autopkgtest failure: times out
On Fri 2020-03-06 10:16:13 +0100, Paul Gevers wrote: > PS: these kind of timeouts are bad for our infrastructure. If this bug > doesn't get fixed in a timely manner, I may add your package to our > ignore-list. Sorry about the delay in getting this fixed, Paul. I believe the test suite will no longer time out (it was missing a dependency on psmisc, so "killall" didn't work). So if you could remove balsa from the ci.debian.net blacklist, i'd appreciate it. Apologies for causing the problem in the first place! All the best, --dkg signature.asc Description: PGP signature
Bug#953230: marked as pending in balsa
Control: tag -1 pending Hello, Bug #953230 in balsa reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/gnome-team/balsa/-/commit/7a026c8e8e0601e42aa8131f7545ac61b185ab7f added psmisc to screenshot test for killall (Closes: #953230) (this message was generated automatically) -- Greetings https://bugs.debian.org/953230
Bug#951025: [pkg-gnupg-maint] Bug#951025: gnupg: GPG tries to get passphrase from wrong place
Control: severity 951025 normal On Sun 2020-02-09 23:27:39 +, Matthew Wakeling wrote: > I am justifying the severity marking of this bug report, because it > does prevent gnupg working correctly in the majority of its use > cases. If there is a nice simple on/off switch that makes it behave > sanely that I have missed, then please downgrade the severity and > document it. Hi, i don't mean to play severity ping-pong, but "the majority of its use cases" is not the same as "My machine currently has a desktop open, but is locked, and i'm ssh'ed in from another computer" :) I agree that this situation is frustrating, but it has been extensively documented, for example in https://bugs.debian.org/842015 and https://dev.gnupg.org/T2818 > The problem is that passphrase prompts now are centrally controlled, > which fundamentally breaks the way that computers are used - you log > in from various different places. The passphrase prompt must go to the > session that caused the passphrase to be needed. Any other action is > completely insane. You may want to reconsider your strong language here. having an agent that always prompts where it was launched is a sensible approach, especially if you want to provide tentative access to the agent to other services, but control the prompting from the original location, in order to retain control over the secrets stored in the agent. While this situation might not be what you personally care about, it's a far stretch from "completely insane". At any rate, please report what version of pinentry you are using on this host, as the choice of pinentry might make a difference. I believe that pinentry-gnome3 is best equipped to deal with the circumstance you're running into. I also recommend upgrading to debian stable (buster) where some of the use cases that you care about might have been better addressed. Thanks for taking the time to report the problem! Regards, --dkg signature.asc Description: PGP signature
Bug#951157: wireguard-dkms: DKMS make.log for wireguard-0.0.20200205 for kernel 5.3.9-sunxi (armv7l)
Control: severity 951157 normal Control: tags 951157 + unreproducible moreinfo Hi Carlos-- On Thu 1970-01-01 00:00:00 +, carlosnewmusic wrote: >* What led up to the situation? > wireguard metapackage installation >* What exactly did you do (or not do) that was effective (or > ineffective)? > install, install kernel headers, but it's useless >* What was the outcome of this action? > error 10 in the construction of the dkms package >* What outcome did you expect instead? > that the module and wireguard will be installed correctly This sounds frustrating! However, it doesn't look like you're using the debian kernel, or the debian kernel header packages. The kernel you're using: > Kernel: Linux 5.3.9-sunxi (SMP w/4 CPU cores) isn't in debian at all, afaict. > DKMS make.log for wireguard-0.0.20191226 for kernel 5.3.9-sunxi (armv7l) > lun ene 20 04:47:15 CET 2020 > make: se entra en el directorio '/usr/src/linux-headers-5.3.9-sunxi' > CC [M] /var/lib/dkms/wireguard/0.0.20191226/build/main.o > CC [M] /var/lib/dkms/wireguard/0.0.20191226/build/noise.o > CC [M] /var/lib/dkms/wireguard/0.0.20191226/build/device.o > CC [M] /var/lib/dkms/wireguard/0.0.20191226/build/peer.o > /bin/sh: 1: ./scripts/recordmcount: not found this error makes me think that you don't have the appropriate linux-kbuild packages installed. for example: https://packages.debian.org/sid/armhf/linux-kbuild-5.4/filelist shows that it contains the recordmcount script (you can find this by searching the packages database: https://packages.debian.org/search?suite=sid=armhf=filename=contents=recordmcount So you might want to try installing some matching kbuild package and see whether it works for you or not -- though i don't think that linux-kbuild-5.3 is available anywhere except for snapshots: https://snapshot.debian.org/binary/linux-kbuild-5.3/ (see https://snapshot.debian.org/ on how to use the snapshots service) Please report back and let me know if you run into the same problem when you have linux-kbuild-5.3 installed! --dkg signature.asc Description: PGP signature
Bug#946747: rust-buffered-reader: autopkgtest failure: no matching package named `bzip2` found
Version: 0.13.0-1
On Sun 2019-12-15 08:29:58 +0100, in #946747, Paul Gevers wrote:
> autopkgtest [03:58:52]: test command5:
> /usr/share/cargo/bin/cargo-auto-test buffered-reader 0.12.0
> --all-targets --features compression-deflate
> autopkgtest [03:58:52]: test command5: [---
> debian cargo wrapper: options, profiles, parallel: ['parallel=2'] [] ['-j2']
> debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu,
> x86_64-linux-gnu
> debian cargo wrapper: linking /usr/share/cargo/registry/* into
> /tmp/tmp.3gOH0iUboN/registry/
> debian cargo wrapper: options, profiles, parallel: ['parallel=2'] [] ['-j2']
> debian cargo wrapper: rust_type, gnu_type: x86_64-unknown-linux-gnu,
> x86_64-linux-gnu
> debian cargo wrapper: running subprocess (['env', 'RUST_BACKTRACE=1',
> '/usr/bin/cargo', '-Zavoid-dev-deps', 'test', '--verbose', '--verbose',
> '-j2', '--target', 'x86_64-unknown-linux-gnu', '--all-targets',
> '--features', 'compression-deflate'],) {}
> error: no matching package named `bzip2` found
> location searched: registry `https://github.com/rust-lang/crates.io-index`
> required by package `buffered-reader v0.12.0
> (/usr/share/cargo/registry/buffered-reader-0.12.0)`
> autopkgtest [03:58:52]: test command5: ---]
I believe that this bug report about the autopkgtest for
rust-buffered-reader (#946747) is due to the same underlying problem
described in #945560.
I've worked around #946747 in rust-buffered-reader version 0.13.0-1 by
marking the affected tests as "flakey". This is disappointing, but i
don't know how to fix #945560 myself.
--dkg
signature.asc
Description: PGP signature
Bug#943555: wireguard-dkms: Kernel modules don't build with kernel 5.3.0-1-arm64 on Raspberry Pi3
Control: tags 943555 + help moreinfo Control: severity 943555 important Control: affects 943555 + linux-headers-5.3.0-1-arm64 gcc-9 Hi Chris-- Thanks for the report! On Sat 2019-10-26 12:51:47 +, Chris. wrote: > on Raspberry Pi3 kernel module stops building since updating to kernel > 5.3.0.1. > > Output of /var/lib/dkms/wireguard/0.0.20191012/build/make.log > DKMS make.log for wireguard-0.0.20191012 for kernel 5.3.0-1-arm64 (aarch64) > Sat Oct 26 12:37:31 UTC 2019 > make: Entering directory '/usr/src/linux-headers-5.3.0-1-arm64' > arch/arm64/Makefile:58: *** arm-linux-gnueabihf-gcc not found, check > CROSS_COMPILE_COMPAT. Stop. > make: *** [/usr/src/linux-headers-5.3.0-1-common/Makefile:179: sub-make] > Error 2 > make: Leaving directory '/usr/src/linux-headers-5.3.0-1-arm64' I'm not sure this is a wireguard-specific issue... This looks to me like you don't have the arm64-specific compiler installed, which ought to have been installed correctly by linux-headers-5.3.0-1-arm64. I note that the arm64 flavor of the linux-headers-* packages just depends directly on gcc-9, and not on any specific variant of it. compare with the x86_64 variant or the armmp variant, which explicitly point toward an arch-specific metapackages for gcc: https://packages.debian.org/sid/linux-headers-5.3.0-1-arm64 vs: https://packages.debian.org/sid/linux-headers-5.3.0-1-amd64 https://packages.debian.org/sid/linux-headers-5.3.0-1-armmp Is it possible that you have some other architecture's gcc-9 installed, or something like that? Regards, --dkg signature.asc Description: PGP signature
Bug#909994: closing 909994
close 909994 0.5.2-2 thanks python-pgpy 0.5.2-2 builds fine on the build daemons. I suspect that the problem in #909994 was due to some breakage with gpgme.
Bug#849308: wireguard: Wireguard should not transition to stable yet
Hi Willem-- On Tue 2019-10-01 06:50:29 +0200, Willem van den Akker wrote: > I offer by help for maintaining packaging WG. Thank you, happy to have help! > Please let me know how I can help. Please make sure you can build the package from the debian/master branch at https://salsa.debian.org/debian/wireguard. If you can do that successfully (it shouldn't be too hard), feel free to take a look at the debian/TODO file, which contains a handful of suggestions, mostly about setting up more detailed autopkgtest testing. Another thing that might be handy is to read through the discussion starting here: https://lists.debian.org/deity/2019/09/msg00017.html The idea is to propose a debian package for binary wireguard kernel modules that matches the current kernel package, so that users wouldn't need to use dkms. getting the dependency details right there is tricky, as is keeping it up to date, but it might be worth trying. I've pushed a very ungainly initial attempt at this binary module packaging to https://salsa.debian.org/debian/wireguard-modules -- you might want to take a look at that and consider fixing one of the things in debian/TODO there, and proposing a fix. Alternately, testing its build and seeing whether the resultant binary works or not on systems without dkms would also be interesting. Thanks for offering to help! --dkg signature.asc Description: PGP signature
Bug#849308: state of wireguard mainline inclusion?
Version: 0.0.20190905-1 Over in 849...@bugs.debian.org, Daniel Kahn Gillmor wrote: > I do plan for putting wireguard into buster-backports, since i expect > the upstream inclusion issues to be resolved one way or another by the > time of bullseye release. If anyone wants to help out by adding it to > stretch-backports-sloppy, i would welcome that. Following up on this, and after some discussion with Jason (upstream), i think it's time to let wireguard migrate into debian testing. So i'm closing #849308 with this e-mail, and once wireguard migrates into testing, i'll look into putting it into buster-backports. I welcome anyone who wants to contribute to the debian packaging to offer maintenance help too! --dkg signature.asc Description: PGP signature
Bug#932015: wireguard-dkms: Wireguard dkms module build fails with gcc-8 on arm for 4.19.0-5-armmp-lpae kernel
On Tue 2019-08-20 22:36:07 +0200, Martin Höfling wrote: > first of all, my bananapi 2 died and I will replace it, probably with a > newer arm board. ouch, sorry to hear that. > Package: linux-headers-4.19.0-5-armmp-lpae > Version: 4.19.37-5+deb10u1 > > Package: linux-headers-4.19.0-5-common > Version: 4.19.37-5+deb10u1 thanks, that's definitely useful data. > Oh ok, no mine is much older as it seems. Also the error looks quite > different from what's described there. As I cannot reproduce it atm, you > can also close it from my side. I will report back / reopen if it also > happens with a new board. i think yours is newer, actually -- 4.19 vs. 4.9 ! I'll close this bug report for now, but please feel free to reopen it if you can reproduce the problem. --dkg signature.asc Description: PGP signature
Bug#932015: wireguard-dkms: Wireguard dkms module build fails with gcc-8 on arm for 4.19.0-5-armmp-lpae kernel
Control: tags 932015 + moreinfo Hi Martin-- On Sun 2019-07-14 02:26:05 +0200, Martin Hoefling wrote: > Package: wireguard-dkms > Version: 0.0.20190702-1 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) > Dear Maintainer, > >* What led up to the situation? > >Upgrading to buster and to kernel 4.19.0-5-armmp-lpae this is a package name, and not a package version. Martin, can you tell me what version of linux-headers-* you have installed on the failing system? If it's version 4.9.168-1+deb9u5 then it's possible that what you're running into is https://bugs.debian.org/935134, which is worked around in wireguard 0.0.20190702-2 (see https://bugs.debian.org/934763). Please let me know when you've tried that version. if it works for you, we can close this bug as a duplicate of #935134. If it doesn't work for you, then i'll need to dig into it further. Thanks for reporting problems to debian! --dkg signature.asc Description: PGP signature
Bug#928963: [pkg-gnupg-maint] Bug#928963: fixed in gnupg2 2.2.13-2
Hi Paul-- On Sat 2019-06-22 20:51:00 +0200, Paul Gevers wrote: > On Tue, 14 May 2019 06:18:31 +0000 Daniel Kahn Gillmor > wrote: >> gnupg2 (2.2.13-2) unstable; urgency=medium >> . >>* Correct gpg-wks-server manpage (Closes: #927431) Thanks, ju xor! >>* Fix handling private keys with comments (Closes: #928963, #928964) >>* clean up logcheck rules for gpg-agent (Closes: #918466) >>* Update gpg-wks-client.1 (Closes: #918586) >>* cherry-pick more patches from upstream STABLE-BRANCH-2-2 > > Is there any reason that we shouldn't want to unblock this for buster > (i.e. is there any reason why you didn't file an unblock bug request)? Filing an unblock for gnupg2 version 2.2.13-2 for buster is on my stack of things to do, but i'm quite far behind on other work. I do think it would be useful to have, and i welcome any help in filing such an unblock request. This change includes several upstream cleanup changes beyond the 2.2.12-1 that is in buster right now, in particular (from upstream's NEWS): * gpg: Implement key lookup via keygrip (using the & prefix). * gpg: Allow generating Ed25519 key from existing key. * gpg: Emit an ERROR status line if no key was found with -k. * gpg: Stop early when trying to create a primary Elgamal key. [#4329] * gpgsm: Print the card's key algorithms along with their keygrips in interactive key generation. * agent: Clear bogus pinentry cache in the error case. [#4348] * scd: Support "acknowledge button" feature. * scd: Fix for USB INTERRUPT transfer. [#4308] * wks: Do no use compression for the the encrypted challenge and response. Since the gnupg2 source produces a udeb for gpgv, there are likely to be additional hurdles to clearing the queue. :/ --dkg signature.asc Description: PGP signature
Bug#929916: libreswan: CVE-2019-12312
On Mon 2019-06-03 06:26:28 +0200, Salvatore Bonaccorso wrote: > Source: libreswan > Version: 3.27-4 > Severity: grave > Tags: patch security upstream fixed-upstream > Justification: user security hole > Forwarded: https://github.com/libreswan/libreswan/issues/246 > Control: fixed -1 3.28-1 > > The following vulnerability was published for libreswan. > > CVE-2019-12312[0]: > | In Libreswan before 3.28, an assertion failure can lead to a pluto IKE > | daemon restart. An attacker can trigger a NULL pointer dereference by > | sending two IKEv2 packets (init_IKE and delete_IKE) in 3des_cbc mode > | to a Libreswan server. This affects send_v2N_spi_response_from_state > | in programs/pluto/ikev2_send.c when built with Network Security > | Services (NSS). thanks for this heads-up, Salvatore. I'm working with upstream libreswan at patching this now, publishing my work on the debian/master branch in salsa. out of curiosity, how was this CVE applied for, and how was it coordinated? When I pointed it out to libreswan upstream on the freenode IRC #swan, it sounded like they had never heard of it. thanks for all you do for debian security! --dkg signature.asc Description: PGP signature
Bug#928963: giveback for monkeysphere 0.43-3 on ppc64, s390x, and sparc64
Hi Debian buildd maintainers for our 64-bit big-endian platforms! monkeysphere 0.43-3 FTBFS on ppc64, s390x, and sparc64. I traced the problem down to https://bugs.debian.org/928963 in GnuPG, which is now fixed upstream (https://dev.gnupg.org/T4501) and patched in debian unstable. This was a subtle bug in GnuPG's use of the GCrypt S-Expression string-assembling printf-style interface. On platforms where int and size_t are the same size, or on little-endian platforms where size_t is bigger than int, there was no problem. However, ppc64, s390x, and sparc64 all are "weird" enough that this subtle bug in GnuPG manifested itself there. With that issue fixed, monkeysphere builds and tests fine on s390x (i've tested directly on the porterbox zelenka.debian.org) and it should be fine on the other platforms as well. if you could poke your architecture's build daemon to give back monkeysphere 0.43-3, that would be great! All the best, --dkg signature.asc Description: PGP signature
Bug#928963: gpg-agent READKEY emits an invalid S-expression when private key file has comment (on 64-bit big-endian platforms)
Package: gpg-agent
Severity: serious
Version: 2.2.12-1
Control: found -1 2.2.13-1
Control: found -1 2.2.14-1
Control: found -1 2.2.15-1
Control: affects -1 src:monkeysphere
Control: tags -1 patch upstream
Control: forwarded -1 https://dev.gnupg.org/T4501
On sparc64, powerpc64, and s390x (debian's three 64-bit big-endian
platforms), gpg is unable to create a new OpenPGP certificate from some
secret keys that it already knows about.
In particular, "gpg --batch --generate" from a Key-Grip: line that
refers to a key file in private-keys-v1.d/ that contains a comment
sublist will fail with "Invalid S-expression" on those platforms.
This is due to a buggy invocation of gcry_sexp_build_array that is only
tickled when int is smaller than size_t and the platform is big-endian,
which causes the comment string to be set to zero length, which itself
is interpreted as an error of GPG_ERR_SEXP_ZERO_PREFIX.
However, this failure causes necessary functionality for
"monkeysphere-host import-key" as of monkeysphere version 0.43-3 to
break on these platforms, making monkeysphere FTBFS because the failure
is caught by its test suite.
The attached patch resolves the issue when i test it on
zelenka.debian.org (s390x), and should also work on the other two
platforms.
--dkg
From e4a158faacd67e15e87183fb48e8bd0cc70f90a8 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor
Date: Tue, 14 May 2019 00:05:42 -0400
Subject: [PATCH] agent: correct length for uri and comment on 64-bit
big-endian platforms
* agent/findkey.c (agent_public_key_from_file): pass size_t as int to
gcry_sexp_build_array's %b.
--
This is only a problem on big-endian systems where size_t is not the
same size as an int. It was causing failures on debian's s390x,
powerpc64, and sparc64 platforms.
There may well be other failures with %b on those platforms in the
codebase, and it probably needs an audit.
Once you have a key in private-keys-v1.d/$KEYGRIP.key with a comment
or a uri of reasonable length associated with it, this fix can be
tested with:
gpg-agent --server <<<"READKEY $KEYGRIP"
On the failing platforms, the printed comment will be of length 0.
Gnupg-bug-id: 4501
Signed-off-by: Daniel Kahn Gillmor
---
agent/findkey.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/agent/findkey.c b/agent/findkey.c
index 755a90be1..20c9dc56a 100644
--- a/agent/findkey.c
+++ b/agent/findkey.c
@@ -1366,6 +1366,7 @@ agent_public_key_from_file (ctrl_t ctrl,
gcry_sexp_t uri_sexp, comment_sexp;
const char *uri, *comment;
size_t uri_length, comment_length;
+ int uri_intlen, comment_intlen;
char *format, *p;
void *args[2+7+2+2+1]; /* Size is 2 + max. # of elements + 2 for uri + 2
for comment + end-of-list. */
@@ -1447,14 +1448,16 @@ agent_public_key_from_file (ctrl_t ctrl,
{
p = stpcpy (p, "(uri %b)");
assert (argidx+1 < DIM (args));
- args[argidx++] = (void *)_length;
+ uri_intlen = (int)uri_length;
+ args[argidx++] = (void *)_intlen;
args[argidx++] = (void *)
}
if (comment)
{
p = stpcpy (p, "(comment %b)");
assert (argidx+1 < DIM (args));
- args[argidx++] = (void *)_length;
+ comment_intlen = (int)comment_length;
+ args[argidx++] = (void *)_intlen;
args[argidx++] = (void*)
}
*p++ = ')';
--
2.20.1
signature.asc
Description: PGP signature
Bug#928684: [Pkg-privacy-maintainers] Bug#928684: monkeysphere-host import-key broken due to ssh-keygen change
Control: unarchive 909700 Control: forcemerge 909700 928684 Control: severity 909700 grave Hi Andrei-- On Wed 2019-05-08 20:45:24 +, Andrei Morgan wrote: > # monkeysphere-host import-key /etc/ssh/ssh_host_rsa_key > ssh://server.example.net > RSA.xs:194: OpenSSL error: no start line at /usr/bin/pem2openpgp line 1106, > line 1. > gpg: no valid OpenPGP data found. > # > > it appears that ssh-keygen is now producing -BEGIN OPENSSH PRIVATE > KEY- > headers which has lead to this no longer working. I believe it used to say > -BEGIN RSA PRIVATE KEY- instead. Thanks for this report. I'm not sure that a11y is an appropriate tag for this, since there is no specific accessibility concern here (see https://wiki.debian.org/accessibility), so i've removed that tag. I can confirm this behavior on a debian buster system and on a debian unstable system. It makes the "monkeysphere-host import-key" subcommand fail. This looks like it's the same issue as #909700, which was "fixed" only by changing the test suite to force creation of PEM files, which is why it was not caught earlier, sigh. So i'm merging this bug with the earlier 909700 and merging it and elevating the severity, since it has an effect on a newly-installed buster system. As a workaround, if you don't care about the existing RSA hostkey on your server, you can just re-generate it with: rm -f /etc/ssh/ssh_host_rsa_key /etc/ssh/ssh_host_rsa_key.pub ssh-keygen -t rsa -N '' -f /etc/ssh/ssh_host_rsa_key First step to a fix to the package is probably to "unfix" the test suite, to have it use the default key generation (you can follow it in /var/lib/dpkg/info/openssh-server.postinst). The correct fix is probably to rewrite "monkeysphere-host import-key" to avoid using keytrans. I think (though i haven't done the work yet) this can be done most flexibly for future reliability by rigging together OpenSSH's key management tools with GnuPG's key management tools. so something like this, which i haven't gotten to work fully yet: a) make an ephemeral GNUPGHOME directory, with "batch" in gpg-agent.conf b) launch gpg-agent in it, using gpconf --launch c) use ssh-add to import the secret key into gpg-agent's ssh-agent emulation using SSH_AUTH_SOCK=$(gpgconf --list-dir agent-ssh-socket) (gpg-agent.conf's "batch" suppresses gpg-agent's attempt to set a passphrase on the key during import). d) learn the associated keygrip from $GNUPGHOME/sshcontrol or $GNUPGHOME/private-keys-v1.d/ e) ask gpg --batch --full-generate-key to craft an openpgp certificate based on that existing key. this appears to be something like: Key-Type: RSA Key-Grip: $KEYGRIP Key-Usage: auth Name-Real: ssh://$HOSTNAME Expires: $EXPIRY %no-protection %commit f) export the secret key material in OpenPGP format (i'm running into trouble here as i try to test this) Alternately, perhaps we could do a-e above directly in /var/lib/monkeysphere/host, then we don't have to worry about the export and might be able to still use the key. The main differences from the current implementation here are: * this might allow us to handle non-RSA host keys, which is kind of nice * the generated certificate has certification capability (since gpg doesn't allow you to generate an OpenPGP certificate without that key usage flag set on the primary key) Thanks for the report! --dkg signature.asc Description: PGP signature
Bug#927255: powerpc-utils is uninstallable
Package: powerpc-utils Version: 1.3.2-1.1 Severity: grave Justification: renders package unusable Control: affects -1 grub-ieee1275 powerpc-utils Depends: pmac-utils, but pmac-utils is no longer in debian. This makes powerpc-utils uninstallable, which in turn makes grub-ieee1275 uninstallatble. --dkg -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: powerpc (ppc) Kernel: Linux 5.0.0-trunk-powerpc-smp (SMP w/1 CPU core) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages powerpc-utils depends on: ii pmac-utils 1.1.3-27 ii powerpc-ibm-utils 1.3.2-1.1 powerpc-utils recommends no packages. powerpc-utils suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#865967: backport to stretch
On Fri 2019-04-12 09:41:11 -0400, Jamie McClelland wrote: > Is it possible to back port this fix to debian stretch, stretch backports? I've uploaded trac-tags 0.9-3~bpo9+1 to stretch-backports just now. I think it has to go through the backports NEW queue before it's easily available. I've also pushed the debian/stretch-backports branch to the salsa repo at https://salsa.debian.org/python-team/applications/trac-tags.git in case you want to build it yourself on a stretch system. The backport was very straightforward. Regards, --dkg signature.asc Description: PGP signature
Bug#925596: Bug #925596 in irssi-plugin-xmpp marked as pending
Control: tag -1 pending Hello, Bug #925596 in irssi-plugin-xmpp reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debian/irssi-plugin-xmpp/commit/be9fdf999da38c4266e6b674adf62729dab6c553 capture irssi ABI dependency (Closes: #925596) (this message was generated automatically) -- Greetings https://bugs.debian.org/925596
Bug#925905: knot: d/copyright is severely incomplete
Package: 2.8.0-1 Severity: serious Flagging as serious because it's a policy violation. autotools files, and install-sh, in various directories not accounted for in d/copyright. distro/deb presumably is GPL-3+ without the SSL exception. contrib/ does not have the OpenSSL exception either ... is that code compiled into the main executable, or not? src/contrib has all sorts of licensing, most of which which is not accounted for in d/copyright. Copyright years for `Files: *` stanza need updating. src/contrib/ucw/lists.c is listed as GPL-3+? The original copyright date is before that license had been published. tests-fuzz/main.c has a different license. Copyright holders and licensing for tests/tap is wrong. It's not just Russ, and some of the files are GPL. Thanks to Sean Whitton for pointing this out! --dkg signature.asc Description: PGP signature
Bug#925596: irssi-plugin-xmpp: ABI mismatch with irssi 1.2.0-2
Package: irssi-plugin-xmpp Version: 0.54-2.1 Severity: grave Justification: renders package unusable I get the following warnings from irssi when trying to use it with irssi-plugin-xmpp: 10:49 -!- Irssi: xmpp/core is ABI version 13 but Irssi is version 20, cannot load 10:49 -!- Irssi: Error loading module xmpp/fe: /usr/lib/x86_64-linux-gnu/irssi/modules/libfe_xmpp.so: undefined symbol: xmpp_subscription 10:49 -!- Irssi: xmpp/core is ABI version 13 but Irssi is version 20, cannot load 10:49 -!- Irssi: Loaded module otr/core 10:49 -!- Irssi: Unknown chat protocol: XMPP I think we need at least a re-build, but we should really use this opportunity to take advantage of the exported ABI versioning irssi packaging exposes now that https://bugs.debian.org/811445 is resolved. The discussion on https://bugs.debian.org/772479 is probably relevant here too. I'll be taking a look at this, and will try to figure out a clean rebuild. --dkg -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_WARN 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) Versions of packages irssi-plugin-xmpp depends on: ii irssi1.2.0-2 ii libc62.28-8 ii libglib2.0-0 2.58.3-1 ii libloudmouth1-0 1.5.3-5 irssi-plugin-xmpp recommends no packages. irssi-plugin-xmpp suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#925374: closing 925374
close 925374 2019031302 thanks
Bug#925374: dns-root-data: ships an obsolete root zone signing key
Package: dns-root-data Version: 2018091102 Severity: serious Control: found -1 2014060201+2 2017072601~deb8u1 2017072601~deb8u2 2017072601~deb9u1 2017072601~deb9u1 Control: fixed -1 2019031302 The versions of dns-root-data marked as "found" above ship a hash for a root zone key that was retired earlier this month. I'm marking this as serious because it is the equivalent of shipping a certificate for a no-longer valid CA in ca-certificates. That key is no longer being used to sign anything that i have been aware of, and hopefully the private elements of it have been destroyed, but we shouldn't ship it any longer. Those of us on the dns team should have gotten this done earlier, but we all appear to have just missed it -- sorry about that! --dkg signature.asc Description: PGP signature
Bug#921904: win-iconv: FTBFS (wine: chdir to /tmp/wine-I6miLw/server-29-3583b06 : No such file or directory)
On Mon 2019-03-18 10:55:44 +0100, Tim Rühsen wrote: > Libiconv 1.15 itself from tarball. > > If you are interested in the details, have a look at our CI Dockerfile > where we build/install the dependencies needed for testing: > > https://gitlab.com/gnuwget/build-images/blob/master/docker-debian-mingw/Dockerfile interesting, thanks! If anyone else needs win-iconv in debian, please speak up! Otherwise i'll probably move forward with orphaning the package soon. --dkg
Bug#921904: win-iconv: FTBFS (wine: chdir to /tmp/wine-I6miLw/server-29-3583b06 : No such file or directory)
On Sun 2019-03-17 13:14:54 +0100, Tim Rühsen wrote: > Fixed it by building my own libiconv on MinGW systems. It really is > straight forward and possibly no extra Debian package is needed. Thanks for the feedback, Tim. For your fix, are you building libiconv itself, or win-iconv for MinGW systems? --dkg
Bug#921904: win-iconv: FTBFS (wine: chdir to /tmp/wine-I6miLw/server-29-3583b06 : No such file or directory)
Control: tags 921904 + help On Sat 2019-02-09 23:50:03 +, Santiago Vila wrote: > Package: src:win-iconv > Version: 0.0.8-2 > Severity: serious > Tags: ftbfs > > Dear maintainer: > > I tried to build this package in buster but it failed: > > > [...] > debian/rules build-indep > dh build-indep >dh_update_autotools_config -i >dh_auto_configure -i >debian/rules override_dh_auto_build-indep > make[1]: Entering directory '/<>' > for arch in x86_64-w64-mingw32 i686-w64-mingw32; do \ > mkdir -p build-$arch && \ > cd build-$arch && \ > ln -s ../*.h ../*.c ../*.def ../Makefile ./ && \ > /usr/bin/make CC=$arch-gcc AR=$arch-ar RANLIB=$arch-ranlib > DLLTOOL=$arch-dlltool prefix=/usr/$arch \ > || exit 1 ; \ > cd .. ; \ > done > make[2]: Entering directory '/<>/build-x86_64-w64-mingw32' > x86_64-w64-mingw32-gcc -g -O2 -fdebug-prefix-map=/<>=. -Wformat > -Werror=format-security -pedantic -Wall -DUSE_LIBICONV_DLL > -DDEFAULT_LIBICONV_DLL=\"\" -c win_iconv.c -DMAKE_DLL > x86_64-w64-mingw32-gcc -shared -o iconv.dll -Wl,-s > -Wl,--out-implib=libiconv.dll.a -Wl,--export-all-symbols win_iconv.o > x86_64-w64-mingw32-gcc -g -O2 -fdebug-prefix-map=/<>=. -Wformat > -Werror=format-security -pedantic -Wall -DUSE_LIBICONV_DLL > -DDEFAULT_LIBICONV_DLL=\"\" -c win_iconv.c > x86_64-w64-mingw32-ar rcs libiconv.a win_iconv.o > x86_64-w64-mingw32-ranlib libiconv.a > x86_64-w64-mingw32-gcc -g -O2 -fdebug-prefix-map=/<>=. -Wformat > -Werror=format-security -pedantic -Wall -DUSE_LIBICONV_DLL > -DDEFAULT_LIBICONV_DLL=\"\" -s -o win_iconv.exe win_iconv.c -DMAKE_EXE > make[2]: Leaving directory '/<>/build-x86_64-w64-mingw32' > make[2]: Entering directory '/<>/build-i686-w64-mingw32' > i686-w64-mingw32-gcc -g -O2 -fdebug-prefix-map=/<>=. -Wformat > -Werror=format-security -pedantic -Wall -DUSE_LIBICONV_DLL > -DDEFAULT_LIBICONV_DLL=\"\" -c win_iconv.c -DMAKE_DLL > i686-w64-mingw32-gcc -shared -o iconv.dll -Wl,-s > -Wl,--out-implib=libiconv.dll.a -Wl,--export-all-symbols win_iconv.o > i686-w64-mingw32-gcc -g -O2 -fdebug-prefix-map=/<>=. -Wformat > -Werror=format-security -pedantic -Wall -DUSE_LIBICONV_DLL > -DDEFAULT_LIBICONV_DLL=\"\" -c win_iconv.c > i686-w64-mingw32-ar rcs libiconv.a win_iconv.o > i686-w64-mingw32-ranlib libiconv.a > i686-w64-mingw32-gcc -g -O2 -fdebug-prefix-map=/<>=. -Wformat > -Werror=format-security -pedantic -Wall -DUSE_LIBICONV_DLL > -DDEFAULT_LIBICONV_DLL=\"\" -s -o win_iconv.exe win_iconv.c -DMAKE_EXE > make[2]: Leaving directory '/<>/build-i686-w64-mingw32' > make[1]: Leaving directory '/<>' >debian/rules override_dh_auto_test > make[1]: Entering directory '/<>' > cd build-x86_64-w64-mingw32 && > WINEPREFIX=/<>/build-x86_64-w64-mingw32/.wine /usr/bin/make > CC=x86_64-w64-mingw32-gcc AR=x86_64-w64-mingw32-ar > RANLIB=x86_64-w64-mingw32-ranlib DLLTOOL=x86_64-w64-mingw32-dlltool test > make[2]: Entering directory '/<>/build-x86_64-w64-mingw32' > x86_64-w64-mingw32-gcc -g -O2 -fdebug-prefix-map=/<>=. -Wformat > -Werror=format-security -pedantic -Wall -DUSE_LIBICONV_DLL > -DDEFAULT_LIBICONV_DLL=\"\" -s -o win_iconv_test.exe win_iconv_test.c > wine ./win_iconv_test.exe > it looks like wine32 is missing, you should install it. > multiarch needs to be enabled first. as root, please > execute "dpkg --add-architecture i386 && apt-get update && > apt-get install wine32" > wine: created the configuration directory > '/<>/build-x86_64-w64-mingw32/.wine' > wine: chdir to /tmp/wine-I6miLw/server-29-3583b06 : No such file or directory > make[2]: *** [Makefile:51: test] Error 1 > make[2]: Leaving directory '/<>/build-x86_64-w64-mingw32' > make[1]: *** [debian/rules:40: override_dh_auto_test] Error 2 > make[1]: Leaving directory '/<>' > make: *** [debian/rules:19: build-indep] Error 2 > dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit > status 2 > E: Build killed with signal TERM after 60 minutes of inactivity > > > (Additionally, the autobuilder hangs and sbuild has to kill remaining > processes) > > The build was made in my autobuilder with "dpkg-buildpackage -A" > and it also fails here: > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/win-iconv.html > > where you can get a full build log if you need it. > > If this is really a bug in one of the build-depends, please use reassign and > affects, > so that this is still visible in the BTS web page for this package. > > Thanks. Interesting. I can see the same behavior above (without the hanging) on my own cowbuilder instance. But building it directly on a dedicated amd64 VM, i see a completed run, (output at the end). I don't think the problem is "missing" wine32, because my run succeeds despite not having wine32 installed. I'm cc'ing the debian-wine mailing list in hopes that they can point to what's happening here.
Bug#911768: pinentry-gnome3 fails to open a window with 'No Gcr System Prompter available, falling back to curses'
Control: severity 911768 normal Hi Simon -- Thanks for this detailed triage! On Sun 2019-03-10 14:35:04 +, Simon McVittie wrote: > I think this should be considered to be a pinentry-gnome3 bug rather than > nfs-kernel-server. I think the plausible routes forward are to either > escalate dbus-user-session from Recommends to Depends, downgrade this bug > to non-RC (because not working completely reliably without Recommends is > not entirely unexpected), or consider it to be "not a bug" and close it > (same reason). escalating dbus-user-session to a Depends: for pinentry-gnome3 seems like a mistake to me (pinentry-gnome3 *should* work even on sytsems where dbus-user-session isn't installed, particularly on systems where there is no systemd session-manager), so i'm downgrading the severity at least here. What do others think? For the moment, i'm reducing severity to "normal" since it seems to only affect certain selections of packages in combination with certain system configurations. This is the worst kind of sticky issue for debian generally, because there is no clear way to apportion responsibility, and the intersection between the packages can fall through the cracks :( If someone can propose a concrete path forward that will resolve the problem for those folks who have it, i'd be happy to try to incorporate it. > It's a pity we can't make pinentry-gnome3 depend on something like > "dbus-user-session | not(libpam-systemd)". that would be nice, but it's still not the most robust, because of course you can have libpam-systemd installed and not have it listed in /etc/pam.d/common-session :/ > As a dbus upstream and Debian maintainer, I'd recommend installing > dbus-user-session, particularly if you have bits of infrastructure that > want to run one instance per (machine,uid) pair (typically user-services > started by `systemd --user`) and communicate via D-Bus. Note that gpg-agent itself, whether invoked as a systemd user-service or manually/automagically (as upstream prefers), is precisely one of these per (machine,uid) pair services. The main difference is that when gpg-agent is invoked as a systemd user-service, its lifetime terminates at the same time as the user session (because the systemd --user manager terminates it upon session close). When gpg-agent is invoked manually/automagically, it has no clear termination strategy, which means it may linger (sometimes with unlocked key material) well after session termination, if no other reaping mechanism is explicitly invoked. > dbus-user-session is entirely "glue" and doesn't contain significant > amounts of code. Depending how other packages' dependencies are set up > and how much progress has been made on fixing my 2016 mass-bug-filing > about dbus-launch (dbus-x11), installing dbus-user-session might let > you remove dbus-x11, which is larger than dbus-user-session. Is that > any help? :-) should we discourage these two packages (dbus-user-session and dbus-x11) from being co-installed somehow? > For what it's worth, I couldn't reproduce this bug by installing a fairly > minimal GUI system (xdm, xorg and openbox) plus pinentry-gnome3 and > gpg-agent in a test VM, purging dbus-user-session, and adding and > removing nfs-kernel-server. Can someone provide a minimal reproducer, starting from an empty VM? --dkg signature.asc Description: PGP signature
Bug#849308: state of wireguard mainline inclusion?
Hi Mika-- On Thu 2019-03-07 16:16:40 +0100, Michael Prokop wrote: > So sadly wireguard didn't make it into buster. :( yep, frustrating. but that was by design -- it isn't clear to me that the ecosystem will be happy with having a wide distribution of an outdated (2019) version running in 2021 :/, depending on what happens with the upstream inclusion work (which i can't currently predict). > Are there any plans for providing backports for stretch and/or buster? I do plan for putting wireguard into buster-backports, since i expect the upstream inclusion issues to be resolved one way or another by the time of bullseye release. If anyone wants to help out by adding it to stretch-backports-sloppy, i would welcome that. --dkg signature.asc Description: PGP signature
Bug#923970: libkres-dev: cannot build anything meaningful against libkres-dev
Package: libkres-dev Version: 3.2.1-1 Severity: grave Justification: renders package unusable A little over half of the header files shipped in libkres-dev contain an #include line that refers to other files in "lib/…", for example: #include "lib/defines.h" You can see these with: grep -n 'include "lib' /usr/include/libkres/*.h This breaks anything that tries to #include these files directly, with errors like this: gcc -o kres-test kres-test.c -lkres In file included from kres-test.c:1: /usr/include/libkres/module.h:23:10: fatal error: lib/defines.h: No such file or directory #include "lib/defines.h" ^~~ compilation terminated. make: *** [Makefile:4: kres-test] Error 1 Of the files that don't include such a broken #include, they are either not particularly useful on their own (e.g. /usr/include/libkres/defines.h) or they refer to functions not actually exported by libkres.so (e.g. /usr/include/libkres/signature.h, which exposes a C header for kr_authenticate_referral, which is not in libkres.so). So libkres-dev doesn't really work at all right now, and the distributed shared object libkres.so.* itself doesn't seem to be useful for anything other than knot-resolver. Upstream is planning to eventually produce some sort of functional library, but they're not clear on what it looks like: https://gitlab.labs.nic.cz/knot/knot-resolver/merge_requests/770 So i think my earlier attempt at splitting out libkres was overly optimistic, and will probably roll it back so that we're not shipping a useless package. When libkres matures, i'm sure we'll be able to split it out again! --dkg -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libkres-dev depends on: ii libkres9 3.2.1-1 libkres-dev recommends no packages. libkres-dev suggests no packages. -- no debconf information
Bug#920695: knot-resolver: uninstallable and FTBFS in stretch-backports
Control: severity 920695 important On Thu 2019-02-28 22:06:09 -0500, Daniel Kahn Gillmor wrote: > So i'm marking #920695 as fixed in 3.2.1-1 with the hope of getting all > of these migrations to move forward. I've tagged the shared git repo for both knot-dns and for knot-resolver source package stretch-backports releases. I've also published the relevant packages to https://people.debian.org/~dkg/knot-stretch-backports/ so that people can get access to them if they want them before stretch-backports is capable of taking them. In order to try to help the transition along, i'm reducing the severity of this bug report as well. If there's a serious objection to this severity reduction, please feel free to correct it back again, and explain what you think the right thing to do is. happy hacking, --dkg
Bug#920695: knot-resolver: uninstallable and FTBFS in stretch-backports
Control: 920695 fixed 3.2.1-1 I'm able to rebuild knot-resolver just fine on stretch, when i build 3.2.1-1 against a backported knot 2.7.6-2. I'll be uploading those to stretch-backports shortly, but they can't go in until they've reached testing. But knot won't go into testing untlik knot-resolver migrates, due to autopkgtests (see #922172), and knot-resolver itself won't migrate until this bug report is non-RC. heh, a tangled mess. So i'm marking #920695 as fixed in 3.2.1-1 with the hope of getting all of these migrations to move forward. --dkg signature.asc Description: PGP signature
Bug#923204: [pkg-gnupg-maint] Bug#923204: Bug#923204: gpg-agent has a false dependency on libpam-systemd
On Mon 2019-02-25 13:33:57 +0100, Werner Koch wrote: > On Sun, 24 Feb 2019 16:56, joshud...@gmail.com said: > >> gpg-agent --server or directly from .profile (ssh sessions) by >> gpg-agent --daemon. > > FWIW, actually gpg-agent is started on-demand from all tools requiring > it. To explicitly start it "gpgconf --launch agent" can and should be > used. On systems where you actually care about all processes terminating when you log out (which is most well-managed systems), you want something that can automatically spawn and reap per-user daemons as they're needed by the user. Users of GNU/Linux systems with systemd as the process supervisor can rely on libpam-systemd to manage user sessions successfully. That way, when you log out, your agent actually goes away, any secrets currently unlocked are flushed, and your overall session (and all related processes) terminates correctly. This allows things like automated unmounting of relevant filesystems, flushing of in-kernel keys, etc. There are many other possible ways to manage per-user daemons on other systems, but if you're already using systemd, it makes no sense to have each daemon re-invent that wheel (and potentially fail to clean up at the end of the session, as Werner's suggestion above does). That's why gpg-agent Suggests: libpam-systemd. If you want to propose better integration with any system or session managers that can be used in Debian (whether systemd or otherwise), i'm all ears -- please submit those changes to the BTS as specific improvements so that we can review them and make things better for users of those systems. Regards, --dkg signature.asc Description: PGP signature
Bug#911768: pinentry-gnome3 fails to open a window with 'No Gcr System Prompter available, falling back to curses'
Control: affects 911768 - gpg-agent Control: affects 911768 + gcr On Fri 2018-12-21 07:28:22 -0500, Theodore Y. Ts'o wrote: > On Thu, Dec 20, 2018 at 03:17:03PM -0500, Daniel Kahn Gillmor wrote: >> >> I wonder whether we can rule out any interaction with gpg-agent itself >> -- does "echo getpin | pinentry-gnome3" itself fall back to curses on >> your system when nfs-kernel-server is installed? > > I can confirm that that I did this experiment before I uninstalled > nfs-kernel-server --- and it fell back to curses. thanks! I think that takes gpg-agent out of the picture (a nice simplification in terms of debugging) but also implicates gcr itself, so i'm adjusting the "affects" tag. > The next experiment to do would be to reinstall nfs-kernel-server and > reboot --- and see if it falls back to curses again. Please report back if you do that experiment! thanks for following up, Ted. --dkg signature.asc Description: PGP signature
Bug#914944: [pkg-gnupg-maint] Bug#914944: gnupg: importing a key fails when there's no tty (regression from 2.1.18-8~deb9u2)
Control: forcemerge 913614 914944 Thanks for noting this, Lucas. On Thu 2018-11-29 00:12:05 +0100, Lucas Nussbaum wrote: > Importing the attached key fails when there's no tty. This is the same as #913614, merging. Note that #914032 proposes an update to stretch that fixes this regression. I've seen no feedback on #914032 yet, though. --dkg signature.asc Description: PGP signature
Bug#912092: impass FTBFS: FAIL decrypt db
Control: tags 912092 + patch
On Sun 2018-10-28 11:22:28 +0200, Adrian Bunk wrote:
> Some recent change in unstable makes impass FTBFS:
>
> https://tests.reproducible-builds.org/debian/history/impass.html
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/impass.html
I'm not convinced that this is a change in unstable -- it appears to be
a bug in the test suite, which is fixed by the attached patch.
--dkg
From 3e6b1fa16887f105adf35599c922b452f8af0af4 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor
Date: Tue, 27 Nov 2018 02:46:30 -0500
Subject: [PATCH 1/2] Fix test/library
We were trying to decrypt the database without any specific keyid.
This meant that the library was looking in ~/.impass/keyid, which was
causing the key selection to raise a failure.
---
test/library | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/test/library b/test/library
index 0963f35..8312e68 100755
--- a/test/library
+++ b/test/library
@@ -31,7 +31,7 @@ test_expect_equal_file OUTPUT EXPECTED
test_begin_subtest "decrypt db"
python3 - <&1 | sed "s|$IMPASS_DB|IMPASS_DB|" >OUTPUT
import impass
-db = impass.Database("$IMPASS_DB")
+db = impass.Database("$IMPASS_DB", '$IMPASS_KEYID')
print(db)
print(db.version)
print('foo@bar' in db)
--
2.19.2
signature.asc
Description: PGP signature
Bug#914269: google-i18n-address FTBFS: UnicodeDecodeError: 'ascii' codec can't decode byte 0xc4 in position 11
On Wed 2018-11-21 17:12:23 +0200, Adrian Bunk wrote: > Fails: > LC_ALL=C dpkg-buildpackage > > Builds: > LC_ALL=C.UTF-8 dpkg-buildpackage > > Python 3.7 has a workaround for C locale. > > In debian/rules add: > export LC_ALL=C.UTF-8 thank you, Adrian! I've lost count of how many beers i owe you, but $beers++ on me whenever we meet up :) (or alternate $beverages++ of your choice if you don't drink beer). regards, --dkg signature.asc Description: PGP signature
Bug#914269: google-i18n-address FTBFS: UnicodeDecodeError: 'ascii' codec can't decode byte 0xc4 in position 11
Control: tags 914269 + confirmed help I see this error in my cowbuilder instance as well, but i don't see the error when i build by hand on a buster/sid system. more confusingly, this error crops up in python3.6, but not when using python3.7 -- so i don't understand what the issue is, or how to debug it further. I welcome any pointers. --dkg signature.asc Description: PGP signature
Bug#913614: [pkg-gnupg-maint] Bug#913614: gnupg2 fails with "cannot open '/dev/tty': No such device or address"
Control: tags 913614 + patch
The attached patch resolves the issue, and also introduces a test to
ensure that the problem is (and remains) fixed.
--dkg
>From 2e3b6845ea6c4762e86d281bcf83bf0e84315d8c Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor
Date: Fri, 16 Nov 2018 00:38:40 -0500
Subject: [PATCH] Avoid crash when importing without a TTY (closes #913614)
We backport a fix from upstream that should probably have been
included with the fix that addressed #906545, but it was not, sigh.
Include a test that ensures this particular failure doesn't get
reintroduced.
---
...rfluous-sig-check-info-during-import.patch | 200 ++
debian/patches/series | 1 +
debian/rules | 6 +
debian/tests/control | 4 +
debian/tests/linus.key| 47
debian/tests/no-tty | 17 ++
6 files changed, 275 insertions(+)
create mode 100644 debian/patches/0094-gpg-Avoid-superfluous-sig-check-info-during-import.patch
create mode 100644 debian/tests/linus.key
create mode 100755 debian/tests/no-tty
diff --git a/debian/patches/0094-gpg-Avoid-superfluous-sig-check-info-during-import.patch b/debian/patches/0094-gpg-Avoid-superfluous-sig-check-info-during-import.patch
new file mode 100644
index 0..5440278c8
--- /dev/null
+++ b/debian/patches/0094-gpg-Avoid-superfluous-sig-check-info-during-import.patch
@@ -0,0 +1,200 @@
+From: Werner Koch
+Date: Thu, 15 Nov 2018 18:24:56 -0500
+Subject: gpg: Avoid superfluous sig check info during import.
+
+* g10/key-check.c (print_info): New.
+(key_check_all_keysigs): Print sig checking results only in debug
+mode. Prettify the stats info and suppress them in quiet mode.
+
+--
+
+This also makes usable stats by prefixing them with the key and the
+program name.
+
+GnuPG-bug-id: 3397
+Signed-off-by: Werner Koch
+
+(cherry-picked/backported from upstream
+84af859e391a757877c9a1d78e35face983e6d23 by dkg)
+
+Signed-off-by: Daniel Kahn Gillmor
+---
+ g10/keyedit.c | 133 +-
+ 1 file changed, 95 insertions(+), 38 deletions(-)
+
+diff --git a/g10/keyedit.c b/g10/keyedit.c
+index 3d6c5d4c4..bdeb251f9 100644
+--- a/g10/keyedit.c
b/g10/keyedit.c
+@@ -329,6 +329,26 @@ print_and_check_one_sig (KBNODE keyblock, KBNODE node,
+ }
+
+
++/* Print PREFIX followed by TEXT. With mode > 0 use log_info, with
++ * mode < 0 use ttyio, else print to stdout. If TEXT is not NULL, it
++ * may be modified by this function. */
++static void
++print_info (int mode, const char *prefix, char *text)
++{
++ char *p;
++
++ if (!text)
++text = "";
++ else if ((p = strchr (text,'\n')))
++*p = 0; /* Strip LF. */
++
++ if (mode > 0)
++ log_info ("%s %s\n", prefix, text);
++ else
++ tty_fprintf (mode? NULL:es_stdout, "%s %s\n", prefix, text);
++}
++
++
+
+ /* Order two signatures. The actual ordering isn't important. Our
+goal is to ensure that identical signatures occur together. */
+@@ -766,8 +786,9 @@ check_all_keysigs (KBNODE kb, int only_selected, int only_selfsigs)
+ has_selfsig = 1;
+ }
+
+-if ((n2 && n2 != last_printed_component)
+-|| (! n2 && last_printed_component != current_component))
++if (DBG_PACKET
++&& ((n2 && n2 != last_printed_component)
++|| (! n2 && last_printed_component != current_component)))
+ {
+ int is_reordered = n2 && n2 != current_component;
+ if (n2)
+@@ -779,31 +800,32 @@ check_all_keysigs (KBNODE kb, int only_selected, int only_selfsigs)
+ ;
+ else if (last_printed_component->pkt->pkttype == PKT_USER_ID)
+ {
+-tty_printf ("uid ");
+-tty_print_utf8_string (last_printed_component
+- ->pkt->pkt.user_id->name,
+- last_printed_component
+- ->pkt->pkt.user_id->len);
++log_debug ("uid ");
++print_utf8_buffer (log_get_stream (),
++ last_printed_component
++ ->pkt->pkt.user_id->name,
++ last_printed_component
++ ->pkt->pkt.user_id->len);
++log_flush ();
+ }
+ else if (last_printed_component->pkt->pkttype
+ == PKT_PUBLIC_KEY)
+- tty_printf ("pub %s",
+- pk_keyid_str (last_printe
Bug#913556: apt-show-versions: Max. recursion depth with nested structures exceeded
I ran into the same issue on a powerpc installation. On Mon 2018-11-12 17:16:10 +0100, Christoph Martin wrote: > please try for me to change the value in line 271 from 65536 to a higher > value which is high enough for your sources.list . When i changed from 65536 to 655360, the "apt-show-versions -i" went through without a problem. > What do you have in sources.list ? Only one repo on the entire machine (powerpc arch, so i have to use debian-ports these days): deb http://ftp.ports.debian.org/debian-ports sid main maybe some platforms have bulkier hash data structures? it wouldn't surprise me if amd64 had better memory optimization under perl than a marginal arch like powerpc. --dkg signature.asc Description: PGP signature
Bug#906843: xul-ext-custom-tab-width no longer works with firefox-esr 60
On Wed 2018-10-03 17:20:02 +0200, Moritz Mühlenhoff wrote: > This is dead upstream and broken even in ESR, let's remove it > from the archive? agreed, i've just filed a RM/ROM bug report (#913215) on custom-tab-width. --dkg
Bug#911768: [pkg-gnupg-maint] Bug#911768: pinentry-gnome3 fails to open a window with 'No Gcr System Prompter available, falling back to curses'
Hi Tiziano--
thanks for following up here! I'm closing the bug report as you
recommended, but i wanted to add a little more followup in case someone
else reads this.
On Thu 2018-10-25 13:03:12 +0200, Tiziano Zito wrote:
> It has nothing to do with pinentry. Given that I have a system with almost
> identical setup without dbus-user-session where everything works, and given
> that
> installing dbus-user-session in the affected system fixed the issue, I
> started
> digging deeper.
I'm glad to hear that installing dbus-user-session fixed the issue. I'm
inclined to make dbus-user-session a hard Depends: of pinentry-gnome3
instead of a Recommends: to avoid future problems like this. What would
you think of that change?
> For the record, in case in the future anyone hits the same problem: The only
> difference between the affected system and the working one was that the
> affected
> system starts nfs-kernel-server.service on boot. This was not only delaying
> the
> boot process (whish is somewhat expected) but additionaly the order changed
> in
> which systemd services were started, resulting in a different order than the
> one
> in the working system. I couldn't pin down exactly what service was the
> problematic one, but disabling the nfs-kernel-server.service fixed the
> pinentry
> issue...
this is strange to me, because i think nfs-kernel-server.service is a
system service, and gpg-agent.{service,socket} (from the gpg-agent
package) and dbus.{service,socket} (from the dbus-user-session package)
are user services -- they shouldn't have any direct interaction, and
they're actually managed by entirely different systemd instances.
> Given that installing dbus-user-session fixed the issue independent of
> nfs-kernel-server being enabled or not, I assume that the problem may be due
> to
> gpg-agent starting *before* dbus in the non dbus-user-session scenario, but I
> am
> only guessing.
This does seem possible to me, but i don't understand how it would
interact with nfs-kernel-server.service unless there is some sort of
more general operating system race condition.
At any rate, i'm glad to hear that dbus-user-session fixed the issue for
you! do you have any reason that you don't want to just leave it
installed?
Thanks for all the debugging and documentation!
--dkg
signature.asc
Description: PGP signature
Bug#911768: [pkg-gnupg-maint] Bug#911768: pinentry-gnome3 fails to open a window with 'No Gcr System Prompter available, falling back to curses'
Hi Tiziano-- On Wed 2018-10-24 17:24:33 +0200, Tiziano Zito wrote: > pinentry-gnome3 (but also pinentry-gtk-2) does not open a window anymore to > ask for a passphrase. If run from terminal it shows: > > No Gcr System Prompter available, falling back to curses > OK Pleased to meet you > > It was working fine since years. Of the packages pinentry-gnome3 depends on, > I have only upgraded recently libgpg-error0, libncursesw6, libtinfo6. > Even downgrading libgpg-error0 to 1.32-1 does not fix the issue. hmm, looking at the installed packages: > Versions of packages pinentry-gnome3 depends on: > ii gcr 3.28.0-1 > ii libassuan0 2.5.1-2 > ii libc62.27-6 > ii libgcr-base-3-1 3.28.0-1 > ii libglib2.0-0 2.58.1-2 > ii libgpg-error01.32-3 > ii libncursesw6 6.1+20181013-1 > ii libsecret-1-00.18.6-3 > ii libtinfo66.1+20181013-1 > > Versions of packages pinentry-gnome3 recommends: > pn dbus-user-session can you try installing dbus-user-session, then log out and log back in and let me know whether it works in that case? Regards, --dkg signature.asc Description: PGP signature
Bug#909000: [Pkg-mozext-maintainers] Bug#909000: Enigmail 2.0 needed in Stretch after Thunderbird 60 upload
Control: clone 909000 -2 Control: retitle -2 apt: error message "apt install enigmail" failure is misleading Control: reassign -2 apt 1.4.8 Control: severity -2 minor On Mon 2018-10-22 08:28:50 -0400, Fabián Rodríguez wrote: > This also fails in a clean Stretch install: > > # apt install enigmail > Reading package lists... Done > Building dependency tree > Reading state information... Done > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help to resolve the situation: > > The following packages have unmet dependencies: > enigmail : Depends: thunderbird (>= 1:52.0) but it is not going to be > installed or > icedove (>= 1:52.0) > E: Unable to correct problems, you have held broken packages. I just want to note that this error message specifically appears to be a bug in apt -- the reason apt won't let you install enigmail is because the version of thunderbird in debian-security stretch/updates (thunderbird 1:60.0) is marked with: Breaks: enigmail (<< 2:2~) That's correct, because versions of enigmail prior to 2.0 do not work on thunderbird 60 any longer. it would be nice if apt improved the reporting here, to identify that the cause of the problem is a conflict between the currently installed version of thunderbird, and the desired version of enigmail. Compare the differences with neither thunderbird nor enigmail installed: root@stretch:~# apt install enigmail Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: enigmail : Depends: thunderbird (>= 1:52.0) but it is not going to be installed or icedove (>= 1:52.0) E: Unable to correct problems, you have held broken packages. root@stretch:~# apt install enigmail thunderbird Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: thunderbird : Breaks: enigmail (< 2:2~) but 2:1.9.9-1~deb9u1 is to be installed E: Unable to correct problems, you have held broken packages. root@stretch:~# the latter error message is clearly the correct one, but it doesn't show in the former attempt. --dkg signature.asc Description: PGP signature
Bug#909000: [Pkg-mozext-maintainers] Bug#909000: Thunderbird 60 cannot STILL be at stretch normal repository
On Tue 2018-10-16 12:05:33 +0200, Carsten Schoenert wrote: > yes, the problem here is Enigmail, not Thunderbird! But I don't see that > this as a vulnerability per se from a security perspective. > And you still can install the Mozilla AddOns manually into FF and TB. > It's a loosing of comfort and easy usage of the system provided > packages, but not more for the typical single user cases on a machine or > laptop. fwiw, the version of enigmail that you get from the Mozilla addons store has what i consider to be pretty serious problems: * it downloads and executes binaries from the web on behalf of the user (its "pEp" mode) without any form of verification beyond https certificate validation. * it contains a bundle of OpenPGP.js, which doesn't appear to be easily buildable (or modifiable) from source, so it's not free software in the sense that debian cares about. I don't think we want to encourage people to do that. > And happily dkg is taking this challenge really seriously! Thanks for the vote of confidence, Carsten! :) > And being not able to send automated encrypted email is not a > vulnerability as you still can use gpg on the command line and encrypt > your content obviously with less comfort, and it's your decision. And > again, you can still install Enigmail from upstream. So hey, that's life. fwiw, i don't consider encryption from the command line to be a substitute for proper integration with your mail user agent. If you do that, you're also likely forcing your peers to do the same thing, and it's really easy to screw it up on one side or the other. So this situation really is a security issue for some people, who are losing the capacity to send and receive encrypted e-mail. There are people who, if their mail is forced back into cleartext, run risks with potential consequences ranging from loss of employment to loss of liberty or even loss of life. I really hope debian can get this sorted out for the next stable point release at the latest. thanks to everyone for their constructive help getting it done! --dkg signature.asc Description: PGP signature
Bug#909837: bug 909837 is forwarded to https://github.com/libreswan/libreswan/issues/206, closing 909837
forwarded 909837 https://github.com/libreswan/libreswan/issues/206 close 909837 3.27-1 thanks
Bug#872806: [pkg-gnupg-maint] Bug#872806: libgpg-error0 packs runtime support files in shared library
On Fri 2018-10-12 12:36:12 +0200, Sven Joachim wrote: > Control: tags -1 + patch thank you, Sven and Helmut for your attention to this kind of detail. I'm preparing an upload with these changes. Y'all rock! --dkg
Bug#909000: Thunderbird 60 cannot be at stretch normal repository
On Wed 2018-10-10 17:30:33 +0200, Narcis Garcia wrote: > The good solution for this is to move Thunderbird 60 to > stretch-backports instead of being at normal repository. > > Normal users will keep current Enigmail 2:1.9 , current Thunderbird 1:52 > and current GnuPG 2.1 and not unstable repositories. > > Other users will be allowed to use stretch-backports to upgrade to > Thunderbird 1:60 , Enigmail 2:2.2 and GnuPG 2.2 when all available. > > No packages break, no Enigmail loss for unexperienced users. i haven't heard anyone from debian say that they're up for maintaining/supporting thunderbird 52 in stretch. do you know anyone who is volunteering for that task? if there isn't anyone, then moving to TB 60 in stretch is probably pretty important, while it also requires all the rest of the maintenance work described upthread. Software maintenance within the context of an active network and complex upstreams is hard :( --dkg
Bug#909000: Enigmail 2.0 needed in Stretch after Thunderbird 60 upload
On Mon 2018-10-08 16:05:39 +0200, W. Martin Borgert wrote: >> In the meantime, for enigmail, i've pushed a debian/stretch branch into >> salsa with commit id b6e978d64af1defdfed876b09c8a57acb796ad72 as > > Did you push? I can't find the id. I would like to test. thanks for testing! it appears that i failed to push earlier, but it should now be pushed to salsa. > Btw. having it in bpo9 would be very good. I know, that this is abuse of > backports. But whatever we do, it's better than letting users install > via "Add-ones Manager". the trouble with putting the updated enigmail in bpo9 is that it depends on the fixes for GnuPG (see #910398) -- it will fail in pretty nasty (and sometimes subtle) ways unless and until those changes are available. I'd love to hear other suggestions for how to do this, but i don't see any better options than the approach outlined here, unfortunately. I'd be thrilled if someone else has a better approach. --dkg
