9:46 a.m.
Hi,
I sorry to tell you, that gpg-agents are inflating on numbers in Fedora
systems:
As far as I understand ssh-agents, you start ONE for each user, but
here, one for each repo is opened by PackageKit:
(today)
root 2530 0.0 0.0 151908 892 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/32/metadata/updates-modular-32-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 2637 0.0 0.0 151908 896 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/32/metadata/rpmfusion-free-32-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 2653 0.0 0.0 151908 796 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/32/metadata/rpmfusion-nonfree-32-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 2668 0.0 0.0 151908 816 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/32/metadata/updates-32-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 2693 0.0 0.0 151908 860 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/32/metadata/fedora-32-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 2710 0.0 0.0 151908 708 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/33/metadata/updates-modular-33-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 2723 0.0 0.0 151908 896 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/33/metadata/updates-33-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3393 0.0 0.0 151908 892 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/fedora-modular-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3404 0.0 0.0 151908 712 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/rpmfusion-free-updates-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3417 0.0 0.0 151908 800 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/updates-modular-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3438 0.0 0.0 151908 812 ? Ss 14:32 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/rpmfusion-free-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3451 0.0 0.0 151908 808 ? Ss 14:33 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/rpmfusion-nonfree-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3464 0.0 0.0 151908 936 ? Ss 14:33 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/updates-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3474 0.0 0.0 151908 948 ? Ss 14:33 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/rpmfusion-nonfree-updates-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3492 0.0 0.0 151908 768 ? Ss 14:33 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/teamviewer-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3512 0.0 0.0 151908 884 ? Ss 14:33 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/fedora-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
root 3526 0.0 0.0 151908 888 ? Ss 14:33 0:00
gpg-agent --homedir
/var/cache/PackageKit/31/metadata/fedora-cisco-openh264-31-x86_64.tmp/gpgdir
--use-standard-socket --daemon
it would be more effective, if you give any programm who needs it, the
password directly, instead of having useless processes laying around ;)
https://bugzilla.redhat.com/show_bug.cgi?id=1895012
it's not even doing this for every system, as my private pc does not
have those (upgraded by dnf, and yes, it's installed), but others do
(upgraded by packagekit).
Systemd opens gpg-agents even for mailserver daemons, which do not need
nor know how to use them.
https://bugzilla.redhat.com/show_bug.cgi?id=1877308
No idea what caused this invasion lately, but bugreports about it, get
ignored.
Could someone please take a look and fix it, if it's bug.
best regards,
Marius Schwarz
6:52 p.m.
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.
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.
7:55 p.m.
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
9:07 p.m.
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.
5:23 a.m.
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
6:34 a.m.
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.
8:19 a.m.
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 Ragusa mail at robertoragusa.it
4:08 p.m.
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.
6:56 a.m.
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
10:20 a.m.
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 Ragusa mail at robertoragusa.it
3:51 p.m.
Hello Roberto,
----- Original Message -----
From: "Roberto Ragusa" <mail(a)robertoragusa.it>
To: devel(a)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 Ragusa mail at robertoragusa.it
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)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
1223
days inactive
1244
days old
10 comments
6 participants
participants (6)
-
Jiri Kucera -
Kevin Kofler -
Marius Schwarz -
Oron Peled -
Roberto Ragusa -
Sam Varshavchik