Bug#1013318: [pkg-gnupg-maint] Behavioral change for pinentry-qt 1.2.0-1

2022-06-23 Thread Daniel Kahn Gillmor
On Thu 2022-06-23 12:24:30 +0200, Gard Spreemann wrote:

> Just needed to wait for my account to be approved. It's done now:
> https://dev.gnupg.org/T6041

Thanks for this!  On that bug report, Ingo linked it to this proposed
patch from qlyiss on https://dev.gnupg.org/D549 :


Index: qt/pinentrydialog.cpp
===
--- qt/pinentrydialog.cpp
+++ qt/pinentrydialog.cpp
@@ -280,6 +280,7 @@
 mainLayout->addLayout(hbox);
 mainLayout->addStretch(1);
 mainLayout->addWidget(buttons);
+mainLayout->setSizeConstraint(QLayout::SetFixedSize);
 
 auto capsLockWatcher = new CapsLockWatcher{this};
 connect(capsLockWatcher, ::stateChanged,


This seems much more narrowly targeted!  Gard, can you test this against
1.2.0?  If you can confirm that it works for you, i'd be happy to patch
the debian package.

--dkg


signature.asc
Description: PGP signature


Bug#998848: thunderbird: please build against librnp-dev (and Depend: on librnp0) directly

2022-06-18 Thread Daniel Kahn Gillmor
On Thu 2022-06-16 20:37:24 +0200, Carsten Schoenert wrote:
> Will do this the next time I import a new upstream version, but my guess 
> is we can simply remove them now.

Sounds like a good plan to me.  Thanks again for doing this work,
Carsten.  I'm running thunderbird from experimental right now, and I
haven't noticed any new problems with it so far.

 --dkg


signature.asc
Description: PGP signature


Bug#998848: thunderbird: please build against librnp-dev (and Depend: on librnp0) directly

2022-06-15 Thread Daniel Kahn Gillmor
On Wed 2022-06-15 18:04:09 +0200, Carsten Schoenert wrote:
> 2) What is needed to modify in the upstream configure script voodoo so
> its possible to use the configure options
>
>   --with-system-botan
>   --with-system-bz2
>   --with-system-jsonc

Is it possible that these three flags aren't relevant any longer
*because* we're using the system rnp?

in comm/third_party/openpgp.configure i see the tests for those options
bracketed within a block that begins:
 
-
with only_when(in_tree_librnp):
-

And i don't see those options anywhere else in the codebase.

It would make sense if those options shouldn't be supplied at all any
longer when we're using the system rnp, and i'd expect that the updated
thunderbird wouldn't acquire any new dependencies from omitting those
changes.

I'd guess that you can probably also remove the build-deps on:

libbotan-2-dev
libbz2-dev
libjson-c-dev

And the build should complete without an error, but i haven't tested it
myself.

Thank you very much for working on this, Carsten!

--dkg


signature.asc
Description: PGP signature


Bug#998848: thunderbird: please build against librnp-dev (and Depend: on librnp0) directly

2022-06-15 Thread Daniel Kahn Gillmor
Hi Carsten--

On Sun 2022-06-12 17:15:08 +0200, Carsten Schoenert wrote:
> Am Sat, Mar 26, 2022 at 04:06:46PM -0400 schrieb Daniel Kahn Gillmor:
>> I've just uploaded rnp 0.16.0 into debian unstable.  According to
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1732809 the main
>> development line of thunderbird now has a --with-system-rnp flag (but
>> the 91esr series doesn't have it.
>> 
>> So when new versions of thunderbird get built in debian (in experimental
>> first, maybe?) please try to use --with-system-rnp.  If you run into any
>> reason why building against the system rnp isn't working, please don't
>> hesitate to file bug reports against rnp and we'll sort them out.
>
> after again months of waiting for some typical build tools and a lot of
> try and errors attempts I'm now able to build the current beta version
> of Thunderbird (102.0~b4) together with the system package of
> librnp-dev.

that's great news!  thanks for doing this.

> The downside is that this requires currently the usage of the internal
> version of botan, bz2 and jsonc.
>
> I've no kowledge if upstream has plans to reenable the usage of system
> packages for these tools, maybe it's also just a misconfiguration of the
> buildsystem.

Ugh, that doesn't sound so reasonable.  I'd expect those libraries to be
internal to librnp, and not directly exposed to the rest of thunderbird.
so they shouldn't be related to the build process at all, afaict.

Have you reported this upstream at all?  do you have examples of the
build failures that happen when you use the system librnp that we could
work through and post where upstream can see them?

 --dkg


signature.asc
Description: PGP signature


Bug#1011505: transition: gpgme1.0

2022-05-23 Thread Daniel Kahn Gillmor
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: d...@fifthhorseman.net, delta...@debian.org

The only packages that need to be rebuilt against this soname bump are
part of KDE, specifically these binary packages:

 accountwizard
 kdepim-addons
 kget
 kleopatra
 kmail
 libkf5libkleo5
 libkf5mailcommon5abi2
 libkf5messagecomposer5abi1
 libkf5messagecore5abi1
 libkf5messageviewer5abi1
 libkf5mimetreeparser5abi1

These come from the following sources:

 kdepim-addons
 kf5-messagelib
 kget
 kleopatra
 kmail
 kmail-account-wizard
 libkf5libkleo
 libkf5mailcommon

Patrick Franz (in Cc) from the KDE team tested them and reported that
they build cleanly with an NMU (see attached message).

Release team, please ACK so i can proceed with the upload to unstable.

Regards,

--dkg


Ben file:

title = "gpgme1.0";
is_affected = .depends ~ "libqgpgme7" | .depends ~ "libqgpgme15";
is_good = .depends ~ "libqgpgme15";
is_bad = .depends ~ "libqgpgme7";
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to
 :references:mime-version:content-transfer-encoding;
bh=oeVrgfF5zWr7ctjic7dVLveRG26Sy0vaKyFu8vQ1Xpo=;
b=g4a5KhJl1Z86Zo5WyqUkuDiZzLvD2ag98UswCzkP/nG8i0tFIglylY0HD1SVg7N+2y
 r+vYb3xuRohGxwSPPZTBWEERpIzMXVwg0qVHdwjvpHWLV21T2OmEwB1r3iLcYHURIOZX
 0aIcaZwSFn7fXBhjYdXRllAi4UzBT87wgo5aTNbrgveYkmuETd2fWnlWt+rdXUnLZtWb
 yNFjOePrrp+2yAQl5vVLno5ljNwvoK3wkJNtPNqX3opWRJRvTKMod2tHXNa1lCVZ86rn
 LXGtxd7EWsVYfTPfJEHFac2ApJpF8PDR1qII9qxXVsKzMrUG0g1RmfCg+D4fCPWgSPlU
 VTuw==
X-Gm-Message-State: AOAM5316WPFtNxI4QQZw4IxqiNBw7n9VbWHLp6yREKH7KwRzmsmJgmWp
gJPDL3BGOlXPpHuJIBOiJQc=
X-Google-Smtp-Source: 
ABdhPJxtTiLSLkyyEU6xbiBlvNXUhN9FH1qGtHs3aTU30OPqODvCX44FW7qW+5V2/w40TEvQxue0Tw==
X-Received: by 2002:a2e:a5ca:0:b0:253:c604:647c with SMTP id 
n10-20020a2ea5ca00b00253c604647cmr11071204ljp.403.1653237143884;
Sun, 22 May 2022 09:32:23 -0700 (PDT)
Received: from delta-one.localnet (217-210-33-15-no2104.tbcn.telia.com. 
[217.210.33.15])
by smtp.gmail.com with ESMTPSA id 
bi23-20020a05651c231700b00253dfbe2522sm1080181ljb.100.2022.05.22.09.32.22
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sun, 22 May 2022 09:32:23 -0700 (PDT)
From: Patrick Franz 
To: debian-qt-...@lists.debian.org, Daniel Kahn Gillmor 
Subject: Re: rebuilding against libqgpgme-dev (soname bump from libqgpgme7 to 
libqgpgme15)
Date: Sun, 22 May 2022 18:32:21 +0200
Message-ID: <1831765.tdWV9SEqCh@delta-one>
In-Reply-To: <87zgjbficl@fifthhorseman.net>
References: <87zgjbficl@fifthhorseman.net>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass (srs.pair.com ... _spfmailwash.pair.com: 209.68.5.116 is 
authorized to use 'SRS0=GHde=V6=gmail.com=deltaone.deb...@srs.pair.com' in 
'mfrom' identity (mechanism 'ip4:209.68.0.0/18' matched)) 
receiver=mailwash52.pair.com; identity=mailfrom; 
envelope-from="SRS0=GHde=V6=gmail.com=deltaone.deb...@srs.pair.com"; 
helo=itihasa.pair.com; client-ip=209.68.5.116
X-Virus-Check-By: mailwash52.pair.com
X-Scanned-By: mailmunge 3.07 on 66.39.2.52
Delivered-To: d...@fifthhorseman.net
X-Scanned-By: mailmunge 3.07 on 66.39.2.52
Delivered-To: daniel_gill...@fifthhorseman.net
X-Envelope-To: daniel_gill...@fifthhorseman.net

Hi Daniel,

Am Samstag, 21. Mai 2022, 09:35:54 CEST schrieb Daniel Kahn Gillmor:
> I think the following 8 source packages will need a rebuild:
>=20
> kdepim-addons
> kf5-messagelib
> kget
> kleopatra
> kmail
> kmail-account-wizard
> libkf5libkleo
> libkf5mailcommon
>=20
> Let me know what you think is a good plan here,

I rebuilt those packages against gpgme 1.17 in experimental and all of=20
them built successfully without the need of adjusting anything.

So I'd suggest you simply request a transition and state that all these=20
packages build against gpgme 1.17 and only need NMUs.


=2D-=20
Med v=C3=A4nliga h=C3=A4lsningar

Patrick Franz




Bug#1011388: ITP: sequoia-wot -- Authenticate OpenPGP certificates using the "Web of Trust"

2022-05-21 Thread Daniel Kahn Gillmor
Package: wnpp
Severity: wishlist
Owner: Daniel Kahn Gillmor 
X-Debbugs-Cc: debian-de...@lists.debian.org, d...@fifthhorseman.net

* Package name: sequoia-wot
  Version : 0.2.0
  Upstream Author : Neal H. Walfield 
* URL : https://gitlab.com/sequoia-pgp/sequoia-wot
* License : LGPL 2.0 or later
  Programming Lang: Rust
  Description : Authenticate OpenPGP certificates using the "Web of Trust"

The "Web of Trust" describes a network of identity assertions
("OpenPGP certifications") and signing delegations ("OpenPGP trust
signatures"), which can be used to formally validate identity
information in a cryptographic certificate.

In particular, this tooling allows the user to associate OpenPGP User
IDs (or simply the e-mail address part of the User ID) with some set
of OpenPGP certificates on the basis of explicit certifications made
by trusted parties.

The validation rules and certificate formats used in the Web of Trust
support corroborative, multiparty certification, so there is no need
to assign full trust to any single party.

This tooling offers a means to explore the Web of Trust by a library
in Rust, and a command-line interface capable of working with either
certificates in the filesystem or interacting with GnuPG's certificate
store and trust database.



Bug#1010491: ruby-kramdown: 2.4 is available upstream

2022-05-02 Thread Daniel Kahn Gillmor
Package: ruby-kramdown
Version: 2.3.1-4
Severity: wishlist
Control: affects -1 + src:ruby-kramdown-rfc2629

Hi Ruby team--

The kramdown gem version 2.4 is available upstream.  The
kramdown-rfc2629 gem now depends on version 2.4 (as of kramdown-rfc
1.6.7; debian is at 1.6.6), so it'd be great to have ruby-kramdown
updated in debian.

Thanks!

--dkg


signature.asc
Description: PGP signature


Bug#992415: [pkg-gnupg-maint] Bug#992415: pinentry-tty: Segfault as host is entering S3/S0ix

2022-04-28 Thread Daniel Kahn Gillmor
Control: tags 992415 + moreinfo unreproducible

Hi Andrew--

On Wed 2021-08-18 19:15:22 +0930, Andrew Savchenko wrote:
> After issuing `systemctl suspend`, pinentry segfaults with the following
> output in the dmesg:
>
> ```
> kern  :info  : [Aug18 21:14] pinentry-tty[140518]: segfault at 0 ip
> 7f395bd5a217 sp 7ffe29e70310 error 4 in
>
> libc-2.31.so[7f395bd0b000+14b000] kern  :info  : [  +0.11] Code: 89
> 23 85 c0 75 d4 e9 2b ff ff ff 0f 1f 84 00 00 00 00 00 e8 3b ad 00 00 e9
> f9 fe ff ff e8 11 94 09 00 90 41 54 55 48 89 fd 53 <8b> 07 f6 c4 20 0f
> 85 ee 00 00 00 89 c2 81 e2 00 80 00 00 0f 84 ed
> ```

I tried to replicate this under qemu on debian unstable with pinentry
1.1.0-4 and did not see the behavior you're describing.

Here's what I did:

 - launch a debian x86_64 qemu/kvm-based guest 

 - as a non-privileged user, connected to it via ssh, ran "pinentry-tty"
   -- in that console, i typed "getpin" (got a prompt "PIN: ")

 - while waiting on that prompt, as the superuser, i did "systemctl
   suspend"

 - the qemu guest froze, and from its monitor port, i ran
   "system_wakeup"

 - the system unfroze, and i was able to continue entering my PIN, and
   pinentry-tty behaved as expected.

 - there was nothing in the dmesg to indicate any problem.

Are you able to help replicate this?

--dkg


signature.asc
Description: PGP signature


Bug#970378: [pkg-gnupg-maint] Bug#970378: pinentry: Add pinentry-efl package

2022-04-28 Thread Daniel Kahn Gillmor
Hi Efraim--

On Tue 2020-09-15 12:17:51 +0300, Efraim Flashner wrote:
> In upstream there is now merged support for pinentry with using EFL as the
> graphical toolkit. I have been using it on my Debian machine for several
> days now and on other machines for months. The attached patch to the
> source comes straight from upstream and I put together the Debian bits
> based on the other files in the debian/ directory.

A very belated thank you for offering these changes to the debian
packaging to enable the pinentry-efl package. (in
https://bugs.debian.org/970378)

Now that pinentry-efl is actually part of upstream directly, and debian
unstable has pinentry 1.2.0, i'm looking into enabling this (when we do
eventually enable it, it'll have to go through the NEW queue because of
the additional binary package created).

You can see my merge of your patch on the debian/WIP-pinentry-efl branch
on https://salsa.debian.org/debian/pinentry.

However, i'm not prepared to release it into debian now, because it's
not behaving the way i'd expect -- i've opened
https://dev.gnupg.org/T5955 upstream to report the issue.  If you have a
chance to review that issue and give feedback (either on the upstream
bugtracker, or here in this issue), i'd appreciate any suggestions on
how to bring this up to parity with the other pinentries so we can
include it in debian.

Regards,

--dkg


signature.asc
Description: PGP signature


Bug#969330: libpam-ssh-agent-auth: Authentication fails a random number of times before succeeding when ED25519 keys are used.

2022-04-28 Thread Daniel Kahn Gillmor
Control: forwarded 969330 https://dev.gnupg.org/T5682
Control: close 969330 2.2.34-1

On Wed 2022-02-02 23:40:28 +, Chris Boot wrote:
> This bug actually appears to be in GnuPG itself, not 
> libpam-ssh-agent-auth. Please see my comments at the end of 
> https://github.com/jbeverly/pam_ssh_agent_auth/issues/28.
>
> The bug is fixed in GnuPG 2.3.4 and 2.2.33 with the following changelog 
> entry for both:
>
>* scd: Support longer data for ssh-agent authentication with openpgp
>  cards.  [T5682]
>
> This corresponds to the following GnuPG bug:
>
> https://dev.gnupg.org/T5682
>
> Please update GnuPG to 2.2.33 or 2.3.4.

Thanks for reporting this, Alexander, and for tracking it down, Chris.
Should be resolved with the recent uploads of 2.2.34 and 2.2.35 to
debian unstable.

   --dkg


signature.asc
Description: PGP signature


Bug#1009311: [pkg-gnupg-maint] Bug#1009311: dirmngr: should no longer use keys.openpgp.org by default

2022-04-28 Thread Daniel Kahn Gillmor
Control: tags 1009311 + wontfix

Hi Vincent--

On Mon 2022-04-11 16:18:45 +0200, Vincent Lefevre wrote:
> The default https://keys.openpgp.org:443 key server is no longer working:
>
> $ gpg -v --recv-keys 7CA7ECAAF06216B90F894146ACF8146CAE8CBBC4
> gpg: data source: https://keys.openpgp.org:443
> gpg: pub  rsa2048/ACF8146CAE8CBBC4 2019-01-02  
> gpg: key ACF8146CAE8CBBC4: new key but contains no user ID - skipped
> gpg: Total number processed: 1
> gpg:   w/o user IDs: 1
>
> https://superuser.com/questions/1485213/gpg-cant-import-key-new-key-but-contains-no-user-id-skipped
> says: "You are probably using the keys.openpgp.org keyserver, which
> has an owner approval system – it will strip all user IDs unless
> the owner of the corresponding email address has allowed them to be
> published. Try to download the key from elsewhere [...]"
>
> The consequence is that when I want to check a signature made with
> this key, I get:
>
> gpg: Signature made 2022-04-09T21:49:20 CEST
> gpg:using RSA key 7CA7ECAAF06216B90F894146ACF8146CAE8CBBC4
> gpg: Can't check signature: No public key

Upstream's preferred default keyserver, hkps://keyserver.ubuntu.com runs
a hockeypuck installation, which distributes arbitrarily large OpenPGP
certificates.  That keyserver is vulnerable to flooding attacks (see
https://datatracker.ietf.org/doc/draft-dkg-openpgp-abuse-resistant-keystore/
for more detail)

For example, consider trying to fetch GnuPG upstream (Werner Koch)'s old
OpenPGP certificate from the upstream-preferred default keyserver:
0x80615870F5BAD690333686D0F2AD85AC1E42B367 (or try fetching my own
expired key 0xC4BC2DDB38CCE96485EBE9C2F20691179038E5C6 for that matter).
The upstream preferred keyserver will push tens of megabytes to you of
flooded key material.  Recent versions of GnuPG will discard almost all
of that data (gpg's dirmngr defaults to importing self-sigs only so that
a flooded certificate doesn't make your local keyring unusable as well),
but the transmission alone will still cost the user in terms of
bandwidth, latency, and battery life.

Anyone who wants to can flood any key on the upstream-preferred default
keyserver, just by pushing additional third-party certifications.

keys.openpgp.org is significantly more conservative: public key material
will show up there, as will revocations and subkey material.  but user
id information is only distributed if the user has responded to an
e-mail feedback request from the operators of keys.openpgp.org
confirming their intent to publish the User ID that contains that e-mail
address.

So we have two choices to compare between:

a) a default keyserver that is willing to publish any user ID
   information, but also permits arbitrarily flooded certificates.

b) a default keyserver that only publishes self-signed material, but
   won't distribute User IDs unless the e-mail account holder has
   explicitly signalled their intent to publish to that keyserver.

Given the bandwidth costs and potential for severe DoS on any user
associated with (a), (b) appears to be a more stable and responsible
default.

If another keyserver operator offers a different value proposition that
is better than either (a) or (b), i'm willing to consider it as a default
for debian.  Or, if someone else wants to take over the packaging of
GnuPG in debian, and they see the comparative advantage differently, i'd
be happy to let them make the decision.

   --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

2022-04-28 Thread Daniel Kahn Gillmor
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#1010171: sbuild's "unshare" test fails with gpg-agent 2.2.34-1

2022-04-27 Thread Daniel Kahn Gillmor
Control: reopen 1010171
Control: reassign 1010171 src:gnupg2 2.2.34-1
Control: affects 1010171 + sbuild
Control: tags 1010171 + patch
Control: forwarded 1010171 https://dev.gnupg.org/T5953

I've tracked this problem down to a change in upstream that was intended
to accomodate non-standards-compliant secret key material.

I'm going to revert that change in debian (using the attached patch)
until we can figure out how to support both existing,
standards-compliant key material and the "SOS"-formatted secret keys.

The change made to sbuild (supplying --batch for key import) is still
the right change to make, but it was insufficient to resolve the
problem.

--dkg

From a86a3026218c2d5ac7cd898666b8ef60a5734bb9 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Wed, 27 Apr 2022 16:57:28 -0400
Subject: [PATCH] gpg: import Ed25519 private keys as MPIs

* g10/parse-packet.c (parse_key): Use mpi_read for Ed25519 private
  key.

--

This functionally reverts 14de7b1e5904e78fcbe413a82d0f19b750bd8830,
because it caused breakage with sbuild's continuous integration
testing, which uses gpg via debsign (see
https://bugs.debian.org/1010171)

In particular, it fixes the use of the following two commands with an
unencrypted Ed25519 secret key where the full 256-bits are used in the
secret scalar:

gpg --allow-secret-key-import --import
gpg --batch --detach-sign

I guess this also unfortunately breaks importing "SOS"-formatted
secret keys as a byproduct, though I don't fully understand the
mechanism.

The upstream test suite should probably be updated to include samples
of each of these flavors of secret key material, and ensure that they
can be imported and used directly.
---
 g10/parse-packet.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/g10/parse-packet.c b/g10/parse-packet.c
index 6a529707a..7eb2d03b0 100644
--- a/g10/parse-packet.c
+++ b/g10/parse-packet.c
@@ -2805,10 +2805,7 @@ parse_key (IOBUF inp, int pkttype, unsigned long pktlen,
   goto leave;
 }
   n = pktlen;
-  if (algorithm == PUBKEY_ALGO_EDDSA)
-pk->pkey[i] = sos_read (inp, , 0);
-  else
-pk->pkey[i] = mpi_read (inp, , 0);
+  pk->pkey[i] = mpi_read (inp, , 0);
   pktlen -= n;
   if (list_mode)
 {
-- 
2.35.1



signature.asc
Description: PGP signature


Bug#1010239: RM: librust-sequoia-openpgp+crypto-nettle-dev -- ROM; binary package v1.3.0-4 no longer built by source v1.8.0-1

2022-04-26 Thread Daniel Kahn Gillmor
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: d...@fifthhorseman.net

The rust-sequoia-openpgp source package is in good shape.

But, due to #1001251 librust-sequoia-openpgp+crypto-nettle-dev was
renamed to rust-sequoia-openpgp+nettle-dev.

As a result, librust-sequoia-openpgp+crypto-nettle-dev 1.3.0-4 lingers
in unstable, even though the source package is at 1.8.0-1.  Removing
the old version of librust-sequoia-openpgp+crypto-nettle-dev should be
sufficient to leave the archive in an acceptable state, as the
Provides: entries can satisfy what needs to be satisfied.

Thanks for maintaining the unstable archive in debian!  Sorry for the
additional hassle.

   --dkg



Bug#1010171: sbuild's "unshare" test fails with gpg-agent 2.2.34-1

2022-04-25 Thread Daniel Kahn Gillmor
Package: sbuild
Version: 0.83.0
Control: affects -1 + gpg-agent
Control: tags -1 + patch

When trying to upgrade to gnupg2 from version 2.2.27-1 to version
2.2.34-1, we see a failure in the unshare-qemuwrapper test:

https://ci.debian.net/data/autopkgtest/testing/amd64/s/sbuild/21152998/log.gz

+ ssh -oUserKnownHostsFile=/dev/null -oStrictHostKeyChecking=no -i 
/tmp/autopkgtest-lxc.29hmt_yk/downtmp/autopkgtest_tmp/id_rsa -T -p 10022 
root@localhost env --chdir=/build/ AUTOPKGTEST_TMP=/tmp runuser -u user -- 
./debian/tests/unshare
Warning: Permanently added '[localhost]:10022' (ED25519) to the list of known 
hosts.
gpg: keybox '/tmp/gpghome/pubring.kbx' created
gpg: /tmp/gpghome/trustdb.gpg: trustdb created
gpg: key F08FF84541F5A0C0: public key "sbuild fake uploader 
" imported
gpg: key F08FF84541F5A0C0/F08FF84541F5A0C0: error sending to agent: Invalid 
argument
gpg: key F08FF84541F5A0C0/A4179B1DD69E01DD: error sending to agent: Invalid 
argument
gpg: key F08FF84541F5A0C0: secret key imported
gpg: Total number processed: 1
gpg:   imported: 1
gpg:   secret keys read: 1
gpg:   secret keys imported: 1

I traced this error down to the use of "gpg --allow-secret-key-import
--import" in the unshare script.  GnuPG upstream has always maintained
that use of gpg in scripts requires use of the --batch directive, which
avoids the error.  Why this error response was introduced in the change
from GnuPG 2.2.27 to 2.2.34, i don't yet fully understand, but using
--batch does avoid the problem.

The attached patch should hopefully make the sbuild autopkgtest succeed
with either version of GnuPG2.

thanks for maintaining sbuild in debian!

   --dkg

From 4bdf145dd92df9db01fa38e1ab33cf1c36926ce9 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Mon, 25 Apr 2022 12:30:11 -0400
Subject: [PATCH] Use --batch with gpg when importing secret key

The use of gpg here is automated, and should not trigger a prompt to
the user.  GnuPG upstream recommends always using --batch in contexts
like this.

With GnuPG 2.2.34, the import actually fails, with gpg-agent logging
the following failures:

2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 <- IMPORT_KEY --timestamp=20210125T124832
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 -> [[Confidential data not shown]]
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 <- [[Confidential data not shown]]
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 <- [[Confidential data not shown]]
2022-04-25 12:28:02 gpg-agent[899673] command 'IMPORT_KEY' failed: Invalid argument 
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 -> ERR 16777261 Invalid argument 
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 <- SETKEYDESC Please+enter+the+passphrase+to+import+the+OpenPGP+secret+key:%0A%22sbuild+fake+uploader+%22%0A255-bit+EDDSA+key,+ID+A4179B1DD69E01DD,%
0Acreated+2021-01-25+(main+key+ID+F08FF84541F5A0C0).%0A
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 -> OK
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 <- IMPORT_KEY --timestamp=20210125T124832
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 -> [[Confidential data not shown]]
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 <- [[Confidential data not shown]]
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 <- [[Confidential data not shown]]
2022-04-25 12:28:02 gpg-agent[899673] command 'IMPORT_KEY' failed: Invalid argument 
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 -> ERR 16777261 Invalid argument 
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 <- SETKEYDESC Please+enter+the+passphrase+to+import+the+OpenPGP+secret+key:%0A%22sbuild+fake+uploader+%22%0A255-bit+ECDH+key,+ID+52C3581ED0C37392,%0
Acreated+2021-01-25+(main+key+ID+F08FF84541F5A0C0).%0A
2022-04-25 12:28:02 gpg-agent[899673] DBG: chan_10 -> OK

Using --batch here changes the IMPORT_KEY assuan directive such that
it includes an --unattended flag, which bypasses the failures we're
seeing on upgrading GnuPG in debian unstable.

Having to perform this workaround is unfortunate.  A better approach
would be to rewrite sbuild's tooling to use OpenPGP utilities designed
for operation in a script, but doing so is a larger and more intrusive
patch.
---
 debian/tests/unshare | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/tests/unshare b/debian/tests/unshare
index aa23bb08..272330f5 100755
--- a/debian/tests/unshare
+++ b/debian/tests/unshare
@@ -101,7 +101,7 @@ verify() {
 
 
 # FIXME: generate a key without expiry date
-cat << END | gpg --allow-secret-key-import --import -
+cat << END | gpg --batch --allow-secret-key-import --import -
 -BEGIN PGP PRIVATE KEY BLOCK-
 
 xVgEYA6+IBYJKwYBBAHaRw8BAQdAM1MKmD3Qm9XwkCv40xOUt1KTLL3nQ2NYfl6B
-- 
2.35.1



signature.asc
Description: PGP signature


Bug#1009837: xdotool: new upstream release available

2022-04-20 Thread Daniel Kahn Gillmor
Control: tags 1009837 + help

Thanks for the nudge, Matti--

On Mon 2022-04-18 15:56:16 -0400, Matti Klock wrote:
> In 2021, xdotool issued its first release in five years, and it includes some 
> new features:
>
> https://github.com/jordansissel/xdotool/releases
>
> It's been stable for a few months. Packaging the new version would be awesome.

I took a look at this and tried to figure out whether i could package
it.  sadly, it looks like there's some pretty ugly ABI breakage, which i
reported upstream:

   https://github.com/jordansissel/xdotool/issues/387

I pushed a debian/experimental branch to
https://salsa.debian.org/debian/xdotool that tries to repair the ABI
breakage to some degree (it's imperfect, but also trying to not be super
invasive), but it doesn't pass the expected tests, and i haven't looked
into it further.

If someone else wants to try to figure out what's breaking, i'd welcome
any assistance.

 --dkg


signature.asc
Description: PGP signature


Bug#1009380: sasl2-bin: make saslpluginviewer more accessible (clearer manpage, put it in /usr/bin)

2022-04-15 Thread Daniel Kahn Gillmor
On Fri 2022-04-15 00:16:22 +0200, Bastian Germann wrote:
> On Tue, 12 Apr 2022 11:43:01 -0700 Daniel Kahn Gillmor 
>  wrote:
>>  - the manual page should also be updated as part of this rename -- it's
>>installed as saslpluginviewer.8.gz, but internally it says
>>"pluginviewer".
>
> This will be fixed with the next release.
>
>>  - it should be available in /usr/bin/, not only in /usr/sbin/.  It's
>>not uncommon for someone to want to investigate the state of
>>installed tooling without having to be root, and /usr/sbin is not
>>typically in the regular user path.
> I will not change the location to a different path from upstream.
> Please ask upstream for this change if it is important for you.

Thanks for this prompt fix and explanation, Bastian!

Regards,

   --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]

2022-04-13 Thread Daniel Kahn Gillmor
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]

2022-04-13 Thread Daniel Kahn Gillmor
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#1009621: ITP: python-sasl -- Python bindings for Cyrus libsasl2

2022-04-13 Thread Daniel Kahn Gillmor
I did a bit of work packaging python-sasl to create a simple/reasonable
debian package, and i've published my work at
https://salsa.debian.org/debian/python-sasl

But after playing with the module more, i no longer think it should be
in in debian.  as the debian/TODO file in the salsa repo notes:

  The module itself doesn't feel great -- it has no documentation, no
  examples, and what feels to me like a distinctly unpythonic interface.
  It has also seen only very intermittent upstream contributions.

  So i'm abandoning this work for now (and closing the bug report) but
  leaving it visible for anyone who wants to pick up on it from here.

Hopefully this data trail is useful for someone in the future.

  --dkg

On Tue 2022-04-12 23:16:48 -0700, Daniel Kahn Gillmor wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Daniel Kahn Gillmor 
> X-Debbugs-Cc: debian-de...@lists.debian.org, d...@fifthhorseman.net
>
> * Package name: python-sasl
>   Version : 0.3.1
>   Upstream Author : Todd Lipcon 
> * URL : https://github.com/cloudera/python-sasl
> * License : Apache-2.0
>   Programming Lang: C, Python
>   Description : Python bindings for libsasl2
>
> This package should enable a Python-based tool to take advantage of
> any installed SASL module.
>
> This should be useful for testing tools like sasl-xoauth2 (see for
> example #1006888)


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]

2022-04-13 Thread Daniel Kahn Gillmor
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#1009621: ITP: python-sasl -- Python bindings for Cyrus libsasl2

2022-04-13 Thread Daniel Kahn Gillmor
Package: wnpp
Severity: wishlist
Owner: Daniel Kahn Gillmor 
X-Debbugs-Cc: debian-de...@lists.debian.org, d...@fifthhorseman.net

* Package name: python-sasl
  Version : 0.3.1
  Upstream Author : Todd Lipcon 
* URL : https://github.com/cloudera/python-sasl
* License : Apache-2.0
  Programming Lang: C, Python
  Description : Python bindings for libsasl2

This package should enable a Python-based tool to take advantage of
any installed SASL module.

This should be useful for testing tools like sasl-xoauth2 (see for
example #1006888)



Bug#1009380: sasl2-bin: make saslpluginviewer more accessible (clearer manpage, put it in /usr/bin)

2022-04-12 Thread Daniel Kahn Gillmor
Package: sasl2-bin
Version: 2.1.28+dfsg-2+b1

The debian installation of SASL's pluginviewer is not particularly
friendly.  The renaming to saslpluginviewer is understandable
("pluginviewer" is a terribly generic name), but:

 - the manual page should also be updated as part of this rename -- it's
   installed as saslpluginviewer.8.gz, but internally it says
   "pluginviewer".

 - it should be available in /usr/bin/, not only in /usr/sbin/.  It's
   not uncommon for someone to want to investigate the state of
   installed tooling without having to be root, and /usr/sbin is not
   typically in the regular user path.

thanks for maintiaining cyrus-sasl2 in debian!

   --dkg


signature.asc
Description: PGP signature


Bug#1003982: postfix: /etc/ssl/certs/ca-certificates.crt not copied to chroot

2022-04-12 Thread Daniel Kahn Gillmor
Control: affects 1003982 + sasl-xoauth2
Control: affects 1006888 + src:sasl-xoauth2

Over in https://bugs.debian.org/1003982, Thomas Fargeix wrote:
> On 2022-01-18 23:19, Scott Kitterman wrote:
>> According to postconf(5) it's not needed.  It says, "These are loaded
>> into memory before the smtp(8) client enters the chroot jail".  Why
>> do you need it in the chroot?
>
> Then there is a different behavior between smtp(d)_tls_CAfile and
> tls_ca_cert_file from the postfix-ldap module (and maybe other TLS
> options from other modules?  I have not see other errors in my setup
> but LDAP is my only non-default one).  I use LDAP map for aliases,
> with tls_ca_cert_file to verify the certificate of the LDAP server,
> and the CA file was not loaded in memory before entering the chroot:

Aside from postfix-ldap as a lookup module, SASL modules might also need
the files to be in the chroot.

For example, I'm preparing the sasl-xoauth2 module for debian (see
https://bugs.debian.org/1006888) and the upstream developer for that
package (Tarick Bedeir, in Cc here) has some hooks in his upstream .deb
packaging (that targets ubuntu), which trying to copy
/etc/ssl/certs/ca-certificates.crt into the chroot whenever
ca-certificates is updated:

   
https://github.com/tarickb/sasl-xoauth2/blob/master/scripts/update-ca-certificates.sh
   https://github.com/tarickb/sasl-xoauth2/blob/master/debian/install
   
https://github.com/tarickb/sasl-xoauth2/blob/master/debian/sasl-xoauth2.postinst

This seems to be a not-particularly-robust approach, including at
least:

   https://github.com/tarickb/sasl-xoauth2/issues/13
   https://github.com/tarickb/sasl-xoauth2/issues/14

I don't plan to adopt this particular approach for the debian package,
for (at least) a few reasons:

- the sasl-xoauth2 package isn't even explicitly related to postfix --
  that's the main upstream test case, but that doesn't mean that the
  sasl-xoauth2 package should fiddle with the default postfix
  installation.

- This approach won't work for a multi-tenant postfix installation; it
  doesn't transfer the CA directory, etc.

- /usr/share/doc/postfix/README.Debian.gz section 2A suggests that
  /etc/default/postfix is supposed be the right way to ensure that these
  files are updated on postfix restart.

My current plan is to drop a short note in
/usr/share/doc/sasl-xoauth2/README.Debian that encourages use of
/etc/default/postfix for postfix admins who install this module.

But it would be pretty cool if postfix could automagically figure out
that it needs the ca-certificates file if this sasl module is
configured.

Scott, if you have any suggestions for how to approach this going
forward, i'd be happy to try to adopt those suggestions in the
sasl-xoauth2 packaging.  Or, if you can see that i'm making some kind of
mistake here, i'd appreciate hearing about it too.

Please let me know what you think!

 --dkg

PS i recognize that some packaging/system-integration decisions might be
   different were i to try to backport sasl-xoauth2 for the existing
   debian stable; but i'd prefer to sort out the cleanest and most
   easily-maintainable packaging for debian unstable first, which is why
   i'm raising this here.  Whoever wants to do fiddly stuff for
   backports can do so as necessary, but i don't want to have to
   maintain that fiddliness in the packaging going forward if i can
   avoid it.


signature.asc
Description: PGP signature


Bug#1009343: please consider adding Boost-1.0 and Expat to /usr/share/common-licenses

2022-04-11 Thread Daniel Kahn Gillmor
Package: base-files
Severity: wishlist
Version: 12.2

Expat and Boost-1.0 are both fairly common licenses in debian.  I
believe they are both well-defined, stable, and reasonably
well-understood variants of the MIT family of licenses.

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ even
explicitly recommends that software with an "MIT" license that matches
the Expat terms should instead refer to Expat.

It would seem reasonable to include both of these licenses in
/usr/share/common-licenses/ to discourage adoption of other
less-well-known variants in the MIT family.

Boost has the advantage over "Expat" of being explicitly included in the
SPDX listing with a short name of "BSL-1.0":

https://spdx.org/licenses/

while Expat doesn't get its own identifier in that list, but instead has
the discouraged "MIT".

For reference, here's Boost 1.0:


from https://www.boost.org/users/license.html and 
https://www.boost.org/LICENSE_1_0.txt

--
Boost Software License - Version 1.0 - August 17th, 2003

Permission is hereby granted, free of charge, to any person or organization
obtaining a copy of the software and accompanying documentation covered by
this license (the "Software") to use, reproduce, display, distribute,
execute, and transmit the Software, and to prepare derivative works of the
Software, and to permit third-parties to whom the Software is furnished to
do so, all subject to the following:

The copyright notices in the Software and this entire statement, including
the above license grant, this restriction and the following disclaimer,
must be included in all copies of the Software, in whole or in part, and
all derivative works of the Software, unless such copies or derivative
works are solely in the form of machine-executable object code generated by
a source language processor.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT
SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE
FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.
--


And here's Expat:

  from http://www.jclark.com/xml/copying.txt

--
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:

The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
--


Thanks for maintaining base-files in debian!

   --dkg


signature.asc
Description: PGP signature


Bug#1009216: /etc/default/prometheus-node-exporter should be much shorter

2022-04-10 Thread Daniel Kahn Gillmor
On Sun 2022-04-10 18:03:13 +0200, Guillem Jover wrote:
> Also true in principle, as long as the man page is coming from upstream
> (and gets updated by them or a script :) or gets generated from the
> Debian packaging out of --help output, which I'm not sure is the case
> for all current exporters. But DRY principle and all.

Agreed.  But if the package maintainer has to spend any time at all
keeping some documentation up to date, please spend it ensuring that the
manpage is up-to-date, as that's going to be relevant for many more
people than /etc/default/prometheus-node-exporter.

> I can bring it up on the team's IRC channel, and gather the feeling of
> the team about this.

Thanks!  One other motivating reason to simplify the file is that it's
easy for a busy/rushed admin to scan the file, see the long list of
commented options and think "i'll just uncomment the ones that i want"
(without understanding that they need to be copied to the ARGS="" line).

Less text makes it easier for someone in a rush to focus on the most
important thing, which is where the options go.

Thanks for looking into this, Guillem!

  --dkg


signature.asc
Description: PGP signature


Bug#1009216: /etc/default/prometheus-node-exporter should be much shorter

2022-04-08 Thread Daniel Kahn Gillmor
Package: prometheus-node-exporter
Version: 1.3.1-1

/etc/default/prometheus-node-exporter contains a huge amount of comments
indicating what possible command line options are available for the
daemon.

Those comments either will get out of date as the package is upgraded
(meaning, they'll be wrong), or, for an admin who has set anything in
ARGS, they'll cause dpkg to warn that a config file is being changed
during package upgrade.

Both of these things are pretty tedious for an admin to deal with.

The comments also recapitulate the date in the associated manpage, which
*will* be kept up-to-date across a package upgrade.

It would be better if /etc/default/prometheus-node-exporter shipped as
(in total):


# Set the command-line arguments to pass to the server in ARGS below.
# Due to shell escaping, to pass backslashes for regexes, you need to double
# them (\\d for \d). If running under systemd, you need to double them again
# (d to mean \d), and escape newlines too.
# See prometheus-node-server(1) for acceptable arguments.

ARGS=""


(the stuff about different forms of escaping is also unfortunate, but
that's probably a different issue)

--dkg


signature.asc
Description: PGP signature


Bug#1008493: gnome-control-center and gnome-settings-daemon version mismatch makes keyboard shortcuts fail

2022-03-29 Thread Daniel Kahn Gillmor
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

2022-03-29 Thread Daniel Kahn Gillmor
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#985907: rnp: accepts weak cryptographic primitives

2022-03-28 Thread Daniel Kahn Gillmor
Control: close 985907 0.16.0-1

On Thu 2021-03-25 13:39:00 -0400, Daniel Kahn Gillmor wrote:
> rnp currently accepts signatures over weak or untrustworthy
> cryptographic primitives.

As of 0.16.0, rnp introduces the following relevant safeguards (from
upstream's CHANGELOG.md):

* Mark SHA1 signatures produced later than 2019-01-19, as invalid.
* Mark MD5 signatures produced later than 2012-01-01, as invalid.
* Use SHA1 collision detection code when using SHA1.

While we might debate whether these are the best possible defaults, it's
no longer completely insecure by default.

In addition, rnp now has the following APIs which can adjust the
underlying acceptable security primitives:

rnp_get_security_rule
rnp_add_security_rule
rnp_remove_security_rule

So it's possible to adjust the acceptable security levels directly if
the user wants to nudge the defaults.

I'm not convinced this is the ideal interface, but it should be at least
usable.

   --dkg


signature.asc
Description: PGP signature


Bug#1008493: gnome-control-center and gnome-settings-daemon version mismatch makes keyboard shortcuts fail

2022-03-27 Thread Daniel Kahn Gillmor
Package: gnome-settings-daemon
Version: 42.1-1
Control: affects -1 gnome-control-center

I have gnome-settings-daemon 42.1-1 installed, and gnome-control-cennter
1:41.4-1

When i open gnome-control-center and go to "Keyboard" and click on "View
and Customize Shortcuts", gnome-control-center crashes, and produces
this on stderr:


(gnome-control-center:3522): GLib-GIO-ERROR **: 12:05:52.032: Settings 
schema 'org.gnome.settings-daemon.plugins.media-keys' does not contain a key 
named 'screenshot'
Trace/breakpoint trap

I reported this upstream:

https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1728

And Jeremy Bicha responded with:

> I think your issue is caused by a version mismatch in Debian, so I'm
> closing this as Not GNOME.

I think either gnome-settings-daemon 42.1-* should indicate that it
Breaks: earlier versions of gnome-control-center, or
gnome-control-center should indicate that it is tightly bound to the
version of gnome-settings-daemon that it ships with.

--dkg


signature.asc
Description: PGP signature


Bug#998848: thunderbird: please build against librnp-dev (and Depend: on librnp0) directly

2022-03-26 Thread Daniel Kahn Gillmor
I've just uploaded rnp 0.16.0 into debian unstable.  According to
https://bugzilla.mozilla.org/show_bug.cgi?id=1732809 the main
development line of thunderbird now has a --with-system-rnp flag (but
the 91esr series doesn't have it.

So when new versions of thunderbird get built in debian (in experimental
first, maybe?) please try to use --with-system-rnp.  If you run into any
reason why building against the system rnp isn't working, please don't
hesitate to file bug reports against rnp and we'll sort them out.

thanks for all your work on thunderbird in debian!

--dkg


signature.asc
Description: PGP signature


Bug#1008107: "mke2fs -E android_sparse" yields: "Unimplemented ext2 library function while setting up superblock" (not built against libsparse?)

2022-03-22 Thread Daniel Kahn Gillmor
Package: libext2fs2
Version: 1.46.5-2
Control: affects -1 + fastboot android-sdk-platform-tools

The -E android_sparse option for mke2fs fails because libext2fs2 reports
EXT2_ET_UNIMPLEMENTED, presumably because libext2fs2 isn't built with
ENABLE_LIBSPARSE .  here's the failure:


```
0 dkg@host:~$ /sbin/mke2fs tmp/control 1000
mke2fs 1.46.5 (30-Dec-2021)
Creating regular file tmp/control
Creating filesystem with 1000 1k blocks and 128 inodes

Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done

0 dkg@host:~$ /sbin/mke2fs -E android_sparse tmp/test 1000
mke2fs 1.46.5 (30-Dec-2021)
Creating regular file tmp/test
tmp/test: Unimplemented ext2 library function while setting up superblock
1 dkg@host:~$ 
```

I ran into this because i wanted to call "fastboot format cache", which
failed when trying to run mke2fs.  it was trying to run it with -E
android_sparse

Looks like fastboot runs mke2fs from
/usr/lib/android-sdk/platform-tools/mke2fs, which is just a symlink back
to /sbin/mkfs, provided by android-sdk-platform-tools.

the "fastboot format cache" command instead fails with:

```
mke2fs 1.46.5 (30-Dec-2021)
/tmp/TemporaryFile-62XVjd: Unimplemented ext2 library function while setting up 
superblock
/usr/lib/android-sdk/platform-tools/mke2fs failed with status 1
fastboot: error: Cannot generate image for cache
```

--dkg


signature.asc
Description: PGP signature


Bug#1004452: bullseye-pu: package gnupg2/2.2.27-2+deb11u1

2022-03-18 Thread Daniel Kahn Gillmor
On Fri 2022-03-18 09:13:08 +, Adam D. Barratt wrote:
> Unfortunately it looks like the upload failed:
>
> gnupg2_2.2.27-2+deb11u1.dsc: Refers to non-existing file
> 'gnupg2_2.2.27.orig.tar.bz2.asc'

Sigh.  thanks for the note.  I've just tried again, this time including
the orig.tar.bz2.asc in the upload.

--dkg


signature.asc
Description: PGP signature


Bug#1004452: bullseye-pu: package gnupg2/2.2.27-2+deb11u1

2022-03-17 Thread Daniel Kahn Gillmor
On Thu 2022-03-17 17:49:04 +, Adam D. Barratt wrote:
> On Sat, 2022-02-19 at 22:24 -0500, Daniel Kahn Gillmor wrote:
>> On Sat 2022-02-19 17:09:21 +, Adam D. Barratt wrote:
>> > Control: tags -1 + confirmed d-i
>> > 
> [...]
>> > That looks fine to me, but will need a d-i ack as the package
>> > builds a
>> > udeb; tagging and CCing accordingly.
>> 
>> Understood -- i'll wait for a d-i ack before uploading.
>
> As we're getting very close to the window for 11.3 closing, please feel
> free to upload.

I've just uploaded gnupg2/2.2.27-2+deb11u1 to bullseye now.  Please let
me know if there are any problems.

thanks for your ongoing work maintaining debian stable!

 --dkg


signature.asc
Description: PGP signature


Bug#1007840: [notmuch-slurp-debbug] notmuch-slurp-debbug should use "notmuch insert"

2022-03-17 Thread Daniel Kahn Gillmor
Hi Sean, thanks for the prompt response.

On Thu 2022-03-17 11:34:32 -0700, Sean Whitton wrote:
> On Thu 17 Mar 2022 at 01:51PM -04, Daniel Kahn Gillmor wrote:
>> For backward compatibility, if a "maildir" configuration variable is
>> present, it could fall back to the old form of insertion, but emit a
>> warning that it is doing so.
>
> How about using 'notmuch insert --folder=' if the old config
> key is present, and not issuing a warning?

The trouble with that is that --insert is defined "relative to the
top-level directory given by the value of database.mail_root.", whereas
the maildir is a full filesystem path.

Seems better to me to do a deprecation cycle.  It's noisier short term,
but cleaner longterm.

The other open question here is that "notmuch insert" on its own
defaults to delivering at the top level, whereas notmuch-slurp-debbug
wants to use the "inbox" folder just below the top level.

I'm personally fine with the default delivery location changing, but if
you think we ought to default to something like --folder=inbox
--create-folder i'd be willing to do that too.

>> When the old method is *not* used, we could add a passthrough option
>> that lets the user append arbitrary arguments to "notmuch insert",
>> which would also conveniently solve #995842.
>
> Nice.

If we go the --folder=inbox --create-folder route, then we'd need to
decide whether the passthrough arguments would *append* to
--folder=inbox --create-folder, or whether they would *replace*
--folder=inbox --create-folder.  I'd lean toward replacement in that
case.

Also, what would you like this configuration key to be named?  I was
thinking "insert_args".

So, four questions:

a) how to deal with existing maildir configuration key?
(i prefer emitting a warning and falling back to old behavior)

b) what should the config key be named?
(i prefer "insert_args")

c) where to place the new messages?
(i prefer the "notmuch insert" defaults, but could be
"--folder=inbox --create-folder")

d) if messages are placed by default via "--folder=inbox
   --create-folder", how should the config key interact with the default
   args?
  (if we get to this question, i prefer replacement)

Let me know what you prefer and i'll see whether i can offer a patch in
the coming days.

--dkg


signature.asc
Description: PGP signature


Bug#1006888: RFP: sasl-xoauth2 -- XOAUTH2 plugin for libsasl2

2022-03-17 Thread Daniel Kahn Gillmor
Control: retitle 1006888 ITP: sasl-xoauth2 -- XOAUTH2 plugin for libsasl2
Control: owner 1006888 d...@fifthhorseman.net
X-Debbugs-Cc: Tarick Bedeir 

On Mon 2022-03-07 17:50:20 +, Reuben Thomas wrote:
> Package: wnpp
> Severity: wishlist
>
> * Package name: sasl-xoauth2
>   Version : 0.11
>   Upstream Author : Tarick Bedeir 
> * URL : https://github.com/tarickb/sasl-xoauth2
> * License : Apache-2.0
>   Programming Lang: C
>   Description : XOAUTH2 plugin for libsasl2
>
> A plugin for libsasl2 that implements the XOAUTH2 protocol, as used by GMail
> and some other major email services. This can be used to allow postfix and
> other MTAs that can use libsasl to authenticate to such services.

I understand this is concretely useful, and it looks straightforward to
package.  I aim to package it and upload it to debian.

  --dkg


signature.asc
Description: PGP signature


Bug#1007840: [notmuch-slurp-debbug] notmuch-slurp-debbug should use "notmuch insert"

2022-03-17 Thread Daniel Kahn Gillmor
Package: mailscripts
Version: 0.24-1
Severity: wishlist
X-Debbugs-Cc: Jameson Rollins 

notmuch has had an "insert" subcommand since notmuch 0.16 (2013-08-03,
according to /usr/share/doc/notmuch/NEWS.gz

rather than guessing at maildir paths or whatever, notmuch-slurp-debbug
should just feed the retreived messages into "notmuch insert".

For backward compatibility, if a "maildir" configuration variable is
present, it could fall back to the old form of insertion, but emit a
warning that it is doing so.

When the old method is *not* used, we could add a passthrough option
that lets the user append arbitrary arguments to "notmuch insert", which
would also conveniently solve #995842.

   --dkg


signature.asc
Description: PGP signature


Bug#1007148: /usr/share/menu/python3-sympy refers to /usr/share/pixmaps/isympy.xpm, but does not recommend isympy-common

2022-03-11 Thread Daniel Kahn Gillmor
Package: python3-sympy
Version: 1.9-1
Control: affects -1 + openbox

I have python3-sympy installed because of weasyprint.

I don't have isympy or isympy-common installed at all.

python3-sympy wants to install a system menuitem with an icon
/usr/share/pixmaps/isympy.xpm from the isympy-common package:

0 dkg@host:~$ cat /usr/share/menu/python3-sympy 
?package(python3-sympy):needs="text" section="Applications/Science/Mathematics"\
title="sympy (Python3)"\
icon="/usr/share/pixmaps/isympy.xpm"\
command="python3 /usr/bin/isympy"
0 dkg@host:~$ 

However, this means that my desktop environment (openbox) produces a
warning on stderr every time it tries to render the menu:

ObRender-Message: Cannot load image "/usr/share/pixmaps/isympy.xpm" from 
file "/usr/share/pixmaps/isympy.xpm"

python3-sympy doesn't Depend, Recommend, or Suggest isympy-common, and i
don't particularly think i should need to install a full package just to
avoid a frequent warning message about an icon.

Not sure what the right resolution is here.  Maybe just ship another
copy of the icon in python3-sympy and refer to it in the menu item?

Thanks for maintaining sympy in debian!

--dkg


signature.asc
Description: PGP signature


Bug#1007147: openbox invokes imlib_free_image when no image is loaded

2022-03-11 Thread Daniel Kahn Gillmor
Package: openbox
Version: 3.6.1-10
Control: forwarded -1 https://bugzilla.icculus.org/show_bug.cgi?id=6447
Control: tags -1 + patch

When i right-click the openbox desktop menu and choose "reconfigure",
openbox produces the following message to stderr:


```
* Imlib2 Developer Warning * :
This program is calling the Imlib call:

imlib_free_image();

With the parameter:

image

being NULL. Please fix your program.
ObRender-Message: Cannot load image "/usr/share/pixmaps/isympy.xpm" from file 
"/usr/share/pixmaps/isympy.xpm"
```

I looked in the openbox source and found this invocation:

https://sources.debian.org/src/openbox/3.6.1-10/obrender/image.c/?hl=484#L484

```
void DestroyImlibLoader(ImlibLoader *loader)
{
if (!loader)
return;

imlib_free_image();
g_slice_free(ImlibLoader, loader);
}
```

I found a report in the upstream bugtracker, and found the report linked
above, which also contains the attached patch from "Grant" from over 5
years ago.  I haven't tested it, but it looks reasonable to me.

  --dkg

diff --git a/obrender/image.c b/obrender/image.c
index cffbaf3..5c689c4 100644
--- a/obrender/image.c
+++ b/obrender/image.c
@@ -476,17 +476,18 @@ struct _ImlibLoader
 Imlib_Image img;
 };
 
 void DestroyImlibLoader(ImlibLoader *loader)
 {
 if (!loader)
 return;
 
-imlib_free_image();
+if (loader->img)
+imlib_free_image();
 g_slice_free(ImlibLoader, loader);
 }
 
 ImlibLoader* LoadWithImlib(gchar *path,
RrPixel32 **pixel_data,
gint *width,
gint *height)
 {


signature.asc
Description: PGP signature


Bug#1006988: rust-svgdom: still needed in the archive?

2022-03-09 Thread Daniel Kahn Gillmor
Package: src:rust-svgdom
Version: 0.18.0-2
Severity: important

rust-svgdom was deprecated by its upstream developer in mid-2019, and
hasn't been touched since.  See https://github.com/RazrFalcon/svgdom

librust-svgdom-dev has no reverse dependencies in debian, and the
package itself has some dependencies on other crates that are in need of
an upgrade (e.g. the rust-svgtypes package).

Andrej, do you think we need to keep this package in debian?  If you
don't think we need it, can you convert this bug report to a removal
request?  (or, feel free to just reply here and i'll do the conversion).

If you do think it needs to stay in the archive, can you explain what is
necessary?

Thanks for thinking about this kind of maintenance,

--dkg


signature.asc
Description: PGP signature


Bug#907264: faketime: timezone bugs: lax parsing, no way to specify UTC or TZ

2022-03-09 Thread Daniel Kahn Gillmor
Control: reassign 907264 libc6 2.33-7
Control: retitle 907264 glibc's strptime does not handle %z and %Z as expected
Control: affects 907264 + faketime

On Sat 2018-08-25 21:44:04 +0200, Wolfgang Hommel wrote:
> Apparently, glibc goes for a new tm->tm_gmtoff field and supports %z 
> (but not %Z) fully yet. This might give some headaches regarding 
> cross-platform compatibility, and implementing a completely own parser 
> (i.e., not using strptime()) does not seem viable, either. So yes, this 
> needs to be addressed, but will take some time.

Since the problem appears to be in strptime(), i'm reassigning this bug
to glibc.

   --dkg


signature.asc
Description: PGP signature


Bug#753461: faketime causes some complex runtime environments (including firefox) to hang

2022-03-09 Thread Daniel Kahn Gillmor
Control: retitle 753461 faketime causes some complex runtime environments 
(including firefox) to hang
Control: tags 753461 - unreproducible
Control: tags 753461 + upstream
Control: forwarded 753461 https://github.com/wolfcw/libfaketime/issues/373

On Wed 2014-08-06 22:38:28 +0200, Wolfgang Hommel wrote:
> In this case, the observed behavior is quite typical for applications 
> which load system libraries (including time-related functions) 
> themselves at run-time. It basically means that the LD_PRELOAD mechanism 
> is somewhat bypassed by the application, which loads the real (not the 
> faking) library again after the linker has loaded the faking library. 
> Strange things (such as slow reactions with few-seconds-offsets or 
> endless hangs with larger offsets) occur when the application is 
> multi-threaded and one thread sees a faked time while another one uses 
> the real system time, and both try to synchronize.

I've just replicated the reporeted behavior with firefox 96.0.3-1 on
debian testing, using a simple testing profile in safe mode:

   faketime 2022-01-01 firefox -P test -no-remote -safe-mode

this hangs indefinitely, presumably due to some of the concerns that
Wolfgang outlines above.

I don't think this is something that we can fix in debian, but i've
noted it in the upstream bugtracker.

  --dkg


signature.asc
Description: PGP signature


Bug#892149: faketime(1) fails on hurd: sem_open: Operation not supported

2022-03-09 Thread Daniel Kahn Gillmor
On Mon 2018-03-05 22:00:35 -0500, Aaron M. Ucko wrote:

> The faketime executable fails on hurd-i386 (admittedly not a release
> architecture) with the error
>
>   sem_open: Operation not supported
>
> as seen in [1].

This doesn't seem to be a problem any more on hurd, though i don't think
that faketime itself changed anything significant.  Rather, i suspect
that libc6 changed on hurd in ways that were more compatible with
faketime.

I'm closing this now because i'm unable to replicate the problem, but if
someone can replicate it, please reopen!

--dkg



signature.asc
Description: PGP signature


Bug#1006950: libreoffice: toggle options in menus are too subtle to see

2022-03-08 Thread Daniel Kahn Gillmor
Package: libreoffice
Version: 1:7.3.1~rc1-1
Control: tags -1 + a11y

The dropdown menus in Libreoffice contain some entries that are toggle
buttons (items with a boolean state, which can be enabled or disabled by
clicking on them).

the toggle indicators in the standard configuration (i've never adjusted
my libreoffice configuration) are extremely difficult to see.

In the attached screenshot, you can see the "Edit" menu is open, with
the "Track Changes" submenu open.

The top two menuitems of the "Track Changes" submenu are toggle buttons.

The "Record" menuitem is a toggle button in the "off" state.

The "Show" menuitem is a toggle button in the "on" state.

Both menuitems have a light grey background.

"Show" has a 1px slightly-darker grey border around its icon to indicate
that it is in the "on" state.

My eyes aren't perfect, but they're not terrible either, and I have to
squint or get up close to the screen to be able to identify when a
toggle menuitem is on or off.  It doesn't help that when i click on the
menuitem to change its state, it also disappears immediately, so i can't
see whether something visually changes during the click.

I can only assume that this is much worse for someone with significant
vision impairment.

  --dkg



signature.asc
Description: PGP signature


Bug#1006636: Thunderbird fails to edit a recurring event

2022-02-28 Thread Daniel Kahn Gillmor
Package: thunderbird
Version: 1:91.6.1-1

The attached .ics file ("foo.ics") contains a recurring event.

If i use Thunderbird's "File » Open » Calendar File…" to open this, it
creates a new calendar named "redacted", and the event shows up as
expected (on 2022-03-02).

If i right-click the event in the calendar view, and choose "edit", i
get an option "Edit only this occurence" or "Edit all occurrences".

If i choose "Edit only this occurrence", the edit dialog box appears,
but i cannot change which calendar it is in (i cannot move it to a
different calendar, because the "Calendar:" entry dropdown field is
grayed out.

If i choose "Edit all occurrences", the Calendar: dropdown is enabled,
but the edit view contains no information but the starting date/time: no
title, ending time is the same as start time, no location, etc.  And
indeed i cannot even save the event properly in this case without
entering something for the title.

I've tried this with a brand new profile, and see the same problem
repeatedly.

It's entirely possible that this is a malformed .ics file, but it is a
copy of a text/calendar attachment that i received from an Outlook
client via Office365, with various content fields redacted: i changed
nothing related to date/time, but redacted participant names, location
URLs, etc.

It's also entirely possible that this is an upstream bug.  If you think
i should forward it upstream, please let me know.

Thanks for maintaining Thunderbird in Debian!

  --dkg

BEGIN:VCALENDAR
METHOD:REQUEST
PRODID:Microsoft Exchange Server 2010
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Eastern Standard Time
BEGIN:STANDARD
DTSTART:16010101T02
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:16010101T02
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=The Sender:mailto:sen...@example.org
DESCRIPTION;LANGUAGE=en-US:test
UID:04008200E00074C5B7101A82E008E970F189431CD801000
 010001AA5D6D60C3FB840A00FDCC4BE749158
RECURRENCE-ID;TZID=Eastern Standard Time:20220302T13
SUMMARY;LANGUAGE=en-US:All Staff Meeting
DTSTART;TZID=Eastern Standard Time:20220302T13
DTEND;TZID=Eastern Standard Time:20220302T14
CLASS:PUBLIC
PRIORITY:5
DTSTAMP:20220228T214601Z
TRANSP:OPAQUE
STATUS:CONFIRMED
SEQUENCE:2
LOCATION;LANGUAGE=en-US:https://test.example.org/
X-MICROSOFT-CDO-APPT-SEQUENCE:2
X-MICROSOFT-CDO-OWNERAPPTID:2120367593
X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE
X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-MICROSOFT-CDO-IMPORTANCE:1
X-MICROSOFT-CDO-INSTTYPE:3
X-MICROSOFT-ONLINEMEETINGINFORMATION:{"OnlineMeetingChannelId":null\,"Onlin
 eMeetingProvider":3}
X-MICROSOFT-SKYPETEAMSMEETINGURL:https://foo.example.org
X-MICROSOFT-SCHEDULINGSERVICEUPDATEURL:https://bar.example.org
X-MICROSOFT-SKYPETEAMSPROPERTIES:{"cid":"19:meeting_baz@thread.v2"\,"rid":0\,"mid":0\,"uid":null\,"priva
 te":true\,"type":0}
X-MICROSOFT-ONLINEMEETINGCONFLINK:conf:sip:sen...@example.org\;gruu\;opaque=a
 pp:conf:focus:id:teams:2:0!19:meeting_baz-thread.v2!uuid1!uuid2
X-MICROSOFT-DONOTFORWARDMEETING:FALSE
X-MICROSOFT-DISALLOW-COUNTER:FALSE
X-MICROSOFT-LOCATIONDISPLAYNAME:https://test.example.org
X-MICROSOFT-LOCATIONSOURCE:None
X-MICROSOFT-LOCATIONS:[{"DisplayName":"https://test.example.org"\,"LocationAnnotation":""\,
 "LocationUri":""\,"LocationStreet":""\,"LocationCity":""\,"LocationState":
 ""\,"LocationCountry":""\,"LocationPostalCode":""\,"LocationFullAddress":"
 "}]
BEGIN:VALARM
DESCRIPTION:REMINDER
TRIGGER;RELATED=START:-PT15M
ACTION:DISPLAY
END:VALARM
END:VEVENT
END:VCALENDAR


signature.asc
Description: PGP signature


Bug#981577: Chromium mis-renders UTF-8 text tables due to Bitstream Vera Sans Mono missing Unicode box drawing characters

2022-02-25 Thread Daniel Kahn Gillmor
Control: unblock 981577 with 981587
Control: reassign 981577 fontconfig
Control: affects 981577 + ttf-bitstream-vera
Control: retitle 981577 fontconfig should prefer DejaVu over Bitstream Vera

On Fri 2022-02-25 11:35:56 -0500, Daniel Kahn Gillmor wrote:
>>  - fontconfig could prefer more complete fonts when searching for a
>>match, which would prioritize dejavu sans (or some other more
>>complete font) over bitstream vera
>>
>>  - fontconfig could manually prefer DejaVu Sans Mono over Bitstream Vera
>>Mono when given the search string "monospace"
>
> Either of these approaches point to https://bugs.debian.org/981587 so
> i'm marking this bug as being blocked on that one.

Hm, i misread/misremembered what 981587 was about -- that was
specifically a bug how fontconfig prunes DejaVu monospace variants, not
about fontconfig preferring Bitstream Vera over DejaVu.

I think this bug needs to be fixed in fontconfig somehow -- fontconfig
needs to prefer DejaVu fonts over Bitstream Vera when DejaVu is
available.

But i don't understand how fontconfig works well enough to know how to
change this prioritization.

   --dkg


signature.asc
Description: PGP signature


Bug#981577: Chromium mis-renders UTF-8 text tables due to Bitstream Vera Sans Mono missing Unicode box drawing characters

2022-02-25 Thread Daniel Kahn Gillmor
Control: block 981577 with 981587

I've looked into #981577 a bit more, and i have more thoughts on the
fixes i'd proposed earlier:

On Mon 2021-02-01 12:51:12 -0500, Daniel Kahn Gillmor wrote:

>  - Bitstream Vera Mono could implement monospaced glyphs for the unicode
>box drawing characters

Upstream appears to be dead, and the trademark arrangement for Bitstream
Vera appears to prohibit a modified font being distributed under the
same name without upstream approval.

So, I don't think this is a possible fix.  It looks to me like
distributing Vera as "Bitstream Vera" is problematic for the archive in
this way.

>  - fontconfig could prefer more complete fonts when searching for a
>match, which would prioritize dejavu sans (or some other more
>complete font) over bitstream vera
>
>  - fontconfig could manually prefer DejaVu Sans Mono over Bitstream Vera
>Mono when given the search string "monospace"

Either of these approaches point to https://bugs.debian.org/981587 so
i'm marking this bug as being blocked on that one.

>  - chromium, when substituting missing glyphs in a monospace font, could
>ensure that the substitute glyphs are appropriately sized for the
>font they are filling in for.
>
>  - chromium could hardcode (and depend on?) a preferred monospace font
>by default that is more complete than Bistream Vera as its default
>monospace font

I don't know how to get chromium to do either of these fixes.  I'd
expect that chromium should just rely on fontconfig directly, but i
don't know for sure that this is the case.

>  - We could drop ttf-bitstream-vera from the archive, which would affect
>packages like python-matplotlib-data, gravit-data, and the ~20 other
>packages that Depend on ttf-bitstream-vera directly.  I can't afford
>to just purge the package from my system because i need matplotlib :(

the list is smaller now than it used to be but it's not empty:

  Depends: freewheeling
  Depends: gearhead2-data
  Depends: gravit-data
  Depends: k3d-data (>= 1.10)
  Depends: libmupen64plus2
  Depends: libncarg0
  Depends: libprojectm3
  Depends: loganalyzer
  Depends: openmsx-data
  Depends: python3-django-captcha
  Depends: r-cran-fontbitstreamvera
  Depends: setbfree
  Recommends: librrd8
  Recommends: mysql-workbench
  Recommends: python3-freetype
  Recommends: vdr
  Suggests: python3-pygments

I could file bug reports against each of these packages asking them to
change their dependency from ttf-bitstream-vera to fonts-dejavu-core, or
at least depend on "fonts-dejavu-core | ttf-bitstream-vera"

That would make it easier to drop ttf-bitstream-vera from the archive in
the future, but of course there are still documents out there that refer
to ttf-bitstream-vera explicitly.  It seems likely that users will want
to have the package directly installed (or even pull it from an old
archive if we drop it in the new one).  If it's installed (even from
outside the archive), then the same problem comes up, so this doesn't
seem like a particularly robust fix.

Furthermore, ttf-bitstream-vera (probably due to its weak character
coverage) is only 600KiB, while fonts-dejavu-core is nearly 3MiB.  This
suggests that a minimalist debian system with limited character
requirements is likely to want to use Bitstream Vera just due to size
constraints.

Probably, debian will be obliged to distribute ttf-bitstream-vera in its
current unchanged form indefinitely :/

>  - fonts-dejavu-core (or fonts-dejavu-extra?) could Provide:
>ttf-bitstream-vera, since it appears to provide aliases for Bitstream
>Vera in e.g. /etc/fonts/conf.avail/57-dejavu-sans-mono.conf -- i
>don't know whether this is sufficient for all the explicit
>Dependencies of ttf-bitstream-vera, though.

This doesn't seem to be sufficient for all users of fonts.  I tested it
with Libreoffice.  When i have an .odt file with a stylesheet that
references "Bitstream Vera Sans", libreoffice renders the text from
DejaVu Sans, but it indicates in its font dropdown box that Bitstream
Vera Sans is not installed: the font name shows up in the dropdown box
in italics, the way that other missing fonts appear.

Given the above analysis, i think this problem will need to be fixed in
fontconfig, maybe by fixing #981587.

--dkg


signature.asc
Description: PGP signature


Bug#1006412: ruby-kramdown-rfc2629: upstream is now kramdown-rfc (and new verson 1.6.2 is available)

2022-02-24 Thread Daniel Kahn Gillmor
Package: src:ruby-kramdown-rfc2629
Version: 1.5.24-0.1
Severity: wishlist

Ruby's kramdown-rfc2629 gem is now named kramdown-rfc, and 1.6.2 is
available from upstream.  (see https://github.com/cabo/kramdown-rfc for
more details about the name change)

At the cost of a trip through NEW and a dummy/transitional package,
debian packaging for this tool should probably follow the name change
when the new version is imported.

This probably means coordinating to move/rename the salsa project within
the ruby-team group as well, from ruby-team/ruby-kramdown-rfc2629 to
ruby-team/ruby-kramdown-rfc .

I'm not on the ruby team, and am unlikely to have the bandwidth to join
it, but if i can help with this transition, please let me know.

--dkg


signature.asc
Description: PGP signature


Bug#1004452: bullseye-pu: package gnupg2/2.2.27-2+deb11u1

2022-02-19 Thread Daniel Kahn Gillmor
On Sat 2022-02-19 17:09:21 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed d-i
>
> On Thu, 2022-01-27 at 17:02 -0500, Daniel Kahn Gillmor wrote:
>> Please consider an update to GnuPG in debian bullseye, from version
>> 2.2.27-2 to 2.2.27-2+deb11u1.
>> 
>
> The version mentioned above is correct, but the proposed changelog is
> not:
>
> +gnupg2 (2.2.27-2+deb11+1) bullseye; urgency=medium
>
> (it should be "deb11u1", not "deb11+1").

thanks for catching that, i've corrected it and pushed the corrected
version to the debian/bullseye branch in salsa.

> That looks fine to me, but will need a d-i ack as the package builds a
> udeb; tagging and CCing accordingly.

Understood -- i'll wait for a d-i ack before uploading.

   --dkg


signature.asc
Description: PGP signature


Bug#1004946: Cannot hold down backspace to delete password

2022-02-14 Thread Daniel Kahn Gillmor
Control: forwarded 1004946 
https://gitlab.freedesktop.org/xorg/lib/libxi/-/issues/13

On Sun 2022-02-13 08:26:24 -0800, Jamie Zawinski wrote:
>> Why did you switch to it? Or am I misunderstanding that you did?
>
> For the new security model. No other way to increase the privilege separation.

Thanks for these explanations, I think I understand the situation better
now.  I've forwarded the concern upstream at the link above.  Maybe the
libXi devs will be able to address the problem, or at least propose an
alternate solution that lets XScreenSaver retain the privilege
separation and the user-friendly key repeat functionality.

   --dkg


signature.asc
Description: PGP signature


Bug#1004946: Cannot hold down backspace to delete password

2022-02-12 Thread Daniel Kahn Gillmor
On Fri 2022-02-11 09:16:09 -0800, Jamie Zawinski wrote:
> On Feb 11, 2022, at 8:51 AM, Daniel Kahn Gillmor  wrote:
>> 
>> If the regression is caused by changes in how XInput/XInput2 behave,
>> then maybe this problem should be addressed in that package.  I'm
>> reassigning this report there and marking that it affects xscreensaver.
>
> I have no reason to believe that XInput2 has not always behaved that way. You 
> are noticing it now because XScreenSaver only began using XInput2 as of 6.x.
>
> Stating the problem/annoyance more concisely:
>
> XInput2 does not send auto-repeat press/release events in the same manner as 
> XNextEvent.

Thanks for the prompt feedback, Jamie!

If you're saying that XInput2 *cannot* send auto-repeat press/release
events, and no tool that uses XInput2 can handle auto-repeating keys,
that seems like a problem with XInput2 -- hence the transfer of the bug.

If you're saying that XScreenSaver is not interpreting the signal of a
held-down backspace key, then it seems like a bug in XScreenSaver to me.

If neither of those is the case, then i'm not understanding the
conversation on this bug report, only observing that the problem for
users still remains.

Regards,

  --dkg


signature.asc
Description: PGP signature


Bug#1004946: Cannot hold down backspace to delete password

2022-02-11 Thread Daniel Kahn Gillmor
Control: reopen 1004946
Control: reassign 1004946 libxi6 2:1.8-1
Control: affects 1004946 + xscreensaver

On Fri 2022-02-04 07:29:55 +0100, martin f krafft wrote:
> Package: xscreensaver
> Version: 6.02+dfsg1-2
> Severity: normal
>
> If I know I mistyped the password, I am used to holding down 
> backspace to erase all characters, effectively making use of the key 
> repeat. This stopped working with version 6, and now holding down 
> the key only ever removes a single character.

On Thu 2022-02-03 22:59:34 -0800, Jamie Zawinski wrote:

> For some reason, the XInput2 extension doesn't auto-repeat certain
> keys that used to auto-repeat when read the "old" way. Unfortunately
> there's nothing I can do about this. I process only the keystrokes
> that I receive.
>
> However you can use the traditional keystrokes ^U and ^X to clear the
> whole line.

As i understand it, XInput2 is provided by libxi6, from the libxi source
package.

This is a significant regression in user experience, and definitely
something confusing for users who see the backspace key and don't
understand why it's not repeating as expected.  Ctrl-U or Ctrl-X might
be an acceptable workaround for weirdos like the three of us, but it is
decidedly user-unfriendly for a screensaver to work this way.  Holding
down backspace to clear screwed up keystrokes is an incredibly common
usage pattern for password entry fields.

If the regression is caused by changes in how XInput/XInput2 behave,
then maybe this problem should be addressed in that package.  I'm
reassigning this report there and marking that it affects xscreensaver.

--dkg


signature.asc
Description: PGP signature


Bug#1005300: RFP: pgpainless -- OpenPGP implementation in Java

2022-02-10 Thread Daniel Kahn Gillmor
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: d...@fifthhorseman.net

* Package name: pgpainless
  Version : 1.0.1
  Upstream Author : Paul Schaub 
* URL : https://pgpainless.org/
* License : Apache 2.0
  Programming Lang: Java
  Description : OpenPGP implementation in Java

PGPainless is a modern implementation of OpenPGP in Java. It offers an
ergonomic interface on top of the BouncyCastle cryptographic toolkit
that makes it straightforward to deal wth OpenPGP data.

Upstream offers both a programmatic interface and a command line
interface, for simple integration into other projects.  The codebase
has received a security audit, and it is actively maintained by a
responsive and friendly upstream.



Bug#1001251: [Pkg-rust-maintainers] Bug#1001251: debcargo changed names of a feature package

2022-02-08 Thread Daniel Kahn Gillmor
Hi Ximin--

thanks for the followup.

On Tue 2022-02-08 15:50:31 +, Ximin Luo wrote:
> Is your issue simply this? https://github.com/rust-lang/cargo/issues/7769

I think if this were fixed, then i could probably convince the sequoia
upstreams to mark the optional-dependency features as non-public,
leaving only their explicit, outwardly-defined features.  They're pretty
committed to API stability and they understand these details.

> If so please close this bug as invalid, since it is not debcargo's 
> responsibility.

While cargo closing that bug would solve my specific problem (after i
convince the relevant upstreams to do the work to think it through), I
don't think that's the only way to solve it, and i also don't think it
solves the general problem.

Even if the rust ecosystem were to allow packages to offer non-public
features, there are still situations where public features could be
aliased to one another, and debcargo would need to choose one or the
other of them as a name for the feature package.  It should do this in a
deterministic way, both for simplicity and reliability, and to avoid
unnecessary churn through NEW.

   --dkg


signature.asc
Description: PGP signature


Bug#939789: faketime: Fails to parse "strict" timestamps with error message "Success"(!)

2022-02-04 Thread Daniel Kahn Gillmor
Control: forwarded 939789 https://github.com/wolfcw/libfaketime/pull/368
Control: tags 939789 + patch

On Sun 2019-09-08 20:54:36 +0200, Ben Wiederhake wrote:

> Steps to reproduce, and actual behavior in bash:
>
> $ LC_ALL=C faketime -f "2019-09-06 03:14:37 02:00" true  # "iso"
> [$? = 0]
> $ LC_ALL=C faketime -f "2019-09-06T03:14:37+02:00" true  # "iso-strict"
> Failed to parse FAKETIME timestamp: Success
> [$? = 1]

I've proposed a patch (attached) for this, and forwarded it upstream, as
this is still an issue on version 0.9.9 and even the upstream git master.

 --dkg

From 18ffd1c9bd3996ac768e9b32c40d52c4af3784fb Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Fri, 4 Feb 2022 17:32:17 -0500
Subject: [PATCH] Avoid spurious "Success" error message.

strptime(3) doesn't set errno, so when it was failing, calling perror()
meant producing messages like:

Failed to parse FAKETIME timestamp: Success

Rather than use perror(), just send the warning message directly to
stderr.

This was first reported in https://bugs.debian.org/939789

diff --git a/src/libfaketime.c b/src/libfaketime.c
index 4ce88ca..68678b8 100644
--- a/src/libfaketime.c
+++ b/src/libfaketime.c
@@ -2374,8 +2374,8 @@ static void parse_ft_string(const char *user_faked_time)
   }
   else
   {
-perror("libfaketime: In parse_ft_string(), failed to parse FAKETIME timestamp");
-fprintf(stderr, "Please check specification %s with format %s\n", user_faked_time, user_faked_time_fmt);
+fprintf(stderr, "libfaketime: In parse_ft_string(), failed to parse FAKETIME timestamp.\n"
+"Please check specification %s with format %s\n", user_faked_time, user_faked_time_fmt);
 exit(EXIT_FAILURE);
   }
   break;
@@ -2418,7 +2418,7 @@ static void parse_ft_string(const char *user_faked_time)
   }
   else
   {
-perror("libfaketime: In parse_ft_string(), failed to parse FAKETIME timestamp");
+fprintf(stderr, "libfaketime: In parse_ft_string(), failed to parse FAKETIME timestamp.\n");
 exit(EXIT_FAILURE);
   }
 
-- 
2.34.1



signature.asc
Description: PGP signature


Bug#831275: faketime: DEP-8 test doesn't work in all timezones

2022-02-04 Thread Daniel Kahn Gillmor
Version: 0.9.7-1

Sorry for the delay in noting this fix in the BTS.  it was fixed in
commit 5ba8629d49a5a208c6ee00f2f79495917a96a172 (using a slightly
different changeset) four years ago :)

   --dkg

On Thu 2016-07-14 13:24:42 +0200, Jakub Wilk wrote:
> Source: faketime
> Version: 0.9.6-7
> Tags: patch
>
> Ooops, the test I included in #830588 happens to work in my timezone, 
> but not necessarily elsewhere. Here's a patch to fix it.
>
> -- 
> Jakub Wilk
> --- a/debian/tests/smoketest
> +++ b/debian/tests/smoketest
> @@ -1,3 +1,4 @@
>  #!/bin/bash
>  export LC_ALL=C
> -exec diff -u <(echo 'Wed Dec 24 07:15:42 UTC 2008') <(faketime '2008-12-24 
> 08:15:42' date -u)
> +export TZ=UTC
> +exec diff -u <(echo 'Wed Dec 24 08:15:42 UTC 2008') <(faketime '2008-12-24 
> 08:15:42' date)



Bug#1004452: gnuplot 5.4.1+dfsg1-1+deb11u1 flagged for acceptance

2022-02-03 Thread Daniel Kahn Gillmor
Hi Adam--

No problem, i've made way worse copy/paste mistakes myself 

On Thu 2022-02-03 06:41:21 +, Adam D. Barratt wrote:
> Control: tags -1 - pending

For clarity, I'm assuming this means that the GnuPG upload for bullseye
(#1004452) is *not* yet approved, and i will wait for additional
feedback from you or other release managers before continuing.

Thanks for the quick followup!

--dkg


signature.asc
Description: PGP signature


Bug#1004452: gnuplot 5.4.1+dfsg1-1+deb11u1 flagged for acceptance

2022-02-02 Thread Daniel Kahn Gillmor
Hi Adam--

Thanks for reviewing, but this is confusing to me.  I thought 1004452
was for GnuPG gnupg2/2.2.27-2+deb11u1, not gnuplot
5.4.1+dfsg1-1+deb11u1.  Which one did you mean to accept with this
message?

  --dkg

On Wed 2022-02-02 20:30:58 +, Adam D Barratt wrote:
> package release.debian.org
> tags 1004452 = bullseye pending
> thanks
>
> Hi,
>
> The upload referenced by this bug report has been flagged for acceptance into 
> the proposed-updates queue for Debian bullseye.
>
> Thanks for your contribution!
>
> Upload details
> ==
>
> Package: gnuplot
> Version: 5.4.1+dfsg1-1+deb11u1
>
> Explanation: fix division by zero [CVE-2021-44917]


signature.asc
Description: PGP signature


Bug#1001251: debcargo changed names of a feature package

2022-02-02 Thread Daniel Kahn Gillmor
Control: affects 1001251 + src:rust-sequoia-openpgp

On Tue 2021-12-07 03:47:32 +0400, Daniel Kahn Gillmor wrote:
> note that previously, …+compression-deflate-dev Provides: a virtual 
> …+flate2-dev
> package.  Now, …+flate2-dev Provides: a virtual
> …+compression-deflate-dev package.

The same thing is happening for rust-sequoia-openpgp: in 1.3.0 (built
with debcargo 2.4.4), rust-sequoia-openpgp+crypto-nettle-dev used to
Provides: rust-sequoia-openpgp+nettle-dev

but as of 1.7.0 (built with debcargo 2.5.0), it is the opposite:
rust-sequoia-openpgp+nettle-dev used to Provides:
rust-sequoia-openpgp+crypto-nettle-dev

The sequoia-openpgp packages are much more involved in terms of
features, and i don't really want to get into the business of overriding
debian/control there, so i'm just passing it on another trip through NEW
(it's in experimental anyway as it's blocked by the rust-random 0.8
transition temporarily).

Just documenting that this is an issue for more than a single crate.

   --dkg


signature.asc
Description: PGP signature


Bug#1004452: bullseye-pu: package gnupg2/2.2.27-2+deb11u1

2022-01-27 Thread Daniel Kahn Gillmor
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: d...@fifthhorseman.net
X-Debbugs-Cc: pkg-gnupg-ma...@lists.alioth.debian.org
Control: affects -1 src:gnupg2

Please consider an update to GnuPG in debian bullseye, from version
2.2.27-2 to 2.2.27-2+deb11u1.

The fixes, by Christoph Biedel and Raphaël Hertzog, are narrowly
targeted and fix real, significant issues that a subset of users have.
They have been in debian unstable and testing for a while now without
issue:

--
  [ Raphaël Hertzog ]
  * Avoid network interaction in generator. Closes: #993578

  [ Christoph Biedl ]
  * Backport "Scd: Fix CCID driver for SCM SPR332/SPR532". Closes: #982546
--

The debdiff from the version in bullseye (2.2.27-2) is attached.

This proposed release is also available on the "debian/bullseye" branch at
the git repo for GnuPG packaging:

 https://salsa.debian.org/debian/gnupg2

Please followup on this ticket to confirm whether I should upload this
revision to bullseye's proposed updates.

Regards,

--dkg

diff -Nru gnupg2-2.2.27/debian/changelog gnupg2-2.2.27/debian/changelog
--- gnupg2-2.2.27/debian/changelog	2021-04-22 14:40:36.0 -0400
+++ gnupg2-2.2.27/debian/changelog	2022-01-27 14:46:11.0 -0500
@@ -1,3 +1,16 @@
+gnupg2 (2.2.27-2+deb11+1) bullseye; urgency=medium
+
+  [ Raphaël Hertzog ]
+  * Avoid network interaction in generator. Closes: #993578
+
+  [ Christoph Biedl ]
+  * Backport "Scd: Fix CCID driver for SCM SPR332/SPR532". Closes: #982546
+
+  [ Daniel Kahn Gillmor ]
+  * update git to point to debian/bullseye branch
+
+ -- Daniel Kahn Gillmor   Thu, 27 Jan 2022 14:46:11 -0500
+
 gnupg2 (2.2.27-2) unstable; urgency=medium
 
   * Add a NEWS entry about the end of support for ~/.gnupg/options.
diff -Nru gnupg2-2.2.27/debian/control gnupg2-2.2.27/debian/control
--- gnupg2-2.2.27/debian/control	2021-04-22 14:40:36.0 -0400
+++ gnupg2-2.2.27/debian/control	2022-01-27 14:45:43.0 -0500
@@ -43,7 +43,7 @@
  libnpth-mingw-w64-dev (>= 1.2),
  libz-mingw-w64-dev,
  mingw-w64,
-Vcs-Git: https://salsa.debian.org/debian/gnupg2.git -b debian/main
+Vcs-Git: https://salsa.debian.org/debian/gnupg2.git -b debian/bullseye
 Vcs-Browser: https://salsa.debian.org/debian/gnupg2
 Homepage: https://www.gnupg.org/
 Rules-Requires-Root: no
diff -Nru gnupg2-2.2.27/debian/gbp.conf gnupg2-2.2.27/debian/gbp.conf
--- gnupg2-2.2.27/debian/gbp.conf	2021-02-08 14:38:26.0 -0500
+++ gnupg2-2.2.27/debian/gbp.conf	2022-01-27 14:45:33.0 -0500
@@ -1,5 +1,5 @@
 [DEFAULT]
-debian-branch = debian/main
+debian-branch = debian/bullseye
 pristine-tar = True
 upstream-vcs-tag = gnupg-%(version)s
 
diff -Nru gnupg2-2.2.27/debian/patches/cherry-picked/1617856888.gnupg-2.3.0-4-gab66c4357.scd-fix-ccid-driver-for-scm-spr332-spr532.patch gnupg2-2.2.27/debian/patches/cherry-picked/1617856888.gnupg-2.3.0-4-gab66c4357.scd-fix-ccid-driver-for-scm-spr332-spr532.patch
--- gnupg2-2.2.27/debian/patches/cherry-picked/1617856888.gnupg-2.3.0-4-gab66c4357.scd-fix-ccid-driver-for-scm-spr332-spr532.patch	1969-12-31 19:00:00.0 -0500
+++ gnupg2-2.2.27/debian/patches/cherry-picked/1617856888.gnupg-2.3.0-4-gab66c4357.scd-fix-ccid-driver-for-scm-spr332-spr532.patch	2022-01-27 14:44:28.0 -0500
@@ -0,0 +1,48 @@
+Subject: Scd: Fix CCID driver for SCM SPR332/SPR532
+Origin: gnupg-2.3.0-4-gab66c4357
+Upstream-Author: NIIBE Yutaka 
+Date: Thu Apr 8 13:41:28 2021 +0900
+Bug-Debian: https://bugs.debian.org/982546
+
+* scd/ccid-driver.c (ccid_vendor_specific_pinpad_setup): New.
+(ccid_vendor_specific_setup): Only send CLEAR_HALT.
+(ccid_transceive_secure): Each time, use send_escape_cmd.
+
+--
+
+GnuPG-bug-id: 5297
+Signed-off-by: NIIBE Yutaka 
+
+--- a/scd/ccid-driver.c
 b/scd/ccid-driver.c
+@@ -1304,10 +1304,20 @@
+ {
+   if (handle->id_vendor == VENDOR_SCM && handle->id_product == SCM_SPR532)
+ {
++  libusb_clear_halt (handle->idev, handle->ep_intr);
++}
++  return 0;
++}
++
++
++static int
++ccid_vendor_specific_pinpad_setup (ccid_driver_t handle)
++{
++  if (handle->id_vendor == VENDOR_SCM && handle->id_product == SCM_SPR532)
++{
+   DEBUGOUT ("sending escape sequence to switch to a case 1 APDU\n");
+   send_escape_cmd (handle, (const unsigned char*)"\x80\x02\x00", 3,
+NULL, 0, NULL);
+-  libusb_clear_halt (handle->idev, handle->ep_intr);
+ }
+   return 0;
+ }
+@@ -3583,6 +3593,8 @@
+   if (pininfo->fixedlen < 0 || pininfo->fixedlen >= 16)
+ return CCID_DRIVER_ERR_NOT_SUPPORTED;
+ 
++  ccid_vendor_specific_pinpad_setup (handle);
++
+   msg = send_buffer;
+   msg[0] = cherry_mode? 0x89 : PC_to_RDR_Secure;
+   msg[5] = 0; /* slot */
diff -Nru gnupg2-2.2.27/debian/patches/series gnupg2-2.2.27/debian/patches/series
--- gnupg2-2.2.27/deb

Bug#1003313: [pkg-gnupg-maint] Bug#1003313: closed by Debian FTP Masters (reply to Daniel Kahn Gillmor ) (Bug#1003313: fixed in libgpg-error 1

2022-01-17 Thread Daniel Kahn Gillmor
On Sat 2022-01-15 10:43:13 +0100, Helmut Grohne wrote:
> I disagree. The version proposed by me was:
>
>> -*-*-linux-gnu*)
>> +*-*-linux-*)
>
> The version that actually ended up upstream was:
>
> +*-*-linux-gnu* | *-*-linux-musl)
>
> The thing that it doesn't match is:
>
> arm-linux-musleabihf

Thanks for this followup, Helmut, and for your persistence.

I've re-opened the upstream bug report with this information.  If
upstream agrees that this makes sense, i'm happy to update the patch for
the debian package.

i appreciate your work on getting (and keeping) alternate debian
architectures in healthy shape!  This is an important backstop for
f/loss ecosystem health.

--dkg


signature.asc
Description: PGP signature


Bug#1003313: [pkg-gnupg-maint] Bug#1003313: libgpg-error FTCBFS for musl: refuses to use generic lock object detection

2022-01-08 Thread Daniel Kahn Gillmor
Control: forwarded 1003313 https://dev.gnupg.org/T5762

On Sat 2022-01-08 01:15:16 +0100, Helmut Grohne wrote:
> A while ago, libgpg-error gained a feature that enabled configure to
> introspect lock objects without running code (via objdump).
> Unfortunately, this code is only used for glibc. When cross building for
> e.g. musl, it falls back to the old way where you'd have to collect the
> results. And since those aren't collected, it fails. The objdump trick
> should work on all Linux systems regardless of the C library in used.

Thanks for this suggestion.  It looks like upstream used to permit this
for all C libraries, and i don't understand why they changed it either.

I've forwarded the suggestion upstream (see the URL above).  If upstream
is ok with it, i'm happy to apply it in debian.

 --dkg


signature.asc
Description: PGP signature


Bug#993857: [pkg-gnupg-maint] Bug#993857: Bug#993857: gnupg2: Please remove librsvg2-bin from BD

2022-01-08 Thread Daniel Kahn Gillmor
On Sat 2022-01-08 21:39:25 +0100, Laurent Bigonville wrote:
> My understanding of the policy has always been that the source tarball 
> shipped in debian must indeed contain all the files in their "preferred 
> form of modification" but the fact that the resulting artifact has to be 
> rebuilt during the build of the package was merely a recommendation.

This is almost certainly not the case for executable code -- if someone
upstream shipped an x86_64 binary, as a debian user i would be pretty
upset if the upstream binary was just passed through directly.

But whether executable code or not, the requirement isn't just that the
source code is available, but that the toolchain is also all free
software, right?  (there may be some exceptions for bootstrapping
tooling, but afaict we're working on trying to fix even that with
diverse dual compiling, rebootstrap, and reproducible builds projects).

The only way that i can see to be confident that the toolchain is
present is to actually do the build, right?  and if we do the build and
it's different than the generated object shipped by upstream, which one
should we prefer?

> My main concern here was to be certain that gnupg can build all 
> architectures even the one without rust support and your proposal allows 
> this, so it's good for me and if you think it's better to rebuild the 
> image during the build I've no objections.

makes sense (and i share your goal)!

> The fact that there is a rendering problem with the .png shipped in the 
> upstream tarball should be reported in any case I think.

Agreed, though i'd just as soon ask upstream to stop shipping the png in
their tarball :)

  --dkg


signature.asc
Description: PGP signature


Bug#994092: gkbd-capplet: keyboard layout display garbled for Hebrew layouts

2022-01-08 Thread Daniel Kahn Gillmor
Control: retitle 994092 gkbd-capplet: keyboard layout display garbled for RTL 
(e.g., Hebrew and Arabic) layouts
Control: forwarded 994092 https://gitlab.gnome.org/GNOME/libgnomekbd/-/issues/8
Control: tags 994092 + patch

On Sat 2021-09-11 16:01:58 +0100, Toni Mueller wrote:
> I have added Hebrew keyboard layouts and then tried to see the layout
> via gkbd-keyboard-display. For Hebrew layouts - I tried 'Hebrew' and
> 'Hebrew (Bibilical)', the display is a bit garbled, showing dotted
> circles instead of the glyphs, although I have installed every font
> containing Hebrew that I could find, using 'apt'. Using the Hebrew
> script in eg. LibreOffice Writer is perfectly possible, it's just this
> program that does not tell me what the keyboard layout actually is.

I ran into the same problem with Arabic layouts.  I reported it upstream
at the URL above, and the attached patch (also forwarded upstream at
https://gitlab.gnome.org/GNOME/libgnomekbd/-/merge_requests/9) solves
the problem.

--dkg

diff --git a/libgnomekbd/gkbd-keyboard-drawing.c b/libgnomekbd/gkbd-keyboard-drawing.c
index da526d2..b5888ee 100644
--- a/libgnomekbd/gkbd-keyboard-drawing.c
+++ b/libgnomekbd/gkbd-keyboard-drawing.c
@@ -666,12 +666,13 @@ set_markup (GkbdKeyboardDrawingRenderContext * context, gchar * txt)
 	}
 }
 
-static void
+static PangoDirection
 set_key_label_in_layout (GkbdKeyboardDrawingRenderContext * context,
 			 guint keyval)
 {
 	gchar buf[5];
 	gunichar uc;
+	PangoDirection dir = PANGO_DIRECTION_LTR;
 
 	switch (keyval) {
 	case GDK_KEY_Scroll_Lock:
@@ -825,6 +826,7 @@ set_key_label_in_layout (GkbdKeyboardDrawingRenderContext * context,
 	default:
 		uc = gdk_keyval_to_unicode (keyval);
 		if (uc != 0 && g_unichar_isgraph (uc)) {
+			dir = pango_unichar_direction (uc);
 			buf[g_unichar_to_utf8 (uc, buf)] = '\0';
 			set_markup (context, buf);
 		} else {
@@ -846,6 +848,7 @@ set_key_label_in_layout (GkbdKeyboardDrawingRenderContext * context,
 set_markup (context, "");
 		}
 	}
+	return dir;
 }
 
 
@@ -927,6 +930,8 @@ draw_key_label_helper (GkbdKeyboardDrawingRenderContext * context,
 		   gboolean is_pressed)
 {
 	gint label_x, label_y, label_max_width, ycell;
+	PangoAlignment align;
+	PangoDirection dir;
 
 	if (keysym == 0)
 		return;
@@ -935,46 +940,36 @@ draw_key_label_helper (GkbdKeyboardDrawingRenderContext * context,
 		(unsigned) keysym, (char) keysym, (int) glp);
 #endif
 
+	ycell = ((glp == GKBD_KEYBOARD_DRAWING_POS_BOTTOMLEFT) ||
+		 (glp == GKBD_KEYBOARD_DRAWING_POS_BOTTOMRIGHT));
+	rotate_coordinate (x, y, x + padding,
+			   y + padding + (height -
+	  2 * padding) *
+			   ycell * 4 / 7, angle, _x,
+			   _y);
+	label_max_width = PANGO_SCALE * (width - 2 * padding);
+	dir = set_key_label_in_layout (context, keysym);
+
 	switch (glp) {
 	case GKBD_KEYBOARD_DRAWING_POS_TOPLEFT:
 	case GKBD_KEYBOARD_DRAWING_POS_BOTTOMLEFT:
-		{
-			ycell =
-			glp == GKBD_KEYBOARD_DRAWING_POS_BOTTOMLEFT;
-
-			rotate_coordinate (x, y, x + padding,
-	   y + padding + (height -
-			  2 * padding) *
-	   ycell * 4 / 7, angle, _x,
-	   _y);
-			label_max_width =
-			PANGO_SCALE * (width - 2 * padding);
-			break;
-		}
+		if (dir == PANGO_DIRECTION_RTL)
+			align = PANGO_ALIGN_RIGHT;
+		else
+			align = PANGO_ALIGN_LEFT;
+		break;
 	case GKBD_KEYBOARD_DRAWING_POS_TOPRIGHT:
 	case GKBD_KEYBOARD_DRAWING_POS_BOTTOMRIGHT:
-		{
-			ycell =
-			glp == GKBD_KEYBOARD_DRAWING_POS_BOTTOMRIGHT;
-
-			rotate_coordinate (x, y,
-	   x + padding + (width -
-			  2 * padding) *
-	   4 / 7,
-	   y + padding + (height -
-			  2 * padding) *
-	   ycell * 4 / 7, angle, _x,
-	   _y);
-			label_max_width =
-			PANGO_SCALE * ((width - 2 * padding) -
-	   (width - 2 * padding) * 4 / 7);
-			break;
-		}
+		if (dir == PANGO_DIRECTION_RTL)
+			align = PANGO_ALIGN_LEFT;
+		else
+			align = PANGO_ALIGN_RIGHT;
+		break;
 	default:
 		return;
 	}
-	set_key_label_in_layout (context, keysym);
 	pango_layout_set_width (context->layout, label_max_width);
+	pango_layout_set_alignment (context->layout, align);
 	label_y -= (pango_layout_get_line_count (context->layout) - 1) *
 	(pango_font_description_get_size (context->font_desc) /
 	 PANGO_SCALE);


signature.asc
Description: PGP signature


Bug#992585: pluto crashes during connection setup (IKEv2, x509)

2022-01-08 Thread Daniel Kahn Gillmor
Hi Phil--

in https://bugs.debian.org/992585, Phil Nightowl wrote:

> Pluto crashes reproducibly when negotiating tunnel type connection on 
> the responder side.

Can you confirm whether this is still a problem with the version of
libreswan in debian stable (4.3-1) or a more recent version in testing
or unstable?

Sorry, i haven't been able to set up a set of hosts and networks that
would replicate the scenario you're describing, so i am not able to
reproduce it.

 --dkg


signature.asc
Description: PGP signature


Bug#995824: ruby-kramdown-rfc2629: new version available (1.5.24)

2021-12-28 Thread Daniel Kahn Gillmor
I've just uploaded ruby-kramdown-rfc2629 version 1.5.24-0.1 as an NMU to
unstable, since it ended up being a fairly straightforward update.

I've pushed the changes in git (on "master", "pristine-tar", and
"upstream" branches) to salsa.  I made an MR for the changes to "master"
here:

   https://salsa.debian.org/ruby-team/ruby-kramdown-rfc2629/-/merge_requests/7

The debdiff between 1.3.35-1 and 1.5.24-0.1 is attached here, if you
prefer it in that form.

   --dkg



ruby-kramdown-rfc2629_1.3.35-1_1.5.24-0.1.debdiff.gz
Description: application/gzip


signature.asc
Description: PGP signature


Bug#995824: New version available (1.5.6)

2021-12-28 Thread Daniel Kahn Gillmor
Control: retitle 995824 ruby-kramdown-rfc2629: new version available (1.5.24)

On Wed 2021-10-06 15:41:59 +0200, chrysn wrote:
> The latest available version (1.5.6) is necessary for many recent
> drafts, please consider updating the packages.

Upstream now has version 1.5.24 available.  There are a few updates to
dependencies , but they are all available in debian stable, so I think
it should be a straightforward upgrade.

--- a/kramdown-rfc2629.gemspec
+++ b/kramdown-rfc2629.gemspec
@@ -1,15 +1,18 @@
 spec = Gem::Specification.new do |s|
   s.name = 'kramdown-rfc2629'
-  s.version = '1.3.35'
+  s.version = '1.5.24'
   s.summary = "Kramdown extension for generating RFC 7749 XML."
   s.description = %{An RFC7749 (XML2RFC) generating backend for Thomas 
Leitner's
 "kramdown" markdown parser.  Mostly useful for RFC writers.}
-  s.add_dependency('kramdown', '~> 1.17.0')
+  s.add_dependency('kramdown', '~> 2.3.0')
+  s.add_dependency('kramdown-parser-gfm', '~> 1.1')
   s.add_dependency('certified', '~> 1.0')
   s.add_dependency('json_pure', '~> 2.0')
-  s.files = Dir['lib/**/*.rb'] + %w(README.md LICENSE kramdown-rfc2629.gemspec 
bin/kdrfc bin/kramdown-rfc2629 bin/doilit bin/kramdown-rfc-extract-markdown 
data/kramdown-rfc2629.erb data/encoding-fallbacks.txt data/math.json)
+  s.files = Dir['lib/**/*.rb'] + %w(README.md LICENSE kramdown-rfc2629.gemspec 
bin/kdrfc bin/kramdown-rfc2629 bin/doilit bin/kramdown-rfc-extract-markdown 
data/kramdown-rfc2629.erb data/encoding-fallbacks.txt data/math.json 
bin/kramdown-rfc-cache-subseries-bibxml bin/de-gfm)
   s.require_path = 'lib'
-  s.executables = ['kramdown-rfc2629', 'doilit', 
'kramdown-rfc-extract-markdown', 'kdrfc']
+  s.executables = ['kramdown-rfc2629', 'doilit', 
'kramdown-rfc-extract-markdown',
+   'kdrfc', 'kramdown-rfc-cache-i-d-bibxml',
+   'kramdown-rfc-cache-subseries-bibxml', 'de-gfm']
   s.required_ruby_version = '>= 2.3.0'
   # s.requirements = 'wget'
   #  s.has_rdoc = true


This update also enables using aasvg (see #1002730), as of upstream
1.5.12.  Maybe you want to add a "Recommends: aasvg" to debian/control.

Thanks for maintaining ruby-kramdown-rfc2629 in debian!

   --dkg


signature.asc
Description: PGP signature


Bug#1002730: ITP: aasvg -- Convert ASCII art diagrams into SVG

2021-12-28 Thread Daniel Kahn Gillmor
Package: wnpp
X-Debbugs-Cc: d...@fifthhorseman.net, 
pkg-javascript-de...@alioth-lists.debian.net

Severity: wishlist
Control: affects -1 src:xml2rfc

* Package name: aasvg
  Version : 0.1.7
  Upstream Author : Martin Thomson 
* URL : https://github.com/martinthomson/aasvg
* License : 2-clausse BSD
  Programming Lang: Javascript
  Description : Convert ASCII art diagrams into SVG

aasvg converts ASCII art diagrams into SVG diagrams.

This is a very simple (no package dependencies afaict) script that
runs on top of node.js.  It is available from npm with "npm install -g
aasvg", but that doesn't seem to be necessary (it runs from a git
checkout directly with nothing but the nodejs package installed on
debian).

The bulk of the code (1424 lines) is in markdeep-diagram.js, which
itself is branched from the original markdeep.js, version 1.13.

This is useful when used with xml2rfc when creating block diagrams
(see
https://github.com/cabo/kramdown-rfc2629/issues/151#issuecomment-984385748 )

I will package this in a simple way, but if anyone from the javascript
team wants to take this over to do it in a more team-preferred way,
I'd welcome any guidance.



Bug#1002710: openssh-server: Include directive in stock /etc/ssh/sshd_config does not play well with Match directives

2021-12-27 Thread Daniel Kahn Gillmor
Package: openssh-server
X-Debbugs-Cc: d...@fifthhorseman.net
Version: 1:8.7p1-2
Severity: normal

The shipped /etc/ssh/sshd_config in debian now starts with the
following directive:

Include /etc/ssh/sshd_config.d/*.conf

However, it then *also* has these directives:

PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
PrintMotd no
AcceptEnv LANG LC_*
Subsystem   sftp/usr/lib/openssh/sftp-server


If an admin puts a Match block (or several Match blocks) inside one of
the /etc/ssh/sshd_config.d/*.conf files, it's not clear how that match
block will interact with these updated bits of configuration.

For example, if /etc/ssh/sshd_config.d/constrainedusers.conf contains:


Match Group constrainedusers
  ForceCommand restricted-shell
  AllowAgentForwarding no
  AllowTcpForwarding no
  X11Forwarding no


Then it looks like all the rest of the directives in
/etc/ssh/sshd_config will only apply to this Matched group, rather
than to the server as a whole.

This makes it awkward to drop Match block directives in the config
dir.

I haven't tested this enough to know what the right fix is, because
there doesn't seem to be a clear way to get out of a Match block.
Perhaps a "Match All" immediately after the Include directive?

(also, since it's first-defined-directive wins, it'd be nice to have
some handily-available documentation (maybe in the comment above the
Include directive?) about the expected sort order of globbed include
directives like this.  looking in the source, it looks like it's going
to be dependent on the implementation of the glob(3) call from the
standard library (or from the openbsd-compat/glob.h wrapper), both of
which have a GLOB_NOSORT flag, which isn't set by the invocation in
servconf.c.  But it's not clear to me what sort order glob() uses --
is it locale-dependent, for example?)

Sorry to raise more questions than answers here.  thanks for the great
work maintaining openssh in debian!

--dkg


signature.asc
Description: PGP signature


Bug#1001656: rust-quickcheck: new upstream release 1.0.3

2021-12-13 Thread Daniel Kahn Gillmor
Package: src:rust-quickcheck
Version: 0.9.2-1.1
Control: affects -1 src:rust-rand src:rust-env-logger src:rust-sequoia-openpgp

The quickcheck crate has released version 1.0 a while back.

Some crates are starting to depend on that semver bump (in particular,
i noticed this becausei've just uploaded rust-xxhash-rust to NEW, and it
depends on version 1.0).

This new version itself depends on:

 - rand 0.8 (unstable only has version 0.7.3-3)
 - env_logger 0.8.2 (unstable already has 0.9.0-1)

here's the list-rdeps result, showing that this might require a lot of
tweaks:

$ ./dev/list-rdeps.sh quickcheck
Versions of rust-quickcheck in unstable:
  librust-quickcheck+default-dev   0.9.2-1.1   
  librust-quickcheck-dev   0.9.2-1.1   
  librust-quickcheck+env-logger-dev0.9.2-1.1   
  librust-quickcheck+log-dev   0.9.2-1.1   
  librust-quickcheck+regex-dev 0.9.2-1.1   
  librust-quickcheck+use-logging-dev   0.9.2-1.1   

Versions of rdeps of rust-quickcheck in unstable, that also exist in testing:
  librust-im-rc+quickcheck-dev 15.0.0-1 depends on  
   librust-quickcheck-0.9+default-dev, 
  librust-petgraph+all-dev 0.5.0-1  depends on  
   librust-quickcheck-0.9-dev | librust-quickcheck-0.8-dev, 
  librust-petgraph+quickcheck-dev  0.5.0-1  depends on  
   librust-quickcheck-0.9-dev | librust-quickcheck-0.8-dev, 
  librust-quickcheck+default-dev   0.9.2-1.1depends on  
   librust-quickcheck+regex-dev (= 0.9.2-1.1), 
librust-quickcheck+use-logging-dev (= 0.9.2-1.1), 

Source packages in unstable whose autopkgtests are triggered by rust-quickcheck:
  rust-bumpalo 3.7.0-3  triggered 
by librust-quickcheck+default-dev=0.9.2-1.1
  rust-bytecount   0.6.0-1  triggered 
by librust-quickcheck+default-dev=0.9.2-1.1
  rust-bzip2   0.4.1-2  triggered 
by librust-quickcheck+default-dev=0.9.2-1.1
  rust-cast0.2.3-2  triggered 
by librust-quickcheck+default-dev=0.9.2-1.1
  rust-diff0.1.12-1 triggered 
by librust-quickcheck+default-dev=0.9.2-1.1
  rust-half1.6.0-2  triggered 
by librust-quickcheck+default-dev=0.9.2-1.1
  rust-libsystemd  0.2.1-2  triggered 
by librust-quickcheck+default-dev=0.9.2-1.1
  rust-muldiv  0.2.1-1  triggered 
by librust-quickcheck+default-dev=0.9.2-1.1
  rust-quickcheck-macros   0.9.1-2  triggered 
by librust-quickcheck+default-dev=0.9.2-1.1
  rust-yaml-rust   0.4.5-1  triggered 
by librust-quickcheck+default-dev=0.9.2-1.1
  rust-zmq 0.9.2-2  triggered 
by librust-quickcheck+default-dev=0.9.2-1.1
  rust-byteorder   1.4.3-2  triggered 
by librust-quickcheck-dev=0.9.2-1.1
  rust-flate2  1.0.22-1 triggered 
by librust-quickcheck-dev=0.9.2-1.1
  rust-itertools   0.10.1-1 triggered 
by librust-quickcheck-dev=0.9.2-1.1
  rust-regex   1.3.9-1  triggered 
by librust-quickcheck-dev=0.9.2-1.1
  rust-sequoia-openpgp 1.1.0-3  triggered 
by librust-quickcheck-dev=0.9.2-1.1
  rust-sequoia-openpgp 1.3.0-4  triggered 
by librust-quickcheck-dev=0.9.2-1.1

This might be a kind of messy transition, so i'm opening this ticket to
keep track of it.

  --dkg


signature.asc
Description: PGP signature


Bug#1001279: bullseye-pu: package publicsuffix/20211207.1025-0+deb11u1

2021-12-08 Thread Daniel Kahn Gillmor
On Tue 2021-12-07 19:03:57 +0200, Daniel Kahn Gillmor wrote:
> Package: release.debian.org
> Severity: normal
> Tags: bullseye
> User: release.debian@packages.debian.org
> Usertags: pu
> X-Debbugs-Cc: d...@fifthhorseman.net
> Control: affects -1 src:publicsuffix
>
> Please consider an update to publicsuffix in debian bullseye.
>
> This package reflects the state of the network, and keeping it current
> is useful for all the packages that depend on it.
>
> The debdiff from the previous version in bullseye is attached.
>
> This proposed release is also available at the
> "publicsuffix_debian/20211207.1025-0+deb11u1" tag on the "debian/bullseye" 
> branch at
> the git repo for publicsuffix packaging:
>
> https://salsa.debian.org/debian/publicsuffix
>
> Please followup on this ticket to confirm whether I should upload this
> revision to bullseye.

Apologies, i just read a late-received message about #999427 and
misinterpreted it as about this report.  I went ahead and uploaded
20211207.1025-0+deb11u1 as a result.  (this is one additional month of
updated data beyond the authorized/accepted 20211109.1735-0+deb11u1)

Feel free to reject it if you think that's appropriate, my feelings
won't be hurt ☺.  sorry about the confusion!

  --dkg


signature.asc
Description: PGP signature


Bug#1001280: buster-pu: package publicsuffix/20211207.1025-0+deb10u1

2021-12-07 Thread Daniel Kahn Gillmor
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: d...@fifthhorseman.net
Control: affects -1 src:publicsuffix

Please consider an update to publicsuffix in debian buster.

This package reflects the state of the network, and keeping it current
is useful for all the packages that depend on it.

The debdiff from the previous version in buster is attached.

This proposed release is also available at the
"publicsuffix_debian/20211207.1025-0+deb10u1" tag on the "debian/buster" branch 
at
the git repo for publicsuffix packaging:

https://salsa.debian.org/debian/publicsuffix

Please followup on this ticket to confirm whether I should upload this
revision to buster.


publicsuffix_20211109.1735-0+deb10u1_20211207.1025-0+deb10u1.debdiff.gz
Description: application/gzip


Bug#1001279: bullseye-pu: package publicsuffix/20211207.1025-0+deb11u1

2021-12-07 Thread Daniel Kahn Gillmor
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: d...@fifthhorseman.net
Control: affects -1 src:publicsuffix

Please consider an update to publicsuffix in debian bullseye.

This package reflects the state of the network, and keeping it current
is useful for all the packages that depend on it.

The debdiff from the previous version in bullseye is attached.

This proposed release is also available at the
"publicsuffix_debian/20211207.1025-0+deb11u1" tag on the "debian/bullseye" 
branch at
the git repo for publicsuffix packaging:

https://salsa.debian.org/debian/publicsuffix

Please followup on this ticket to confirm whether I should upload this
revision to bullseye.


publicsuffix_20211109.1735-0+deb11u1_20211207.1025-0+deb11u1.debdiff.gz
Description: application/gzip


Bug#1001251: debcargo changed names of a feature package

2021-12-06 Thread Daniel Kahn Gillmor
Package: debcargo
Version: 2.5.0-2
Control: affects -1 src:rust-buffered-reader

debcargo 2.4.4 packaged rust-buffered-reader 1.0.1 with four non-virtual
packages:

librust-buffered-reader-dev
librust-buffered-reader+bzip2-dev
librust-buffered-reader+compression-dev
librust-buffered-reader+compression-deflate-dev

buffered-reader 1.1.1 does not differ in its features at all from 1.0.1,
but when i try to package it with debcargo 2.5.0, it produces the
following list instead:

librust-buffered-reader-dev
librust-buffered-reader+bzip2-dev
librust-buffered-reader+compression-dev
librust-buffered-reader+flate2-dev

note that previously, …+compression-deflate-dev Provides: a virtual …+flate2-dev
package.  Now, …+flate2-dev Provides: a virtual
…+compression-deflate-dev package.

Note that the [features] section of the upstream Cargo.toml has not
changed:


[features]
compression = ["compression-deflate", "compression-bzip2"]
compression-bzip2 = ["bzip2"]
compression-deflate = ["flate2"]
default = ["compression"]


This change does make for a consistency between the way the packages
represent the bzip2 and flate2 features, but the fact that the
non-virtual package name has changed means we're incurring a needless
round trip through NEW, which incurs more friction between the rust and
FTP teams.

To avoid the friction, i'll probably work around by overriding the
generated debian/control, but this is kind of a sledgehammer approach to
fix a problem that i think debcargo was meant to solve.

If there are any suggestions for how to handle this more gracefully, i'd
be interested.

   --dkg


signature.asc
Description: PGP signature


Bug#999427: bullseye-pu: package publicsuffix/20211109.1735-0+deb11u1

2021-12-01 Thread Daniel Kahn Gillmor
On Wed 2021-12-01 09:43:18 +, Adam D. Barratt wrote:
> It looks like you've hit a (fairly) common issue with trying to upload
> the same upstream version to multiple suites in a short time.

thanks for keeping an eye on this, and giving a quick diagnosis, Adam.

> I assume both of your uploads included the .orig.tar.gz and were made
> close together.

This is exactly right.

> At this point your options are either to re-upload the .orig.tar.gz
> directly, or dcut and re-upload the complete bullseye upload.

i've taken the former approach, uploading directly with sftp.  hopefully
that'll work :)

> In general, either don't include the orig in the later upload, or space
> them apart so that you receive the queued confirmation for the first
> before uploading the second. (If the orig is already in the archive, as
> I assume is the case here, then you don't actually need to include it
> in either upload.)

Thanks, this is useful guidance for a workaround.

I can't help but wonder whether there isn't some way to avoid the need
for a workaround in the backend anyway, though.  for example, if the
orig.tar.gz is missing, look in neighboring suites for one with the
matching digest.  Where would i look for a bug report on the
infrastructure that would cover this?

   --dkg


signature.asc
Description: PGP signature


Bug#999427: bullseye-pu: package publicsuffix/20211109.1735-0+deb11u1

2021-12-01 Thread Daniel Kahn Gillmor
On Mon 2021-11-29 20:46:25 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
>
> On Wed, 2021-11-10 at 16:09 -0500, Daniel Kahn Gillmor wrote:
>> Please consider an update to publicsuffix in debian bullseye.
>> 
>> This package reflects the state of the network, and keeping it
>> current
>> is useful for all the packages that depend on it.
>> 
>
> Please go ahead.

thanks, uploaded just now.

--dkg
  



Bug#999427: bullseye-pu: package publicsuffix/20211109.1735-0+deb11u1

2021-12-01 Thread Daniel Kahn Gillmor
On Mon 2021-11-29 20:46:25 +, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
>
> On Wed, 2021-11-10 at 16:09 -0500, Daniel Kahn Gillmor wrote:
>> Please consider an update to publicsuffix in debian bullseye.
>> 
>> This package reflects the state of the network, and keeping it
>> current
>> is useful for all the packages that depend on it.
>> 
>
> Please go ahead.

Thanks, uploaded just now.

--dkg



Bug#999496: inkscape: Extensions >> Manage Extensions... fails unless python3-appdirs is installed

2021-11-11 Thread Daniel Kahn Gillmor
Package: inkscape
Version: 1.1.1-2
Severity: normal
X-Debbugs-Cc: d...@fifthhorseman.net

I have inkscape open.  from the Extensions menu, i choose "Manage Extensions..."

i get an error message about "appdirs" being a missing python module.

If i "apt install python3-appdirs" and then try again, a dialog box comes up.

I note that when doing that it looks like a folder
"org.inkscape.inkman" is created in ~/.config/inkscape/extensions
which includes a bunch of python code.  Does this mean that clicking
"Manage Extensions..." is actually fetching code from the internet,
installing it, and running it unsandboxed on my behalf?  if so, this
might also be a DFSG-free issue (i think browsers have run into
similar problems, e.g. with the cisco h.265 codecs, though it's not a
clean analogy).

Let me know if i can help diagnose further!  if it's not a DFSG issue,
maybe the right way to fix this is to add python3-appdirs to
Recommends.

--dkg


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

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

Versions of packages inkscape depends on:
ii  libatkmm-1.6-1v5   2.28.2-1
ii  libboost-filesystem1.74.0  1.74.0-12
ii  libc6  2.32-4
ii  libcairo2  1.16.0-5
ii  libcairomm-1.0-1v5 1.12.2-4
ii  libcdr-0.1-1   0.1.6-2
ii  libdbus-glib-1-2   0.112-2
ii  libdouble-conversion3  3.1.5-7
ii  libfontconfig1 2.13.1-4.2
ii  libfreetype6   2.11.0+dfsg-1
ii  libgc1 1:8.0.4-3
ii  libgcc-s1  11.2.0-10
ii  libgdk-pixbuf-2.0-02.42.6+dfsg-2
ii  libglib2.0-0   2.70.1-1
ii  libglibmm-2.4-1v5  2.66.2-1
ii  libgomp1   11.2.0-10
ii  libgsl25   2.7+dfsg-2
ii  libgspell-1-2  1.9.1-2
ii  libgtk-3-0 3.24.30-3
ii  libgtkmm-3.0-1v5   3.24.5-1
ii  libharfbuzz0b  2.7.4-1
ii  libjpeg62-turbo1:2.0.6-4
ii  liblcms2-2 2.12~rc1-2
ii  libmagick++-6.q16-88:6.9.11.60+dfsg-1.3
ii  libpango-1.0-0 1.48.10+ds1-1
ii  libpangocairo-1.0-01.48.10+ds1-1
ii  libpangoft2-1.0-0  1.48.10+ds1-1
ii  libpangomm-1.4-1v5 2.46.1-1
ii  libpng16-161.6.37-3
ii  libpoppler-glib8   20.09.0-3.1
ii  libpoppler102  20.09.0-3.1
ii  libpotrace01.16-2
ii  libreadline8   8.1-2
ii  librevenge-0.0-0   0.0.4-6+b1
ii  librsvg2-common2.50.7+dfsg-2
ii  libsigc++-2.0-0v5  2.10.4-2
ii  libsoup2.4-1   2.74.1-1
ii  libstdc++6 11.2.0-10
ii  libvisio-0.1-1 0.1.7-1+b1
ii  libwpg-0.3-3   0.3.3-1
ii  libx11-6   2:1.7.2-2+b1
ii  libxml22.9.12+dfsg-5
ii  libxslt1.1 1.1.34-4
ii  python33.9.7-1
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages inkscape recommends:
pn  aspell
pn  fig2dev   
pn  imagemagick   
pn  libimage-magick-perl  
pn  libwmf-bin
ii  python3-lxml  4.6.3+dfsg-1
ii  python3-numpy 1:1.19.5-1
pn  python3-scour 

Versions of packages inkscape suggests:
pn  dia   
ii  inkscape-tutorials1.1.1-2
pn  libsvg-perl   
pn  pstoedit  
pn  python3-uniconvertor  
ii  ruby  1:2.7.6

-- no debconf information



Bug#999430: buster-pu: package publicsuffix/20211109.1735-0+deb10u1

2021-11-10 Thread Daniel Kahn Gillmor
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: d...@fifthhorseman.net
Control: affects -1 src:publicsuffix

Please consider an update to publicsuffix in debian buster.

This package reflects the state of the network, and keeping it current
is useful for all the packages that depend on it.

The debdiff from the previous version in buster is attached.

This proposed release is also available at the
"publicsuffix_debian/20211109.1735-0+deb10u1" tag on the "debian/buster" branch 
at
the git repo for publicsuffix packaging:

https://salsa.debian.org/debian/publicsuffix

Please followup on this ticket to confirm whether I should upload this
revision to buster.


publicsuffix_20190925.1705-0+deb10u1_20211109.1735-0+deb10u1.debdiff.gz
Description: application/gzip


Bug#999427: bullseye-pu: package publicsuffix/20211109.1735-0+deb11u1

2021-11-10 Thread Daniel Kahn Gillmor
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: d...@fifthhorseman.net
Control: affects -1 src:publicsuffix

Please consider an update to publicsuffix in debian bullseye.

This package reflects the state of the network, and keeping it current
is useful for all the packages that depend on it.

The debdiff from the previous version in bullseye is attached.

This proposed release is also available at the
"publicsuffix_debian/20211109.1735-0+deb11u1" tag on the "debian/bullseye" 
branch at
the git repo for publicsuffix packaging:

https://salsa.debian.org/debian/publicsuffix

Please followup on this ticket to confirm whether I should upload this
revision to bullseye.


publicsuffix_20210108.1309-1_20211109.1735-0+deb11u1.debdiff.gz
Description: application/gzip


Bug#998848: thunderbird: please build against librnp-dev (and Depend: on librnp0) directly

2021-11-09 Thread Daniel Kahn Gillmor
On Mon 2021-11-08 20:11:06 +0100, Carsten Schoenert wrote:
> But I think it's a bit more complicated currently, a quick look into the 
> source shows me that the upstream build system doesn't support the usage 
> of an external librnp-dev package right now.
> This needs to get addressed upstream I think so we can build against the 
> system library.

Thanks, I've opened https://bugzilla.mozilla.org/show_bug.cgi?id=1740320
so that upstream is aware of the issue.

 --dkg


signature.asc
Description: PGP signature


Bug#998848: thunderbird: please build against librnp-dev (and Depend: on librnp0) directly

2021-11-08 Thread Daniel Kahn Gillmor
Package: thunderbird
Version: 1:78.14.0-1+b2
Control: affects -1 + librnp-dev librnp0

Hi Thunderbird devs--

librnp has made it into debian testing (0.15.2-6 as of right now).

I think thunderbird is currently building from an embedded copy of
librnp.

RNP Upstream has been collaborating nicely by fixing issues i've raised
with them that highlight concerns in debian.

It would be better if we could avoid the embedded code copy by building
thunderbird against the debian librnp-dev package, and depending on
librnp0.

Thanks for maintaining thunderbird in debian!

Regards,

--dkg


signature.asc
Description: PGP signature


Bug#983770: Acknowledgement (rnp: FTBFS on 32-bit platforms (test suite failures))

2021-10-29 Thread Daniel Kahn Gillmor
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)

2021-10-29 Thread Daniel Kahn Gillmor
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#998076: darkslide: contains embedded fonts with licenses that aren't accounted for

2021-10-29 Thread Daniel Kahn Gillmor
Package: darkslide
Version: 6.0.0-2

darkslide contains:

 /usr/share/doc/darkslide/examples/_assets/SourceSansPro.woff2

this appears to be the SourceSansPro font, which is otherwise only
referenced (and also distributed?) in debian in texlive-fonts-extra
package.  (i can't figure out what licensing is appropriate for
SourceSansPro from a quick scan of
/usr/share/doc/texlive-fonts-extra/copyright)

and the following files appear to embed base64-encoded versions fonts in
the Alegreya Sans family in the following files:

/usr/lib/python3/dist-packages/darkslide/themes/abyss/css/theme.css
/usr/lib/python3/dist-packages/darkslide/themes/default/css/theme.css
/usr/lib/python3/dist-packages/darkslide/themes/white/css/theme.css
/usr/lib/python3/dist-packages/darkslide/themes/void/css/theme.css

Alegreya Sans is in the fonts-alegreya-sans package, but
/usr/share/doc/fonts-alegreya-sans/copyright claims it is licensed under
OFL-1.1, while /usr/share/doc/darkslide/copyright makes no mention of
OFL-1.1

i also note that these embedded fonts end up taking up more than 75% of
the darkslide package (on the order of 400KiB each, i think).

Not sure what the right resolution here is.  it'd be nice to reduce the
weight of the package by stripping them, which would also significantly
reduce the size of any slideshow generated using darkslide --embed
(though it might not render the same on a machine that doesn't have the
associated fonts available).

Thanks for maintaining darkslide in debian!

--dkg


signature.asc
Description: PGP signature


Bug#997967: weasyprint: new upstream version 53.3 available

2021-10-27 Thread Daniel Kahn Gillmor
Package: src:weasyprint
Version: 51-2
Severity: wishlist
Control: block -1 by 997910

Weasyprint upstream version 53.3 was released 2021-09-10.

Since 53.0, it depends on the pydyf python module instead of cairo (see #997910)

It'd be great to get latest version of weasyprint in debian unstable.

Regards,

--dkg


signature.asc
Description: PGP signature


Bug#997910: RFP: pydyf -- A low-level PDF generator library (python)

2021-10-26 Thread Daniel Kahn Gillmor
Package: wnpp
Severity: wishlist

* Package name: pydyf
  Version : 0.1.1
  Upstream Author : CourtBouillon 
* URL : https://www.courtbouillon.org/pydyf
* License : BSD 3-clause
  Programming Lang: Python
  Description : A low-level PDF generator library (python)

pydyf is a low-level PDF generator written in Python and based on PDF
specification 1.7.

This is useful to have in debian because the latest revision of
weasyprint (53) depends on pydyf instead of cairo.



Bug#997896: darkslide: new upstream version 6.0.0 is available

2021-10-26 Thread Daniel Kahn Gillmor
Package: src:python-darkslide
Version: 5.1.0-1

darkslide upstream released 6.0.0 last year.  It would be great to have
it updated in Debian.

Thanks for maintaining darkslide in debian!

   --dkg


signature.asc
Description: PGP signature


Bug#968525: lintian: breakout-link reported for /usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks

2021-09-16 Thread Daniel Kahn Gillmor
Control: affects 968525 + libgpg-error-dev

On Thu 2021-08-19 20:52:16 -0400, Daniel Kahn Gillmor wrote:
> Control: affects 968525 - libgpg-error-dev
> Control: retitle 968525 lintian: breakout-link reported for 
> /usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks
>
> On Thu 2021-08-19 19:20:16 -0400, Daniel Kahn Gillmor wrote:
>> I see the same issue in libgpg-error-dev with lintian 2.104.0.  If I try
>> to fix it in libgpg-error-dev (i.e. by moving the symlink into lib/
>> instead of usr/lib),
>
> hm, on further experimentation, i now take it back -- this warning
> appeared in libgpg-error-dev because debian/rules in libgpg-error source
> was manually adding an additional breakout-link.  In particular, i think
> for libgpg-error-dev the problem was that there was a link in lib/ that
> was pointing to usr/lib/ (the other way around from what Aurelian
> reported).
>
> After removing the override_dh_link target in libgpg-error, lintian
> doesn't complain about either breakout-link or
> lacks-unversioned-link-to-shared-library

i'm now more confused than ever about this situation.  Apparently,
clearing this lintian warning in libgpg-error introduced #992573 (a
grave bug) despite my testing it locally and it seeming to work (perhaps
my test was on a merged-/usr machine?  i don't have the artifacts from
that test any longer to confirm).

The fact that silencing this warning in the expected way ended up
injecting a grave bug seems problematic.  The test probably needs more
thought and fine-tuning.

--dkg


signature.asc
Description: PGP signature


Bug#994434: mypy: new upstream version (0.910) available

2021-09-15 Thread Daniel Kahn Gillmor
Package: mypy
Version: 0.812-1
Severity: wishlist

Dear Maintainer,

back in June, mypy upstream released 0.910:

https://mypy-lang.blogspot.com/2021/06/mypy-0910-released.html

note that this includes a switch to modular typeshed, as referenced here:


https://mypy-lang.blogspot.com/2021/05/the-upcoming-switch-to-modular-typeshed.html

it'd be great to have the most recent mypy available in debian.

thanks for maintaining mypy!

   --dkg

-- System Information:
Debian Release: 11.0
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 
'stable'), (200, 'unstable-debug'), (200, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
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 /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mypy depends on:
ii  python3   3.9.2-3
ii  python3-mypy  0.812-1

mypy recommends no packages.

Versions of packages mypy suggests:
ii  mypy-doc  0.812-1

-- no debconf information



Bug#968525: lintian: breakout-link reported for /usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks

2021-08-19 Thread Daniel Kahn Gillmor
Control: affects 968525 - libgpg-error-dev
Control: retitle 968525 lintian: breakout-link reported for 
/usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks

On Thu 2021-08-19 19:20:16 -0400, Daniel Kahn Gillmor wrote:
> I see the same issue in libgpg-error-dev with lintian 2.104.0.  If I try
> to fix it in libgpg-error-dev (i.e. by moving the symlink into lib/
> instead of usr/lib),

hm, on further experimentation, i now take it back -- this warning
appeared in libgpg-error-dev because debian/rules in libgpg-error source
was manually adding an additional breakout-link.  In particular, i think
for libgpg-error-dev the problem was that there was a link in lib/ that
was pointing to usr/lib/ (the other way around from what Aurelian
reported).

After removing the override_dh_link target in libgpg-error, lintian
doesn't complain about either breakout-link or
lacks-unversioned-link-to-shared-library

sorry for the additional confusion,

--dkg


signature.asc
Description: PGP signature


Bug#968525: lintian: breakout-link reported for /usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks

2021-08-19 Thread Daniel Kahn Gillmor
Control: affects 968525 + libgpg-error-dev libc6-dev
Control: found 968525 2.104.0
Control: retitle 968525 lintian: breakout-link reported for 
/usr/lib/$(DEB_HOST_MULTIARCH) -> /lib/$(DEB_HOST_MULTIARCH) symlinks, 
conflicts with lacks-unversioned-link-to-shared-library

On Mon 2020-08-17 00:00:07 +0200, Aurelien Jarno wrote:
> Since recent version of lintian, the following tags are reported against
> the libc6-dev package:
>
> W: libc6-dev: breakout-link usr/lib/x86_64-linux-gnu/libBrokenLocale.so -> 
> lib/x86_64-linux-gnu/libBrokenLocale.so.1

I see the same issue in libgpg-error-dev with lintian 2.104.0.  If I try
to fix it in libgpg-error-dev (i.e. by moving the symlink into lib/
instead of usr/lib), then instead i get a lintian warning
lacks-unversioned-link-to-shared-library, whose description reads in
part:

N:   The symlink is generally expected in the same directory as the library
N:   itself. The major exception to this rule is if the library is
N:   installed in (or beneath) /lib, where the symlink must be installed in
N:   the same dir beneath /usr.

So these two lintian tags appear to be in conflict!

   --dkg


signature.asc
Description: PGP signature


Bug#989406: wireguard-dkms makes little sense with the bullseye kernel

2021-06-06 Thread Daniel Kahn Gillmor
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

2021-06-03 Thread Daniel Kahn Gillmor
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#968683: resolvconf and wireguard-tools

2021-06-03 Thread Daniel Kahn Gillmor
On Mon 2020-10-12 09:35:56 +0200, Jack Henschel wrote:

> I also just ran into this issue yesterday.
> I installed `wireguard-tools` on a minimal Debian Buster system and 
> `wg-quick` gave me the same error:
>
>> wg-quick up wg0
>> ...
>> 
>> [#] resolvconf -a wg0 -m 0 -x
>> /usr/bin/wg-quick: line 32: resolvconf: command not found
>
> Is there a particular reason why `wireguard-tools` only "suggests" resolvconf 
> but does not depend on it?
> From my point of view, resolvconf should be a hard dependency.
>
> As mentioned before, installing the `resolvconf` package fixed the issue.

Some users of wireguard-tools may never need to use wg-quick (e.g. they
might just use /usr/bin/wg)

Or, if they do use wg-quick, they might not use it with a configuration
that tries to adjust the system resolvers.

Finally, the resolvconf interface might be supplied by a number of
different implementations -- either resolvconf, openresolv, or
systemd-resolved's alias of resolvectl could be the relevant
implementations.

please see #930735 for more discussion.

   --dkg


signature.asc
Description: PGP signature


Bug#970275: lintian: Please allow /usr/share/gtk-doc/html without emitting package-contains-documentation-outside-usr-share-doc

2021-05-26 Thread Daniel Kahn Gillmor
Control: affects 970275 + libgmime-3.0-doc

On Mon 2020-09-14 09:13:02 +0100, Simon McVittie wrote:

> However, it currently causes Lintian to emit
> package-contains-documentation-outside-usr-share-doc. Perhaps there could
> be logic like this pseudocode?
>
> for each file outside /usr/share/doc that looks like documentation:
> if there is a symlink in /usr/share/doc to the file or one of
> its ancestor directories:
> # assume it is used or read by programs
> no tag
> else:
> package-contains-documentation-outside-usr-share-doc

I agree with Simon that this is the right thing to do.  the gmime
packages are affected by this as well, and it makes lintian output very
noisy for that package.  I imagine that any package that uses the
gtk-doc tooling will trigger this warning unnecessarily.

 --dkg


signature.asc
Description: PGP signature


Bug#989058: Acknowledgement (dumpasn1: new upstream version 20200928)

2021-05-25 Thread Daniel Kahn Gillmor
Version: 20200928-0.1

I uploaded the new version of dumpasn1 to experimental, and somehow
forgot about my plan to use DELAYED/7, so it's live in experimental
already.  That's my bad, and i hope i didn't ruffle any feathers.  I can
revert the changes with a 20200928-0.2 if they're problematic!  please
let me know.

Regards,

--dkg


signature.asc
Description: PGP signature


Bug#989058: dumpasn1: new upstream version 20200928

2021-05-24 Thread Daniel Kahn Gillmor
Package: dumpasn1
Version: 20191022-2
Severity: wishlist
Tags: patch

Peter Gutmann released dumpasn1 20200928 last year.  It'd be great to
have it in debian, as it includes a default configuration with many more
OIDs than the version currently patched.

I looked into the packaging and it looks like a straightforward upgrade.

In reviewing the two outstanding patches, i realized that they're
actually the same feature (handling non-ASCII strings) -- one was a
cleanup of the other patch, so i consolidated them.

I also updated to dh 13, trimmed out unused files for debian packaging,
added a couple build-time and runtime tests to exercise the non-ASCII
handling.

I'm attaching a consolidated diff here, but I've pushed my edits to the
debian/experimental branch in salsa so the individual commits have
better detail.

Mathieu, given that you're listed at
https://wiki.debian.org/LowThresholdNmu, i'll probably NMU the update to
experimental DELAYED/7 shortly unless I hear an objection (i'm sure this
kind of change is too much to expect in unstable during the freeze).
Feel free to reject it if there are problems, my feelings won't be hurt,
and I'd be happy to learn what you prefer.

Regards,

--dkg

diff --git a/debian/changelog b/debian/changelog
index 59fab36..996f357 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,23 @@
+dumpasn1 (20200928-0.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload
+  * New upstream release
+  * use https:// in debian-specific files
+  * move to idiomatic dh 13
+  * bump standards-version to 4.5.1 (no changes needed)
+  * Rules-Requires-Root: no
+  * add hardening features
+  * build and clean up generated manpage
+  * d/copyright: move to DEP 5
+  * drop unneeded files from debian/
+  * wrap-and-sort -ast
+  * add tests (both build-time and autopkgtest) covering certificates
+with UTF8Strings and BMPStrings
+  * get-orig-source: avoid using deprecated $GZIP env var
+  * refresh and consolidate patches
+
+ -- Daniel Kahn Gillmor   Mon, 24 May 2021 14:13:11 -0400
+
 dumpasn1 (20191022-2) unstable; urgency=medium
 
   * d/rules: Make sure to build man page during build
@@ -27,13 +47,13 @@ dumpasn1 (20170309-1) unstable; urgency=medium
 
 dumpasn1 (20150808-3) unstable; urgency=medium
 
-  * Really fix segfaults on valid certificate. Closes: #840771 
+  * Really fix segfaults on valid certificate. Closes: #840771
 
  -- Mathieu Malaterre   Thu, 20 Oct 2016 09:18:29 +0200
 
 dumpasn1 (20150808-2) unstable; urgency=medium
 
-  * Fix segfaults on valid certificate. Closes: #840771 
+  * Fix segfaults on valid certificate. Closes: #840771
   * Bump Std-Vers to 3.9.8, no changes needed
 
  -- Mathieu Malaterre   Wed, 19 Oct 2016 20:33:47 +0200
@@ -120,4 +140,3 @@ dumpasn1 (20020612-1) unstable; urgency=low
   * Initial Release.
 
  -- Oliver Kurth   Mon,  2 Sep 2002 17:13:04 +0200
-
diff --git a/debian/clean b/debian/clean
index bdc3274..b2eca8a 100644
--- a/debian/clean
+++ b/debian/clean
@@ -1,2 +1,4 @@
 dumpasn1
 Makefile
+debian/dumpasn1.1
+dumpasn1.o
diff --git a/debian/compat b/debian/compat
deleted file mode 100644
index ec63514..000
--- a/debian/compat
+++ /dev/null
@@ -1 +0,0 @@
-9
diff --git a/debian/control b/debian/control
index 4870ded..a3ebc8b 100644
--- a/debian/control
+++ b/debian/control
@@ -2,15 +2,21 @@ Source: dumpasn1
 Section: utils
 Priority: optional
 Maintainer: Mathieu Malaterre 
-Build-Depends: debhelper (>= 9), help2man
-Homepage: http://www.cs.auckland.ac.nz/~pgut001/
+Build-Depends:
+ debhelper-compat (= 13),
+ help2man,
+ valgrind ,
+Homepage: https://www.cs.auckland.ac.nz/~pgut001/
 Vcs-Git: https://salsa.debian.org/debian/dumpasn1.git
 Vcs-Browser: https://salsa.debian.org/debian/dumpasn1
-Standards-Version: 4.5.0
+Standards-Version: 4.5.1
+Rules-Requires-Root: no
 
 Package: dumpasn1
 Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}
+Depends:
+ ${misc:Depends},
+ ${shlibs:Depends},
 Description: ASN.1 object dump program
  An ASN.1 object dump program which will dump data encoded using any of the
  ASN.1 encoding rules in a variety of user-specified formats.
diff --git a/debian/copyright b/debian/copyright
index 7c6df59..3844b49 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,27 +1,38 @@
-This package was debianized by Oliver Kurth  on
-Mon,  2 Sep 2002 17:13:04 +0200.
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: dumpasn1
+Upstream-Contact: Peter Gutmann 
+Source: https://www.cs.auckland.ac.nz/~pgut001/
 
-It was downloaded from http://www.cs.auckland.ac.nz/~pgut001/
+Files: *
+Copyright: 1997-2020 dumpasn1 authors, including Peter Gutmann,
+ David Kemp,
+ Matthew Hamrick,
+ Bruno Couillard,
+ Hallvard Furuseth,
+ Geoff Thorpe,
+ David Boyce,
+ John Hughes,
+ 'Life is hard, and then you die',
+ Hans-Olof Hermansson,
+ Tor Rustad,
+ Kjetil Barvik,
+ James Sweeny,
+ Chris Ridd,
+ David Lemley,
+ John Tobey,
+ James Manger,
+ Igor Perminov
+Lice

Bug#988436: RFP: certlint -- X.509 certificate linter

2021-05-13 Thread Daniel Kahn Gillmor
On Thu 2021-05-13 03:14:23 +, Paul Wise wrote:
> On Wed, 12 May 2021 23:00:52 -0400 Daniel Kahn Gillmor wrote:
>
>> This and zlint (#915788) are apparently the two dominant X.509
>> certificate checkers
>
> A third one by a Debian person is x509lint:
>
> https://github.com/kroeckx/x509lint

Yep, this would be a good thing to have in debian too.  Kurt, would you
be willing to consider packaging x509lint for debian?  I can file a
formal RFP if that would encourage you to do it :)

   --dkg


signature.asc
Description: PGP signature


  1   2   3   4   5   6   7   8   9   10   >