Steps to reproduce: 1. Setup binpkg signing as described on the wiki 2. emerge some random package 3. emerge tries to unlock the key, when the prompt for the password appears: cancel, CTRL+C, type the password wrong three times, or have pinentry unavailable (due to e.g. being in an ssh session that tries to use graphical pinentry while X/wayland forwarding is not available) 4. Example result: Would you like to merge these packages? [Yes/No] y >>> Unlocking GPG... gpg: WARNING: unsafe permissions on homedir '/etc/portage/gnupg' gpg: signing failed: No pinentry gpg: signing failed: No pinentry !!! GPG unlock failed 5. Running emerge again will now fail because /dev/null is a plain text file: andrew-gentoo-pc ~ # emerge -1 -j1 oneDPL Failed to validate a sane '/dev'. '/dev/null' is not a device file. andrew-gentoo-pc ~ # ls -l /dev/null -rw-r--r-- 1 root root 0 Aug 22 09:37 /dev/null 6. Many other things that rely on /dev/null stop working. To fix /dev/null again, either reboot or run 'mknod -m 0666 /dev/null c 1 3' Possibly the problem originates somewhere outside of portage (some python package, or maybe gnupg/pinentry itself?)
Actually, it looks like the problem is that /dev/null is removed not overwritten. Using zsh shell completion somehow triggers it to be recreated as regular file. andrew-gentoo-laptop ~ # ls /dev/null ls: cannot access '/dev/null': No such file or directory andrew-gentoo-laptop ~ # emerge -1 oneDPL Failed to validate a sane '/dev'. '/dev/null' does not exist. andrew-gentoo-laptop ~ # ls /dev/null ls: cannot access '/dev/null': No such file or directory andrew-gentoo-laptop ~ # ls -l /dev/null ls: cannot access '/dev/null': No such file or directory andrew-gentoo-laptop ~ # ls -l /dev/n (tried to do the shell completion here) (eval):6: no such file or directory: /dev/null andrew-gentoo-laptop ~ # ls -l /dev/null -rw-r--r-- 1 root root 0 Aug 22 10:01 /dev/null andrew-gentoo-laptop ~ # ls -l /dev/null -rw-r--r-- 1 root root 0 Aug 22 10:01 /dev/null
The root of the problem is on line 38 of lib/portage/gpg.py: "--output /dev/null /dev/null", Replacing /dev/null with /tmp/null fixes the problem (as in /dev/null is no longer removed). After successfully unlocking the key /tmp/null is populated with: -----BEGIN PGP MESSAGE----- ... -----END PGP MESSAGE----- On failure /tmp/null is removed (by gpg?)! And this is what causes my problem.
What version of app-crypt/gnupg? I think it would be helpful if we try to reproduce the issue outside of Portage.
(In reply to Mike Gilbert from comment #3) > What version of app-crypt/gnupg? 2.4.3 > I think it would be helpful if we try to reproduce the issue outside of > Portage. I'll give this a shot. But it might also be that gnupg actually intentionally removes this file after a failed unlock.
Created attachment 868499 [details] strace log I can reproduce the issue with app-crypt/gnupg-2.2.41 using the following command: > gpg --sign --armor --output /dev/null /dev/null I then enter an empty string for my password in pinentry. On line 534 of the strace output, you can see an unlink("/dev/null"). The issue does not occur with app-crypt/gnupg-2.4.3.
(In reply to Andrew Ammerlaan from comment #4) Hmm, I wasn't able to reproduce it with 2.4.3. Let me try again.
Ok, I can reproduce it with gnupg-2.4.3 as well. I suppose portage should use a temporary file for output instead of /dev/null.
According to GnuPG upstream, this behaviour is intentional: > That is intentional. If we are able to remove a file we do it. > Solution for you is easy: gpg .... -o - </dev/null >/dev/null I'm not sure whether we want to do it like this, or simply use some different temporary file. WDYT?
(In reply to Andrew Ammerlaan from comment #8) > According to GnuPG upstream, this behaviour is intentional: > > > That is intentional. If we are able to remove a file we do it. > > Solution for you is easy: gpg .... -o - </dev/null >/dev/null > > I'm not sure whether we want to do it like this, or simply use some > different temporary file. WDYT? I think I prefer the idea of a temporary file, but I don't feel strongly about it either.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=9d278330839049a818ba9f1e3985c7e502c63451 commit 9d278330839049a818ba9f1e3985c7e502c63451 Author: Andrew Ammerlaan <andrewammerlaan@gentoo.org> AuthorDate: 2023-08-23 11:47:32 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2023-08-24 18:23:41 +0000 lib/portage/gpg.py: send gpg output to stdout, then send stdout to /dev/null GnuPG removes the --output file on failure. Removing /dev/null breaks all kinds of things. Instead of telling GnuPG to output to /dev/null we output to stdout and then send the stdout to /dev/null, this avoids the problem where /dev/null is removed when the key fails to unlock. Bug: https://bugs.gentoo.org/912808 Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org> Signed-off-by: Mike Gilbert <floppym@gentoo.org> lib/portage/gpg.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
Andrew, would you mind following up on the upstream comment at https://dev.gnupg.org/T6556#174635?
(In reply to Sam James from comment #11) > Andrew, would you mind following up on the upstream comment at > https://dev.gnupg.org/T6556#174635? As in open a new issue? To be honest, I don't see the point since upstream made it clear that this is the intended behaviour.
sorry, what I meant is the part about -help because I'm curious as to if they have a better way to "unlock the key". Our method seems really brittle and I've hit so many issues with it where it just suddenly becomes locked again, or it doesn't unlock in the first plsace.
(In reply to Sam James from comment #13) > sorry, what I meant is the part about -help because I'm curious as to if > they have a better way to "unlock the key". Our method seems really brittle > and I've hit so many issues with it where it just suddenly becomes locked > again, or it doesn't unlock in the first plsace. Thanks! https://lists.gnupg.org/pipermail/gnupg-users/2023-August/066692.html
Sorry I am traveling. Is this new behavior in GNUPG? I clearly remember that I have terminated many times in this password interface, and I have never encountered this problem.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9f9211a35abef13079f93a96f57f3a96083c69a7 commit 9f9211a35abef13079f93a96f57f3a96083c69a7 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-10-03 15:38:28 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-10-03 15:38:41 +0000 sys-apps/portage: add 3.0.52 Closes: https://bugs.gentoo.org/704866 Closes: https://bugs.gentoo.org/877793 Closes: https://bugs.gentoo.org/889300 Closes: https://bugs.gentoo.org/900224 Closes: https://bugs.gentoo.org/912676 Closes: https://bugs.gentoo.org/912808 Closes: https://bugs.gentoo.org/913070 Closes: https://bugs.gentoo.org/913103 Closes: https://bugs.gentoo.org/914159 Closes: https://bugs.gentoo.org/915054 Closes: https://bugs.gentoo.org/915119 Signed-off-by: Sam James <sam@gentoo.org> sys-apps/portage/Manifest | 1 + sys-apps/portage/portage-3.0.52.ebuild | 235 +++++++++++++++++++++++++++++++++ 2 files changed, 236 insertions(+)
