Dashamir Hoxha dashohoxha at gmail.com
Tue Mar 22 20:53:59 CET 2016

On Tue, Mar 22, 2016 at 10:54 AM, Paolo Bolzoni <
paolo.bolzoni.brown at gmail.com> wrote:

> I totally agree, Dashamir I really think you should focus on what you
> think is hard in gnupg? And why?
> Are you sure a new program (and not a simple patch) is the best answer?
> At the moment you are showing us strange defaults, an implementation
> that can break at any time, and I am not really sure how much it is
> easier anyway.

The implementation will not break, as long as it is based on the latest
stable release.
When the next stable release of gpg is out, the implementation will be
adjusted to match it.

> For example, I find strange and needlessy difficult that the keys have
> a duration and not an expiration date. So when one wants the key to
> last until the end of the year or to his birthday one has to make a
> date difference manually.

You are right, I find it strange and counterintuitive too. I can try to fix
it on egpg.

Regarding your main question above (I have also answered it previously), I
think that `gpg` (the command) is monolithic, bloated with functionality
and options, the docs are like a maze and not clearly structured, the
number of commands and options is huge, there is no clear distinction
between the commands and the options, the supported use cases are not so
clear (it actually tries to support everything), the default values are not
well-thought, the terminology is confusing and counter-intuitive, etc.
Do you think these can be fixed with simple patches?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20160322/6ac05a58/attachment.html>

More information about the Gnupg-users mailing list