Description of problem: Starting with the Fedora 39 container image, invoking gpg in a Containerfile RUN step will leave a lock file behind that prevents future RUN steps from invoking gpg. This appears to be because either or both of gpg-agent and keyboxd are left running when the build step invoking gpg finishes, and they (seems like keyboxd specifically) own the lock file. The existence (and contents?) of the lock file seem to be responsible for the failure to acquire the necessary lock in subsequent build steps. Version-Release number of selected component (if applicable): N/A for base? gnupg2 2.4.3-3? How reproducible: 100% Steps to Reproduce: 1. Create a Containerfile with the following contents: FROM fedora:39 RUN curl -fSLO https://www.mediawiki.org/keys/keys.txt && gpg --import keys.txt RUN curl -fSLO https://releases.wikimedia.org/mediawiki/1.41/mediawiki-core-1.41.1.tar.gz && \ curl -fSLO https://releases.wikimedia.org/mediawiki/1.41/mediawiki-core-1.41.1.tar.gz.sig && \ gpg --verify mediawiki-core-1.41.1.tar.gz.sig mediawiki-core-1.41.1.tar.gz 2. Run podman build . Actual results: ... gpg: Signature made Thu Mar 28 22:16:05 2024 UTC gpg: using DSA key 1D98867E82982C8FE0ABC25F9B69B3109D3BB7B0 gpg: Note: database_open 134217901 waiting for lock (held by 5) ... gpg: Note: database_open 134217901 waiting for lock (held by 5) ... gpg: Note: database_open 134217901 waiting for lock (held by 5) ... gpg: Note: database_open 134217901 waiting for lock (held by 5) ... gpg: Note: database_open 134217901 waiting for lock (held by 5) ... gpg: keydb_search failed: Connection timed out gpg: Note: database_open 134217901 waiting for lock (held by 5) ... gpg: Note: database_open 134217901 waiting for lock (held by 5) ... gpg: Note: database_open 134217901 waiting for lock (held by 5) ... gpg: Note: database_open 134217901 waiting for lock (held by 5) ... gpg: Note: database_open 134217901 waiting for lock (held by 5) ... gpg: keydb_search failed: Connection timed out gpg: Can't check signature: No public key Error: building at STEP "RUN curl -fSLO https://releases.wikimedia.org/mediawiki/1.41/mediawiki-core-1.41.1.tar.gz && curl -fSLO https://releases.wikimedia.org/mediawiki/1.41/mediawiki-core-1.41.1.tar.gz.sig && gpg --verify mediawiki-core-1.41.1.tar.gz.sig mediawiki-core-1.41.1.tar.gz": while running runtime: exit status 2 Expected results: ... gpg: Signature made Thu Mar 28 22:16:05 2024 UTC gpg: using DSA key 1D98867E82982C8FE0ABC25F9B69B3109D3BB7B0 gpg: Good signature from "Sam Reed <reedy>" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 1D98 867E 8298 2C8F E0AB C25F 9B69 B310 9D3B B7B0 COMMIT ... Additional info: I believe this issue was introduced with gnupg2 2.4.3-3, but I cannot confirm as every version I've tried to install from koji after 2.4.0-3 hangs. Per the release notes[0] on the introduction of keyboxd as the default, Adding a ~/.gnupg directory before the very first invocation of gpg solves the problem. [0]: https://github.com/gpg/gnupg/blob/gnupg-2.4.3/README#L119-L145
Upon further consideration, I now believe that this has nothing to do with the systemd unit files and probably was caused purely by the upstream change in default behavior introduced in 2.4.1.
This message is a reminder that Fedora Linux 39 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '39'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 39 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Issue still exists in Fedora 40 (and Fedora 41). Fedora 41 needs the following Containerfile as gnupg2 is no longer installed by default in the base container image: FROM fedora:41 RUN dnf install -y gnupg2 RUN curl -fSLO https://www.mediawiki.org/keys/keys.txt && gpg --import keys.txt RUN curl -fSLO https://releases.wikimedia.org/mediawiki/1.41/mediawiki-core-1.41.1.tar.gz && \ curl -fSLO https://releases.wikimedia.org/mediawiki/1.41/mediawiki-core-1.41.1.tar.gz.sig && \ gpg --verify mediawiki-core-1.41.1.tar.gz.sig mediawiki-core-1.41.1.tar.gz
This message is a reminder that Fedora Linux 40 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 40 on 2025-05-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '40'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 40 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
I have tested this against the Fedora 42 Container Image and the problem still exists.