AW: Users GnuPG aims for?

[Fiedler Roman]

> Von: Gnupg-users [mailto:gnupg-users-bounces at 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 use)
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 working")

Other examples:
https://lists.gnupg.org/pipermail/gnupg-users/2016-February/055294.html (do not use gpg for encryption with different policies)
https://lists.gnupg.org/pipermail/gnupg-devel/2016-September/031557.html (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