Bug#984884: libgcrypt20: Unknown error executing apt-key [Bullseye]
On 2021-09-09 Mateusz Rejek wrote: > Interestingly enough got the same problem on ARMHF after moving to bullseye. > I have version 1.8.7-6 installed over 1.8.4-5+deb10u1 > # cat /var/log/dpkg.log.1 | grep libgcrypt > > 2021-09-07 13:07:54 upgrade libgcrypt20:armhf 1.8.4-5+deb10u1 1.8.7-6 > > 2021-09-07 13:07:54 status half-configured libgcrypt20:armhf > > 1.8.4-5+deb10u1 > > 2021-09-07 13:07:54 status unpacked libgcrypt20:armhf 1.8.4-5+deb10u1 > > 2021-09-07 13:07:54 status half-installed libgcrypt20:armhf 1.8.4-5+deb10u1 > > 2021-09-07 13:07:54 status unpacked libgcrypt20:armhf 1.8.7-6 > > 2021-09-07 13:07:54 configure libgcrypt20:armhf 1.8.7-6 > > 2021-09-07 13:07:54 status unpacked libgcrypt20:armhf 1.8.7-6 > > 2021-09-07 13:07:54 status half-configured libgcrypt20:armhf 1.8.7-6 > > 2021-09-07 13:07:54 status installed libgcrypt20:armhf 1.8.7-6 [...] > # ls -al /lib/arm-linux-gnueabihf/libgcrypt.so.20 > > lrwxrwxrwx 1 root root 19 Sep 7 14:30 > > /lib/arm-linux-gnueabihf/libgcrypt.so.20 -> libgcrypt.so.20.0.3 [...] > IMO problem is coming from libgcrypt moving in Debian 11 from > /lib/arm-linux-gnueabihf/ to /usr/lib/arm-linux-gnueabihf/ and leaving old > lib behind The left behind file (libgcrypt.so.20.0.3) is from libgcrypt20 1.6.3 so the actual error (dpkg failing to remove an file on upgrade) happened a lot earlier. 1.6.3 was shipped in Debian8/jessie. cu Andreas
Bug#984884: libgcrypt20: Unknown error executing apt-key [Bullseye]
Hi,
Interestingly enough got the same problem on ARMHF after moving to bullseye.
I have version 1.8.7-6 installed over 1.8.4-5+deb10u1
# cat /var/log/dpkg.log.1 | grep libgcrypt
> 2021-09-07 13:07:54 upgrade libgcrypt20:armhf 1.8.4-5+deb10u1 1.8.7-6
> 2021-09-07 13:07:54 status half-configured libgcrypt20:armhf
> 1.8.4-5+deb10u1
> 2021-09-07 13:07:54 status unpacked libgcrypt20:armhf 1.8.4-5+deb10u1
> 2021-09-07 13:07:54 status half-installed libgcrypt20:armhf 1.8.4-5+deb10u1
> 2021-09-07 13:07:54 status unpacked libgcrypt20:armhf 1.8.7-6
> 2021-09-07 13:07:54 configure libgcrypt20:armhf 1.8.7-6
> 2021-09-07 13:07:54 status unpacked libgcrypt20:armhf 1.8.7-6
> 2021-09-07 13:07:54 status half-configured libgcrypt20:armhf 1.8.7-6
> 2021-09-07 13:07:54 status installed libgcrypt20:armhf 1.8.7-6
and confirmed to be OK:
# dpkg -s libgcrypt20
> Package: libgcrypt20
> Status: install ok installed
> Priority: optional
> Section: libs
> Installed-Size: 1027
> Maintainer: Debian GnuTLS Maintainers <
> pkg-gnutls-ma...@lists.alioth.debian.org>
> Architecture: armhf
> Multi-Arch: same
> Version: 1.8.7-6
> Depends: libc6 (>= 2.28), libgpg-error0 (>= 1.25)
> Suggests: rng-tools
> Description: LGPL Crypto library - runtime library
> libgcrypt contains cryptographic functions. Many important free
> ciphers, hash algorithms and public key signing algorithms have been
> implemented:
> .
> Arcfour, Blowfish, CAST5, DES, AES, Twofish, Serpent, rfc2268 (rc2), SEED,
> Poly1305, Camellia, ChaCha20, IDEA, Salsa, Blake-2, CRC, MD2, MD4, MD5,
> RIPE-MD160, SHA-1, SHA-256, SHA-512, SHA3-224, SHA3-256, SHA3-384,
> SHA3-512,
> SHAKE128, SHAKE256, Tiger, Whirlpool, DSA, DSA2, ElGamal, RSA, ECC
> (Curve25519, sec256k1, GOST R 34.10-2001 and GOST R 34.10-2012, etc.)
> Homepage: https://directory.fsf.org/project/libgcrypt/
gpg is linking to libgcrypt.so.20
# ldd /usr/bin/gpg
> linux-vdso.so.1 (0x7ed53000)
> /usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so =>
> /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so (0x76ec2000)
> libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0x76e85000)
> libbz2.so.1.0 => /lib/arm-linux-gnueabihf/libbz2.so.1.0 (0x76e65000)
> libsqlite3.so.0 => /usr/lib/arm-linux-gnueabihf/libsqlite3.so.0
> (0x76d39000)
> libgcrypt.so.20 => /lib/arm-linux-gnueabihf/libgcrypt.so.20 (0x76c96000)
> libreadline.so.8 => /lib/arm-linux-gnueabihf/libreadline.so.8 (0x76c43000)
> libassuan.so.0 => /usr/lib/arm-linux-gnueabihf/libassuan.so.0 (0x76c23000)
> libgpg-error.so.0 => /lib/arm-linux-gnueabihf/libgpg-error.so.0
> (0x76bf6000)
> libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76aa2000)
> /lib/ld-linux-armhf.so.3 (0x76ed7000)
> libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x76a33000)
> libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x76a07000)
> libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0x769f3000)
> libtinfo.so.6 => /lib/arm-linux-gnueabihf/libtinfo.so.6 (0x769c1000)
That is pointing to libgcrypt.so.20.0.3
# ls -al /lib/arm-linux-gnueabihf/libgcrypt.so.20
> lrwxrwxrwx 1 root root 19 Sep 7 14:30
> /lib/arm-linux-gnueabihf/libgcrypt.so.20 -> libgcrypt.so.20.0.3
but in the system there also:
# ls -al /usr/lib/arm-linux-gnueabihf/libgcrypt.so.20
> lrwxrwxrwx 1 root root 19 May 27 18:07
> /usr/lib/arm-linux-gnueabihf/libgcrypt.so.20 -> libgcrypt.so.20.2.8
coming from:
root@rpi3:~# dpkg -L libgcrypt20
> /.
> /usr
> /usr/lib
> /usr/lib/arm-linux-gnueabihf
> /usr/lib/arm-linux-gnueabihf/libgcrypt.so.20.2.8
> /usr/share
> /usr/share/doc
> /usr/share/doc/libgcrypt20
> /usr/share/doc/libgcrypt20/AUTHORS.gz
> /usr/share/doc/libgcrypt20/NEWS.gz
> /usr/share/doc/libgcrypt20/README.gz
> /usr/share/doc/libgcrypt20/THANKS.gz
> /usr/share/doc/libgcrypt20/changelog.Debian.gz
> /usr/share/doc/libgcrypt20/changelog.gz
> /usr/share/doc/libgcrypt20/copyright
> /usr/lib/arm-linux-gnueabihf/libgcrypt.so.20
After removing old lib from /lib/arm-linux-gnueabihf/libgcrypt.so.20,
leaving /usr/lib/arm-linux-gnueabihf/libgcrypt.so.20 in place and
re-running ldconfig
I moved from
# gpg --version
> gpg: Fatal: libgcrypt is too old (need 1.8.0, have 1.6.3)
to
# gpg --version
> gpg (GnuPG) 2.2.27
> libgcrypt 1.8.8
> Copyright (C) 2021 Free Software Foundation, Inc.
> License GNU GPL-3.0-or-later
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
Home: //.gnupg
> Supported algorithms:
> Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
> Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
> CAMELLIA128, CAMELLIA192, CAMELLIA256
> Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
> Compression: Uncompressed, ZIP, ZLIB, BZIP2
This was following an dist-upgrade from Debian 10 to Debian 11.
IMO problem is coming from libgcrypt moving in Debian 11 from
/lib/arm-linux-gnueabihf/ to /usr/lib/arm-linux-gnueabihf/ and leaving old
lib behind
--
Mat
Bug#984884: libgcrypt20: Unknown error executing apt-key [Bullseye]
Hi Andreas, On 10/03/21 07:37, Andreas Metzler wrote: On 2021-03-09 Davide Prina wrote: [...] Some users in Italian mailing list have reported that they have an error when they try upgrade/install packages: [...] dig the problem we found that they have the following files on their system: [...] $ ls -l /lib/x86_64-linux-gnu/libgcrypt.so.20.1.5 -rw-r--r-- 1 root root 1112184 14 gen 2017 /lib/x86_64-linux-gnu/libgcrypt.so.20.1.5 but these files are from package migrated to testing in: [2017-01-25] libgcrypt20 1.7.5-3 MIGRATED to testing (Debian testing watch)[¹] So for some reason when the library path change they have not been deleted. Another possibility would be that the user tried to upgrade from pre-oldstable directly to current-testing, skipping releases. he never do that Do you have any further information on the upgrade, which version of libgcrypt was upgraded with what version of dpkg/apt to which version? in /var/log/dpkg.log* user has no more info of that old version he think he has Debian stable until summer 2020 or few month before, than he upgrades to testing. He has problems with samba, so he downgraded samba and he used pinning (samba/winbind/...) or used a stable/testing repositories (he don't remember). At 14th October he change his domain and removed all (pinning and/or stable repo) and since that he has used only testing without security repository in his sources.list But the library version is from 2017, so probably the problem is generated before. [...] I suggest to check that those file are removed from /lib/x86_64-linux-gnu/ in all new libgcrypt20 new version, elsewhere when Bullseye become stable more user can have that problem. [...] Sure it is possible to apply a bandaid but this just scale. Packages normally need to be able to rely on dpkg to work. If it is a wide-spread problem the cost/benefit ration can make sense. it can be interesting to know if there are other user that have this older library in their systems... but I don't know if there is a good solution (the only thing I can imagine is something like this: let apt check and ask people to report this issue to this bug report) Ciao Davide
Bug#984884: libgcrypt20: Unknown error executing apt-key [Bullseye]
Control: tags -1 moreinfo Control: severity -1 normal On 2021-03-09 Davide Prina wrote: [...] > Some users in Italian mailing list have reported that they have an error > when they try upgrade/install packages: [...] > dig the problem we found that they have the following files on their system: [...] > $ ls -l /lib/x86_64-linux-gnu/libgcrypt.so.20.1.5 > -rw-r--r-- 1 root root 1112184 14 gen 2017 > /lib/x86_64-linux-gnu/libgcrypt.so.20.1.5 > but these files are from package migrated to testing in: > [2017-01-25] libgcrypt20 1.7.5-3 MIGRATED to testing (Debian testing > watch)[¹] > So for some reason when the library path change they have not been deleted. Hello Davide, 1.7.5 is ancient, it was shipped in Debian during the development cycle of Debian 9 (stretch) but was not part of the Debian 9 (stretch) release. So the actual breakage happened when the user upgraded from 1.7.5-1/2/3 to some later version, using the Debian infrastructure (dpkg, apt, kernel, filesystem) at this point of time, probably in 2017. Another possibility would be that the user tried to upgrade from pre-oldstable directly to current-testing, skipping releases. If that is the case he/she is doing something we do not support. Do you have any further information on the upgrade, which version of libgcrypt was upgraded with what version of dpkg/apt to which version? [...] > I suggest to check that those file are removed from > /lib/x86_64-linux-gnu/ > in all new libgcrypt20 new version, elsewhere when Bullseye become stable > more user can have that problem. [...] Sure it is possible to apply a bandaid but this just scale. Packages normally need to be able to rely on dpkg to work. If it is a wide-spread problem the cost/benefit ration can make sense. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#984884: libgcrypt20: Unknown error executing apt-key [Bullseye]
Package: libgcrypt20 Version: 1.8.7-3 Severity: critical I set it as critical because user cannot anymore upgrade their system, please adjust Severity if you think it not correct. Note that this can be also a security problem because very old libgcrypt20 is in use. Some users in Italian mailing list have reported that they have an error when they try upgrade/install packages: # apt update Get:1 http://deb.debian.org/debian bullseye InRelease [142 kB] Err:1 http://deb.debian.org/debian bullseye InRelease Unknown error executing apt-key Reading package lists... Done Building dependency tree... Done Reading state information... Done All packages are up to date. W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://deb.debian.org/debian bullseye InRelease: Unknown error executing apt-key W: Failed to fetch http://deb.debian.org/debian/dists/bullseye/InRelease Unknown error executing apt-key W: Some index files failed to download. They have been ignored, or old ones used instead. dig the problem we found that they have the following files on their system: $ /sbin/ldconfig -p | grep libgcrypt libgcrypt.so.20 (libc6,x86-64) => /lib/x86_64-linux-gnu/libgcrypt.so.20 libgcrypt.so.20 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libgcrypt.so.20 $ ls -l /lib/x86_64-linux-gnu/libgcrypt.so.20 lrwxrwxrwx 1 root root 19 17 mar 2020 /lib/x86_64-linux-gnu/libgcrypt.so.20 -> libgcrypt.so.20.1.5 $ ls -l /lib/x86_64-linux-gnu/libgcrypt.so.20.1.5 -rw-r--r-- 1 root root 1112184 14 gen 2017 /lib/x86_64-linux-gnu/libgcrypt.so.20.1.5 but these files are from package migrated to testing in: [2017-01-25] libgcrypt20 1.7.5-3 MIGRATED to testing (Debian testing watch)[¹] So for some reason when the library path change they have not been deleted. All users with that problem cannot use apt to solve the issue. I know that the user that report the problem has not the security repository in its sources.list file. I suggest to check that those file are removed from /lib/x86_64-linux-gnu/ in all new libgcrypt20 new version, elsewhere when Bullseye become stable more user can have that problem. Ciao Davide [¹] https://tracker.debian.org/pkg/libgcrypt20/news/?page=3 https://snapshot.debian.org/archive/debian/20170114T162918Z/pool/main/libg/libgcrypt20/libgcrypt20_1.7.5-3_amd64.deb
