Univention Bugzilla – Bug 48817
python-gnupg in UCS doesn't support GnuPG version in UCS
Last modified: 2021-05-14 16:33:57 CEST
The stretch version of python-gnupg doesn't support GnuPG 2.1, which is installed in UCS 4.3. Keys imported on the command line cannot be used with python-gnupg. Update python-gnupg to the version from stretch-backports (0.4.3).
Where is this a problem? For repo-ng this was worked around with git:1bc88f28fe21f2d424d0ecc43c7a2a60d245d198 For now make sure that you have the "classic version" "gnupg1" also installed and do not specify GPG(gpgbinary='gpg') as that references the new v2 implementation. $ dpkg -s python-gnupg ... Depends: ..., gnupg1
# mkdir /root/importgnupg2.1 # gpg --homedir /root/importgnupg2.1/ --import key.gpg # ls -l /root/importgnupg2.1/ drwx------ 2 root root 4096 Feb 28 10:33 private-keys-v1.d -rw-r--r-- 1 root root 1390 Feb 28 10:33 pubring.kbx -rw------- 1 root root 32 Feb 28 10:33 pubring.kbx~ srwx------ 1 root root 0 Feb 28 10:33 S.gpg-agent srwx------ 1 root root 0 Feb 28 10:33 S.gpg-agent.browser srwx------ 1 root root 0 Feb 28 10:33 S.gpg-agent.extra srwx------ 1 root root 0 Feb 28 10:33 S.gpg-agent.ssh -rw------- 1 root root 1200 Feb 28 10:33 trustdb.gpg No pubring.gpg and secring.gpg there. # python >>> import gnupg >>> gpg = gnupg.GPG(gnupghome='/root/importgnupg2.1') >>> gpg.list_keys() [] >>> gpg.gpgbinary 'gpg1' When using gpg.import_keys() to import the keys, it works, as that creates pubring.gpg and secring.gpg. Another possibility is to use # gpg1 --homedir /root/importgnupg1.4/ --import key.gpg root@master:~# ls -l importgnupg1.4/ -rw------- 1 root root 1220 Feb 28 10:37 pubring.gpg -rw------- 1 root root 0 Feb 28 10:37 pubring.gpg~ -rw------- 1 root root 2598 Feb 28 10:37 secring.gpg -rw------- 1 root root 1200 Feb 28 10:37 trustdb.gpg So yes a workaround exists: you can export GnuPGv2 keys and import them with GnuPGv1. Bug still: the keys produced by the GnuPG version installed with UCS are not supported by the python-gnupg installed with UCS.
(In reply to Daniel Tröder from comment #0) > Keys imported on the command line cannot be used with python-gnupg. python-gnupg is an interface to GPG1 - NOT GnuPG2 (at least with the version as shipped within Debian-Stretch). Yes, that looks like an internal detail, nobody wants to know, but we have to live with it. PS: I've been through that rabbit hole with repo-ng. GnuPG-2.1 has some radical changes, which makes it incompatible with GPG1. FYI: The note from <https://gnupg.readthedocs.io/en/latest/#deployment-requirements> is useful to know. See "test/ucs-test/tests/09_updater/pool.sh" for some workarounds to get GnuPG-2.1 working in non-interactive environments. This is what "python-gnupg" tries to archive by directly interfacing with the CLI tool! Also consider switching to "python-gpg" as "python-gnupg" handles several things wrong (according to my security contact at Debian). python-gpgme: Just a Python wrapper at the low-level C API - not recommended python-gpg: Pythonic High-Level API using the C API python-gnupg: Pythonic wrapper for the CLI tools Read <https://wiki.python.org/moin/GnuPrivacyGuard> and <http://files.au.adversary.org/crypto/gpgme-python-howto.html#Difference-between-the-Python-bindings-and-other-GnuPG-Python-packages> (In reply to Daniel Tröder from comment #2) > # gpg --homedir /root/importgnupg2.1/ --import key.gpg > # ls -l /root/importgnupg2.1/ > drwx------ 2 root root 4096 Feb 28 10:33 private-keys-v1.d ... > No pubring.gpg and secring.gpg there. Yes, GnuPG-2 implements a new layout using one private key per file in a the sub-directory 'private-keys-v1.d/', which GPG1 does not understand. > So yes a workaround exists: you can export GnuPGv2 keys and import them with > GnuPGv1. > Bug still: the keys produced by the GnuPG version installed with UCS are not > supported by the python-gnupg installed with UCS. Debatable, but yes: mid- to long-term a working "python-gnupg" would be nice. PS: python-gnupg was only moved to maintained as part of Bug #46291.
(In reply to Philipp Hahn from comment #3) > Also consider switching to "python-gpg" as "python-gnupg" handles several > things wrong (according to my security contact at Debian). Yes - I read that, but the python-gnupg documentation says: ------------------------------- There is at least one fork of this project, which was apparently created because an earlier version of this software used the subprocess module with shell=True, making it vulnerable to shell injection. This is no longer the case. ------------------------------- It seems to have been fixed in version 0.3.7. https://wiki.python.org/moin/GnuPrivacyGuard seems believe that too. > python-gpgme: Just a Python wrapper at the low-level C API - not recommended This one doesn't have a homepage or documentation, so IMHO it shouldn't be used. > python-gpg: Pythonic High-Level API using the C API I read https://wiki.python.org/moin/GnuPrivacyGuard and it's a little bit ambiguous to me if they recommend to use python-gpg (only from distro!) or rather python-gnupg. IMHO we should investigate in this direction (maybe ask on a mailinglist?), the next time we have to use PGP in a project. I have removed the school customer flag and lowered the severity, because the customer can easily use the workaround (gpg1 --import ...) and in this case it's a one time setup issue.
(In reply to Daniel Tröder from comment #4) > > python-gpgme: Just a Python wrapper at the low-level C API - not recommended > > This one doesn't have a homepage or documentation, ... FYI: Initially "PyME" was a self-contained project started by a 3rd party, but then got included into GPGME itself. This is just a small Python-wrapper over the C API and using it is more like C-programming than Python-programming. As it is now included upstream in GPGME, it's easier to keep it in sync with the C library as it gets build from the same source. If you prefer Python, use "python-gpg" which is the high-level API.
This issue has been filed against UCS 4.3. UCS 4.3 is out of maintenance and many UCS components have changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen it and update the UCS version. In this case please provide detailed information on how this issue is affecting you.