> Von: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] Im Auftrag von
> Am Donnerstag 17 Mai 2018 10:45:18 schrieb Fiedler Roman:
> > As gnupg starts getting more and more problematic regarding some
> functions
> > (see the discussions on command line/unattended use)
> Can you give me pointers here.
> Even unattented use needs proper care of passphrases
> (best is to leave them out) and status codes (which a command line cannot
> usually handle well, thus gpgme for more complicated cases).

There were quite many messages, that caused alarm bells ringing for me. Hard to 
dig them out all now. But maybe I am just over-sensitive to words between the 
lines or wrong in some other ways. Here are some examples:

Pinentry: I for myself struggled with it also for a day, but also many other 
users have problems. Realizing, that gpg aims might be going into a different 
direction may motivate you to leave now before having to struggle again and 
maybe more at the next OS update, when you need to apply more workarounds.

https://lists.gnupg.org/pipermail/gnupg-users/2018-March/060097.html (initramfs 
https://lists.gnupg.org/pipermail/gnupg-users/2015-March/053175.html (systemd 
"So it feels quite strange that i need to do all this juggling to get it 

Other examples:
https://lists.gnupg.org/pipermail/gnupg-users/2016-February/055294.html (do not 
use gpg for encryption with different policies)
(gpg-agent idle timeout workarounds)
http://seclists.org/oss-sec/2017/q4/373 (a former gpg developer is explaining 
decisions, why he is implementing a new variant and his arguments (short lived 
processes) make completely sense for those usecases I envision, compare to the 
previous mail thread).

> In my experience command line and unattended use is fully supported
> and extended in GnuPG. It is just the rare unix system or very small system
> space that may get more problematic because of different support libraries
> and
> system calls. GnuPG cannot implement all functionality it needs by itself
> and thus we inherit some size and platform restrictions.

That is understandable. But I cannot see the concept already, how this bloating 
can be avoided in future. And in the end gpg has to come up with some concept, 
e.g. regarding support of older mail message decryption modes plus all the 
libraries required to do that. Hence my critical remarks.
> I wonder about pubkey management though. There is a faster pubkey store,
> there are ways to automatically assign fetch pubkeys with basic trust (WKD)
> and options to give a pubkey for just this encryption operation, those all
> sound like improvements in the server use cases to me.

Yes, but all those features do not apply to apt-key or are of little relevance. 
Hence gpg seems to have been included just for minimal use (just 
adding/removing keys, everything is trusted as performed by root user anyway). 
I do not know the reasons behind them dropping gpg, but I guess the just needed 
a failesafe, minimalistic tool for that purpose and now they dropped gpg and 
run only with gpgv to my knowledge.

LG Roman
Gnupg-users mailing list

Reply via email to