Ben McGinnes ben at adversary.org
Tue Mar 22 15:14:41 CET 2016

On Mon, Mar 21, 2016 at 03:05:05PM +0100, Bernhard Reiter wrote:
> Hi Dashamir,
> On Friday 18 March 2016 at 09:49:16, Dashamir Hoxha wrote:
> > I am writting some shell scripts for making GnuPG more accessible and
> > easier to use:
> >  - https://github.com/dashohoxha/egpg
> I like the goal of making gpg2 more accessible.
> However I am not sure that you are actually reaching the goal
> by using sh wrappers. When looking at the man pages, it seems
> that they are already long with a number of phrases to learn.
> Most of these commands are not much easier than the direct gpg2
> commands they are aiming to replace.

You know what might, though, if someone were to take up the old GPA
project perhaps ... maybe port it to GTK 3 or implement a Qt version.

Or make a free thing that does what that GPGShell GUI thing so many
Windows users seem fond of, but isn't even available under a BSD or
LGPL license, let alone GPL 2 or 3.  I've never used that one, but so
many of the PGPNET subscribers swear by the thing for ease of use as
well as effectiveness.

> Drawbacks I see with your approach:
> * people will have to learn a slightly different set of commands
>   with egpg and gpg2 and sooner or later will use the gpg2 commands
>   and then they will be confused or have extra learning efforts.
> * shell scripts will not work on plattforms without a shell
>   (e.g. Windows)

And those of us used to using shells have probably rolled our own by
this stage.  In my case gpg1 is a shell wrapper for GPG 1.4.x and an
alternate homedir so I really can keep using both keyring formats,
gpg2 is 2.1 with some kind of proper-ish trust model, gpg21 is the
same except it also reloads dirmngr to use tor and gpg runs the 2.1
binary with trust-model always.  Although all mine still use and
accept all the standard flags, they just load slightly different
configurations for the most part.

> * I haven't looked into the .epgp directory, but it may have some configs
>   and then the behaviour of other applications will depend on whoch config
>   they use.

> * BTW: There is a potential name clash with https://wiki.gnupg.org/EasyGpg2016

Also with the old Emacs binding of EasyPG (now under the EPA banner).

> Ideas for improvements:
> * I you must, write wrappers code it in something more plattform indepentent, 
>   e.g. in python3 (using pyme or pygpgme where appropriate)

There's already a port of pyme to Python 3, it's pretty much ready to
go save for some final PEP8 checks which I'm working through the last
of currently (in between the occasional local unrelated catastrophe,
of course).  The 99% ready code is in one of my branches in the gpgme
repo on playfair.

> * Suggest and improve the original gpg2 command line interface, so that
>   usage is easier and the more esotheric options will not be seen or used
>   by default.

Given most of them should be in the gpg.conf file anyway, they
normally only need to be set once.  Sometimes toggled back and forth
(e.g. with --expert), but mostly it's set once and leave it that way
(e.g. enable-large-rsa, enable-dsa2, allow-freeform-uid, etc.).


|   Ben McGinnes  |  Adversarial Press  |  Twitter: benmcginnes     |
| Writer, Publisher, Systems Administrator, Trainer, ICT Consultant |
|   http://www.adversary.org/      http://publishing.adversary.org/ |
| GPGME Python 3 API Dev, GNU Privacy Guard  https://www.gnupg.org/ |
| Encrypted email preferred, OpenPGP/GPG key: 0x321E4E2373590E5D    |
| OpenPGP/GPG key here: http://goo.gl/GVGwT and http://goo.gl/SDs0D |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 630 bytes
Desc: not available
URL: </pipermail/attachments/20160323/b91a3655/attachment.sig>

More information about the Gnupg-users mailing list