Bug#1071202: [pkg-gnupg-maint] Bug#1071202: src:gnupg2: upstream tarball ships files not in upstream revision control

[NIIBE Yutaka]

Hello,

For your information, let me explain about regexp support.

Daniel Kahn Gillmor  wrote:
>  regexp/_unicode_mapping.c  |   284 +
[...]
> Maybe the right (and more up-to-date) solution is to build-depend on
> unicode-data, strip both this file and UnicodeData.txt in
> debian/clean, and patch to generate this file from
> /usr/share/unicode/UnicodeData.txt instead.

The regexp subdirectory was introduced to support POSIX regexp functions
on Windows.  The intention is providing same behavior among GnuPG on
different Operating Systems.  Historically, regexp in OpenPGP had been
not supported by Windows versions of GnuPG; In the past, when a user
switched his Operating System from common POSIX one to Windows, it
stopped working.

If it is only for Debian, possibly, we can simply use POSIX regexp
functions in the C library, perhaps.

There are corner cases for regexp matching among different regexp
functions support and Unicode versions.

Strictly speaking about a data specification, it would be more acculate
to specify exact Unicode version explicitly in the OpenPGP standard.
-- 

Bug#1071168: [pkg-gnupg-maint] Bug#1071168: gnupg: Yubikey with KDF enabled: PKDECRYPT failed: Bad PIN

[NIIBE Yutaka]

Hello,

Julian Wollrath  wrote:
> after updating to 2.2.43 I cannot use a key stored on a Yubikey (with
> KDF enabled, not sure, if that matters) anymore, since the PIN is
> rejected:
> gpg-agent[38887]: detected card with S/N XXX
> gpg-agent[38889]: scdaemon[38889]: sending signal 12 to client 38887
> gpg-agent[38889]: [111B blob data]
> gpg-agent[38889]: scdaemon[38889]: Prüfung des CHV2 fehlgeschlagen: Bad PIN
> gpg-agent[38889]: scdaemon[38889]: app_decipher failed: Bad PIN
> gpg-agent[38887]: smartcard decryption failed: Bad PIN
> gpg-agent[38887]: command 'PKDECRYPT' failed: Bad PIN 

Thank you for the bug report.  The bug is tracked in upstream now:

https://dev.gnupg.org/T7121
-- 

Bug#1058572: [pkg-gnupg-maint] Bug#1058572: Bug#1058572: gnupg2.4: fail to initialize homedir and generate key due to keyboxd

[NIIBE Yutaka]

Hello, again,

YunQiang Su  wrote:
> gpg: error writing public keyring '[keyboxd]': Attempt to write a
> readonly SQL database
> Key generation failed: Attempt to write a readonly SQL database

NIIBE Yutaka  wrote:
> I can't replicate this issue on my system.  With a new user I created
> for the test, I had no problem; The directory ~/.gnupg is created,
> ~/.gnupg/public-keys.d is created, and ~/.gnupg/public-keys.d/pubring.db
> is created.  Note that keyboxd just works with systemd by socket
> activation.

For your information, I managed to replicate the error by doing
following:

# For the user having no .gnupg directory, run gpg at the first
# time.  It creates .gnupg directory by gpg and .gnupg/public-keys.d
# by keyboxd
$ gpg -k
gpg: directory '/home/u/.gnupg' created
gpg: /home/u/.gnupg/trustdb.gpg: trustdb created

# Move the ~/.gnupg/public-keys.d while it is in-use by keyboxd
$ mv ~/.gnupg/public-keys.d ~/.gnupg/public-keys.d.bak

# In this situation, creat a key, to be stored by keyboxd
# Then, we see the error
$ gpg --pinentry-mode=loopback --debug ipc --quick-gen-key "a user 
"
[...]
gpg: writing public key to '[keyboxd]'
gpg: error writing public keyring '[keyboxd]': Attempt to write a readonly 
SQL database
Key generation failed: Attempt to write a readonly SQL database

The error may occur, when the database is moved and some data is to be written.

I don't think your case was same, but when someone encounters similar,
this would be an information to investigate the cause.
-- 

Bug#1058572: [pkg-gnupg-maint] Bug#1058572: gnupg2.4: fail to initialize homedir and generate key due to keyboxd

[NIIBE Yutaka]

Hello,

YunQiang Su  wrote:
> gpg: error writing public keyring '[keyboxd]': Attempt to write a
> readonly SQL database
> Key generation failed: Attempt to write a readonly SQL database

I can't replicate this issue on my system.  With a new user I created
for the test, I had no problem; The directory ~/.gnupg is created,
~/.gnupg/public-keys.d is created, and ~/.gnupg/public-keys.d/pubring.db
is created.  Note that keyboxd just works with systemd by socket
activation.

> The problem is due to when create gnupg 2.4+ will add a "common.conf"
> in new created ~/.gnupg directory, with "use-keyboxd", while keyboxed
> is not enabled on Debian yet.

Keyboxd is enabled, but only with 2.4.

I wonder if this is a transition problem after the installation of
GnuPG.

When you see the failure, what is the output of the following command?

$ systemctl --user status keyboxd

(I mean, how keyboxd complained.)
-- 

Bug#1022702: [pkg-gnupg-maint] Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x

[NIIBE Yutaka]

Hello,

NIIBE Yutaka  wrote:
> I backported and pushed my changes to tmp-gniibe-v2.4.
>
> https://salsa.debian.org/gniibe/gnupg2
>
> This is Debian compatible version of GnuPG 2.4.1.

Today, I merged 2.4.3 from Andreas Metzler's tmp-ametzler-v2.4 branch.

This is Debian compatible version of GnuPG 2.4.3.  I just started to use
this GnuPG on my system.
-- 

Bug#1022702: [pkg-gnupg-maint] Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x

[NIIBE Yutaka]

NIIBE Yutaka  wrote:
> I'm going to backport the improvement to my branch of tmp-gniibe-v2.4
> for Debian.

I backported and pushed my changes to tmp-gniibe-v2.4.

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

This is Debian compatible version of GnuPG 2.4.1.
-- 

Bug#1022702: [pkg-gnupg-maint] Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x

[NIIBE Yutaka]

NIIBE Yutaka  wrote:
> I was wrong.  The ticket for agent_cache_housekeeping is:
>
> https://dev.gnupg.org/T3829
>
> It was introduced because of some risk keeping passphrase.
>
> I'd like to consider to improve the implementation of cache and
> expiration, not using handle_tick.

In the upstream, I created a ticket for this task.

https://dev.gnupg.org/T6681

Then, I did some work.  I believe that I somehow sorted out and deal
with problems for T3829 and gpg-agent-idling.

I'm going to backport the improvement to my branch of tmp-gniibe-v2.4
for Debian.

*   *   *

During my implementing the code for T6681, I realized that the possible
reason why Christoph disabled use of debian/patches/gpg-agent-idling
when he packaged 2.3.1-1; The patches were written in Oct/Nov of 2016.
In 2018, to solve an issue of T3829, cache expiration code was added at
the handle_tick function.
-- 

Bug#1050886: [pkg-gnupg-maint] Bug#1050886: Issues that need to be fixed in "yat2m" for transforming manuals to a man-page format

[NIIBE Yutaka]

Bjarni Ingi Gislason  wrote:

> Package: gpgrt-tools
> Version: 1.47-2
> Severity: normal
>
> Dear Maintainer,
>
>   The following are issues that yat2m needs to correct when producing
> man-page formatted manuals.
>
>   The example is from "gpg(1)".

Thank you for your bug report and good descriptions.

Last week, in upstream, I created a ticket for the problem of U+2010
vs. U+002D.

https://dev.gnupg.org/T6674

Since it's for yat2m, other problems should be handled in this ticket
too.
-- 

Bug#1022702: [pkg-gnupg-maint] Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x

[NIIBE Yutaka]

NIIBE Yutaka  wrote:
> Besides, in my opinion, the agent_cache_housekeeping function makes less
> sense (it's totally OK to only check the expiration on its use).  Having
> expired entries on memory is no problem at all, than running gpg-agent
> process periodically; memory is cheap but buttery power is not (for my
> use case).

I was wrong.  The ticket for agent_cache_housekeeping is:

https://dev.gnupg.org/T3829

It was introduced because of some risk keeping passphrase.

I'd like to consider to improve the implementation of cache and
expiration, not using handle_tick.
-- 

Bug#1022702: [pkg-gnupg-maint] Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x

[NIIBE Yutaka]

NIIBE Yutaka  wrote:
> Based on your work of tmp-ametzler-v2.4 branch, I created my own fork.
>
> My hope is that the migration from 2.4 won't introduce (much) surprise
> to Debian users.
>
>https://salsa.debian.org/gniibe/gnupg2/-/tree/tmp-gniibe-v2.4
>
> This work of mine is:
>
> - Keep systemd support (despite its deprecation in upstream)
> - Introduce keyboxd package (with systemd support, for integrity)
> - Put backport of BEGIN_ENCRYPTION status output (from master of upstream)

Further, I recover the patches/gpg-agent-idling series.

- Enable patches/gpg-agent-idling

In the upstream, scd monitoring has improved by introducing a watching
thread.  I updated the patches to address this change of scd monitoring.

Actually, we can improve the code more.  On Windows, since parent_pid is
always -1 (running command by gpg-agent is not supported), the need_tick
function should return 0.  And the return value of the need_tick function
is determined at initialization, we can clean up the code.

Besides, in my opinion, the agent_cache_housekeeping function makes less
sense (it's totally OK to only check the expiration on its use).  Having
expired entries on memory is no problem at all, than running gpg-agent
process periodically; memory is cheap but buttery power is not (for my
use case).
-- 

Bug#1022702: [pkg-gnupg-maint] Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x

[NIIBE Yutaka]

Hello,

Andreas Metzler  wrote:
> On 2023-04-30 Andreas Metzler  wrote:
> [...]
>> However I have updated the GIT branches to 2.4.1 today.
>
> Now at 2.4.3.

Based on your work of tmp-ametzler-v2.4 branch, I created my own fork.

My hope is that the migration from 2.4 won't introduce (much) surprise
to Debian users.

   https://salsa.debian.org/gniibe/gnupg2/-/tree/tmp-gniibe-v2.4

This work of mine is:

- Keep systemd support (despite its deprecation in upstream)
- Introduce keyboxd package (with systemd support, for integrity)
- Put backport of BEGIN_ENCRYPTION status output (from master of upstream)

It doesn't (yet) have TPM support and update to 2.4.3.

I don't insist that it's a solution.  I am in seek of a point of
possible agreement/compromise for Debian users.  The current choice
would be rather arbitrary (it's based on my use case on Debian), but I
believe that the packages will provide less surprise.
-- 

Bug#1022702: I volunteer to maintain GnuPG and friends in the long-term

[NIIBE Yutaka]

Hello,

I'd like to help the packaging of GnuPG and its friends in Debian, in
the long term.  I am a developer of the GnuPG team, and DD who maintains
scute in Debian.  I joined the team in 2011, then, mainly working for
smartcard support.

I don't think I can help solving the policy issue which Andreas Metzler
addressed.  Rather, I'm afraid that I will make the situation more
complicated and unsolvable, if I will try to solve something political
by myself.

So, I should work for the parts where there are no conflicts of policy
(between GnuPG and IETF specification thing).

For the packaging work, I think that we should value current Debian
specific changes, so that Debian users will see less surprise.  We need
to maintain Debian specific changes (for foreseeable future, at least).

Here are some topics of Debian specific changes.

- Debian packaging of GnuPG has its specific preferences:
  debian/patches/update-defaults/

- ... and default keyserver choice:
  debian/patches/Use-hkps-keys.openpgp.org-as-the-default-keyserver.patch

- And for the specific keyserver, there are local changes:
  debian/patches/import-merge-without-userid/

And the change of upstream which should not be introduced for Debian
users:

- Upstream deprecates systemd support, which was originally introduced
  in Debian version.  Perhaps, we will need a Debian local patch for
  this.


Today, I cloned libgpg-error, libassuan, npth, and gnupg2 from
salsa.d.o.

I found that we have an issue of build for x86_64-w64-mingw32.  In the
upstream, we maintain a local change of libtool to change shared library
name for 64-bit version (so that users can see less problem when
installing 32-bit version and 64-bit version at the same time).  In the
current Debian build process, the local change of libtool is ignored.
IIUC, it's not intentional.

Let me start by fixinig this problem (of libgpg-error) at first.
-- 

Bug#1032611: ITP: sp800-90b-entropy-assessment -- Estimating the quality of a source of entropy

[NIIBE Yutaka]

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

* Package name: sp800-90b-entropy-assessment
  Version : 1.1.5
  Upstream Contact: Chris Celi 
* URL : https://github.com/usnistgov/SP800-90B_EntropyAssessment
* License : 
https://www.nist.gov/open/copyright-fair-use-and-licensing-statements-srd-data-software-and-technical-series-publications#software
  Programming Lang: C++
  Description : Estimating the quality of a source of entropy

 Cryptographic random bit generators (RBGs), also known as random
 number generators (RNGs), require a noise source that produces
 digital outputs with some level of unpredictability, expressed as
 min-entropy.  SP 800-90B provides a standardized means of estimating
 the quality of a source of entropy.

This is a set of tools for NIST's SP 800-90B Recommendation for the
Entropy Sources Used for Random Bit Generation.

Debian has packages for RNG: ent and dieharder.  This package is
specifically useful for evaluating/building TRNG.

Good source of entropy is important for computing, especially for free
computing.  I started PLL-based true random generator project, named
Gomti: https://sr.ht/~gniibe/gomti/

For Gomti, I'm using ea_iid, ea_non_iid, and ea_restart in this
package to evaluate the output of TRNG.

It requires following packages:

libbz2-dev libdivsufsort-dev libjsoncpp-dev libssl-dev libmpfr-dev

I plan to maintain the package at salsa.debian.org.  I'm open to team
maintenance (or co-maintainers), but I don't know appropriate one.
Suggestions are welcome.
-- 

Bug#1014849: Newer jimtcl (>= 0.81) requires fix to scripts

[NIIBE Yutaka]

Package: openocd
Version: 0.11.0-1+b1
Severity: serious

Hello,

After I upgraded to libjim0.81, OpenOCD started to emit errors like:
==
Error executing event examine-end on target stm32f0x.cpu:
/usr/bin/../share/openocd/scripts/mem_helper.tcl:37: Error: wrong # args: 
should be "expr expression"
in procedure 'program' 
in procedure 'stm32f0x_default_examine_end' called at file 
"/usr/bin/../share/openocd/scripts/target/stm32f0x.cfg", line 93
in procedure 'mmw' called at file 
"/usr/bin/../share/openocd/scripts/target/stm32f0x.cfg", line 74
at file "/usr/bin/../share/openocd/scripts/mem_helper.tcl", line 37
==

I think that this is due to the change in expr command of jimtcl.
(IIUC, OpenOCD in Debian uses shared library in system for libjim.)

We can see the changes in upstream.

startup.tcl: prepare for jimtcl 0.81 'expr' syntax change:
https://repo.or.cz/openocd.git/commit/82b6a41117fa99e760681d9f31163e7b68357e71

tcl: [1/3] prepare for jimtcl 0.81 'expr' syntax change:
https://repo.or.cz/openocd.git/commit/f5657aa76e795e4ed5b13a9f5df943181a123e49

tcl: [2/3] prepare for jimtcl 0.81 'expr' syntax change:
https://repo.or.cz/openocd.git/commit/f855fdcf0d95ff9ba18a83f9a97d5368844d4f2c

tcl: [3/3] prepare for jimtcl 0.81 'expr' syntax change:
https://repo.or.cz/openocd.git/commit/64d89d5ee1a554fbae8eb0a7231ccb2dc4428c1a

openocd: prepare for jimtcl 0.81 'expr' syntax change
https://repo.or.cz/openocd.git/commit/c7eaaf620488c3268d02313dd5a30101d7aff37b


I confirmed that the error above is fixed by the patch to mem_helper.tcl,
adding quotation by { }.

-- System Information:
Debian Release: 11.4

Versions of packages openocd depends on:
ii  libc6  2.33-7
ii  libcapstone4   4.0.2-3
ii  libftdi1-2 1.5-5+b1
ii  libgpiod2  1.6.2-1
ii  libhidapi-hidraw0  0.10.1+dfsg-1
ii  libjaylink00.2.0-1
ii  libjim0.81 0.81+dfsg0-2
ii  libusb-0.1-4   2:0.1.12-32
ii  libusb-1.0-0   2:1.0.26-1

openocd recommends no packages.

openocd suggests no packages.

-- no debconf information

Bug#1008573: gpg-agent -managed SSH keys stored in Yubikeys cannot be used with OpenSSH 8.9

[NIIBE Yutaka]

On Mon, 11 Apr 2022 11:00:55 -0700 Vagrant Cascadian  wrote:
> Same problem with Gnuk, presumably multiple or all smartcards are
> affected?

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

Bug#972525: fixed in gnupg2 2.2.27-1

[NIIBE Yutaka]

Aurelien Jarno  wrote:
> control: reopen 972525
> control: found 972525 gnupg2/2.2.27-2

Thanks a lot for sharing the fact.

I assume that the failure occurs in a situation of heavy load, where it
takes time for gpg-agent to start its service.

In upstream, I opened another ticket, because I found
a possible cause of this issue (another one):

https://dev.gnupg.org/T5884

The change of GnuPG 2.3 in master:

   https://dev.gnupg.org/rGd94b411f129f572aace005f38cd78515d810135a

can be applied manually.  (Manually, because we had spell fix
of the comment in 2.3.)
-- 

Bug#949761: gpgconf: make socketdir configurable to users

[NIIBE Yutaka]

On Fri, 24 Jan 2020 17:21:43 +0100 Thorsten Glaser  wrote:
> Package: gpgconf
> Version: 2.2.19-1
> Severity: important
> 
> gpg2 and gpg-agent (used by gnupg (1.x) as well) now uses
> GPG_AGENT_INFO=/run/user/2339/gnupg/S.gpg-agent:0:1 but
> the directory /run/user/2339 is removed on logout by elogind
> even if processes are still running.

I happened to find a possible solution for this problem, if a user uses
systemd.

It seems that your use case is with elogind, so, this solution may not
work directly, but it would help seeking the way to solve.

In my system, I identified that:

The initial command creating /run/user/$UID/gnupg is this one (for
systemd users) by running gpgconf command:

/lib/systemd/user-environment-generators/90gpg-agent

And then, this script also invokes gpgconf command:

/etc/X11/Xsession.d/90gpg-agent

To introduce keeping old behavior of sockdir, I needed something
which runs before 90gpg-agent.

So, I created the file:
/etc/systemd/user-environment-generators/89-gpg-keep-old-behavior-of-sockdir-under-home

with the content of:
==
#!/bin/sh

D=/run/user/$(id -u)/
CONFIG_FILE=$HOME/.keep-old-behavior-of-gpg-sockdir

# Make a file to prevent use socketdir under /run by gnupg, but keep
# old behavior using $HOME/.gnupg
if [ -e $CONFIG_FILE ]; then
touch ${D}/gnupg
fi
==

That is, when a user specified by the file of
$HOME/.keep-old-behavior-of-gpg-sockdir, it creates a file
'/run/user/$UID/gnupg' before the creation of directory
/run/user/$UID/gnupg, so that the directory cannot be created and used.

Then, by the fallback mechanism of GnuPG, $HOME/.gnupg will be used.
-- 

Bug#987956: libgcrypt20: ECDH decryption fails with "gpg: public key decryption failed: Invalid object" error message

[NIIBE Yutaka]

On Sun, 02 May 2021 19:47:15 +0200 "Xavier G."  wrote:
> Package: libgcrypt20
> Version: 1.8.7-4
> Severity: important
> 
> Dear Maintainer,
> 
> After a full-upgrade in Sid on 2021-05-02, `gpg --decrypt somefile.gpg` fails:
> 
>   gpg: encrypted with 256-bit ECDH key, ID [hopefully irrelevant]
>   gpg: public key decryption failed: Invalid object
>   gpg: decryption failed: No secret key
[...] 
> The second patch is precisely about returning "Invalid object" /
> GPG_ERR_INV_OBJ in some case related to GnuPG and ECDH decryption.

Sorry, it's my fault.

Fixed in the upstream repo.  It's tracked by:

https://dev.gnupg.org/T5423
-- 

Bug#987297: Dependency to libpth20

[NIIBE Yutaka]

Package: genometools-common
Version: 1.6.1+ds-3
Severity: normal

Hello,

I am a package maintainer of GNU Pth, (non-preemptive) Portable
Threads library.

GNU Pth in Debian:
https://tracker.debian.org/pkg/pth

It's an old package.  It used to be used by GnuPG 2.0.  These days,
mostly no software uses GNU Pth.

I checked users of GNU Pth in Debian and found that genometools-common
depends on libpth20.  However, I can't see any use of Pth in the
software.

The dependency is manually specified at:


https://salsa.debian.org/med-team/genometools/-/blob/master/debian/control#L63

IIUC, this is not needed (and wrong).  I think that no users need
libpth20 for genometools.  Could you please remove this dependency, if
I am not wrong?

Please note that Pthreads (in the manual pthreads(7)) is full featured
preemptive threads library (comes with libc), which is different from
GNU Pth.

If non-preemptive threads library is needed, I suggest use of Npth library,
as GnuPG 2.2 does.

npth in Debian:
https://tracker.debian.org/pkg/npth
-- 

Bug#979379: ITS: src:gnupg2

[NIIBE Yutaka]

Hello,

On 2021-01-05 +0100, Christoph Biedl  wrote:
> | missing upstream releases,
> 
> Several. Debian has 2.20, uploaded in March. Upstream is at 2.26.

FYI, I tried to build GnuPG 2.2.26-1-of-mine package:

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

I did:

  * fetch by 'git fetch '
  * import upstream tar balls by 'gbp import-orig'
  * refresh patches
  * add a line to debian/rules for Windows (building regexp.a).
  * follow the changes of upstream (gpgsplit and symcryptrun).
  * merge pull request for scdaemon configuration
  * add one patch of mine to fix #868550, #972525.

It builds well for me (and works for me).

I have no intention of NMU at all for this work.  As one of upstream
maintainers, I'd like to make sure Debian version of GnuPG works well.
Please note that the patch for #868550, #972525 is a backport from
master, which is only for Debian (it won't be in 2.2 series of
upstream).

I hope my changes above help Debian GnuPG packaging.
-- 

Bug#972525: buildd: sbuild randomly fails to sign changes file despite valid signature keys

[NIIBE Yutaka]

Hello,

IIUC, it is likely a bug of GnuPG.

When a server with higher load, it takes time for a process of gpg-agent
to start listen(2)ing the connection than the value of
SECS_TO_WAIT_FOR_AGENT.  It's five seconds, hard-coded.

Last year, I pushed a change to remove possible race condition around
the initial connect to gpg-agent.

I don't know if this patch fixes the particular problem of sbuild, but,
it should improve the situation, hopefully, much.

-- 

commit b1c56cf9e2bb51abfd47747128bd2a6285ed1623
Author: NIIBE Yutaka 
Date:   Wed Jul 24 15:15:32 2019 +0900

common: Use gnupg_spawn_process_fd to invoke gpg-agent/dirmngr.

* common/asshelp.c (start_new_gpg_agent): Call gnupg_spawn_process_fd
and gnupg_wait_process.
(start_new_dirmngr): Likewise.

--

With --daemon option, gpg-agent/dirmngr detaches by itself.

Signed-off-by: NIIBE Yutaka 

diff --git a/common/asshelp.c b/common/asshelp.c
index 5209ea6cf..600774330 100644
--- a/common/asshelp.c
+++ b/common/asshelp.c
@@ -492,8 +492,13 @@ start_new_gpg_agent (assuan_context_t *r_ctx,
   if (!(err = lock_spawning (, gnupg_homedir (), "agent", verbose))
   && assuan_socket_connect (ctx, sockname, 0, 0))
 {
-  err = gnupg_spawn_process_detached (program? program : agent_program,
-  argv, NULL);
+  pid_t pid;
+
+  err = gnupg_spawn_process_fd (program? program : agent_program,
+argv, -1, -1, -1, );
+  if (!err)
+err = gnupg_wait_process (program? program : agent_program,
+  pid, 1, NULL);
   if (err)
 log_error ("failed to start agent '%s': %s\n",
agent_program, gpg_strerror (err));
@@ -627,7 +632,12 @@ start_new_dirmngr (assuan_context_t *r_ctx,
   if (!(err = lock_spawning (, gnupg_homedir (), "dirmngr", verbose))
   && assuan_socket_connect (ctx, sockname, 0, 0))
 {
-  err = gnupg_spawn_process_detached (dirmngr_program, argv, NULL);
+  pid_t pid;
+
+  err = gnupg_spawn_process_fd (dirmngr_program, argv,
+-1, -1, -1, );
+  if (!err)
+err = gnupg_wait_process (dirmngr_program, pid, 1, NULL);
   if (err)
 log_error ("failed to start the dirmngr '%s': %s\n",
dirmngr_program, gpg_strerror (err));

Bug#967969: pkg-config-crosswrapper wrongly asks to install dpkg-dev even if installed already

[NIIBE Yutaka]

Control: merge 930492

Sorry, I should have installed newer mingw-w64-tools.  I learned after
writing the report.
-- 

Bug#967969: pkg-config-crosswrapper wrongly asks to install dpkg-dev even if installed already

[NIIBE Yutaka]

Package: pkg-config
Version: 0.29.2-1
Severity: normal
Tags: patch

Hello,

With newer dpkg-architecture (I'm using 1.19.7), when I cross build
for i686-w64-mingw32, the command i686-w64-mingw32-pkg-config (linked
to pkg-config-crosswrapper) fails with the message:

Please install dpkg-dev to use pkg-config when cross-building

... even if dpkg-dev is installed.

This is because the command invocation in pkg-config-crosswrapper

   dpkg-architecture -ti686-w64-mingw32 -qDEB_HOST_MULTIARCH

fails with the message:

   dpkg-architecture: error: unknown GNU system type i686-w64-mingw32, you must 
specify Debian architecture, too

with the exit code of 255 (as of version 1.19.7).

# It is related to the change of dpkg and this dpkg bug:
# https://bugs.debian.org/606825
#
# When I modify /usr/share/dpkg/ostable and
# /usr/share/dpkg/tupletable, I can let i686-w64-mingw32-pkg-config
# work correctly.


If we can depend on the behavior of shell having the exit code of 127 when
it can't find the command, I think that we can do like this:

===

--- pkg-config-crosswrapper~2020-04-22 03:30:00.0 +0900
+++ pkg-config-crosswrapper 2020-08-06 10:24:58.149356309 +0900
@@ -11,7 +11,7 @@
   triplet="${basename%-pkg-config}"
   # Normalized multiarch path if any, e.g. i386-linux-gnu for i386
   multiarch="$(dpkg-architecture -t"${triplet}" -qDEB_HOST_MULTIARCH 
2>/dev/null)"
-  if [ "$?" != 0 ]; then
+  if [ "$?" = 127 ]; then
   echo "Please install dpkg-dev to use pkg-config when cross-building" >&2
   exit 1
   fi

===

Could you please consider an improvement like this?


Well, let me explain my situation adding some more information.

I encounter this bug when I cross build GnuPG for i686-w64-mingw32 on
Debian host.  Note that Debian's GnuPG package build process includes
building gpgv for Windows (IIUC, so that it can be used for
win32-loader).

Even if I have dpkg-dev installed, when the GnuPG's configure script
invokes pkg-config, pkg-config fails like:

=
...
checking for cc for build... cc
checking for i686-w64-mingw32-pkg-config... /usr/bin/i686-w64-mingw32-pkg-config
checking pkg-config is at least version 0.9.0... Please install dpkg-dev to use 
pkg-config when cross-building
no
...
=


-- System Information:
Debian Release: 10.5
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-debug'), (500, 'unstable'), (500, 
'testing'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, ppc64el

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

Versions of packages pkg-config depends on:
ii  libc6 2.31-3
ii  libdpkg-perl  1.19.7
ii  libglib2.0-0  2.64.3-2

pkg-config recommends no packages.

Versions of packages pkg-config suggests:
ii  dpkg-dev  1.19.7

Bug#954506: ttyrec: diff for NMU version 1.0.8-5.1

[NIIBE Yutaka]

Sudip Mukherjee  wrote:
> I've prepared an NMU for ttyrec (versioned as 1.0.8-5.1) and
> uploaded it to mentors for sponsoring. Please feel free to tell me if I
> should remove it.

Thank you for your work.

It is OK for Debian.

Ideally, it should not be Debian-only patch, so that upstream will
eventually be able to merge the fix.

When I will have time, I'll try that approach.
-- 

Bug#933713: [pkg-gnupg-maint] Bug#933713: libgpg-error-dev: make package fit for cross development

[NIIBE Yutaka]

Hello,

Let me explain that what direction we should go.

On Tue 2020-01-28 13:01:04 +0100, Francois Gouget wrote:
> The only blocker for making libgpg-error-dev Multi-Arch: same is
> gpg-error-config. However gpg-error-config is not needed on Debian
> since there is no need for -I or -L directives; and it has been 
> superseded by gpgrt-config and pkgconfig anyway.

True.

Since 1.33, libgpg-error have distributed new
libgpg-error/src/gpg-error.m4 which can be used with no gpg-error-config
(but gpgrt-config).  In other cases, software which builds with
pkgconfig just uses gpg-error.pc directly.

My intention of keeping gpg-error-config is to support existing system
which depends on old behavior.  New gpgrt-config requires POSIX
compatible Borne shell and I was afraid that there are still some OSes
without POSIX compatible Borne shell, so, it still distributes the old
gpg-error-config.

Daniel Kahn Gillmor  wrote:
> I agree that upstream's preferred configuration mechanism
> (gpg-error-config) is not well-suited for the modern multiarch world.

gpg-error-config is shipped for backword compatibility.  When there will
be no packages which use gpg-error-config, it could be removed or for
system with POSIX compatible Borne shell, it could be replaced by
gpgrt-config (symbolic link to gpgrt-config) if needed.

In future release of libgpg-error, gpg-error-config will be a symbolic
link to gpgrt-config at installation (when detected POSIX compatible
Borne shell, or we will ignore system with no POSIX compatible Borne
shell).
-- 

Bug#949565: IPv6 Router Advertisement: skip interfaces by no-dhcp-interface

[NIIBE Yutaka]

Package: dnsmasq
Version: 2.80-1
Severity: normal
Tags: ipv6 patch upstream

Hello,

Situation: My ISP doesn't offer IPv6 prefix delegation and just gives
/64 IPv6 address.  I configure my router with ndppd (NDP Proxy
Daemon), running dnsmasq for internal network.

It mostly works, but I observed no periodical IPv6 Router
Advertisement (only reply to Router Solicitation) to internal network.

With a line in dnsmasq.conf:

no-dhcp-interface=
interface=

I expected dnsmasq does IPv6 Router Advertisement, even though these
interfaces share same IPv6 network address.  It does for Router
Solicitation request, but no periodical ones.

I think I found a problem in src/radv.c.  When an interface is
searched, it doesn't skip interfaces with no-dhcp-interface, so,
invalid interface may be identified.  (Note that in the periodic_ra
function, there is code to skip the interface _after_ interface is
identified.)


When I applied following patch, I started to observe IPv6 Router
Advertisement in internal network.

I'm not sure if this patch is correct, or good one.  This is for
sharing the problem.

diff --git a/src/radv.c b/src/radv.c
index cad0530..82f9603 100644
--- a/src/radv.c
+++ b/src/radv.c
@@ -917,6 +917,17 @@ static int iface_search(struct in6_addr *local,  int 
prefix,
param->iface = 0;
return 0;
  }
+
+{
+ struct iname *tmp;
+ for (tmp = daemon->dhcp_except; tmp; tmp = tmp->next)
+   if (tmp->name && wildcard_match(tmp->name, param->name))
+ break;
+
+  /* Skip this interface.  */
+  if (tmp)
+return 1;
+}

new_timeout(context, param->name, param->now);



-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-debug'), (500, 'unstable'), (500, 
'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages dnsmasq depends on:
ii  dnsmasq-base [dnsmasq-base]  2.80-1
ii  init-system-helpers  1.56+nmu1
ii  lsb-base 10.2019051400
ii  netbase  5.6

dnsmasq recommends no packages.

Versions of packages dnsmasq suggests:
pn  resolvconf  

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

-- no debconf information

Bug#934237: [pkg-gnupg-maint] Bug#934237: yubikey communication fails on startup

[NIIBE Yutaka]

Antoine Beaupre  wrote:
> When I login in the morning, my Yubikey setup fails to let me connect
> to remove SSH servers:

How do you invoke gpg-agent?  If it is through your first SSH
invocation, gpg-agent wouldn't know the place where to ask PIN (TTY and
DISPLAY).

You can check if you can use your tokan with SSH after your first
invocation of:

$ gpg --card-status

or

$ gpg-connect-agent UPDATESTARTUPTTY /bye

Then, that's the case.

gpg-agent should know the place where to ask PIN (TTY and DISPLAY), and
it is told by gpg frontend or gpg-connct-agent.  But in the case of SSH
(external/foreign program), there is no such mechanism telling the
place.

> aoû 08 09:51:37 curie gpg-agent[3298]: smartcard signing failed: Ioctl() 
> inapproprié pour un périphérique 
> aoû 08 09:51:37 curie gpg-agent[3298]: ssh sign request failed: Ioctl() 
> inapproprié pour un périphérique  

If it is "Inappropriate ioctl for device", it means that pinentry failed
because of no place to ask.

> Once gpg-agent is restarted, the Yubikey works fine again. And that
> is, even if it's unplugged and plugged back in again.

For me, it sounds like... it is your first invocation of SSH (by systemd
watching the socket), which invokes gpg-agent.
-- 

Bug#926984: [pkg-gnupg-maint] Bug#926984: Bug#926984: gnupg2 FTBFS with gcc-9: dirmngr/dns.h:1058:24: error: lvalue required as unary '&' operand

[NIIBE Yutaka]

Control: tags 926984 fixed-upstream

It was fixed in GnuPG 2.2.14.
-- 

Bug#926788: gauche-c-wrapper: FTBFS randomly (autobuilder hangs)

[NIIBE Yutaka]

Hello,

I managed to identify the bug and upload the fix.  Thanks.
-- 

Bug#926788: gauche-c-wrapper: FTBFS randomly (autobuilder hangs)

[NIIBE Yutaka]

Here is some information.

It is garbage collection + threads bug (possibly + dynamic loading).

When I reproduce the failure (by make check) on my machine, it keeps
running at gauche-c-wrapper/testsuite/cwrappertest.scm.

gauche-c-wrapper/testsuite/test.log having:
---
[...]
Testing c-wrapper (ffi) ===
testing bindings in # ... ok
test dlopen, expects #f ==> ok
test dlsym, expects #f ==> ok
test ffi_prep_cif, expects 0 ==> ok
test ffi_call, expects 3 ==> ok
test ffi_closure, expects #t ==> ok
test call callback, expects 5 ==> 
---

In this situation, here is the GDB trace:
---
Current directory is ~/debian/gauche/src/
GNU gdb (Debian 8.2.1-2) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from gosh...done.
(gdb) attach 8096
Attaching to program: /home/gniibe/debian/gauche/src/gosh, process 8096
[New LWP 8097]
[New LWP 8098]
[New LWP 8099]
warning: Could not load shared library symbols for 4 libraries, e.g. 
../src/c-ffi.so.
Use the "info sharedlibrary" command to see the complete listing.
Do you need "set solib-search-path" or "set sysroot"?[Thread debugging using 
libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7fc407a35c13 in ?? ()
(gdb) info threads
  Id   Target Id   Frame 
* 1Thread 0x7fc409a14740 (LWP 8096) "gosh" 0x7fc407a35c13 in ?? ()
  2Thread 0x7fc409a13700 (LWP 8097) "gosh" futex_wait_cancelable 
(private=0, expected=0, futex_word=0x7fc40a27db68 ) at 
../sysdeps/unix/sysv/linux/futex-internal.h:88
  3Thread 0x7fc409082700 (LWP 8098) "gosh" futex_wait_cancelable 
(private=0, expected=0, futex_word=0x7fc40a27db68 ) at 
../sysdeps/unix/sysv/linux/futex-internal.h:88
  4Thread 0x7fc4086f1700 (LWP 8099) "gosh" futex_wait_cancelable 
(private=0, expected=0, futex_word=0x7fc40a27db68 ) at 
../sysdeps/unix/sysv/linux/futex-internal.h:88
(gdb) bt
#0  0x7fc407a35c13 in ?? ()
#1  0x7fc407a308b5 in ?? ()
#2  0x5613a63c4f90 in ?? ()
#3  0x7fc40a06e29f in GC_invoke_finalizers () at finalize.c:1236
#4  0x7fc409f358c9 in Scm_VMFinalizerRun (vm=vm@entry=0x5613a55a3c00) at 
core.c:305
#5  0x7fc409f38313 in process_queued_requests (vm=0x5613a55a3c00) at 
vm.c:2691
#6  0x7fc409f45d35 in run_loop () at vm.c:909
#7  0x7fc409f4d1dc in user_eval_inner (program=, 
codevec=codevec@entry=0x7ffe3b75b510) at vm.c:1489
#8  0x7fc409f4ee4f in apply_rec (vm=, vm=, 
nargs=2, proc=0x5613a56c6580) at vm.c:1582
#9  Scm_ApplyRec2 (proc=0x5613a56c6580, arg0=arg0@entry=0x5613a63d5cb0, 
arg1=arg1@entry=0x5613a6323f50) at vm.c:1622
#10 0x7fc409f4f412 in Scm_Compile (program=program@entry=0x5613a63d5cb0, 
env=env@entry=0x5613a6323f50) at compaux.c:65
#11 0x7fc409f389f3 in Scm_VMEval (expr=0x5613a63d5cb0, e=0x5613a6323f50) at 
vm.c:1388
#12 0x7fc409ff9010 in libevaleval (SCM_FP=, 
SCM_ARGCNT=, data_=) at libeval.scm:5149
#13 0x7fc409f421cc in run_loop () at ./vmcall.c:193
#14 0x7fc409f4d1dc in user_eval_inner (program=, 
codevec=codevec@entry=0x7ffe3b75b890) at vm.c:1489
#15 0x7fc409f4edc3 in apply_rec (vm=, vm=, 
nargs=1, proc=0x5613a5ca7100) at vm.c:1582
#16 Scm_ApplyRec1 (proc=0x5613a5ca7100, arg0=0x5613a5c7e300) at vm.c:1614
#17 0x7fc407a338f1 in ?? ()
#18 0x0001 in ?? ()
#19 0x5613a55a3c00 in ?? ()
#20 0x7fc40a12bd08 in ccEnvMark () from /lib/libgauche-0.9.so.0
#21 0x7fc409f421cc in run_loop () at ./vmcall.c:193
#22 0x7fc409f4d1dc in user_eval_inner (program=, 
codevec=codevec@entry=0x7ffe3b75bbf0) at vm.c:1489
#23 0x7fc409f4e0e2 in apply_rec (vm=0x5613a55a3c00, vm=0x5613a55a3c00, 
nargs=, proc=0x5613a5626140) at vm.c:1582
#24 Scm_ApplyRec (proc=0x5613a5626140, args=0x20b) at vm.c:1602
#25 0x7fc409fa0794 in Scm_Load (cpath=, flags=, packet=0x7ffe3b75bd30) at load.c:223
#26 0x5613a36c46ce in execute_script (scriptfile=, 
args=0x5613a5743490) at main.c:550
#27 0x5613a36c36f4 in main (ac=, av=) at 
main.c:751
(gdb) thread 2
[Switching to thread 2 (Thread 0x7fc409a13700 (LWP 8097))]
#0  futex_wait_cancelable (private=0, expected=0, futex_word=0x7fc40a27db68 
) at 

Bug#926788: gauche-c-wrapper: FTBFS randomly (autobuilder hangs)

[NIIBE Yutaka]

Hello,

Santiago Vila  wrote:
> but the failure rate is extremely high (around 70% here).

Thanks for the number.  When I built, I didn't get failure in such a
rate.  I built it in my machine (a few times), and upload it to Debian,
where it automatically built on several machines, you know.

So far, I have no clue fixing this bug (I have been not able to identify
the cause).

> If the package is useful despite of this, I recommend disabling the
> test suite completely, as in the patch below (there will be plenty
> of time after the release of buster to fix the buggy test suite).

I believe it is useful, that is a reason why I maintain it.

In my opinion, your patch is hiding a problem.  I'm afraid it is against
our social contract #3 (We will not hide problems).  With it, there will
be no information if it build well or not.

I think that a (possibly right) procedure is to downgrade severity, in
this situation.

For me, it's difficult to accept a patch to hide a problem.  If you
claim that it is so severe that it (randomly) FTBFS on your machine
(despite it was successfully built on several Debian machines), that's
unfortunate for potential users of this package.
-- 

Bug#922603: lightdm-gtk-greeter: Default layout no longer has "language" in indicators

[NIIBE Yutaka]

Package: lightdm-gtk-greeter
Version: 2.0.6-1
Severity: normal

Hello,

Testing lightdm-gtk-greeter in buster, I found that default layout no
longer has "language" selection in indicators.  It seems that it's
upstream change, but someone (like me) would depends on this feature.

For me, this is important feature.

For backward compatibility, I use a configuration with "~language" in
/etc/lightdm/lightdm-gtk-greeter.conf.  I think that (at least) it's
better to include this line as a comment in the configuration
distributed.

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

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

Versions of packages lightdm-gtk-greeter depends on:
ii  libc6   2.28-6
ii  libcairo2   1.16.0-2
ii  libgdk-pixbuf2.0-0  2.38.0+dfsg-7
ii  libglib2.0-02.58.3-1
ii  libgtk-3-0  3.24.5-1
ii  libindicator3-7 0.5.0-4
ii  liblightdm-gobject-1-0  1.26.0-3
ii  libx11-62:1.6.7-1

Versions of packages lightdm-gtk-greeter recommends:
ii  adwaita-icon-theme  3.30.1-1
ii  desktop-base10.0.0
ii  gnome-themes-extra  3.28-1
ii  policykit-1 0.105-25

lightdm-gtk-greeter suggests no packages.

-- Configuration Files:
/etc/lightdm/lightdm-gtk-greeter.conf changed:
[greeter]
indicators=~host;~spacer;~clock;~spacer;~session;~language;~a11y;~power


-- no debconf information

Bug#919856: [pkg-gnupg-maint] Bug#919856: gpg-agent: agent refuses operation again

[NIIBE Yutaka]

Control: tags 919856 fixed-upstream

Norbert Preining  wrote:
>> The exact cause would be there is an empty cache remained in
>> gnome-keyring-daemon.  In my case, it is under:
> [...]
>> Attached is a Python script (I name it test_clear.py) to clear the cache
>> entry (your specific keygrip is hard-coded).  You need python3-gi
>> package (and ignoring warning about version specification).
>
> Bingo! That worked like a charm!

Thank you for your confirmation.  Now, I can reproduce it by a Python
script.  And then, I created this entry:

https://dev.gnupg.org/T4348

Because gpg-agent should be robust even with such an erroneous data.
This is fixed in master branch of GnuPG.

> I leave it to you to close/rename/reassign this bug, not sure what
> should be best done with it.
>
> It is strange that there was a empty pwd stored.

I think that it is good for this bug report to be one of GnuPG, because
people will encounter same trouble.

I'm adding a tag of fixed-upstream.

If we will be able to have a reproducible scenario for
gnome-keyring-daemon with an erroneous entry, that will be qualified as
a bug report for gnome-keyring-daemon, though.
-- 

Bug#919856: [pkg-gnupg-maint] Bug#919856: gpg-agent: agent refuses operation again

[NIIBE Yutaka]

Hello,

I have been chasing the bug in gpg-agent, pinentry, libscret, and
gnome-keyring.  But, I forgot to consider about a simple problem of
data.  Sorry, I should have considered that, in the first place.

The exact cause would be there is an empty cache remained in
gnome-keyring-daemon.  In my case, it is under:

~/.local/share/keyrings/

I don't know the reason why it was created, but it makes sence to
remove the entry... to see if it's working well again. 

Attached is a Python script (I name it test_clear.py) to clear the cache
entry (your specific keygrip is hard-coded).  You need python3-gi
package (and ignoring warning about version specification).


Here is an example session of mine.
==
$ python3 test_clear.py 
test_clear.py:1: PyGIWarning: Secret was imported without specifying a version 
first. Use gi.require_version('Secret', '1') before import to ensure that the 
right version gets loaded.
  from gi.repository import Secret
False
==

In your case, it prints out "True".  After clearing the entry, it should
work again if this is the case.



While gpg-agent supports clearing cache entry for normal and user
usages (by CLEAR_PASSPHRASE command), currently, it doesn't support 
SSH usage.  I just created a task to request this feature.

https://dev.gnupg.org/T4340

-- 
from gi.repository import Secret

THE_KEYGRIP="s/A337DE390143074C6DBFEA64224359B9859B02FC"

the_schema = Secret.Schema.new("org.gnupg.Passphrase",
Secret.SchemaFlags.NONE,
{
"stored-by": Secret.SchemaAttributeType.STRING,
	"keygrip"  : Secret.SchemaAttributeType.STRING,
}
)

attributes = {
"stored-by" : "GnuPG Pinentry",
"keygrip"   : THE_KEYGRIP,
}

removed = Secret.password_clear_sync(the_schema, attributes, None)
print(removed)

Bug#919856: [pkg-gnupg-maint] Bug#919856: gpg-agent: agent refuses operation again

[NIIBE Yutaka]

Norbert Preining  wrote:
>> "no-allow-external-cache" in your .gnupg/gpg-agent.conf.
>
> Confirmed, that made it work.

Good.

> Around 12/28 there was an update of libsecret in unstable, that was more
> or less when it started - hard to say, I wasn't online for some time
> around new year etc.

I tried to reproduce your problem in my envirionment of XFCE4 desktop.
I use testing, and libsecret is new one.  I haven't reprodeced yet.

>> In GNOME Desktop, it is gnome-keyring-daemon which handles secret store.
>> Please check your gnome-keyring-daemon is running correctly.  It's in
>> gnome-keyring package.
>
> How do I check that it is running correctly? It is running, and it
> serves secrets, because my offlineimap client gets them via a python
> module from the store for mail sync. Any other tests I should/can do?

That's the question, I want to know.

I only have small knowledge;  The libsecret is a client of the "Secret
Service API", where gnome-keyring-daemon serves.  The API specification
is available here:

https://specifications.freedesktop.org/secret-service/index.html

After login by lightdm with libpam-gnome-keyring installed,
I observed that I have this process.

/usr/bin/gnome-keyring-daemon --daemonize --login

I think gnome-keyring-daemon is invoked by libpam-gnome-keyring to
"unlock" the secret store.

And after use of pinentry, there are two processes.

/usr/bin/gnome-keyring-daemon --daemonize --login
/usr/bin/gnome-keyring-daemon --start --foreground --components=secrets

I think that latter is started by systemd via libsecret using
DBUS_SESSION_BUS_ADDRESS.

When I manually killed the latter, pinentry still works well,
only with the former process.

>> You are using gpg-agent as ssh-agent.  Please don't activate
>> gnome-keyring-daemon's feature as ssh-agent.
>
> Where would I check/configure that?

I only have partial knowledge.

There are three scripts under /etc/xdg/autostart/.  They have the line:

OnlyShowIn=GNOME;Unity;MATE;

So, it is not relevant to XFCE4.  I guess it is same for Cinnamon.

XFCE4 Desktop has it's own autostart entry for gnome-keyring's secret
service, which I disabled.

gnome-keyring package provides following files:

/usr/share/dbus-1/services/org.freedesktop.secrets.service
/usr/share/dbus-1/services/org.gnome.keyring.service

I think that these files are used by dbus to launch gnome-keyring-daemon.

> $ ps ax | grep gnome
>  2330 ?SLl0:00 /usr/bin/gnome-keyring-daemon --daemonize --login

I think that your configuration is correct (I guess that it is the
gnome-keyring-daemon which is invoked by lightdm through
libpam-gnome-keyring).


For a while, please stand with the workaround.


BTW, my problem of pinentry-qt was identified in this report:

   https://dev.gnupg.org/T4339
-- 

Bug#919856: [pkg-gnupg-maint] Bug#919856: gpg-agent: agent refuses operation again

[NIIBE Yutaka]

Thanks for your patience.

I think I identified an issue in your debug log.  Not yet catch the bug,
though.

The problem is caching passphrase by libsecret using
gnome-keyring-daemon.  I believe that possible workaround is having
"no-allow-external-cache" in your .gnupg/gpg-agent.conf.


Let me explain, following the log...

> 2019/01/24 12:02:47.157702  length=37 from=15 to=51
OPTION allow-external-password-cache
< 2019/01/24 12:02:47.157773  length=3 from=40 to=42
OK

Here, gpg-agent sets allow-external-password-cache option.

> 2019/01/24 12:02:47.159062  length=54 from=536 to=589
SETKEYINFO s/A337DE390143074C6DBFEA64224359B9859B02FC
< 2019/01/24 12:02:47.159127  length=3 from=193 to=195
OK

Here, gpg-agent informs pinentry for keyinfo (it works as cache
identifier).  "s/" stands for SSH, and A3...FC is the keygrip.

And then, GETPIN is issued from gpg-agent, (I think) pinentry must
examine the cache by the function
secret_password_lookup_nonpageable_sync in libsecret.

> 2019/01/24 12:02:47.159342  length=7 from=723 to=729
GETPIN
< 2019/01/24 12:02:47.175799  length=25 from=202 to=226
S PASSWORD_FROM_CACHE
OK

This means cache hits, and passphrase is "" (empty).  This is wrong.

I guess, for some unknow reason, secret_password_lookup_nonpageable_sync
seems to return "", where NULL is expected (because of no cache hit).
Something is going wrong in libsecret, it is related to gnome-keyring
service.


In GNOME Desktop, it is gnome-keyring-daemon which handles secret store.
Please check your gnome-keyring-daemon is running correctly.  It's in
gnome-keyring package.

You are using gpg-agent as ssh-agent.  Please don't activate
gnome-keyring-daemon's feature as ssh-agent.
-- 

Bug#919856: [pkg-gnupg-maint] Bug#919856: gpg-agent: agent refuses operation again

[NIIBE Yutaka]

Hello,

This is a report of my case.  Sorry, it doesn't have a solution for you
(yet).  I hope you can find some information to try.


I usually invoke gpg-agent manually (because I use my own development
version).  This time, I enable systemd socket activation. 

I did test with installed gnupg together with systemd, so that
/usr/bin/gpg-agent is invoked with --supervised option.

In my case (xfce4 desktop), the first invocation of ssh in terminal on
the desktop (which lets start gpg-agent), pinentry-gnome3 and
pinentry-gtk-2 work fine, while pinentry-qt doesn't.

Perhaps, I need to open another bug report for my use case.  I found
that Qt5 doesn't support application having -display option any more.
This is the cause of my own problem.  I think Qt5 application requires
DISPLAY environment variable (instead of command line option).


What I did is following.

To debug pinentry session, I added this line in my .gnupg/gpg-agent.conf:
==
pinentry-program /home/gniibe/tmp/mypinentry
==


I installed socat by 'apt install socat'.

Using socat, I create /home/gniibe/tmp/mypinentry, having +x:
==
#! /bin/sh

PINENTRY_ARGS=$(echo $@ | sed -e 's/:/\\:/g')

ENV_LOG=/run/user/1000/pinentry-env.txt
date > $ENV_LOG
ls -l /etc/alternatives/pinentry >> $ENV_LOG
/bin/echo -e "$PINENTRY_ARGS" >> $ENV_LOG
env >> $ENV_LOG

exec socat -v STDIO "SYSTEM:/usr/bin/pinentry $PINENTRY_ARGS" 2> 
/run/user/1000/pinentry-log.txt
==

In the file of /run/user/1000/pinentry-env.txt, we can see the
environment variables of pinentry process.

In the file of /run/user/1000/pinentry-log.txt, we can observe the
session of gpg-agent <-> pinentry.  I tweak (escape for ':') the
argument of pinentry, so that it can be in the expression of socat.

Please be aware that this is for debugging.  The session log
may include your passphrase in clear text.


I confirmed that there is no DISPLAY in the environment variables (when
--supervised option).  The pinentry process is invokde with --display
option (when gpg-agent has DISPLAY setting). 
-- 

Bug#919856: [pkg-gnupg-maint] Bug#919856: gpg-agent: agent refuses operation again

[NIIBE Yutaka]

Hello,

Thanks for your testing again.

I think that your ssh invocation is the first trigger to invoke
gpg-agent (by systemd).

Does SSH work successfully, when gpg-agent is invoked by gpg, by running
something like "gpg --card-status" before running ssh?  If SSH works
after "gpg --card-status", this is another way of workaround.

Norbert Preining  wrote:
>> It may happen when gpg-agent doesn't know DBUS_SESSION_BUSS_ADDRESS.
>
> See above, at least in my shell it is set.
>
>> >then I switched to pinentry-gtk-2, same
>
> confirmed again.
>
>> It may happen when gpg-agent doesn't know DISPLAY or XAUTHORITY.
>
> both are set in my env.

Sorry for confusion.  I meant environment variables in the process of
gpg-agent.

You can check by:

$ gpg-connect-agent "getinfo std_startup_env" /bye

In my case, the output is like:
==
D TERM=xterm-256color
D DISPLAY=:0.0
D XAUTHORITY=/home/gniibe/.Xauthority
D DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
OK
==

The updatestartuptty sub-command is to update those variables from your
shell to gpg-agent running background.

The failure is gpg-agent cannot run pinentry correctly for some
reason(s).

You can test if pinentry itself works in your environment.  Here is my
example session, where "-->" stands for my input and "#" is comment.

==
 -->$ pinentry-gnome3
OK Pleased to meet you
 -->getpin
# a dialog window pops up, I enter "hello"
D hello
OK
 -->bye
OK closing connection
==

-- 

Bug#919856: [pkg-gnupg-maint] Bug#919856: gpg-agent: agent refuses operation again

[NIIBE Yutaka]

Hello,

It looks like similar to the bug 835394.

Manual workaround to set environment variables is:

$ gpg-connect-agent updatestartuptty /bye

As explained in:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835394#43

Norbert Preining  wrote:
>   the default was pinentry-gnome3:
>
> 2019-01-20 15:44:30 gpg-agent[25582] failed to unprotect the secret key: No 
> passphrase given
> 2019-01-20 15:44:30 gpg-agent[25582] failed to read the secret key
> 2019-01-20 15:44:30 gpg-agent[25582] ssh sign request failed: No passphrase 
> given 

It may happen when gpg-agent doesn't know DBUS_SESSION_BUSS_ADDRESS.

>   then I switched to pinentry-gtk-2, same
>
> 2019-01-20 15:47:18 gpg-agent[25582] failed to unprotect the secret key: No 
> passphrase given
> 2019-01-20 15:47:18 gpg-agent[25582] failed to read the secret key
> 2019-01-20 15:47:18 gpg-agent[25582] ssh sign request failed: No passphrase 
> given 

It may happen when gpg-agent doesn't know DISPLAY or XAUTHORITY.

> After switching to pinentry-qt it started to work ...

Umm...  Strange.
-- 

Bug#643341: [pkg-gnupg-maint] Bug#643341: Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful

[NIIBE Yutaka]

Simon McVittie  wrote:
> The multiarch tuple used to form ${libdir} on Debian is not always
> identical to the GNU host.
[...]
> There's a Debian-specific option "gcc -print-multiarch" added by a
> Debian patch, although not all of our compilers have a similar patch
> (gcc does but clang doesn't).

I see.  Thanks for your teaching.  I realized that there are more detail
than I had expected.

Today, I updated the change [0] to allow CC as one of clang.  I'm going
to push this change, soon.

My intention is to show our support making gpg-error-config script
architecture independent on multiarch environment, to avoid having many
-gpg-error-config scripts.  I wish we will have co-installable
libgpg-error-dev:amd64 and libgpg-error-dev:i386 on Debian, and we won't
need any change for gpg-error.m4 (and updating it in several packages).


Now, I think that more changes (Debian specific) are better to be left
to Debian Maintainer of libgpg-error.

FYI, upstream discussion is here [1].


[0] https://dev.gnupg.org/D467
[1] https://dev.gnupg.org/T4085
-- 

Bug#643341: [pkg-gnupg-maint] Bug#643341: Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful

[NIIBE Yutaka]

Hello, again,

Simon McVittie  wrote:
> For Debian, I wonder whether we might be able to patch the script to
> remove this part, which looks like the only architecture variation:
>
> prefix=@prefix@
> exec_prefix=@exec_prefix@
> libdir=${PKG_CONFIG_LIBDIR:-@libdir@}
> PKG_CONFIG_PATH="$PKG_CONFIG_PATH${PKG_CONFIG_PATH:+:}${libdir}/pkgconfig"

How about a change like this?

https://dev.gnupg.org/D467

At configure time, if it detects libdir for multiarch, it lets
gpg-error-config script architecture independent to dynamically define
PKG_CONFIG_LIBDIR (by CC or gcc -dumpmachine).

With this, we don't need to have -gpg-error-config.
-- 

Bug#643341: [pkg-gnupg-maint] Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful

[NIIBE Yutaka]

Hello,

Thanks for your explanation.  I learn.

Let me explain from GnuPG development side.  We care traditional UNIXen
and unusual OSes.  (minimum version of) GnuPG should be able to be built
and installed in early stage of development.

Simon McVittie  wrote:
> Control: tags -1 - wontfix

OK.

> That will fix cross-compilation if dependent packages are changed to
> use (for example) PKG_CHECK_MODULES([GPG_ERROR], [gpg-error >= 1.33])
> instead of AM_PATH_GPG_ERROR([1.33]).

Yup.  That is my intention.

But... please note that, we don't have an idea doing like that for GnuPG
and its friends.  For building GnuPG, pkg-config (or its alternatives)
should not be one of requirements.

> Is 
> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=blob;f=src/gpg-error-config-new.in
> the new script?

Yes.

> It's very unusual to parse .pc files "by hand" like this.

I know.  Someone has to do unusual thing to break a tie.  I don't think
it's a good solution, but it makes sense in this situation.  Ugly
compromise, but I did my best to provide gpg-error.pc from upstream.

> The usual way to consume .pc files is to run pkg-config (the reference
> implementation in C) or pkgconf (a reimplementation in Perl).

Perhaps, you mean PkgConfig.  It seems it lacks PKG_CONFIG_SYSROOT_DIR
support.

There is another alternative, pkgconf in FreeBSD.  This looks easier
to build.

> For Debian, I wonder whether we might be able to patch the script to
> remove this part, which looks like the only architecture variation:
>
> prefix=@prefix@
> exec_prefix=@exec_prefix@
> libdir=${PKG_CONFIG_LIBDIR:-@libdir@}
> PKG_CONFIG_PATH="$PKG_CONFIG_PATH${PKG_CONFIG_PATH:+:}${libdir}/pkgconfig"

For Debian, where we can assume good environment, package maintainer(s)
can do many things.  I'd suggest something like:

   (1) Having architecture independent -dev package _and_
   architecture dependent -dev package,

   (2) by installing original gpg-error-config as
   -gpg-error-config,

   (3) ... and installing Debian specific gpg-error-config
   which detects architecture dependent path dynamically.

Just an idea.  I don't know this feasibility.

> This is not usually possible. If I run gpg-error-config, for example like
> this:
>
> https://sources.debian.org/src/deja-dup/38.0-1/meson.build/?hl=60#L60
>
> how do you know which architecture I wanted?

Should libdir have the triplet in multiarch environment?
Or simply invoking 'dpkg-architecture -qDEB_HOST_GNU_TYPE'?


*   *   *

These posts from me are basically to inform forthcoming upstream
changes.  I don't insist changes for Debian packaging.  It's up to
Debian.

On the other hand, we are welcom to improve libgpg-error to be Debian
friendly (but not Debian specific).
-- 

Bug#643341: [pkg-gnupg-maint] Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful

[NIIBE Yutaka]

Simon McVittie  wrote:
> The wontfix tag was because upstream are not willing to add pkg-config
> metadata

It was.  Now, it has been changed.

In the next version of libgpg-error (1.33), we will offer gpg-error.pc
(if nothing is going wrong).  I believe this change helps
cross-compiling other packages with libgpg-error.

IIUC, Debian offers its (special) script named pkg-config-crosswrapper,
then, users can use -pkg-config command generated by
pkg-config-dpkghook.

Currently, in our development version (to be 1.33), gpg-error-config
script itself is not architecture independent (having architecture
dependent string), because it needs to find the gpg-error.pc file in
architecture dependent path, just like pkg-config does.

I'm not sure if it's worth to have -gpg-error-config command,
when we have gpg-error.pc.

Nevertheless, I think that it is possible to improve gpg-error-config
script to detect architecture dependent path dynamically... to be Debian
friendly (possibly), so that Debian can offer -gpg-error-config
command.
-- 

Bug#911035: O: ngetty -- getty replacement - one single daemon for all consoles

[NIIBE Yutaka]

Package: wnpp
Severity: normal

I intend to orphan the ngetty package.

The package description is:
 Ngetty is a daemon that starts login sessions on virtual console
 terminals, on demand.  It is a good replacement for all those getty
 processes started from init that, most of the time, are only taking
 up memory.  Since it is compiled statically with dietlibc, the ngetty
 binary size is only about 2k and uses considerably less memory than a
 usual getty implementations.


Upstream ( http://riemann.fmi.uni-sofia.bg/ngetty/ ) has gone, and
things around system daemon has been changed.  The original idea might
be still valid, but the software itself would be questionable.  Thus,
I stop maintaining.
-- 

Bug#911034: O: libpcre++ -- C++ wrapper class for pcre

[NIIBE Yutaka]

Package: wnpp
Severity: normal

I intend to orphan the libpcre++ package.

The package description is:
 PCRE++ is a C++ wrapper-class for the library PCRE (Perl Compatible
 Regular Expressions).
 .
 Its class allows you to use perl alike regular expressions in your C++
 applications. You can use it to search in strings, to split strings
 into parts using expressions or to search and replace a part of a
 string with another part.

Upstream is no longer active.  IIRC, I started packaging this for
libapache2-mod-auth-openid, but it removed the dependency by using
libpcre directly.  And it seems that's a practice.  Thus, I stop
maintaining.
-- 

Bug#911033: O: libopkele -- OpenID support library in C++

[NIIBE Yutaka]

Package: wnpp
Severity: normal

I intend to orphan the libopkele package.

The package description is:
 libopkele is a C++ implementation of an OpenID decentralized identity
 system.  It provides OpenID protocol handling, leaving authentication
 and user interaction to the implementor.

The only use of this package is by libapache2-mod-auth-openid.
And upstream is no longer active.  Thus, I stop maintaining.
-- 

Bug#911032: O: libapache2-mod-auth-openid -- OpenID authentication module for Apache2

[NIIBE Yutaka]

Package: wnpp
Severity: normal

I intend to orphan the libapache2-mod-auth-openid package.

The package description is:
 mod_auth_openid is an authentication module for Apache2.
 It handles the functions of an OpenID consumer as specified in the
 OpenID 2.0 specification.

Upstream is no longer active and libapache2-mod-auth-openidc is better
now.  Thus, I stop maintaining.
-- 

Bug#906545: [pkg-gnupg-maint] Bug#906545: gnupg 2.1 (in stretch) fails to fetch some ECC keys

[NIIBE Yutaka]

Roger Shimizu  wrote:
> I'd like to leave this to pkg maintainer, whether to backport those
> patches, or release a latest 2.1.x for stretch.

For Debian, I think that packaging 2.2.x for stable-bpo would be easier
than cherry picking patches.
-- 

Bug#906545: [pkg-gnupg-maint] Bug#906545: gnupg 2.1 (in stretch) fails to fetch some ECC keys

[NIIBE Yutaka]

Hello,

Thanks for your report.

Roger Shimizu  wrote:
> Package: gnupg
> Version: 2.1.18-8~deb9u2
> Severity: normal
[...]
> And I confirm above issue cannot be reproduced under gnugp 2.2
> (sid version).
> So maybe this can be fixed for the stretch/stable version?

In the upstream, it was fixed by the commit:

commit 9b12b45aa5e67d4d422bf75a3879df1d52dbe67f
Author: Justus Winter 
Date:   Tue Jun 13 15:35:01 2017 +0200

gpg: Check and fix keys on import.

* doc/gpg.texi: Document the new import option.
* g10/gpg.c (main): Make the new option default to yes.
* g10/import.c (parse_import_options): Parse the new option.
(import_one): Act on the new option.
* g10/options.h (IMPORT_REPAIR_KEYS): New macro.

GnuPG-bug-id: 2236
Signed-off-by: Justus Winter 

and in the release of 2.1.22.
-- 

Bug#898552: [pkg-gnupg-maint] Bug#898552: gnupg: wrong key in danish translation for --update-trustdb option

[NIIBE Yutaka]

Hello,

Jonas Smedegaard  writes:
> When running "gpg --update-trustdb" in a da_DK.UTF-8 locale, I am
> presented with the following options:
[...]
> Last option "a" to "afslut" (i.e. "quit") does not work.
>
> Instead pressing "q" quits.

Thanks.

We also have another bug for "  m = back to the main menu"
("  h = tilbage til hovedmenuen\n").

Here is the fix, which I'm about to push to the upstream.

diff --git a/po/da.po b/po/da.po
index c8cd33c9e..74951b0ae 100644
--- a/po/da.po
+++ b/po/da.po
@@ -5065,7 +5065,7 @@ msgstr "tilbagekaldskommentar: "
 #. q = quit
 #.
 msgid "iImMqQsS"
-msgstr "iImMqQsS"
+msgstr "iIhHaAsS"
 
 msgid "No trust value assigned to:\n"
 msgstr "Ingen tillidsværdi tildelt til:\n"
-- 

Bug#894983: gnupg2: CVE-2018-9234: Able to certify public keys without a certify key present when using smartcard

[NIIBE Yutaka]

Hello,

Thank you for the bug report.

Salvatore Bonaccorso <car...@debian.org> wrote:
> The following vulnerability was published for gnupg2:

Vulnerability? ... well, a kind of.

Given this is escalated to CVE, I considered and evaluated the problem
again.

I think that we need to fix the checking of signature by a key which
does not have a capability to certify other keys.

> CVE-2018-9234[0]:
> | GnuPG 2.2.4 and 2.2.5 does not enforce a configuration in which key
> | certification requires an offline master Certify key, which results in
> | apparently valid certifications that occurred only with access to a
> | signing subkey.

This description sounds not accurate for me.  In my opinion, the
certifications are invalid.

The smartcard problem was introduced by the commits of mine:

commit fbb2259d22e6c6eadc2af722bdc52922da348677
Author: NIIBE Yutaka <gni...@fsij.org>
Date:   Mon May 22 09:27:36 2017 +0900

g10: Fix default-key selection for signing, possibly by card.

and

commit 97a2394ecafaa6f58e4a1f70ecfd04408dc15606
Author: NIIBE Yutaka <gni...@fsij.org>
Date:   Thu Apr 27 10:33:58 2017 +0900

g10: For signing, prefer available card key when no -u option.

2.1.21 or later versions have this problem.  It will be fixed in
forthcoming 2.2.6.

Invalid certifications can only be generated by GnuPG 2.1/2.2 with
smartcard, not by 2.0 or 1.4.

> Please adjust the affected versions in the BTS as needed. Can you
> clarify if this affects as well way back to STABLE-BRANCH-1-4?

The checking of invalid certifications would be worth to all branches of
GnuPG.  For the fix of checking, I'm not that confident my proposed fix
of gpg-CVE-2018-9234.diff at [0] is correct or not.  Review is required.

[0] https://dev.gnupg.org/T3844
-- 

Bug#891663: [pkg-gnupg-maint] Bug#891663: [PATCH] libgpg-error: Add support for the riscv64 architecture

[NIIBE Yutaka]

Hello,

Thanks for your report.

Karsten Merker  wrote:
> AIUI, libgpg-error requires a per-architecture header file
> "src/syscfg/lock-obj-pub..h", which upstream doesn't
> provide for riscv64.

As upstream, the change is pushed by the commit: 596c0d7
-- 

Bug#878952: [pkg-gnupg-maint] Bug#878952: scdaemon: avoid ptrace on scdaemon?

[NIIBE Yutaka]

Daniel Kahn Gillmor  wrote:
> Package: scdaemon
> Version: 2.2.1-2
> Severity: normal
[...]
> Should we add a similar "prctl(PR_SET_DUMPABLE, 0)" to scdaemon as
> well?

I think we should.  Or else, someone might confuse as if the specific
attack condition is somehow different for scdaemon.
-- 

Bug#878812: [pkg-gnupg-maint] Bug#878812: hits bug_at when encrypting to 1A6F3E639A4467E8C3476525DF6D76C44D696F6B

[NIIBE Yutaka]

Fixed in master of GnuPG git repo:
995c46ea77cff5b99b2fca17b547d6525a4f227e

https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=995c46ea77cff5b99b2fca17b547d6525a4f227e

It will be backported to 2.2 (STABLE-BRANCH-2-2).
-- 

Bug#878812: [pkg-gnupg-maint] Bug#878812: hits bug_at when encrypting to 1A6F3E639A4467E8C3476525DF6D76C44D696F6B

[NIIBE Yutaka]

Thanks Guido for the log.

Now, I managed to replicate the problem.

I created /tmp/0xDF6D76C44D696F6B from debian-keyring.  The key is expired.

And then, I get the key from keyserver.

Now, we have two keyrings.  In this situation, it hits bug_at.

==
$ /usr/bin/gpg --no-default-keyring --keyring /tmp/k.gpg --recv-key 
1A6F3E639A4467E8C3476525DF6D76C44D696F6B
gpg: keybox '/tmp/k.gpg' created
key DF6D76C44D696F6B:
39 signatures not checked due to missing keys
gpg: key DF6D76C44D696F6B: public key "Sven Bartscher 
" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:   imported: 1
$ /usr/bin/gpg --no-default-keyring --keyring /tmp/k.gpg --list-key
/tmp/k.gpg
--
pub   rsa4096 2014-08-15 [SC] [expires: 2018-06-08]
  1A6F3E639A4467E8C3476525DF6D76C44D696F6B
uid   [ unknown] Sven Bartscher 
uid   [ unknown] Sven Bartscher 
uid   [ unknown] Sven Bartscher 
uid   [ unknown] Sven Bartscher 
sub   rsa4096 2014-08-15 [E]
sub   rsa4096 2016-06-14 [S]

$ /usr/bin/gpg --no-default-keyring --keyring /tmp/0xDF6D76C44D696F6B --keyring 
/tmp/k.gpg --list-key
/tmp/0xDF6D76C44D696F6B
---
pub   rsa4096 2014-08-15 [SC] [expired: 2017-06-03]
  1A6F3E639A4467E8C3476525DF6D76C44D696F6B
uid   [ expired] Sven Bartscher 
uid   [ expired] Sven Bartscher 
uid   [ expired] Sven Bartscher 

/tmp/k.gpg
--
pub   rsa4096 2014-08-15 [SC] [expires: 2018-06-08]
  1A6F3E639A4467E8C3476525DF6D76C44D696F6B
uid   [ unknown] Sven Bartscher 
uid   [ unknown] Sven Bartscher 
uid   [ unknown] Sven Bartscher 
uid   [ unknown] Sven Bartscher 
sub   rsa4096 2014-08-15 [E]
sub   rsa4096 2016-06-14 [S]

$ /usr/bin/gpg --no-default-keyring --keyring /tmp/0xDF6D76C44D696F6B --keyring 
/tmp/k.gpg --debug=8192 --encrypt --armor --always-trust -r 
1A6F3E639A4467E8C3476525DF6D76C44D696F6B
gpg: enabled debug flags: lookup
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search   0: FPR20: '1A6F 3E63 9A44 67E8 C347  6525 DF6D 76C4 
4D69 6F6B'
gpg: DBG: keydb_search: searching keyring (resource 0 of 2)
gpg: DBG: keyring_search: need_uid = 0; need_words = 0; need_keyid = 0; 
need_fpr = 1; any_skip = 0
gpg: DBG: keyring_search: initializing offset table. (need_keyid: 0 => 1)
gpg: DBG: keyring_search: searching from start of resource.
gpg: DBG: keyring_search: packet starting at offset 0 matched descriptor 0
gpg: DBG: keyring_search: returning success
gpg: DBG: keydb_search: searched keyring (resource 0 of 2) => Success
gpg: DBG: finish_lookup: checking key 4D696F6B (all)(req_usage=2)
gpg: DBG:   checking subkey ED764C3A
gpg: DBG:   subkey has expired
gpg: DBG:   checking subkey 217028C2
gpg: DBG:   usage does not match: want=2 have=1
gpg: DBG:   no suitable subkeys found - trying primary
gpg: DBG:   primary key usage does not match: want=2 have=5
gpg: DBG:   no suitable key found -  giving up
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search   0: FPR20: '1A6F 3E63 9A44 67E8 C347  6525 DF6D 76C4 
4D69 6F6B'
gpg: DBG: keydb_search: searching keyring (resource 0 of 2)
gpg: DBG: keyring_search: need_uid = 0; need_words = 0; need_keyid = 0; 
need_fpr = 1; any_skip = 0
gpg: DBG: keyring_search: initializing offset table. (need_keyid: 0 => 1)
gpg: DBG: keyring_search: not searching from start of resource.
gpg: DBG: keyring_search: no matches (EOF)
gpg: DBG: keydb_search: searched keyring (resource 0 of 2) => EOF
gpg: DBG: keydb_search: searching keybox (resource 1 of 2)
gpg: DBG: keydb_search: searched keybox (resource 1 of 2) => Success
gpg: DBG: finish_lookup: checking key 4D696F6B (all)(req_usage=2)
gpg: DBG:   checking subkey ED764C3A
gpg: DBG:   subkey might be fine
gpg: DBG:   checking subkey 217028C2
gpg: DBG:   usage does not match: want=2 have=1
gpg: DBG:   using key ED764C3A
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search   0: LONG_KID: 'DF6D76C44D696F6B'
gpg: DBG: keydb_search: searching keyring (resource 0 of 2)
gpg: DBG: keyring_search: need_uid = 0; need_words = 0; need_keyid = 1; 
need_fpr = 0; any_skip = 0
gpg: DBG: keyring_search: initializing offset table. (need_keyid: 1 => 1)
gpg: DBG: keyring_search: searching from start of resource.
gpg: DBG: keyring_search: packet starting at offset 0 matched descriptor 0
gpg: DBG: keyring_search: returning success
gpg: DBG: keydb_search: searched keyring (resource 0 of 2) => Success
gpg: DBG: finish_lookup: checking key 4D696F6B (one)(req_usage=0)
gpg: DBG:   using key 

Bug#878812: [pkg-gnupg-maint] Bug#878812: hits bug_at when encrypting to 1A6F3E639A4467E8C3476525DF6D76C44D696F6B

[NIIBE Yutaka]

Guido Günther  wrote:
>> > #4  0x556a0f29306f bug_at (gpg)
>> > #5  0x556a0f243c1e do_we_trust (gpg)
>> > #6  0x556a0f243fff find_and_check_key (gpg)
>> > #7  0x556a0f2455b6 find_and_check_key (gpg)
>> > #8  0x556a0f24b6c2 encrypt_crypt (gpg)
>> > #9  0x556a0f203563 main (gpg)
>> > #10 0x7fd58eee12e1 __libc_start_main (libc.so.6)
>> > #11 0x556a0f2054da _start (gpg)
[...]
> I can trivially reproduce this without having mutt involved like:
>
> $ gpg  --encrypt --armor --always-trust -r 
> 1A6F3E639A4467E8C3476525DF6D76C44D696F6B
> gpg: O j: ... this is a bug (../../g10/pkclist.c:417:do_we_trust)
> Aborted (core dumped)
>
> Where the above key is from the debian-keyring package.

Could you please try with --debug=8192 option (debug for key lookup)?

Here, I cannot replicate with Debian's gnupg 2.2.1-2. 

When key search, it failed as expired, and it didn't go the code path to
do_we_trust.


$ /usr/bin/gpg --debug=8192 --encrypt --armor --always-trust -r 
1A6F3E639A4467E8C3476525DF6D76C44D696F6B
gpg: enabled debug flags: lookup
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search   0: FPR20: '1A6F 3E63 9A44 67E8 C347  6525 DF6D 76C4 
4D69 6F6B'
gpg: DBG: keydb_search: searching keybox (resource 0 of 1)
gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => Success
gpg: DBG: finish_lookup: checking key 4D696F6B (all)(req_usage=2)
gpg: DBG:   checking subkey ED764C3A
gpg: DBG:   subkey has expired
gpg: DBG:   checking subkey 217028C2
gpg: DBG:   usage does not match: want=2 have=1
gpg: DBG:   no suitable subkeys found - trying primary
gpg: DBG:   primary key usage does not match: want=2 have=5
gpg: DBG:   no suitable key found -  giving up
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search   0: FPR20: '1A6F 3E63 9A44 67E8 C347  6525 DF6D 76C4 
4D69 6F6B'
gpg: DBG: keydb_search: searching keybox (resource 0 of 1)
gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => EOF
gpg: 1A6F3E639A4467E8C3476525DF6D76C44D696F6B: skipped: Unusable public key
gpg: [stdin]: encryption failed: Unusable public key
gpg: secmem usage: 0/65536 bytes in 0 blocks
$

-- 

Bug#869416: [pkg-gnupg-maint] Bug#869416: pinentry-gtk2: fails to request passphrase when importing OpenPGP secret key with Seahorse

[NIIBE Yutaka]

intrigeri  wrote:
> Can you please take a look, and maybe attach an updated patch?

OK.

Attached is updated patch for gcr to fix this issue, by simply supplying
parent's environ untouched, intended to be put under debian/patches/.
While this patch fixes the particular issue, I think that more clean up
will be needed, perhaps.

The function g_spawn_async_with_pipes let inherit child process parent's
environ when envp=NULL.  By the change, _gcr_gnupg_process_run_async
does so for its envp, when GCR_GNUPG_PROCESS_RESPECT_LOCALE is
specified.

I put the patch in public domain, or it may be distributed
under the licence of LGPL-2.1+.

It is tested by seahorse and pinentry-gtk-2.
-- 
Index: gcr-3.20.0/gcr/gcr-gnupg-importer.c
===
--- gcr-3.20.0.orig/gcr/gcr-gnupg-importer.c
+++ gcr-3.20.0/gcr/gcr-gnupg-importer.c
@@ -330,7 +330,7 @@ _gcr_gnupg_importer_import_async (GcrImp
 	 _gcr_gnupg_importer_import_async);
 
 	_gcr_gnupg_process_run_async (self->pv->process, argv, NULL,
-	  GCR_GNUPG_PROCESS_WITH_STATUS,
+	  GCR_GNUPG_PROCESS_RESPECT_LOCALE|GCR_GNUPG_PROCESS_WITH_STATUS,
 	  cancellable, on_process_run_complete,
 	  g_object_ref (res));
 
Index: gcr-3.20.0/gcr/gcr-gnupg-process.c
===
--- gcr-3.20.0.orig/gcr/gcr-gnupg-process.c
+++ gcr-3.20.0/gcr/gcr-gnupg-process.c
@@ -1027,12 +1027,13 @@ _gcr_gnupg_process_run_async (GcrGnupgPr
 		!g_str_has_prefix (envp[i], "LOCALE="))
 			g_ptr_array_add (envs, (gpointer)envp[i]);
 	}
-	if (!(flags & GCR_GNUPG_PROCESS_RESPECT_LOCALE))
-		g_ptr_array_add (envs, (gpointer)"LOCALE=C");
-	g_ptr_array_add (envs, NULL);
-
+	if (i || !(flags & GCR_GNUPG_PROCESS_RESPECT_LOCALE)) {
+		if (!(flags & GCR_GNUPG_PROCESS_RESPECT_LOCALE))
+			g_ptr_array_add (envs, (gpointer)"LOCALE=C");
+		g_ptr_array_add (envs, NULL);
+	}
 	gchar *command = g_strjoinv (" ", (gchar**)args->pdata);
-	gchar *environ = g_strjoinv (", ", (gchar**)envs->pdata);
+	gchar *environ = envs->pdata?g_strjoinv (", ", (gchar**)envs->pdata):NULL;
 	g_debug ("running command: %s", command);
 	g_debug ("process environment: %s", environ);
 	g_free (command);

Bug#868550: [pkg-gnupg-maint] Bug#868550: reprepro seems to provide a repro

[NIIBE Yutaka]

Ian Jackson  wrote:
> I tried this.  I applied this change and I can confirm that I have
> seen this message in all the failing tests I looked at.

OK.

> With that patch, I can still reproduce the failure.  The passing tests
> succeed and exit, leaving a failing test (so far, only one out of a
> test run) sitting about.  The machine load is low.  There is no
> gpg-agent running.  So the problem I am seeing is not simply that the
> agent process is starved (although I don't doubt that the race you
> describe exists).

I see.

> Each individual test runs with its own GNUPGHOME and is largely
> singlethreaded so I think there are probably not multpile competing
> agents starting up.  Is it possible that the agent started up and then
> exited for some reason ?

Possibly.

I examined the code again.  I found a redundant part in
exechelp-posix.c.  I think that gnupg_spawn_process_detached can be
simplified.  That's because: When gpg-agent (and dirmngr) is invoked
with --daemon option, it does fork, setsid and chdir by itself.

Could you please try with following patch?  This patch also makes
tracking the possible cause easier/simpler.

With the patch, when gpg-agent fails, gpg frontend will emit the error of: 

gpg: waitpid failed in gnupg_spawn_process_detached...

===
diff --git a/common/exechelp-posix.c b/common/exechelp-posix.c
index 7237993a2..33004250b 100644
--- a/common/exechelp-posix.c
+++ b/common/exechelp-posix.c
@@ -850,17 +850,7 @@ gnupg_spawn_process_detached (const char *pgmname, const 
char *argv[],
 }
   if (!pid)
 {
-  pid_t pid2;
-
   gcry_control (GCRYCTL_TERM_SECMEM);
-  if (setsid() == -1 || chdir ("/"))
-_exit (1);
-
-  pid2 = fork (); /* Double fork to let init take over the new child. */
-  if (pid2 == (pid_t)(-1))
-_exit (1);
-  if (pid2)
-_exit (0);  /* Let the parent exit immediately. */
 
   if (envp)
 for (i=0; envp[i]; i++)
===
-- 

Bug#789927: Anthy library breakage

[NIIBE Yutaka]

Osamu Aoki  wrote:
> If what NOKUBI Takatsugu's comment is correct, I wonder why anthy is
> upgraded without coordinating with key users:
>  ibus
>  uim
>  fcitx
>
> (Please note these have many dependence packages so the testing
> migration is slow if package version dependency is correctly recorded.)

I'm sorry.  It was me who upload the anthy package for Sid.  Apparently,
I was conscious of the impact when I was uploading it for experimental
in 2015.  In August 2017, I forgot this issue when I was asked uploading
new Anthy for Debian.  I had thought as if it's only anthy's own problem.

The original plan in 2010 was doing the migration in Debian around 2010.
It didn't occur because of our human resources (and troubles).  What we
did in 2010 was: We made a team as pkg-anthy on Alioth and revived
upstream development to collect patches floating around and to merge.
Then, in 2015, I uploaded it in experimental.

> I agree moving to utf8 is right thing to do but this breakage is
> something we should avoid.

Yes.

> If -dev package version is bumped, we can have slow migration without
> breaking packages depending on old anthy.  But if we share the same -dev
> package name, all related package needs to be uploaded together
> (otherwise we suffer long broken sid system).

Thanks.  Now, I understand (I didn't know that fully).  I should have
learned before uploading to Sid.

> But if library change its API spec from non-utf8 to utf8, this needs to
> be coordinated carefully.

I learned.

> It's not simple. What does people think is the right way to fix.

I have been using Anthy since its birth, but I only use through Emacs
with egg.  Even if I don't use, I should be careful when I touch Debian
package.

Today, the Emacs module egg requires total rewrite for Emacs 25, due to
the change of Emacs (display property thing).  I was considering making
a loadable module for Emacs for Anthy.  That was another pressure.


Any suggestions are welcome.  It seems for me that it would be better
to change the -dev package name.
-- 

Bug#868550: [pkg-gnupg-maint] Bug#868550: reprepro seems to provide a repro

[NIIBE Yutaka]

Ian Jackson  wrote:
>> The invocation of gpg-agent by gpg frontend has an inherent race in the
>> current implementation; When gpg frontend invokes gpg-agent, after
>> spawning gpg-agent, gpg frontend tries to connect five times with one
>> second intervals.  When a machine is busy enough and scheduling of
>> processes goes not that fair, the connection to gpg-agent from gpg
>> frontend may fail.
>
> This might be relevant.  My test suite failures occur on a loaded
> machine, because the test case runner parallelises separate tests.
>
> Does this produce a particular message, when it occurs ?

Yes.

> There are other possible approaches to this situation than to hope to
> win the race.  But I hesitate to suggest adding additional code to
> this area, having seen what's there already...
>
> If you would like to suggest a debug printf, or name lines of source
> code, I can probably arrange to see if this is happening.

Here is the lines.

diff --git a/common/asshelp.c b/common/asshelp.c
index f3a92f9e5..8c584fb4f 100644
--- a/common/asshelp.c
+++ b/common/asshelp.c
@@ -451,6 +451,8 @@ start_new_gpg_agent (assuan_context_t *r_ctx,
   break;
 }
 }
+  if (i >= SECS_TO_WAIT_FOR_AGENT)
+log_error ("agent invoked successfully, but...\n");
 }
 }
 
-- 

Bug#869416: [pkg-gnupg-maint] Bug#869416: pinentry-gtk2: fails to request passphrase when importing OpenPGP secret key with Seahorse

[NIIBE Yutaka]

Control: reassign -1 gcr

NIIBE Yutaka <gni...@fsij.org> wrote:
> Now, I guess that the problem is in the implementaiton of libgcr library.
>
> While I'm reading gcr-3.20.0/gcr/gcr-gnupg-process.c, getting the source
> by apt source libgcr-base-3-1, I suspect the function
> _gcr_gnupg_process_run_async, which doesn't provide GPG_TTY and/or
> DISPLAY to "gpg" process.

Attached is a patch for gcr to fix this issue.  When I apply this patch
to build libgcr-base-3-1 package (and install), the problem of seahorse
has gone.

I also created a ticket for GnuPG upstream to improve its documentation:

https://dev.gnupg.org/T3353

I put the patch in public domain, or it may be distributed
under the licence of LGPL-2.1+.
-- 
Index: gcr-3.20.0/gcr/Makefile.am
===
--- gcr-3.20.0.orig/gcr/Makefile.am
+++ gcr-3.20.0/gcr/Makefile.am
@@ -118,6 +118,7 @@ nodist_libgcr_base_@GCR_MAJOR@_la_SOURCE
 libgcr_base_@GCR_MAJOR@_la_CFLAGS = \
 	$(LIBGCRYPT_CFLAGS) \
 	$(P11_KIT_CFLAGS) \
+	$(GTK_CFLAGS) \
 	-DGCK_API_SUBJECT_TO_CHANGE \
 	-DP11_KIT_API_SUBJECT_TO_CHANGE \
 	-DGCR_COMPILATION \
@@ -133,7 +134,8 @@ libgcr_base_@GCR_MAJOR@_la_LIBADD = \
 	libgck-@GCK_MAJOR@.la \
 	$(GLIB_LIBS) \
 	$(LIBGCRYPT_LIBS) \
-	$(P11_KIT_LIBS)
+	$(P11_KIT_LIBS) \
+	$(GTK_LIBS)
 
 gcr/gcr-marshal.h: gcr/gcr-marshal.list $(GLIB_GENMARSHAL)
 	$(AM_V_GEN) $(GLIB_GENMARSHAL) $< --header --prefix=_gcr_marshal > $@
Index: gcr-3.20.0/gcr/gcr-gnupg-process.c
===
--- gcr-3.20.0.orig/gcr/gcr-gnupg-process.c
+++ gcr-3.20.0/gcr/gcr-gnupg-process.c
@@ -27,6 +27,7 @@
 #include "gcr/gcr-marshal.h"
 
 #include 
+#include 
 
 #include 
 #include 
@@ -971,6 +972,8 @@ _gcr_gnupg_process_run_async (GcrGnupgPr
 	GSource *source;
 	GPid pid;
 	guint i;
+	GdkDisplay *display;
+	const gchar *display_name;
 
 	g_return_if_fail (GCR_IS_GNUPG_PROCESS (self));
 	g_return_if_fail (argv);
@@ -996,6 +999,13 @@ _gcr_gnupg_process_run_async (GcrGnupgPr
 	child_fds[FD_OUTPUT] = 1;
 	child_fds[FD_ERROR] = 2;
 
+	if ((display = gdk_display_get_default ())
+	&& (display_name = gdk_display_get_name (display)))
+	  {
+	g_ptr_array_add (args, g_strdup ("--display"));
+	g_ptr_array_add (args, g_strdup (display_name));
+	  }
+
 	if (flags & GCR_GNUPG_PROCESS_WITH_STATUS) {
 		if (pipe (status_fds) < 0)
 			g_return_if_reached ();

Bug#869416: [pkg-gnupg-maint] Bug#869416: pinentry-gtk2: fails to request passphrase when importing OpenPGP secret key with Seahorse

[NIIBE Yutaka]

intrigeri  wrote:
> So I'm reassigning this to gnupg-agent, where the root cause of the
> problem seems to live.

It seems for me that gpg-agent can not do anything for this bug.

I tried to locate the invocation of "gpg" from seahorse.  I figured out
that when this issue occurred (replacing gpg by shell script), it was
invoked by something like

gpg --status-fd 20 --import

and environment variables are only LOCALE and PWD.  This is the cause of
the problem;  Environment variables (like GPG_TTY, DISPLAY) should be
provided by the parent process.

Also, I ran "seahorse" with the setting of:

export GPGME_DEBUG=9:/tmp/gpgme.log

... and I realized that the invocation of gpg --import is not through
gpgme.

Then, I found: in seahorse/src/seahorse-import-dialog.c, there is a call
to function gcr_import_button_new.  I think that this is the function to
create the "Import" button in the particular dialog.

Now, I guess that the problem is in the implementaiton of libgcr library.

While I'm reading gcr-3.20.0/gcr/gcr-gnupg-process.c, getting the source
by apt source libgcr-base-3-1, I suspect the function
_gcr_gnupg_process_run_async, which doesn't provide GPG_TTY and/or
DISPLAY to "gpg" process.
-- 

Bug#868550: [pkg-gnupg-maint] Bug#868550: reprepro seems to provide a repro

[NIIBE Yutaka]

Ian Jackson  wrote:
>gpg --ignore-time-conflict
>  --no-options
>  --no-default-keyring
>  --homedir
>  /tmp/apt-key-gpghome.yLlu1bwwPI
>  --no-auto-check-trustdb
>  --trust-model
>  always
>  --batch
>  --import

Thank you for minimizing.  I'd like to clarify the case.  Is this
importing private key?

The invocation of gpg-agent by gpg frontend has an inherent race in the
current implementation; When gpg frontend invokes gpg-agent, after
spawning gpg-agent, gpg frontend tries to connect five times with one
second intervals.  When a machine is busy enough and scheduling of
processes goes not that fair, the connection to gpg-agent from gpg
frontend may fail.

That's I have investigated, so far.  I wonder if this is related to the
issue.
-- 

Bug#869416: [pkg-gnupg-maint] Bug#869416: pinentry-gtk2: fails to request passphrase when importing OpenPGP secret key with Seahorse

[NIIBE Yutaka]

Thanks for your reply.

intrigeri  wrote:
> Anything else I should try? Something about $GPG_TTY, or starting
> Seahorse from GNOME Terminal (instead of the GNOME Overview), perhaps?

It seems that the most likely case is the following scenario:

  (1) Upon login, gpg-agent is invoked with no DISPLAY.
  (2) While Sheahorse has DISPLAY and invokes gpg by gpgme,
  gpg connects to existing gpg-agent.
  (3) Because gpg-agent has no DISPLAY, when gpg-agent invokes
  pinentry, it fails at isatty(3).

Could you please try this?

  $ gpg-connect-agent updatestartuptty /bye

It should be done from your GNOME Terminal, before importing key by
Seahorse.  It updates variables of DISPLAY and TTY in gpg-agent.
-- 

Bug#869416: [pkg-gnupg-maint] Bug#869416: pinentry-gtk2: fails to request passphrase when importing OpenPGP secret key with Seahorse

[NIIBE Yutaka]

Hello,

intrig...@debian.org writes:
>   gpg-agent[11835]: DBG: error calling pinentry: Inappropriate ioctl for 
> device 

This error message is related to DISPLAY or GPG_TTY.

I guess that pinentry is invoked with no DISPLAY and no GPG_TTY.  It
failed to open window, and then, it failed at isatty (3), then return
ENOTTY (its error string: "Inappropriate ioctl for device").

>  * This problem doesn't happen when using pinentry-gnome3.
>The difference I see in gpg-agent's debug log is that when using
>pinentry-gnome3, I see a number of OPTION commands sent to
>gpg-agent, e.g. OPTION display=:1, while I see no such thing when
>using pinentry-gtk-2. I'm not sure who's responsible for sending
>these options.

When DISPLAY is there for gpgme, gpgme sends "OPTION display=:1" to
gpg-agent.

Does Seahorse have DISPLAY env var?

>  * Importing the same key with gpg on the command line in GNOME
>Terminal works just fine: the expected pinentry-gtk2 dialog is
>displayed and the key is imported as a result.

I think that gpg has DISPLAY env var under GNOME Terminal.
-- 

Bug#866964: Fwd: mpi_set_secure leads to heap corruption

[NIIBE Yutaka]

Hello,
(Cc-ed to the bug report BTS)

Thank you for forwarding the bug report.

Fixed both for master and LIBGCRYPT-1-7-BRANCH.

master:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=5feaf1cc8f22c1f8d19a34850d86fe190f1432e2

LIBGCRYPT-1-7-BRANCH:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=a195d7346a8006f3b6fb77ccd6df8e91833d2b5a

> The patch fixes the problem.  I've not thought deeply about the
> performance effects: maybe it'd be better to allocate the same total
> limb buffer rather than just the active size, but this patch is simple
> and obviously right.

Yes.  While the patch is right, I followed the suggestion for less
surprise.

While there is the API, I don't know the real use case.  So, I did
search:

https://codesearch.debian.net/search?q=mpi_set_flag.*GCRYMPI_FLAG_SECURE

and seccure-0.5_1 has use cases.  Since all use cases are gcry_mpi_scan
then gcry_mpi_set_flag, I think that those cases are safe for heap
corruption.

==
Commit: a195d7346a8006f3b6fb77ccd6df8e91833d2b5a

mpi: Fix mpi_set_secure.

* mpi/mpiutil.c (mpi_set_secure): Allocate by ->alloced.

--

The code was simply wrong.  The question is if (1) it allocates
(possibly) more or (2) modifi ->alloced.  The choice is (1).

Because we have routines of mpi_set_cond and mpi_swap_cond which
assume no change for the allocated length of limbs, no surprise is
better.  See _gcry_mpi_ec_mul_point for concrete example for those
routines.  That's for constant-time computation.

Debian-bug-id: 866964
Suggested-by: Mark Wooding <m...@distorted.org.uk>
Signed-off-by: NIIBE Yutaka <gni...@fsij.org>

(backport from master commit:
5feaf1cc8f22c1f8d19a34850d86fe190f1432e2)

1 file changed, 1 insertion(+), 1 deletion(-)
mpi/mpiutil.c | 2 +-

modified   mpi/mpiutil.c
@@ -256,7 +256,7 @@ mpi_set_secure( gcry_mpi_t a )
   gcry_assert (!ap);
   return;
 }
-  bp = mpi_alloc_limb_space (a->nlimbs, 1);
+  bp = mpi_alloc_limb_space (a->alloced, 1);
   MPN_COPY( bp, ap, a->nlimbs );
   a->d = bp;
   _gcry_mpi_free_limb_space (ap, a->alloced);

-- 

Bug#862032: [pkg-gnupg-maint] Bug#862032: [scdaemon] yubikey 4 stops working after upgrade from 2.1.18-6

[NIIBE Yutaka]

Shin Ice  writes:
> Package: scdaemon
> Version: 2.1.18-7
> Severity: important
>
> --- Please enter the report below this line. ---
>
> Hi there,
>
> after upgrading to 2.1.18-7 my yubikey stops working again.
> In difference to #852702 I can't get serious output to append to the bug
> report since an "gpg --card-status" dont' get me any update.
[...]
> If you need additional information or anything that I can troubleshoot,
> tell it :)

Thanks for the report.  I confirmed the bug with PC/SC.

I introduced this bug when I backported a fix for factory reset of the
card.

This fixes the issue:


http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/2017-May/005650.html

This is 2.1.18-7 only bug, not in 2.1.20-?.
-- 

Bug#810417: [pkg-gnupg-maint] Bug#810417: gnupg: please switch to libusb 1.0

[NIIBE Yutaka]

Daniel Kahn Gillmor  wrote:
> So i'm inclined to address this by just doing
> --disable-smartcard-support for gnupg1 for debian.  I think this would
> adequately reflect upstream's preferred maintenance posture for GnuPG
> smartcard access (that scdaemon is preferred), and it would remove the
> dependency on the old libusb 1.0 in debian, thereby resolving
> https://bugs.debian.org/810417.

I support this direction.  I think that we already don't have
gnupg.udev for the direct access to USB.


BTW, old one is libusb-0.1, I suppose.

Old: https://tracker.debian.org/pkg/libusb
New: https://tracker.debian.org/pkg/libusb-1.0
-- 

Bug#703062: please add udev rules for cardman 4040

[NIIBE Yutaka]

Hello,

Sorry to reply old bug report.

On Thu, 14 Mar 2013 21:13:38 +0100 Reinhard Müller  wrote:
> Package: gnupg
> Version: 1.4.11-3
> 
> Dear Maintainer,
> 
> the Omnikey CardMan 4040 is a nice PCMCIA smart card reader supported by gpg. 
> It would work out of the box *if* only normal users had read/write permission 
> on /dev/cmx0.
> 
> So please add an udev rule like
> 
>   ACTION=="add", SUBSYSTEM=="cardman_4040", GROUP="plugdev", MODE="0660"
> 
> to the ruleset shipped with gnupg.
> 
> There are several howtos out in the net telling to explicitly add these lines 
> manually if the reader should be used, so having it there by default would 
> greatly increase the usefulness of gnupg in Debian for the people using this 
> widely used card reader.

While I haven't remove the support of CardMan 4040 in GnuPG, I don't
know if it still works or not.  Actually, we are considering the removal
of this card reader support.

If you still have the device, please let me know if it works.  I'm
afraid it's too old to support current version of OpenPGP card with
RSA key length >= 2048.
-- 

Bug#855056: [pkg-gnupg-maint] Bug#855056: scdaemon: Duplicate udev lines in debian/scdaemon.udev file

[NIIBE Yutaka]

Hello,

Thank you for your report.

Teemu Likonen  wrote:
> Scdaemon package version 2.1.18-5 introduced new udev rules for
> Nitrokey and Yubikey. All the Nitrokey lines were already in the file
> so there are now duplicates.

My bad.  I didn't check well when I add the entries for Nitrokey.  Well,
if I could say an excuse :-), Nitrokey people should have closed
relevant reports when they were added.

Fixed in the repo of the package.

https://anonscm.debian.org/cgit/pkg-gnupg/gnupg2.git/commit/?id=874d7ac7bcc42875882eeba6586024fe6f796d9f
-- 

Bug#854595: [pkg-gnupg-maint] Bug#854595: scdaemon: Yubikey smartcards (maybe others) are not recognized after update from 2.1.17-4 to 2.1.18-4

[NIIBE Yutaka]

Hello,

Thank you for your reporting.

Camille MONCELIER  wrote:
> After updating gnupg2 to 2.1.18-4, I'm unable to use my gpg keys stored on a
> Yubikey.
>
> I can easily reproduce the problem like this:

If you don't need PC/SC service, and when it can be your option, please
try using the internal CCID driver of GnuPG by configuring udev rules.

> 2017-02-08 15:17:24 scdaemon[11764] DBG: chan_5 <- SERIALNO openpgp
> 2017-02-08 15:17:24 scdaemon[11764] DBG: apdu_open_reader: BAI=10901
> 2017-02-08 15:17:24 scdaemon[11764] DBG: apdu_open_reader: new device=10901
> 2017-02-08 15:17:24 scdaemon[11764] ccid open error: skip
> 2017-02-08 15:17:24 scdaemon[11764] DBG: chan_5 -> ERR 100696144 No such
> device
> 

This error is from the internal CCID driver of GnuPG.  It fails to
find a device because you don't have a configuration.

As I explained in:

https://bugs.debian.org/854616

Until we fixed configuration (by adding an entry for Yubikey),
please have a udev rules like:

 /etc/udev/rules.d/yubikey-neo-u2f-ccid.rules
ATTRS{idVendor}=="1050", ATTRS{idProduct}=="0115", MODE="664", GROUP="plugdev"


And please add yourself as a group member of "plugdev".

In my case, I have this line in /etc/group:

plugdev:x:46:gniibe

The idProduct value is my guess.  Please confirm by lsusb command.

In my case:

$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 009: ID 234b:  
Bus 001 Device 008: ID 234b:  
Bus 001 Device 007: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 003: ID 0489:e056 Foxconn / Hon Hai 
Bus 001 Device 002: ID 1bcf:2c67 Sunplus Innovation Technology Inc. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

234b: (idVendor = 234b, idProduct=) is my Gnuk Tokens.

And please reply back to us again, so that we can add a correct
entry for the configuration.
-- 

Bug#854616: [pkg-gnupg-maint] Bug#854616: scdaemon cannot access yubikey using ccid driver without pcscd

[NIIBE Yutaka]

Antoine Beaupré  writes:
> This reminds me - it sure looks like pcscd was crashing back
> there. Should I revert back to using pcscd to try and reproduce the
> problem and file a pcscd bug about this?

Yes.  I think that this is a different problem, and it's pcscd issue.
-- 

Bug#854616: [pkg-gnupg-maint] Bug#854616: scdaemon cannot access yubikey using ccid driver without pcscd

[NIIBE Yutaka]

Thanks a lot for your confirmation.

Antoine Beaupré  writes:
>> If this works, the udev line should be included into scdaemon package in
>> future, so that each user doesn't need to configure.
>
> I confirm the udev hack works.

No, this is not a hack.  This is a configuration needed.

It seems for me that Yubico has been recommended use of PC/SC service.
Since no one has reported for use of internal CCID driver, there is no
entry for Yubikey in /lib/udev/rules.d/60-scdaemon.rules on Debian.

Now, since it is confirmed, we should add an entry.
-- 

Bug#854359: [pkg-gnupg-maint] Bug#854359: gnupg: always fails when --recv-keys

[NIIBE Yutaka]

Roger Shimizu <rogershim...@gmail.com> wrote:
> On Wed, Feb 8, 2017 at 9:02 PM, NIIBE Yutaka <gni...@fsij.org> wrote:
>>
>> The keyservers have a problem and the current implementation of dirmngr
>> doesn't like this particular problem.
>
> I think this conclusion is just the same as upstream.
> So applying upstream's patch [0] should fix this issue.
>
> [0] 
> https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=b200e636ab20d2aa93d9f71f3789db5a04af0a56

??? Please note that I am a developer of the upstream.  The patch you
addressed is already included in 2.1.18.

My point is that currently there is a little issue in keyservers side
themselves.  One of keyservers in hkps.pool.sks-keyservers.net doesn't
have valid combination of PTR record and A record.  Current
implementation of dirmngr is not robost enough to handle this
glitch ... which should be fixed, IMO.
-- 

Bug#854616: [pkg-gnupg-maint] Bug#854616: scdaemon cannot access yubikey using ccid driver without pcscd

[NIIBE Yutaka]

Hello,

Thank you for reporting in detail.

Antoine Beaupre  wrote:
> In Bug#854005, I have described a distinct issue I have experience
> with my Yubikey since the upgrade of the GnuPG suite from 2.1.17 to
> 2.1.18, and in the case of pcscd, from 1.8.19-1 to 1.8.20-1.
[...]
> anything i can do to improve debugging here? note that I don't *need*
> pcscd at all. i don't actually know what it is or what it's for. just
> want this yubikey to work reliably. :)

While I don't know about pcscd crash, I explain how to use card reader /
token with internal ccid driver of GnuPG.

You need a configuration file to allow USB access by user, when you use
internal ccid driver of GnuPG.

Please create a file /etc/udev/rules.d/yubikey-neo-otp-ccid.rules
with the content of:

 /etc/udev/rules.d/yubikey-neo-otp-ccid.rules
ATTRS{idVendor}=="1050", ATTRS{idProduct}=="0111", MODE="664", GROUP="plugdev"


And please add yourself as a group member of "plugdev".

In my case, I have this line in /etc/group:

plugdev:x:46:gniibe

If this works, the udev line should be included into scdaemon package in
future, so that each user doesn't need to configure.
-- 

Bug#854359: [pkg-gnupg-maint] Bug#854359: gnupg: always fails when --recv-keys

[NIIBE Yutaka]

Thanks a lot for your testing.  I think that I located the issue.

Roger Shimizu  wrote:
> $ dirmngr --server --homedir=/run/user/1000/test
[...]
> dirmngr[25354.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net':
> 'ip-209-135-211-141.ragingwire.net'
[...]
> dirmngr[25354.0]: resolving 'ip-209-135-211-141.ragingwire.net' failed: No 
> name
> dirmngr[25354.0]: can't connect to
> 'ip-209-135-211-141.ragingwire.net': host not found
> dirmngr[25354.0]: error connecting to
> 'https://ip-209-135-211-141.ragingwire.net:443': No name
> dirmngr[25354.0]: command 'KS_GET' failed: No name
> ERR 167772380 No name 

The keyservers have a problem and the current implementation of dirmngr
doesn't like this particular problem.

The keyservers of hkps.pool.sks-keyservers.net has A record of
209.135.211.141.  And 209.135.211.141 has a name of
ip-209-135-211-141.ragingwire.net.  But when it tries to resolve
ip-209-135-211-141.ragingwire.net, it results NODOMAIN.



Here is information in detail.

$ host -d hkps.pool.sks-keyservers.net
Trying "hkps.pool.sks-keyservers.net"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33307
;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;hkps.pool.sks-keyservers.net.  IN  A

;; ANSWER SECTION:
hkps.pool.sks-keyservers.net. 505 INA   216.66.15.2
hkps.pool.sks-keyservers.net. 505 INA   163.172.29.20
hkps.pool.sks-keyservers.net. 505 INA   92.43.111.21
hkps.pool.sks-keyservers.net. 505 INA   51.15.53.138
hkps.pool.sks-keyservers.net. 505 INA   18.9.60.141
hkps.pool.sks-keyservers.net. 505 INA   94.142.242.225
hkps.pool.sks-keyservers.net. 505 INA   193.224.163.43
hkps.pool.sks-keyservers.net. 505 INA   209.135.211.141
hkps.pool.sks-keyservers.net. 505 INA   192.94.109.73
hkps.pool.sks-keyservers.net. 505 INA   130.206.1.8

Received 206 bytes from 192.168.43.1#53 in 2 ms
Trying "hkps.pool.sks-keyservers.net"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65108
;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;hkps.pool.sks-keyservers.net.  IN  

;; ANSWER SECTION:
hkps.pool.sks-keyservers.net. 499 IN2001:bc8:2515::1
hkps.pool.sks-keyservers.net. 499 IN
2a02:898:31:0:48:4558:73:6b73
hkps.pool.sks-keyservers.net. 499 IN2001:720:418:caf1::8
hkps.pool.sks-keyservers.net. 499 IN2606:9500:201:1::141
hkps.pool.sks-keyservers.net. 499 IN2606:1c00:2802::b
hkps.pool.sks-keyservers.net. 499 IN2001:470:1:116::6
hkps.pool.sks-keyservers.net. 499 IN
2a01:4a0:59:1000:223:9eff:fe00:100f
hkps.pool.sks-keyservers.net. 499 IN
2001:738:0:600:216:3eff:fe02:42
hkps.pool.sks-keyservers.net. 499 IN
2001:bc8:4700:2300::10:f15

Received 298 bytes from 192.168.43.1#53 in 48 ms
Trying "hkps.pool.sks-keyservers.net"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18642
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;hkps.pool.sks-keyservers.net.  IN  MX

;; AUTHORITY SECTION:
sks-keyservers.net. 300 IN  SOA ns2.kfwebs.net. kf.kfwebs.net. 
3170208123 600 14400 172800 600

Received 96 bytes from 192.168.43.1#53 in 49 ms
$ host 209.135.211.141
141.211.135.209.in-addr.arpa domain name pointer 
ip-209-135-211-141.ragingwire.net.
$ host ip-209-135-211-141.ragingwire.net
Host ip-209-135-211-141.ragingwire.net not found: 3(NXDOMAIN)
$ 
-- 

Bug#854359: [pkg-gnupg-maint] Bug#854359: gnupg: always fails when --recv-keys

[NIIBE Yutaka]

Hello, Roger,

Roger Shimizu  wrote:
> While trying to using caff to sign keys, I find I cannot retrieve other
> people's keys. So for debug, I tried to get my own key by:
>
> $ gpg -vvv --debug-all --recv-keys 0x6C6ACD6417B3ACB1

It is the failure of dirmngr which does actual key retrieval.

In my environment, it works fine.  Could you please test dirmngr
directly.  Here is a session example which I did.  My input is "->".

 -> $ mkdir /run/user/1000/test
 -> $ dirmngr --server --homedir=/run/user/1000/test
dirmngr[2004]: error opening 
'/run/user/1000/test/dirmngr_ldapservers.conf': No such file or directory
dirmngr[2004.0]: permanently loaded certificates: 0
dirmngr[2004.0]: runtime cached certificates: 0
# Home: /run/user/1000/test
# Config: [none]
 -> KS_GET -- 0x6C6ACD6417B3ACB1
dirmngr[2004.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'oteiza.siccegge.de'
dirmngr[2004.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'bone.digitalis.org'
dirmngr[2004.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'prod00.keyserver.dca.witopia.net'
dirmngr[2004.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'gpg.NebrWesleyan.edu'
dirmngr[2004.0]: resolve_dns_addr failed while checking 
'hkps.pool.sks-keyservers.net': No name
dirmngr[2004.0]: resolve_dns_addr failed while checking 
'hkps.pool.sks-keyservers.net': No name
dirmngr[2004.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'hufu.ki.iif.hu'
dirmngr[2004.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'gozer.rediris.es'
dirmngr[2004.0]: resolve_dns_addr failed while checking 
'hkps.pool.sks-keyservers.net': Server indicated a failure
dirmngr[2004.0]: resolve_dns_addr failed while checking 
'hkps.pool.sks-keyservers.net': Server indicated a failure
S PROGRESS tick ? 0 0
dirmngr[2004.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'bone.digitalis.org' [already known]
dirmngr[2004.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'ip-209-135-211-141.ragingwire.net'
dirmngr[2004.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'hufu.ki.iif.hu' [already known]
dirmngr[2004.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'gpg.NebrWesleyan.edu' [already known]
dirmngr[2004.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'vsund.de'
dirmngr[2004.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'gozer.rediris.es' [already known]
dirmngr[2004.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'oteiza.siccegge.de' [already known]
dirmngr[2004.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'ams.sks.heypete.com'
dirmngr[2004.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'host-37-191-238-78.lynet.no'
S SOURCE https://ams.sks.heypete.com:443
D -BEGIN PGP PUBLIC KEY BLOCK-%0AVersion: SKS 
1.1.6%0AComment:Hostname: ams.sks.heypete.com%0A%0A
...
OK
 -> bye
OK closing connection
$

-- 

Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

[NIIBE Yutaka]

Hello,

Thank you very much for the discussion.  I appreciate the viewpoints
from users.  No, it's not frustrating at all.

Daniel Kahn Gillmor  wrote:
> Can we offer a user experience that doesn't involve them making a choice
> between two indistinguishable options?
>
> A few ideas (no idea how plausible they are to implement, or even
> whether they'd solve the problems people are having):
>
>  0) if pcscd is running and has claimed the smartcard, then by default
> disable ccid?
>
>  1) for each device that is detected by ccid, try to access it.  If it
> is not accessible because someone else has it locked, and pcscd
> appears to be running, and a similar-looking device is accessible
> through pcsc, then skip the device entirely without complaint.
>
>  2) revert whatever the change was in 2.1.18 (handling multiple cards?)
> that made things worse for people who had things working in 2.1.17
>
> Any other suggestions?

2) would be easy choice if any breaking is considered bad and that's the
highest priority.  I am sorry that I break this use case on GNU/Linux.
I thought I tested carefully, but my test coverage is apparently not
that large, I learned.

On GNU/Linux, use of PC/SC service is not recommended for OpenPGP card
(installing PC/SC is OK) and the use of different smartcards with PC/SC
(OpenPGP card together with other cards) requires struggle anyway, so, I
think that asking such users would be an option.

No, I don't say I won't fix this issue.  Surely, I will.

Currently, I am considering something like 1).



Some more information, from here.  Please skip.

> My only concern with this explanation is that most people (even those
> with smartcards!) have *no*idea* whether they "want to use PC/SC
> service."  They just bought a smartcard (or were given one by their
> employer or their government or their friend or whatever) and they know
> they're supposed to use it.

Yes.  This is an important point.

Unfortunately, I think that current situation of use of OpenPGP card is
somehow far from this.  Let me explain.

The situation is complicated becase only some limited card readers works
for OpenPGP card.  Since most users prefer longer key size of RSA these
days, the use of OpenPGP card requires tough condition to card reader.
Some workaround in the lower level of USB communcation for specific card
readers are implemented in the internal CCID driver, so, if the use if
for OpenPGP card, internal CCID driver is better option.

Please note that this is common:

A card reader itself works well on the machine, but OpenPGP card
with (common configuration of) RSA-4096 doesn't work with a reader.
While --card-status works, decryption fails.

I think that something like this is common problem in smartcard
industry.  Current industrial practice seems to be a smartcard requires
specific card reader and vendor's offering application specific driver
which doesn't use general purpose PC/SC service.  Ideally, such
fragmentation should be avoided and it would be better to put all
lower-level knowledge/workaround to PC/SC service, so that all
application can be share common ground.  But it seems going
another direction.

Perhaps, card + reader can not be abstracted well.


And I think that there are two distinct use cases.

(1) Smartcard is given by external entity to user.  He has a little
interest in detail.  The purpose is "just use it".

(2) User cares a lot on her privacy, and that is the reason why she
starts to use smartcard.

It would make sense to put priority to the use case of (1), because
there are more users in this situation.  And since PC/SC serivice tries
to support more card readers, which are listed in
/etc/libccid_Info.plist, it might be a natural choice for a user in this
situation to prefer PC/SC even if he only uses OpenPGP card.

I agree that it is best if we don't need to ask users of (1) to put
"disable-ccid" in his configuration file.  So, I will try, but I don't
have a good solution at hand, right now.

Please note that current default of scdaemon is for the use case of (2).
And I recommend use of the internal CCID driver, a dedicated card reader
access implementation specific to OpenPGP card.  For the readers which
are listed in /lib/udev/rules.d/60-scdaemon.rules, it is easy to use (I
mean, no other configuration needed).  But user needs her own udev rules
if her reader is not listed there.
-- 

Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

[NIIBE Yutaka]

Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote:
> On Mon 2017-02-06 01:04:44 -0500, NIIBE Yutaka <gni...@fsij.org> wrote:
>> This works.  Actually, this is not mandatory.  It is OK to have pcscd
>> package installed **if not used**.
>
> I take it you mean that the system-wide pcscd service itself needs to be
> stopped.

In another message:
> I take it you mean that the the system-wide pcscd service itself needs
> to be disabled and prevented from being started again:
> 
>  systemctl disable --now pcscd.socket pcscd.service

No.  It is OK systemd watches the socket to invoke pcscd.service, as
long as no client tries to connect the socket (by libpcsclite.so.1.0.0).

>> The order of usage by scdaemon is:
>>
>>  (1) First, try internal ccid-driver.
>>  (2) Then, try PC/SC service.
>>
>> I enbugged in 2.1.18 and the transition (1)->(2) doesen't work well now.
>
> Are you saying that 2.1.18-4 isn't a sufficient fix for this?  Are there
> other patches we should consider applying in debian to smooth this
> (1)->(2) transition?

No, 2.1.18-4 (or even master in upstream) is not a sufficient fix.  I
don't have an idea of any good solution at hand, yet.  Thus, workaround
of "disable-ccid".

>>> or per-user:
>>>
>>> echo 'pcsc-driver:0:"does-not-exist' | gpgconf --change-options scdaemon
>>
>> ... this does not work.  A user need to kill pcscd service.
>
> This is because the pcscd service itself will be locking the card in an
> exclusive fashion, right?

Let me clarify.  It is not the problem of locking of the card, but
problem of which process is using USB device.  Only a single process can
claim an interface of a USB device at given time.  And pcscd serves all
CCID devices to client(s).

Upon initialization of pcscd, pcscd claims all CCID devices (= card
readers).  Then, it starts accepting request from clients.  A client 
asks list of card readers, and then connects to a card reader.  For
PC/SC service, it is possible for client to access a card in shared
fashon or exclusive fashion.

Once pcscd is invoked, all CCID devices are under control of pcscd, even
if there are no client.

>> For GNU/Linux system, yes.  However, there are users (especially in
>> Eurpoe), who want to use other smcartcards like citizen ID card
>> simultaneously/interchangeably on a system.  scdaemon is not a system-
>> wide service for all smartcards, but it's specific to OpenPGP card and
>> it's per user service for gpg-agent.
>
> Would it work for the user to tell pcscd to explicitly ignore certain
> devices that are expected to be handled only by scdaemon?  that would
> allow pcscd to run and serve the non-OpenPGP cards, while allowing
> scdaemon to do its work with the OpenPGP cards.

In some use cases, this would be possible;  Say, Yubikey and Nitrokey
are handled only by scdaemon through its CCID driver.

The other use case is: some users want to use a single card reader for
both of OpenPGP card and non-OpenPGP card, interchangeably.

> I'm not suggesting that this would be particularly easy (or even
> possible, in some cases) to configure, but i'm just trying to explore
> the space of options for users.
>
> This should really all be much easier, sigh :(
>
>>> Would it make sense instead to just change the defaults for pcsc-driver
>>> to be the empty string?
>>
>> The problem is pcscd holds the access to device, which prevents
>> ccid-driver's access.
>>
>> Current order makes some sense.  Specific one first, then catch-all one
>> second.  However, in future implementation of scdaemon, perhaps,
>> changing the order of access (pcscd first, ccid-driver second) would
>> also make sense for some use cases.
>
> so many options!  and yet users generally just want things to Just Work™
> :/
>
> Do you want to propose any documentation or notes about this situation?
> README.Debian, or something else?

I think that an explanation like following is good.

If you want to use PC/SC service, please add 

disable-ccid

in .gnupg/scdaemon.conf.  Or do:

echo disable-ccid:0:1 | gpgconf --change-options scdaemon
-- 

Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

[NIIBE Yutaka]

Daniel Kahn Gillmor  wrote:
> To be concrete, i believe the two proposed solutions for users are:
[...]
> Do not use CCID
> ---
>
> echo disable-ccid:0:1 | gpgconf --change-options scdaemon
>

Correct.

The things for PCSC is a bit complicated.  Let me describe.

> Do not use PCSC
> ---
>
> Either system-wide:
>
> apt purge pcscd

This works.  Actually, this is not mandatory.  It is OK to have pcscd
package installed **if not used**.

The order of usage by scdaemon is:

 (1) First, try internal ccid-driver.
 (2) Then, try PC/SC service.

I enbugged in 2.1.18 and the transition (1)->(2) doesen't work well now.

When pcscd is not running, ccid-driver just works well even if pcscd
package is installed.

Internal ccid-driver fails when pcscd service is running and it tries to
open USB devices which are now under the control of pcscd.

And when pcscd is running on a system,

> or per-user:
>
> echo 'pcsc-driver:0:"does-not-exist' | gpgconf --change-options scdaemon

... this does not work.  A user need to kill pcscd service.

>> However, the gnupg package maintainers might want to think about how
>> to best document this issue.
>
> aiui, CCID is the preferred method for scdaemon to access smartcards.

For GNU/Linux system, yes.  However, there are users (especially in
Eurpoe), who want to use other smcartcards like citizen ID card
simultaneously/interchangeably on a system.  scdaemon is not a system-
wide service for all smartcards, but it's specific to OpenPGP card and
it's per user service for gpg-agent.

> Would it make sense instead to just change the defaults for pcsc-driver
> to be the empty string?

The problem is pcscd holds the access to device, which prevents
ccid-driver's access.

Current order makes some sense.  Specific one first, then catch-all one
second.  However, in future implementation of scdaemon, perhaps,
changing the order of access (pcscd first, ccid-driver second) would
also make sense for some use cases.
-- 

Bug#852702: [pkg-gnupg-maint] Bug#852702: [gnupg2] gpg: OpenPGP card not available: No such device after upgrade to 2.1.18-3

[NIIBE Yutaka]

Shin Ice  writes:
> Package: gnupg2
> Version: 2.1.18-3
> Severity: important
>
> --- Please enter the report below this line. ---
>
> Hi,
>
> after upgrading gnupg2 (and related) to version 2.1.18-3 the yubikey 4
> can't be used. On a different system (still sid) with version 2.1.16-3
> all works as desired and designed.
>
> $ gpg2 --card-status
> gpg: selecting openpgp failed: No such device
> gpg: OpenPGP card not available: No such device

I think that I enbugged scdaemon.  Could you please try to put
a line in your .gnupg/scdaemon.conf?

--- .gnupg/scdaemon.conf
disable-ccid
---

-- 

Bug#854005: [pkg-gnupg-maint] Bug#854005: Bug#854005: ssh-agent no longer works

[NIIBE Yutaka]

NIIBE Yutaka <gni...@fsij.org> wrote:
> Ah... I think that I enbugged a bug for PC/SC, and scdaemon with PC/SC
> is somehow broken in 2.1.18.  Please try with internal CCID driver of
> GnuPG.  I mean, don't use PC/SC service.

Or, please add:

disable-ccid

in your scdaemon.conf if you want to use PC/SC service with scdaemon of
2.1.18.
-- 

Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

[NIIBE Yutaka]

Wouter Verhelst  wrote:
> wouter@gangtai:~$ cat .gnupg/scdaemon.conf
> reader-port O2 Micro Oz776 01 00
> log-file /home/wouter/.gnupg/scdaemon.log
> pcsc-driver libpcsclite.so

Ah... I think that I enbugged a bug for PC/SC, and scdaemon with PC/SC
is somehow broken in 2.1.18.  Please try with internal CCID driver of
GnuPG.  I mean, don't use PC/SC service.

>> I'm now at NRT airport to BRU.
>
> Interesting. I live 10 minutes away (by train) from that airport :-)
>
> I take it you'll be at FOSDEM? I'll be giving a talk in the
> IaaS/Virtualization devroom at 14:00 on saturday[1]. If it helps, I'll
> have my laptop with me (and a few cardreaders too, probably); we can
> then debug things face to face if you want me to.
>
> [1] https://fosdem.org/2017/schedule/event/iaas_netblodev/

Yes, I'll be at FOSDEM.  It's good if we can debug things after your
talk.
-- 

Bug#854005: [pkg-gnupg-maint] Bug#854005: ssh-agent no longer works

[NIIBE Yutaka]

Hello,

Thanks to dkg to explicitly CC me.

On Thu 2017-02-02 17:54:26 -0500, Wouter Verhelst wrote:
> Since a recent upgrade, gnupg-agent no longer finds the authentication
> (SSH) key on my OpenPGP smartcard:
>
> wouter@gangtai:~$ gpg --card-status

It should be an issue of scdaemon.  For 2.1.18, I added multiple card
reader support.  This might be a possible cause.  Please let me know, if
2.1.17 worked fine or not.

Daniel Kahn Gillmor  wrote:
> is the key you expect to use listed in ~/.gnupg/sshcontrol ?  I'd expect
> it to be listed by its keygrip, which i think is:
>
> 40277D42041E8A6E9AC9206FB335DDBA4B57A505

No, this line is not needed for card; It is automatically available for
auth key on card.

I'm now at NRT airport to BRU.  So, I won't be available for 12 hours or
so.
-- 

Bug#841143: [pkg-gnupg-maint] Bug#841143: False assumptions about nPth (was: Bug#841143: Suspected race in gpg1 to gpg2 conversion or agent startup)

[NIIBE Yutaka]

Daniel Kahn Gillmor  wrote:
> fwiw, i don't want the behavior to be exactly the same as upstream -- i
> don't want gpg-agent to wake up every few seconds on platforms where it
> shouldn't need to, for example :/

Yes, I understand your purpose.  +1 from me.  Actually, I was inspired
by your patches and I'd like to do something similar in scdaemon.

> but the change i think you're proposing might be OK -- if it does the
> frequent wakeups when it's trying to shut down...

Yes.  My intention was to minimize the change and to show the issue
clearly.  (And my preference is less change against upstream.)

My point was that there is a condition when the main thread keeps
blocking at npth_pselect, when shutdown_pending != 0.

Perhaps, you like Ian's approach better: when --active_connections == 0,
send SIGCONT to resume the main thread.

> You're just talking about adding this one test, right?

Exactly.

> It seems to me like this shouldn't be necessary, since i'd have thought
> the child channel (chan_9 in your example) receiving eof would make the
> main thread wake back up.

It is needed.  (With Ian's approach, the main thread is waken up.)

The main thread blocks at npth_pselect watching the sockets.  The
sockets are listening connection from client.  Connection comming, the
main thread accepts it (by new fd) and creates a thread to handle
commands from fd.  After creating a thread, the main thread does nothing
with the new fd, it's up to the new thread just created.

> Ideally, we don't want to wait a timer tick (up to 2 seconds) before
> shutting down.  if we know we're shutting down and the last client has
> closed, we should just fall into the main loop itself, right?

So, you like Ian's approach.

Ian's approach is to change the line of

  active_connections--;

into:

  if (--active_connections == 0)
interrupt_main_thread_loop ();

There are two parts in gpg-agent.c to change.

I think that it does exactly what you described.

I'm glad that we communicate successfully, and we will have a fix soon.

I don't know if this fix solves all the problems of Ian.  One step done,
that's good.
-- 

Bug#841143: race condition

[NIIBE Yutaka]

Hello,

I'm sorry I didn't put the context.  I am a developer of GnuPG and nPth.
I join the Debian GnuPG mailing list, so that development can go well.
Thus, I receive your bug report.  (I also maintain some packages in
Debian but most are not related to GnuPG.)

Since I felt that there is a kind of not-so-good communication in this
bug of #841143, I am trying to help.

Well, I would like to inform dkg that I review the Debian specific
patches, I mean, they are not ignored.

Ian Jackson  wrote:
> That's the symptoms I saw.  What version did you see this with ?

I'm testing with 2.1.7-2 in Stretch.  It is not reproducible (for me) by
upstream versions.

Today, I managed to have a concrete reproducible case.  Please find an
attached script (gpg-agent-locks-up.sh).

With GPGAGENT=/usr/local/bin/gpg-agent of upstream, the log is:

2017-01-18 09:41:15 gpg-agent[4168] SIGTERM received - shutting down ...
2017-01-18 09:41:17 gpg-agent[4168] DBG: chan_9 <- [eof]
2017-01-18 09:41:18 gpg-agent[4168] gpg-agent (GnuPG) 2.1.18-beta70 stopped


gpg-agent cleanly exits.

With the one in Stretch, the log is:

2017-01-18 09:41:31 gpg-agent[4185] SIGTERM received - shutting down ...
2017-01-18 09:41:33 gpg-agent[4185] DBG: chan_9 <- [eof]
2017-01-18 09:41:36 gpg-agent[4185] SIGTERM received - still 0 open connections
2017-01-18 09:41:36 gpg-agent[4185] gpg-agent (GnuPG) 2.1.17 stopped


It didn't exit even after "[eof]" and needed second SIGTERM.
--
#! /bin/sh

GPGAGENT=/usr/bin/gpg-agent
GPG_CONNECT_AGENT=/usr/bin/gpg-connect-agent

GPGTESTTMPDIR=$HOME/tmp/test-gpg.$$
echo "Test in $HOME/tmp/test-gpg.$$"

mkdir -p $GPGTESTTMPDIR
cat > $GPGTESTTMPDIR/gpg-agent.conf 

Bug#841143: False assumptions about nPth (was: Bug#841143: Suspected race in gpg1 to gpg2 conversion or agent startup)

[NIIBE Yutaka]

Ian Jackson  wrote:
> I think that at least my patch
>   [PATCH 4/4] gpg agent lockup fix: Interrupt main loop when 
> active_connections_value==0
> is very likely a fix to an actual race.
[...]
> I would like this bug fixed in stretch.

I think that this issue is a bug in the patches of
debian/patches/gpg-agent-idling/.

I confirmed the possibility where the main thread might block at
npth_pselect forever.  There are connections, shutdown_pending is set by
signal, npth_pselect is called, then connections are finished.  The main
thread keeps staying at npth_pselect.

For me, it is a bit difficult to apply the fourth patch only.  So, I
seek the update of the patch:

0003-agent-Avoid-tight-timer-tick-when-possible.patch

How about changing the need_tick function, instead?  My intention is to
make the behavior of gpg-agent as similar as upstream version.

I mean, changing the first hunk of the patch of gnupg/agent/gpg-agent.c,
like this (adding the check against shutdown_pending).

--- gnupg.orig/agent/gpg-agent.c
+++ gnupg/agent/gpg-agent.c
@@ -2267,6 +2267,29 @@ create_directories (void)
 }
 
 
+static int
+need_tick (void)
+{
+#ifdef HAVE_W32_SYSTEM
+  /* We do not know how to interrupt the select loop on Windows, so we
+ always need a short tick there. */
+  return 1;
+#else
+  /* if we were invoked like "gpg-agent cmd arg1 arg2" then we need to
+ watch our parent. */
+  if (parent_pid != (pid_t)(-1))
+return 1;
+  /* if scdaemon is running, we need to check that it's alive */
+  if (agent_scd_check_running ())
+return 1;
+  /* if a shutdown was requested, we wait all connections closing.  */
+  if (shutdown_pending)
+return 1;
+  /* otherwise, nothing fine-grained to do. */
+  return 0;
+#endif /*HAVE_W32_SYSTEM*/
+}
+
 
 /* This is the worker for the ticker.  It is called every few seconds
and may only do fast operations. */
-- 

Bug#850686: npth can make reentrant calls to sigaddset

[NIIBE Yutaka]

Hello,

I am reading GNU C library manual.

24.7.2 Signal Sets:
https://www.gnu.org/software/libc/manual/html_node/Signal-Sets.html

All functions have MT-Safe | AS-Safe | AC-Safe attributes.

So, I wonder what your problem is, and what you are suggesting.

> This code is not properly reentrant, but it can be reentered if
> another one of the trapped signals occurs

I think that there is no problem that another signal occurs when
_sigev_handler is called, provided the sigaddset function is safe.
(1) Different signals are recorded properly in sigev_pending.
(2) When they are same signal (two or occurrences), it is marked
properly as occurred.  (Signal handling should be done with the
assumption that it might be multiple occurrences.)

Reading the __sigaddset implementation:


https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/bits/sigset.h;hb=b040e1b0842c35ab444e8502db6ae59389d1e3d5#l117

For me, it is not clear if it can be done atomically.  If the bit
handling is not atomic, I think that it's not MT-Safe.  But, this is the
issue of C library.

Well, npth_sigev_get_pending should be used by a single thread (with the
current nPth implementation); Or else, there is a race between
sigismember and sigdel call.  An event of signal (that might be multiple
signals of SIGNUM) can be handled multiple times by different threads.
-- 

Bug#850808: emacs25-common: install-info dependency

[NIIBE Yutaka]

Package: emacs25-common
Version: 25.1+1-3
Severity: important

Dear Maintainer,

I did clean install of Debian Stretch and found that M-x info doesn't
work well (because of empty dir entries).  That's because install-info
was not installed when I installed Emacs25 (so, I manually installed
install-info package).  I think that it is due to the dependency
specified for emacs25-common.

Here is the dependency in debian/control of emacs25 source package:

Package: emacs25-common
Depends: emacsen-common (>= 2.0.8), dpkg (>= 1.15.4) | install-info, 
${shlibs:Depends}, ${misc:Depends}

Please note that newer dpkg doesn't have install-info any more, as
described:

https://lists.debian.org/debian-devel/2013/05/msg00243.html

So, I think that the dependency:

dpkg (>= 1.15.4) | install-info

should be only:

install-info

now.

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

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

Versions of packages emacs25-common depends on:
ii  dpkg1.18.18
ii  emacsen-common  2.0.8
ii  install-info6.3.0.dfsg.1-1+b1

Versions of packages emacs25-common recommends:
ii  emacs25-el  25.1+1-3

Versions of packages emacs25-common suggests:
ii  emacs25-common-non-dfsg  25.1+1-1
ii  ncurses-term 6.0+20161126-1

-- no debconf information

Bug#846168: [pkg-gnupg-maint] Bug#846168: gnupg2: --export-ssh-key is not working

[NIIBE Yutaka]

On 11/29/2016 06:46 AM, Hans Freitag wrote:
> Exporting ssh2 keys is not working with gnupg 2.1.16
> 
> $ gpg2 --export-ssh-key SOMEKEYID
> gpg: O j: Assertion "ret_found_key == NULL || ret_keyblock != NULL" 
> in lookup failed (../../g10/getkey.c:3677)
> Abgebrochen

Thank you for bug report.  It is just fixed in upstream yesterday.

commit 4db9a425644dccaf81b51ebc97b32a9cc21941a4
Author: Justus Winter 
Date:   Mon Nov 28 13:36:56 2016 +0100

g10: Fix iteration over getkey results.

* g10/getkey.c (getkey_next): Only ask 'lookup' for the exact match if
our caller requested the key.  Fixes a crash in 'lookup'.

GnuPG-bug-id: 2848
Fixes-commit: 1d03cc77e1706f7da653153ad4b58c61e4fd2573
Signed-off-by: Justus Winter 

-- 

Bug#811096: Re-open the bug (libpam-poldi: missing pam configuration)

[NIIBE Yutaka]

reopen 811096
thanks

In 0.4.2+git20161107.16912be-1, I closed this bug by offering the
config, but it resulted bad configuration.  It's:

 Part of /etc/pam.d/common-auth
# here are the per-package modules (the "Primary" block)
auth[success=2 default=ignore]  pam_unix.so nullok_secure
auth[success=1 default=ignore]  pam_poldi.so


I think that this is pretty bad configuration for Poldi.  It should
not be in common-auth.

Please note that Poldi is somehow experimental.  Even though it's
a PAM module, the code was not written carefully assuming the code
may be used with privileged mode.

The authentication by Poldi should be only allowed to specific
service(s) and remote services should not be allowed.

I think that it's good to leave as administrator task to configure
Poldi so that some local services enables Poldi but requiring local
and secure TTY.

I'll remove configuration in updated package.
-- 

Bug#811096: libpam-poldi: missing pam configuration

[NIIBE Yutaka]

Hello,

Thank you for your bug report.

On 01/16/2016 12:50 AM, Andrew Gallagher wrote:
> Package: libpam-poldi
> Version: 0.4.2+git20151221.338f78b-1
> Severity: important
> Tags: patch
> 
> Dear Maintainer,
> 
> poldi requires the following extra file before it will be active in pam. It
> will also need a call to "pam-auth-update" in both the postinst and postrm
> scripts to (de)activate the change on (un)install.
> 
> /usr/share/pam-configs/poldi:
> 
> 
> Name: PGP smartcard authentication
> Default: yes
> Priority: 254
> Auth-Type: Primary
> Auth:
> [success=end default=ignore]pam_poldi.so
> Auth-Initial:
> [success=end default=ignore]pam_poldi.so
> 

I included this change, and I closed this bug report.  However,
I think that it's better to discuss.

IIUC, this usage of poldi allow adding authentication with smartcard
as an option.  By the configuration above, an entry in
/etc/pam.d/common-auth will be created.

Then, a user can skip traditional UNIX password authentication
to proceed authentication with smartcard.

Is it really good configuration, installed as a default? I'm afraid.

Currently, I'm working Poldi upstream so that it can be used for
sudo/su to connect gpg-agent (again).  Here's a work of today:


https://git.gnupg.org/cgi-bin/gitweb.cgi?p=poldi.git;a=commit;h=56b759da589bdfa3af31ed95839ba59f12e94fb7

With this patch, it would be good if we can distinguish between
login/gdm and su/sudo/screen-saver.

For login and gdm/xdm/kdm/lightdm, poldi module for PAM should not
connect gpg-agent but invoke scdaemon to access smartcard.

For su/sudo/screen-saver, poldi module for PAM is allowed to access
user's gpg-agent if the configuration has --use-agent option.

How do you think?

Could you please help me to write good PAM configuration for Poldi?
It seems it's Debian specific.
-- 

Bug#806940: [pkg-gnupg-maint] Bug#806940: Bug#806940: gpgv-static possible?

[NIIBE Yutaka]

On 11/09/2016 11:22 AM, Daniel Kahn Gillmor wrote:
> ../common/libcommon.a(libcommon_a-stringhelp.o): In function `get_pwdir':
> ./build-gpgv-static/common/../../common/stringhelp.c:378: warning: Using 
> 'getpwnam' in statically linked applications requires at runtime the shared 
> libraries from the glibc version used for linking
> ./build-gpgv-static/common/../../common/stringhelp.c:385: warning: Using 
> 'getpwuid' in statically linked applications requires at runtime the shared 
> libraries from the glibc version used for linking
> 
> That doesn't sound like a warning we want.  does anyone know how to
> resolve it?

If we want to support exact same behavior for gpgv-static, shared
libraries for NSS should come together with it.

GnuPG allows use "~" or "~username" to specify file.  To expand the
tilda, getpwnam or getpwuid is used.

~username can be expanded by NSS module of LDAP, for example.

I think that it is OK for gpgv-static not supporting tilda expansion.
-- 

Bug#840697: modemmanager: interferes NeuG TRNG

[Niibe Yutaka]

Package: modemmanager
Version: 1.6.2-1
Severity: normal

Dear Maintainer,

I develop/use/sell USB TRNG (True Random Number Generator) device
which works as an USB CDC/ACM device.

The intention is that users can get the random bytes from /dev/ttyACM0
with no drivers installed.  Unfortunately modemmanager interferes.

For its users, I recommend to have a following udev rule:

   SUBSYSTEMS=="usb", ATTRS{idVendor}=="234b", ATTRS{idProduct}=="0001", 
ENV{ID_MM_DEVICE_IGNORE}="1"

And then, the device works fine.

Given the situation I distributed more than 200 devices, I think that
it makes sense to have the udev rule above in the modemmanager
package.

The hardware is by free hardware design and the firmware is free
software.

It is also possible to run the firmware on another board which is
cheap enough.  Please have a look at:

http://www.fsij.org/gnuk/neug-on-stm32-nucleo-f103.html

So, I think there are more users of this device.

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

Kernel: Linux 4.7.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages modemmanager depends on:
ii  init-system-helpers1.45
ii  libc6  2.24-1
ii  libglib2.0-0   2.48.1-3
ii  libgudev-1.0-0 230-3
ii  libmbim-glib4  1.14.0-1
ii  libmbim-proxy  1.14.0-1
ii  libmm-glib01.6.0-1
ii  libpolkit-gobject-1-0  0.105-16
ii  libqmi-glib5   1.16.0-1
ii  libqmi-proxy   1.16.0-1

Versions of packages modemmanager recommends:
ii  usb-modeswitch  2.4.0+repack0-1

modemmanager suggests no packages.

-- no debconf information

Bug#840312: [pkg-gnupg-maint] Bug#840312: scdaemon: Add udev rule for Fujitsu Siemens smart card reader?

[NIIBE Yutaka]

On 10/10/2016 10:11 PM, Petter Reinholdtsen wrote:
> Hi.  I got a smart card reader from Fujitsu Siemens that is not
> recognized by scdaemon.  Perhaps it should be added to the udev rules.d
> file?

Thanks for the report.  If it works well, it should be added.

> Perhaps it is better to try to recognize all USB smart card readers
> using the bus class instead of trying to list the IDs of all card
> readers that exist?

Yes, it is possible for udev to match USB class.  I'm not sure if
it's better to do so.

Please note that smartcard reader products and the standard of CCID
are not that good, unfortunately.

My experience says: Most card readers don't work with OpenPGP card by
scdaemon, only some card readers work well.

Major problem is that people use larger key (RSA-2048 or RSA-4096)
with OpenPGP card.  This is considered "huge" for the technology
around smartcard.
-- 

Bug#839614: gnupg2: what happened to scdaemon?

[NIIBE Yutaka]

I replied only to the pkg-gnupg-maint list.  I send again to the bug
tracker.


On 10/03/2016 06:44 AM, Kevin Gallagher wrote:
> I updated packages at some point and now my smartcards don't work,
> because scdaemon has disappeared.

In the migration of gnupg2 to gnupg, scdaemon's path has been changed.
It is now: /usr/lib/gnupg/scdaemon

> $ cat ~/.gnupg/gpg-agent.conf
> pinentry-program /usr/local/bin/pinentry-qt
> keep-display
> display :0.0
> enable-ssh-support
> default-cache-ttl 14400
> max-cache-ttl 14400
> scdaemon-program /usr/lib/gnupg2/scdaemon
> sh
> debug-level none
> homedir /home/kevin/.gnupg

You can remove the option scdaemon-program, then it will work.
I wonder the reason why you have that.
-- 

Bug#814584: gnupg2: gpg2 --card-status fail on armel / Raspberry Pi - "Card error"

[NIIBE Yutaka]

On 08/05/2016 10:52 PM, Petter Reinholdtsen wrote:
> fbx@freedombox:~$ sudo chmod a+rw /dev/bus/usb/001/00*
> fbx@freedombox:~$ gpg2 --card-status
> Reader ...: 08E6:3438:C4CC14F3:0
> Application ID ...: D27600012401020100054202
> Version ..: 2.1
> Manufacturer .: ZeitControl
> Serial number : 4202
> Name of cardholder: [not set]
> Language prefs ...: de
> Sex ..: unspecified
> URL of public key : [not set]
> Login data ...: [not set]
> Signature PIN : forced
> Key attributes ...: rsa2048 rsa2048 rsa2048
> Max. PIN lengths .: 32 32 32
> PIN retry counter : 3 0 3
> Signature counter : 0
> Signature key : [none]
> Encryption key: [none]
> Authentication key: [none]
> General key info..: [none]
> fbx@freedombox:~$
> 
> Indeed, access was the problem!

Great.

> So I guess the key to getting this to work is simply to add the USB ID
> of my card reader to the scdaemon udev setup.  Daniel, do you want a
> separate bug report for that, or can you apply the patch above to the
> next upload?

In #35, it once failed with good permission.  I think something is
different this time.  If it's because of the change introduced in
2.1.14, that's also good for GnuPG to stabilize its internal ccid
driver.

> Thank you very much for your help and patience. :)

No, it's me who say thanks to you.  Without your patience, we can't
get the success.  I appreciate your effort.
-- 



signature.asc
Description: OpenPGP digital signature

Bug#814584: gnupg2: gpg2 --card-status fail on armel / Raspberry Pi - "Card error"

[NIIBE Yutaka]

On 08/05/2016 09:01 PM, Petter Reinholdtsen wrote:
> I decided to test again using an FreedomBox image to reduce the
> difference since my initial testing. First I tested using version
> 2.1.11-7 in Debian testing, and then using version 2.1.14-1 in Debian
> experimental.  Both fail.  First the test using testing.

Thank you for your time.

With 2.1.11-7:

> fbx@freedombox:~$ cat .gnupg/scdaemon.conf 
> debug-level guru
> debug-all
> debug-ccid-driver
> log-file /run/user/1000/scd.log
> verbose
> fbx@freedombox:~$ touch /run/user/1000/scd.log; tail -f 
> /run/user/1000/scd.log &
> fbx@freedombox:~$ gpg2 --card-status  
>  2016-05-22 00:57:45 scdaemon[15783] listening on socket 
> '/home/fbx/.gnupg/S.scdaemon'
> 2016-05-22 00:57:45 scdaemon[15783] handler for fd -1 started
> 2016-05-22 00:57:45 scdaemon[15783] DBG: enter: apdu_open_reader: 
> portstr=(null)
> 2016-05-22 00:57:45 scdaemon[15783] DBG: ccid-driver: using CCID reader 0 
> (ID=08E6:3438:X:0)
[...]
> 2016-05-22 00:57:45 scdaemon[15783] DBG: ccid-driver: usb_claim_interface 
> failed: -1

I think that this failure is because of insufficient configuration of
the access permission.

Please read my message again:

Message-ID: <5760e002.1090...@fsij.org>

It is also available as:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814584#30

Let's see the log of version 2.1.14-1:

> Next, after running 'apt install -t experimental gnupg2 scdaemon', I got
> this result:
> fbx@freedombox:~$ killall gpg-agent scdaemon  
> 2016-05-22 01:04:09 scdaemon[15783] DBG: chan_5 <- [eof]
> 2016-05-22 01:04:09 scdaemon[15783] handler for fd -1 terminated
> 2016-05-22 01:04:09 scdaemon[15783] SIGTERM received - still 0 running threads
> 2016-05-22 01:04:09 scdaemon[15783] scdaemon (GnuPG) 2.1.11 stopped
> fbx@freedombox:~$ 
> fbx@freedombox:~$ gpg2 --card-status  
> 2016-05-22 01:04:17 scdaemon[16362] listening on socket 
> '/run/user/1000/gnupg/S.scdaemon'
> 2016-05-22 01:04:17 scdaemon[16362] handler for fd -1 started
> 2016-05-22 01:04:17 scdaemon[16362] DBG: enter: apdu_open_reader: 
> portstr=(null)
> 2016-05-22 01:04:17 scdaemon[16362] DBG: ccid-driver: usb_open failed: 
> LIBUSB_ERROR_ACCESS

In 2.1.14, libusb has been changed, so, the error message is
different, but it also means access error.  It's highly likely access
permission problem.

> So I guess it is one step forward, two steps back. :(

We are still same place, I think.

>> Well, if you would like to change other factors to get success anyway,
>> I'd recommend to take some hardware approach which possibly may
>> stabilize the USB communication:
>>
>>   (1) Use good voltage supply to RPi board.
>>
>>   (2) Only connect the card reader (+ the smart card) to USB port of
>>   RPi so that we can minimize the load of USB.  If you connect
>>   keyboard and mouse, try good ones (or none by using the
>>   network).
>>
>>   (3) Use a USB HUB with an external voltage supply to connect the
>>   card reader.
> 
> I've tried all three adjustments, did not make a difference. :(

Please try again with proper permission.

> I bought the the card and reader I am using from
> http://shop.kernelconcepts.de/ >.  They work fine using amd64, but
> not at all using armel. :(

I don't know about FreedomBox image.  Apparently, udev rules doesn't
work well.  Please try manually chmod or chgrp device file under
/dev/bus/usb/
-- 

Bug#814584: gnupg2: gpg2 --card-status fail on armel / Raspberry Pi - "Card error"

[NIIBE Yutaka]

On 08/03/2016 10:10 PM, Petter Reinholdtsen wrote:
> My original test was done using a Freedombox image, which was armel.
> 
> Todays test was done using some random RPi and SD card I found on my
> desk and I did not notice it was using a different architecture.  I can
> try again on armel, if you believe it mattes.

I see the situation.  I have no idea about the segmentation fault.

I don't know if the difference of armel/armhf matters or not.  My
point was that in order to narrow down an issue (to be fixed), in
general, it would be better not to change other factors.

While I guess that the major problem is hardware related, I modified
the ccid-driver of GnuPG so that the difference between PC/SC service
can be smaller (less factors involved).

Well, if you would like to change other factors to get success anyway,
I'd recommend to take some hardware approach which possibly may
stabilize the USB communication:

  (1) Use good voltage supply to RPi board.

  (2) Only connect the card reader (+ the smart card) to USB port of
  RPi so that we can minimize the load of USB.  If you connect
  keyboard and mouse, try good ones (or none by using the
  network).

  (3) Use a USB HUB with an external voltage supply to connect the
  card reader.

My daily development environment and desktop environment is Wandboard
(armhf).  I test on BeagleBone Green (armhf) and SheevaPlug clone
(armel), too.

For those boards, USB host is not as good as PC, signal-wise and
power-wise.  For example, I can reproduce USB communication failure on
my Wandboard by inserting an additional USB Hub with no voltage supply
(while the USB specification allows many).
-- 

Bug#814584: gnupg2: gpg2 --card-status fail on armel / Raspberry Pi - "Card error"

[NIIBE Yutaka]

On 08/03/2016 09:03 PM, Petter Reinholdtsen wrote:
> Thank you.  I just tested on a Raspberry Pi using the gnupg2/scdaemon
> version 2.1.14-2 in Debian experimental, and this now segfaults when I
> try 'gpg2 --card-status'.  But for some reason I can't get info from
> valgrind, so here is the backtrace from gdb:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0xb6cbc020 in strlen () from /lib/arm-linux-gnueabihf/libc.so.6
> (gdb) bt
> #0  0xb6cbc020 in strlen () from /lib/arm-linux-gnueabihf/libc.so.6
> #1  0x7f5b2174 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb) 

arm-linux-gnueabihf ?  Your original report says "armel" in the
subject.

According to https://wiki.debian.org/RaspberryPi, it seems armel.

> But I do not quite understand why the old code should work on amd64 but
> not on arm.

I don't think architecture matters.  IIUC, the problem is Raspberry Pi
specific, reader specific, or the combination of board and reader.

Please note that it works both on armel and armhf on my environment
with Gnuk Token and some other readers.
--