Date: Tue, 19 Dec 2017 00:14:21 +0000 From: halfdog <me@...fdog.net> To: oss-security@...ts.openwall.com Subject: Re: Recommendations GnuPG-2 replacement Leonid Isaev writes: > On Mon, Dec 18, 2017 at 08:21:56PM +0000, halfdog wrote: >> The point in starting this thread was, that GnuPG does NOT >> conveniently cover usecases for headless or scripting operation. >> Thus it seems that the time has come to look for replacement, >> as GnuPG is moving more in the "desktop" direction, as also >> your comments indicate. > > You are talking about policies here, not technical issues. > Gnupg is perfectly scriptable, see pacman-key(1) tool in Arch > Linux. Moreover, gpg-agent is easily usable on a headless machine. > At least, I mostly use it this way when checking email... So maybe SSH cares for you to have sane pty with all the features needed to make gnupg run smoothly? Perhaps you may want to respond, that it is not gnupg at fault, if e.g. an embedded boot image does not use openvt and /dev/tty[1-6] during early boot in correct ways, thus causing problems. But the way gnupg reacts in that situation (not working and not giving meaningful error messages either) does not really help the user and gave me the impression, that those usecases are out of scope - and hence also of scope for testing. You may want to read  to see how another user on "gnupg-users" describes in more detail the "user experience" when trying to get TTYs, pinentry, gpg-agent ... up and running. The post quite reflects also my user experience, the difference is just that he writes lengthy mails to get things running, I write them to see if there are alternatives. > You will lose nothing if you just pkill(1) gpg-agent though. So > I don't understand why you claim that gpg is moving towards > desktop. Well, on a server running multiple concurring tasks, I feel somehow uncomfortable killing a process just by UID and process name. How to make sure, that not a parallel task is still using the agent? Signals are just fine for control: when a parent knows exactly its children and signals them. For processes starting automagically I just do not want to care about how their daemonizing works and if there might be races during that procedure, how to craft pkill regex to reduce the risk of killing the wrong agent under some circumstances, ... >> That's really a strange argument. You fear PTRACING for key >> extraction of a short-lived, per-key instance of gpg1 process >> and solve that by putting all the key material into a single >> long-lived gpg-agent process, not even providing convenient >> commands to flush the keys from there? > > pkill -hup gpg-agent. Please read the manpages. Please give realistic answers. And if you try, you may notice, that things are not just as simple as "send a signal to any process with a given name". Your backup system vendor and your colleagues will love you, when killing the sign/encryption process that way, yielding spurious errors from time to time. Could be quite some beer to spend when they completed their root cause analysis. Maybe your pkill would not cause those side effects, but I just do not want to care about them. I am quite sure, that they are ignorable on desktop environments or for e-mail reading, in a production environment they might just be a risk and an annoyance. Hence my argument about desktop and server. hd  https://lists.gnupg.org/pipermail/gnupg-users/2017-December/059600.html
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ