Re: gpg-agents all over the place
Hello Roberto, - Original Message - > From: "Roberto Ragusa" > To: devel@lists.fedoraproject.org > Sent: Thursday, December 24, 2020 5:20:38 PM > Subject: Re: gpg-agents all over the place > > On 12/23/20 1:56 PM, Oron Peled wrote: > > > More problematic, but possible. > > > > The key is using "--pinentry-mode=loopback" (I don't have my scripts in > > front of me for further details) > There are simple use cases that are very problematic. > Consider this: > > [me@localhost tmp]$ date >date.txt > [me@localhost tmp]$ gpg --pinentry-mode=loopback -c date.txt ### this asks > for a passphrase > [me@localhost tmp]$ ls -l > total 8 > -rw-rw-r-- 1 me me 32 Dec 24 16:59 date.txt > -rw-rw-r-- 1 me me 110 Dec 24 17:00 date.txt.gpg > [me@localhost tmp]$ rm date.txt > [me@localhost tmp]$ gpg --pinentry-mode=loopback date.txt.gpg ### this does > not ask! > gpg: WARNING: no command supplied. Trying to guess what you mean ... > gpg: AES encrypted data > gpg: encrypted with 1 passphrase > [me@localhost tmp]$ ls -l > total 8 > -rw-rw-r-- 1 me me 32 Dec 24 17:00 date.txt > -rw-rw-r-- 1 me me 110 Dec 24 17:00 date.txt.gpg > > that would be a very simple tutorial about symmetric encryption and it is > absolutely surprising, since decryption happens without any need to supply > the passphrase. > Because an agent was forked and it remembers the symmetric > passphrase I've used! Crazy. > > So let's see if we can use --batch: using it on encryption conflicts with > pineentry, > using it on decryption doesn't disable the gpg-agent usage. > > We should try to avoid the agent, let's see in the man page: > --use-agent > --no-use-agent >This is dummy option. gpg always requires the agent. > Wow, the option you want, but with a dummy implementation. > > There is a --no-autostart, let's try it: more wasted time. > > The use case I care about is for a script that reads some data > from an encrypted file, asking me the passphrase when necessary. > Something like: > > token="$(gpg1 --output - secrets.gpg | grep ^token= | cut -d= -f2)" > # use $token > > The passphrase should not be hardcoded in the script or remembered by > a magic gpg-agent forked behind my back. > > My only solution has been: >dnf install gnupg1 did you try `--no-symkey-cache` option? It disables password caching during the session: # date > date.txt # gpg --pinentry-mode=loopback --no-symkey-cache -c date.txt gpg: directory '/root/.gnupg' created gpg: keybox '/root/.gnupg/pubring.kbx' created # gpg --pinentry-mode=loopback --no-symkey-cache date.txt.gpg gpg: WARNING: no command supplied. Trying to guess what you mean ... gpg: AES.CFB encrypted data gpg: encrypted with 1 passphrase gpg: decryption failed: Bad session key # gpg --pinentry-mode=loopback --no-symkey-cache date.txt.gpg gpg: WARNING: no command supplied. Trying to guess what you mean ... gpg: AES.CFB encrypted data gpg: encrypted with 1 passphrase gpg: decryption failed: Bad session key # gpg --pinentry-mode=loopback --no-symkey-cache date.txt.gpg gpg: WARNING: no command supplied. Trying to guess what you mean ... gpg: AES.CFB encrypted data gpg: encrypted with 1 passphrase File 'date.txt' exists. Overwrite? (y/N) N Enter new filename: date2.txt # diff date.txt date2.txt # rpm -q gnupg2 gnupg2-2.2.23-1.fc33.x86_64 Regards Jiri > > Regards. > > -- > Roberto Ragusamail at robertoragusa.it > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gpg-agents all over the place
On 12/23/20 1:56 PM, Oron Peled wrote: More problematic, but possible. The key is using "--pinentry-mode=loopback" (I don't have my scripts in front of me for further details) There are simple use cases that are very problematic. Consider this: [me@localhost tmp]$ date >date.txt [me@localhost tmp]$ gpg --pinentry-mode=loopback -c date.txt ### this asks for a passphrase [me@localhost tmp]$ ls -l total 8 -rw-rw-r-- 1 me me 32 Dec 24 16:59 date.txt -rw-rw-r-- 1 me me 110 Dec 24 17:00 date.txt.gpg [me@localhost tmp]$ rm date.txt [me@localhost tmp]$ gpg --pinentry-mode=loopback date.txt.gpg ### this does not ask! gpg: WARNING: no command supplied. Trying to guess what you mean ... gpg: AES encrypted data gpg: encrypted with 1 passphrase [me@localhost tmp]$ ls -l total 8 -rw-rw-r-- 1 me me 32 Dec 24 17:00 date.txt -rw-rw-r-- 1 me me 110 Dec 24 17:00 date.txt.gpg that would be a very simple tutorial about symmetric encryption and it is absolutely surprising, since decryption happens without any need to supply the passphrase. Because an agent was forked and it remembers the symmetric passphrase I've used! Crazy. So let's see if we can use --batch: using it on encryption conflicts with pineentry, using it on decryption doesn't disable the gpg-agent usage. We should try to avoid the agent, let's see in the man page: --use-agent --no-use-agent This is dummy option. gpg always requires the agent. Wow, the option you want, but with a dummy implementation. There is a --no-autostart, let's try it: more wasted time. The use case I care about is for a script that reads some data from an encrypted file, asking me the passphrase when necessary. Something like: token="$(gpg1 --output - secrets.gpg | grep ^token= | cut -d= -f2)" # use $token The passphrase should not be hardcoded in the script or remembered by a magic gpg-agent forked behind my back. My only solution has been: dnf install gnupg1 Regards. -- Roberto Ragusamail at robertoragusa.it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gpg-agents all over the place
On Thursday, 17 December 2020 00:08:48 IST Sam Varshavchik wrote: > Roberto Ragusa writes: > > > On 12/16/20 2:55 AM, Kevin Kofler via devel wrote: > > > >> Believe it or not, GNU/Linux is no longer a text-only operating system, nor > >> are window managers just a container for terminal emulators. :-) > > > > But that is different than saying the GNU/Linux has become a no-text > > operating system.Version 2 of gpg is impossible to use in scripts. More problematic, but possible. The key is using "--pinentry-mode=loopback" (I don't have my scripts in front of me for further details) > Oh, look, someone else is using scripted build tools that use gpg. Nice to > meet you. I actually use them in build scripts that sign repositories, (in Debian, but don't tell anyone ;-)) -- Oron Peled Voice: +972-4-8228492 Ignore Your Rights And They'll Go Away ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gpg-agents all over the place
Roberto Ragusa writes: On 12/16/20 2:55 AM, Kevin Kofler via devel wrote: Believe it or not, GNU/Linux is no longer a text-only operating system, nor are window managers just a container for terminal emulators. :-) But that is different than saying the GNU/Linux has become a no-text operating system.Version 2 of gpg is impossible to use in scripts. Oh, look, someone else is using scripted build tools that use gpg. Nice to meet you. pgp3f2OhEUyKU.pgp Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gpg-agents all over the place
On 12/16/20 2:55 AM, Kevin Kofler via devel wrote: Believe it or not, GNU/Linux is no longer a text-only operating system, nor are window managers just a container for terminal emulators. :-) But that is different than saying the GNU/Linux has become a no-text operating system.Version 2 of gpg is impossible to use in scripts. -- Roberto Ragusamail at robertoragusa.it ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gpg-agents all over the place
Kevin Kofler via devel writes: Sam Varshavchik wrote: > But, for some reason that I do not understand, the existing terminal > interface always gets broken. Well, how prompts in terminal emulator sessions in the GUI should work is a design decision. Some people (like you, apparently) expect them to behave the terminal way (so the isatty check is the right one for them), whereas others expect them to behave the GUI way (so the code checks whether a GUI agent is running, and only falls back to a TTY prompt if there is none in scope – not sure whether GPG gets this right, but most agent interfaces are implemented like that). If, and if, it actually behaved this way, and actually worked as advertised, I would not object to entering my password into a popup dialog. But it never worked this way. Perhaps because the terminal session is an ssh session from another host. Now, you aren't going to start an agent on the host I'm ssh-ing from (and who's to say that the origin host even has an X session, it does in my case but that's not guaranteed either), even with X forwarding. X forwarding can't do that. And starting an agent on the headless server I've ssh-ed into is not going to accomplish anything. And just to make sure that things haven't changed since the last time I wrestled with this: they haven't. I moved gpg-agent.conf out of the way, made sure that no stray gpg-agent processes are anyway. End result: mrsam@jack ~]$ gpg --sign z [one minute delay] gpg: signing failed: Timeout gpg: signing failed: Timeout Found a gpg-agent process running at this point. What it was doing, for a minute or so, who knows. Maybe it's trying to pop up a dialog on the headless server I've ssh-ed into, instead of actually looking at DISPLAY that tunnels X over the ssh connection. Even if I unset DISPLAY before running "gpg --sign z", it still hangs for about a minute, before deciding that whatever it's doing doesn't work and then runs pinentry-curses to prompt for the password. It does so rather rudely, taking over the entire terminal, but at least it gets restored afterwards. I haven't looked at the code, so I have no idea if it's technically impossible, for some reason, to simply check DISPLAY, and if unset fallback to pinentry-curses immediately, instead of standing around and looking at each other. That's the very first though that occured to me, when this whole thing broke: should just do that. But, anyway, before all this jazz with gpg-agent things just …worked. I ran gpg, it prompted for the password, I typed it in, and it was a done deal. Sadly for things to remain simple and work by default is out of fashion now. It's quite acceptable now for things suddenly break one fine day, until I waste away the whole day plumbing the depth of Google to find out I have to drop an explicit pinentry-program /usr/bin/pinentry-curses into ~/.gnupg/gpg-agent.conf in order for thing to continue limping along, as they did before. pgpvSj5Rfmhq2.pgp Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gpg-agents all over the place
Sam Varshavchik wrote: > But, for some reason that I do not understand, the existing terminal > interface always gets broken. Well, how prompts in terminal emulator sessions in the GUI should work is a design decision. Some people (like you, apparently) expect them to behave the terminal way (so the isatty check is the right one for them), whereas others expect them to behave the GUI way (so the code checks whether a GUI agent is running, and only falls back to a TTY prompt if there is none in scope – not sure whether GPG gets this right, but most agent interfaces are implemented like that). Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gpg-agents all over the place
Kevin Kofler via devel writes:
Sam Varshavchik wrote:
> I miss the days when gpg needed a passphrase it simply prompted a message
> on standard output, turned off tty echo, and just read the password that I
> typed in.
>
> But that was too simple, primitive, and bulletproof. I guess that things
> can't be as simple any more, and the forward march of progress is
> unstoppable.
That approach simply does not work for GUI applications.
Sure. But it seems that more often that not making things work for GUI
applications must mean that plain text interface ends up being broken.
if (isatty(2))
{
/* Existing code, that prompts for a password or reads it from stdin */
}
else
{
/* The GUI equivalent */
}
Now, your terminal interface continues to work as before, and you can
provide a GUI interface too.
But, for some reason that I do not understand, the existing terminal
interface always gets broken.
pgpZndKZe7ZHK.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gpg-agents all over the place
Sam Varshavchik wrote: > I miss the days when gpg needed a passphrase it simply prompted a message > on standard output, turned off tty echo, and just read the password that I > typed in. > > But that was too simple, primitive, and bulletproof. I guess that things > can't be as simple any more, and the forward march of progress is > unstoppable. That approach simply does not work for GUI applications. Believe it or not, GNU/Linux is no longer a text-only operating system, nor are window managers just a container for terminal emulators. :-) Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: gpg-agents all over the place
Marius Schwarz writes: Hi, I sorry to tell you, that gpg-agents are inflating on numbers in Fedora systems: I miss the days when gpg needed a passphrase it simply prompted a message on standard output, turned off tty echo, and just read the password that I typed in. But that was too simple, primitive, and bulletproof. I guess that things can't be as simple any more, and the forward march of progress is unstoppable. The most simple interface I could get working these days is the curses pinentry. And that was no easy task to set up. I had to do some serious googling around, and sifting through the manual pages, to come up with the right set of spells and magic woids and phrases (I'm channeling Bugs Bunny) to make it happen. it would be more effective, if you give any programm who needs it, the password directly, instead of having useless processes laying around ;) Nah. That's too simple of a solution. https://bugzilla.redhat.com/show_bug.cgi?id=1895012 Any changes will likely need to originate upstream; I'll be surprised if there'll be any Fedora-originated development on this topic. Systemd opens gpg-agents even for mailserver daemons, which do not need nor know how to use them. Oh, sure. I had a nagging feeling something was missing, here. systemd, that's it. No idea what caused this invasion lately, but bugreports about it, get ignored. The drive to fix this needs to come upstream. But nobody pays attention any more to the simpletons like us, who like to work in a terminal or, heavens forbid, an ssh connection. Or (and I know how this can be shocking to hear) run build scripts. Everyone expects to have pretty windows, menu, dialogs, and animated gophers to join them on their quest to use gpg. Hence, the agent. Could someone please take a look and fix it, if it's bug. I would be very happy if someday I can simply run gpg(2) and have it simply prompt me for my password, by default, without me having to fiddle anything, not gpg-agent.conf, not anything else. Alas, I've resigned to those simpler days being just a fond memory. pgpendVy3XHgz.pgp Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
