EasyGnuPG

[Dashamir Hoxha]

Ok, criticism is always good, although I know from my experience that 90%
of it is wrong.

There is plenty of documentation about gpg out there, both old and new one.
Maybe I am not smart enough, but believe me that I have spent a huge time
with gpg documentation, many years ago and recently, but I still feel lost
at it. For example I have seen some tutorials which explain some best
practices about how to move the private key offline. I believe that it is
time to write some scripts to automate these best practices, instead of
writing more tutorials about them.

There is no pupose in using a different homedir, except for being prudent
not to mess with the existing keyring that people may already have. If you
want, you can modify the config of egpg to use the default homedir, but you
should not do it unless you are confident with using egpg.

The expiry of one month is good for beginners, who may play around and
don't really know what they are doing. If they loose the passphrase, or
just forget at all about gpg after playing with it for some time, this is
not going to have long lasting consequencies. Those who still remember the
passphrase can always extend the expiration at any time, and make it as
long as they wish.

For simplicity, egpg tries to make sure that there is always only one valid
private key at any time.

And yes, there are still some bugs and things to be improved, it is not
perfect yet.

If you don't like this approach and think that you can do something better,
this is fine, just give it a try, I have nothing against it. If you think
that gpg is great and it needs no improvements, this is still fine.

Peace,
Dashamir

On Mon, Mar 21, 2016 at 6:38 PM, Peter Lebbing <peter at digitalbrains.com>
wrote:

> 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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160321/5a7f1c66/attachment.html>