EasyGnuPG

[Peter Lebbing]

On 21/03/16 16:49, Dashamir Hoxha wrote:
> Yes, but the overall number of commands and options supported
> is 10 times smaller than those of gpg2. Tutorials about egpg are also
> much shorter.

These things can simply be solved through new documentation rather than a new
interface. The man page is typical reference style: all commands and options in
a list format. It's not tutorial style, omitting all but common options and
presenting the material in a tutorial form.

> And the default values of the options are more suitable
> for a beginner (at least in my opinion).

I had a quick look through the source.

The only thing I see in that category, IMHO, is automatically naming output
filenames. The rest is debatable whether it should be the default, or it could
easily go into gpg.conf.

My impression is that it's superfluous. Automatically naming an output file
would be some nice icing on the cake; the rest can go. If GnuPG had an option -A
(--auto-name) I would definitely use it:

$ gpg2 -Ar de500b3e -e file.txt

is nicer than:

$ gpg2 -o file.txt.gpg -r de500b3e -e file.txt

My main objection to your solution: it increases incompatibility with other
people. Your filenames end in .sealed and .signature where everybody else uses
.asc (since you use ASCII armour) or .gpg (for binary files). You use a separate
homedir, meaning for instance getting GnuPG plugins for e-mail programs to work
require configuration work on the part of the user. The same for SSH
authentication, where it may work automatically for a distribution-managed
configuration. When somebody wishes to do something more than your wrappers
handle, they need to take care of insuring they still work with the same
homedir. I don't see the purpose of changing the homedir.

You override defaults for key generation, and do so badly, I'm sorry. 4k RSA
keys can be debated; I think they're overkill and are even unbalanced. But a
primary key that signs, *encrypts* and certifies? An expiry of *one month*?? I'd
pick the defaults, and would consider not setting an expiry, though I might also
pick a long expiry to reduce the number of trash keys on the keyservers.

Why do you make the passphrase end up in a process list through this construction:

> "echo -e \"$PASSPHRASE\n$COMMANDS\" | gpg --batch --passphrase-fd=0 [...]

While you should probably generate keys on a single user system, this still is
unnecessarily revealing... anybody typing "ps a" at the correct time (a long
time, it's key generation) will see the passphrase. GnuPG has an excellent
passphrase interface: the pinentry.

Why do you override the private key selection by always picking the first usable
private key explicitly? This seems to me to be a worse default than the default
algorithm, and it's not even possible to override it.

Many of your commands rely on the user interface of GnuPG not changing, for example:

> $(echo "addkey|4|4096|1m|addkey|6|4096|1m|save" | tr '|' "\n")

Are you aware that this can change any time the developers feel like it? It is
meant for human consumption.

That's my first impression.

> To switch from using egpg to using gpg2 you just need to change GNUPGHOME
> from '~/.gnupg' to '~/.egpg/.gnupg'.

Well... the distribution scripts that launch X may not look there, for instance.
There may be more cases where programs will not notice an environment variable
set in .profile. You probably should not change the homedir at all... what is
the purpose?

> I guess these two are suggestions for EasyGpg2016.

I think they are meant as alternatives to your project.

Cheers,

Peter.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>