openSUSE has issued an advisory on February 7:
The issue is fixed upstream in 0.4.4.
Mageia 6 is also affected.
Fixed upstream in 0.4.4
Pushed 0.4.4 to cauldron and mga6 core/updates_testing.
Updated python-gnupg packages fix security vulnerability:
When symmetric encryption is used, data can be injected through the passphrase
property of the gnupg.GPG.encrypt() and gnupg.GPG.decrypt() methods. The
supplied passphrase is not validated for newlines, and the library passes
--passphrase-fd=0 to the gpg executable, which expects the passphrase on the
first line of stdin, and the ciphertext to be decrypted or plaintext to be
encrypted on subsequent lines. By supplying a passphrase containing a newline
an attacker can control/modify the ciphertext/plaintext being
Updated packages in core/updates_testing:
Fixed upstream in 0.4.4 =>
MGA6-32 MATE on IBM Thinkpad R50e
No installation issues
# urpmq --whatrequires python3-gnupg
So I installed mageiasync and pointed it to my Downloads folder which has never been used for mageiasync or gpg before.
$ strace -o pyth3gpg.txt mageiasync
Signature file /home/tester6/Downloads/Mageia-7-beta2-Live-Xfce-i586/Mageia-7-beta2-Live-Xfce-i586.iso.md5.gpg not found
And in the trace there is no ref to gnupg (of course???)
The download completed successfully.
So that leaves me with a clean install.
Re comment #3:
Yes the gpg signature files are not provided any more but the tools are configured to search for them by the look of it. Using --whatrequires-recursive turns up isodumper as well and that loads libgpg-error.so.0. As you found, python3-gnupg will not be called into play if the signature file is not found.
So you should allot the 32-bit OK on the basis of your clean install.