Bug#1070688: [pkg-gnupg-maint] Bug#1070688: gnupg: PINENTRY_USER_DATA not passed to pinentry
Hi Farblos-- On Tue 2024-05-14 21:28:05 +0200, Farblos wrote: > Should I open another issue about PINENTRY_USER_DATA not being > forwarded to the pinentry when using the gpg from package gpg-sq/ > gpg-from-sq? If yes, on what repository exactly? I would report it at https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg -- the more you can explain your specific setup, and reference the gpg documentation (perhaps the "environment variables" subsection of the FILES section of gpg(1)?) to justify the behavior would probably help sequoia figure out what needs fixing for your scenario. > gpg-from-sq indeed was on my system, and I think it got there because > of some of aptitude's proposals to resolve broken references. Thanks for including the apt logs. I'm still not sure how to replicate this change. It looks like some part of gpg was explicitly "held" by apt? and the other packages involved during this upgrade run (libdv4t64, libnetpbm11t64, libopencore-amrnb0, libopencore-amrwb0, gstreamer1.0-plugins-good, netpbm) don't seem related to GnuPG at all. And, gpgv itself somehow wasn't held? Curious! but i still don't really understand what happened here, unfortunately ☹ If anyone else has any insights or can suggest other things that Farblos could report, i'd welcome other suggestions. --dkg signature.asc Description: PGP signature
Bug#1070688: [pkg-gnupg-maint] Bug#1070688: gnupg: PINENTRY_USER_DATA not passed to pinentry
Hi Daniel,
On 2024-05-08 19:25, Daniel Kahn Gillmor wrote:
thanks for taking care about this in general and this one:
> Thanks, i've reported this part upstream:
> https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg/-/issues/74
in particular.
Should I open another issue about PINENTRY_USER_DATA not being
forwarded to the pinentry when using the gpg from package gpg-sq/
gpg-from-sq? If yes, on what repository exactly?
With respect to your packaging questions:
> gpg-sq doesn't install any diversions to my knowledge. the only
> diversions that might be installed are in gpg-from-sq or gpgv-from-sq.
You are right here, I've been sloppy in my wording.
> If those packages were on your system, then they could indeed have
> installed a diversion. But nothing explicitly depends on those packages
> (try running "apt rdepends gpg{,v}-from-sq") so i'm not sure how they
> got installed during an upgrade.
gpg-from-sq indeed was on my system, and I think it got there because
of some of aptitude's proposals to resolve broken references.
> Perhaps it has something to do with the fact that the packages use the
> Provides field? If you didn't deliberately install either of the
> *-from-sq packages, and they ended up on your system, is there some way
> that you can replicate the upgrade path? I'd like to understand that
> better, as i don't think it should have happened by accident.
Unfortunately, I don't think I can explain that fully, but I can try
to provide some more information. (Even if I'm now rather sure that
this should not affect too many other users ...)
As mentioned before, this all happened in the heat of the t64 upgrade
on a Debian testing system. For a month or so I would have to wait
until the daily unattended upgrade failed to completely do its job,
then I would use aptitude to manually handle the remaining packages
in a way that wouldn't deinstall anything valuable. Meaning: In the
aptitude curses front-end I would press "+" on the "Upgradable
Packages" and then cycle through aptitude's proposal on how to
resolve the packages that unattended upgrade (and aptitude) would not
upgrade automatically.
I have attached the interesting bits for that day (2024-05-07) from
my unattended upgrade logs and from the aptitude log below. If you
think there could be more treasures hidden in my logs (nothing special
configured on my system), please let me know.
> Perhaps there is some signal either package can give to apt to help it
> avoid that problem in the future?
This would be a question for the apt (or aptitude) folks, I think,
but as mentioned above this was probably a rather special case, so
not really worth further effort ...
unattended-upgrades.log
2024-05-07 10:28:56,541 INFO Starting unattended upgrades script
2024-05-07 10:28:56,542 INFO Allowed origins are:
origin=Debian,archive=testing,label=Debian
2024-05-07 10:28:56,542 INFO Initial blacklist:
2024-05-07 10:28:56,542 INFO Initial whitelist (not strict):
2024-05-07 10:29:09,972 INFO Packages that will be upgraded: acl e2fsprogs
elpa-org fwupd gir1.2-lightdm-1 groff-base gstreamer1.0-plugins-base libacl1
libboost-iostreams1.83.0 libboost-locale1.83.0 libboost-thread1.83.0 libc-bin
libc-dev-bin libc-l10n libc6 libc6-dev libcairo-gobject2 libcairo2 libcom-err2
libext2fs2t64 libfftw3-double3 libfftw3-single3 libfwupd2
libgstreamer-plugins-base1.0-0 liblightdm-gobject-1-0 libp11-kit0
libpolkit-agent-1-0 libpolkit-gobject-1-0 libsnappy1v5 libsqlite3-0 libss2
libudisks2-0 lightdm locales logsave org-mode-doc pkexec policykit-1 polkitd
postfix python-apt-common python3-apt rsyslog sqlite3 udisks2
2024-05-07 10:29:09,973 INFO Writing dpkg log to
/var/log/unattended-upgrades/unattended-upgrades-dpkg.log
2024-05-07 10:29:46,076 INFO All upgrades installed
2024-05-07 10:29:46,269 INFO Package dirmngr is kept back because a related
package is kept back or due to local apt_preferences(5).
2024-05-07 10:29:46,278 INFO Package gnupg is kept back because a related
package is kept back or due to local apt_preferences(5).
2024-05-07 10:29:46,278 INFO Package gnupg-l10n is kept back because a related
package is kept back or due to local apt_preferences(5).
2024-05-07 10:29:46,278 INFO Package gnupg-utils is kept back because a related
package is kept back or due to local apt_preferences(5).
2024-05-07 10:29:46,282 INFO Package gpg is kept back because a related package
is kept back or due to local apt_preferences(5).
2024-05-07 10:29:46,282 INFO Package gpg-agent is kept back because a related
package is kept back or due to local apt_preferences(5).
2024-05-07 10:29:46,283 INFO Package gpg-wks-client is kept back because a
related package is kept back or due to local apt_preferences(5).
2024-05-07 10:29:46,283 INFO Package gpg-wks-server is kept back because a
related package is kept back or due to local apt_preferences(5).
2024-05-07 10:29:46,283 INFO Package gpgconf is kept back because
Bug#1070688: [pkg-gnupg-maint] Bug#1070688: gnupg: PINENTRY_USER_DATA not passed to pinentry
Control: affects 1070688 + gpg-from-sq apt
Hi Farblos, all--
Thanks for this detailed bug report (https://bugs.debian.org/1070688).
I'm a bit confused about the following:
On Wed 2024-05-08 11:07:28 +0200, Farblos wrote:
> Never mind. During one of the last t64 upgrade orgies package gpg-sq got
> installed on my system and succeeded to install the diversion to /usr/bin/gpg.
> And the sequoia replacement is not very feature complete, as they continue
> to stress themselfes.
gpg-sq doesn't install any diversions to my knowledge. the only
diversions that might be installed are in gpg-from-sq or gpgv-from-sq.
If those packages were on your system, then they could indeed have
installed a diversion. But nothing explicitly depends on those packages
(try running "apt rdepends gpg{,v}-from-sq") so i'm not sure how they
got installed during an upgrade.
Perhaps it has something to do with the fact that the packages use the
Provides field? If you didn't deliberately install either of the
*-from-sq packages, and they ended up on your system, is there some way
that you can replicate the upgrade path? I'd like to understand that
better, as i don't think it should have happened by accident.
Perhaps there is some signal either package can give to apt to help it
avoid that problem in the future?
> For example, referencing a recipient by exact name with "="
> does not work in gpg-sq, either.
Thanks, i've reported this part upstream:
https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg/-/issues/74
--dkg
signature.asc
Description: PGP signature
Bug#1070688: gnupg: PINENTRY_USER_DATA not passed to pinentry
Never mind. During one of the last t64 upgrade orgies package gpg-sq got installed on my system and succeeded to install the diversion to /usr/bin/gpg. And the sequoia replacement is not very feature complete, as they continue to stress themselfes. For example, referencing a recipient by exact name with "=" does not work in gpg-sq, either. I just purged gpg-sq and its dependencies and now I'm back to normal. Feel free to close this issue.
Bug#1070688: gnupg: PINENTRY_USER_DATA not passed to pinentry
A quick comparison of the package sources hasn't revealed anything obvious. So here is a reproducer (custom pinentry defined in gpg-agent.conf that dumps its environment): [~]$ grep ^pinentry-program .gnupg/gpg-agent.conf pinentry-program/home/farblos/tmp/pinentry [~]$ cat /home/farblos/tmp/pinentry #!/bin/bash ( date; export; ) > /tmp/pinentry.log [~]$ ls -al /home/farblos/tmp/pinentry -rwxrwxr-x 1 farblos farblos 51 May 7 11:48 /home/farblos/tmp/pinentry [~]$ gpg --encrypt --recipient BEA00D6B5803B828854E115908C216F6FF7B6B30 /home/farblos/tmp/pinentry > /home/farblos/tmp/pinentry.gpg [~]$ systemctl --user restart gpg-agent [~]$ gpg --decrypt /home/farblos/tmp/pinentry.gpg gpg: encrypted with 3072-bit RSA key, ID 646746DE42C89279, created 2022-11-30 "backup" gpg: decryption failed: No secret key [~]$ cat /tmp/pinentry.log Tue May 7 11:55:11 CEST 2024 declare -x DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" declare -x DISPLAY=":0" declare -x GSM_SKIP_SSH_AGENT_WORKAROUND="true" declare -x HOME="/home/farblos" declare -x INVOCATION_ID="73be729ef883415aaf43ca4a4de2049b" declare -x JOURNAL_STREAM="8:18301" declare -x LANG="en_US.UTF-8" declare -x LANGUAGE="en_US:en" declare -x LC_COLLATE="POSIX" declare -x LC_MEASUREMENT="de_DE.UTF-8" declare -x LC_PAPER="de_DE.UTF-8" declare -x LC_TIME="POSIX" declare -x LISTEN_FDNAMES="extra:ssh:std:browser" declare -x LISTEN_FDS="4" declare -x LISTEN_PID="4355" declare -x LOGNAME="farblos" declare -x MANAGERPID="1776" declare -x MEMORY_PRESSURE_WATCH="/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/gpg-agent.service/memory.pressure" declare -x MEMORY_PRESSURE_WRITE="c29tZSAyMDAwMDAgMjAwMDAwMAA=" declare -x OLDPWD declare -x PATH="/home/farblos/bin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games" declare -x PWD="/home/farblos" declare -x SHELL="/bin/bash" declare -x SHLVL="1" declare -x SSH_AUTH_SOCK="/run/user/1000/gnupg/S.gpg-agent.ssh" declare -x SYSTEMD_EXEC_PID="4355" declare -x USER="farblos" declare -x XAUTHORITY="/home/farblos/.Xauthority" declare -x XDG_RUNTIME_DIR="/run/user/1000" declare -x XDG_SESSION_ID="1" declare -x XDG_SESSION_TYPE="x11" declare -x _assuan_pipe_connect_pid="4355" [~]$ PINENTRY_USER_DATA=foobarbaz gpg --decrypt /home/farblos/tmp/pinentry.gpg gpg: encrypted with 3072-bit RSA key, ID 646746DE42C89279, created 2022-11-30 "backup" gpg: decryption failed: No secret key [~]$ cat /tmp/pinentry.log Tue May 7 12:08:16 CEST 2024 declare -x DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus" declare -x DISPLAY=":0" declare -x GSM_SKIP_SSH_AGENT_WORKAROUND="true" declare -x HOME="/home/farblos" declare -x INVOCATION_ID="73be729ef883415aaf43ca4a4de2049b" declare -x JOURNAL_STREAM="8:18301" declare -x LANG="en_US.UTF-8" declare -x LANGUAGE="en_US:en" declare -x LC_COLLATE="POSIX" declare -x LC_MEASUREMENT="de_DE.UTF-8" declare -x LC_PAPER="de_DE.UTF-8" declare -x LC_TIME="POSIX" declare -x LISTEN_FDNAMES="extra:ssh:std:browser" declare -x LISTEN_FDS="4" declare -x LISTEN_PID="4355" declare -x LOGNAME="farblos" declare -x MANAGERPID="1776" declare -x MEMORY_PRESSURE_WATCH="/sys/fs/cgroup/user.slice/user-1000.slice/user@1000.service/app.slice/gpg-agent.service/memory.pressure" declare -x MEMORY_PRESSURE_WRITE="c29tZSAyMDAwMDAgMjAwMDAwMAA=" declare -x OLDPWD declare -x PATH="/home/farblos/bin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games" declare -x PWD="/home/farblos" declare -x SHELL="/bin/bash" declare -x SHLVL="1" declare -x SSH_AUTH_SOCK="/run/user/1000/gnupg/S.gpg-agent.ssh" declare -x SYSTEMD_EXEC_PID="4355" declare -x USER="farblos" declare -x XAUTHORITY="/home/farblos/.Xauthority" declare -x XDG_RUNTIME_DIR="/run/user/1000" declare -x XDG_SESSION_ID="1" declare -x XDG_SESSION_TYPE="x11" declare -x _assuan_pipe_connect_pid="4355" I also took debug traces of the agent, which show that the pinentry user data is passed from gpg to the agent through assuan, but not forwarded from there to the pinentry. Data available on request.
Bug#1070688: gnupg: PINENTRY_USER_DATA not passed to pinentry
Package: gnupg Version: 2.2.40-3 Severity: normal X-Debbugs-Cc: in.cognit...@arcor.de Dear Maintainer, * What led up to the situation? Most likely today's upgrade from GnuPG related packages 2.2.40-1.1 -> 2.2.40-3. "Yesterday this still has been working." * What exactly did you do (or not do) that was effective (or ineffective)? Use my custom pinentry that relies on PINENTRY_USER_DATA (or on Assuan command "OPTION pinentry-user-data") being passed through from client to pinentry. * What was the outcome of this action? Environment variable PINENTRY_USER_DATA is not set when the pinentry is called, and OPTION pinentry-user-data is not provided by the caller of the pinentry. * What outcome did you expect instead? The information set in environment variable PINENTRY_USER_DATA being forwarded from the client to the pinentry. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.7.12-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnupg depends on: ii dirmngr 2.2.40-3 ii gnupg-l10n 2.2.40-3 ii gnupg-utils 2.2.40-3 ii gpg 2.2.40-3 ii gpg-agent2.2.40-3 ii gpg-from-sq [gpg]0.8.0-5 ii gpg-wks-client 2.2.40-3 ii gpg-wks-server 2.2.40-3 ii gpgsm2.2.40-3 ii gpgv 2.2.40-3 ii gpgv-from-sq [gpgv] 0.8.0-5 gnupg recommends no packages. Versions of packages gnupg suggests: pn parcimonie pn xloadimage -- no debconf information
