Mailing List Archive

Improving the command line UI of gpg
Hello GnuPG developers,

I would like to discuss a subject that has been really bothering me and
I hope I'm not the only one.

I've been using `gpg` for a while. Honestly, I must say it's
command-line user interface is super uncomfortable. Let me explain:

The problem resides in the fact that it accepts only `options` (starting
with `--` or `-`. Shell completion engines are better built for commands
that accept both options and commands. This makes it easier for the user
(getting help either from the shell tab completion engine or the
program's manual) to distinguish between commands and the optional
flags.

Inspired by the (super comfortable IMO) command line user interface of
`git`, I've had a vision for a new set of `gpg` subcommands and the
corresponding arguments and options I think naming them so would be
comfortable enough. I've attached a text file with the subcommands and
the arguments and options they should accept. I hope it's format is
clear.

I would really like to improve the usability of `gpg` and I think this
is a crucial step towards making it more user friendly. From reading the
source code, I've noticed GnuPG implements it's own command line
arguments parsing. Maybe it'll be better to use a standard library like
`argp.h`?

This obviously mean that it would make the next version of `gpg`
incompatible with the older versions but I really think it's worth the
effort.

I'd love to hear your opinions.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Improving the command line UI of gpg [ In reply to ]
Hello GnuPG developers,

I would like to discuss a subject that has been really bothering me and
I hope I'm not the only one.

I've been using `gpg` for a while. Honestly, I must say it's
command-line user interface is super uncomfortable. Let me explain:

The problem resides in the fact that it accepts only `options` (starting
with `--` or `-`. Shell completion engines are better built for commands
that accept both options and commands. This makes it easier for the user
(getting help either from the shell tab completion engine or the
program's manual) to distinguish between commands and the optional
flags.

Inspired by the (super comfortable IMO) command line user interface of
`git`, I've had a vision for a new set of `gpg` subcommands and the
corresponding arguments and options I think naming them so would be
comfortable enough. I've attached a text file with the subcommands and
the arguments and options they should accept. I hope it's format is
clear.

I would really like to improve the usability of `gpg` and I think this
is a crucial step towards making it more user friendly. From reading the
source code, I've noticed GnuPG implements it's own command line
arguments parsing. Maybe it'll be better to use a standard library like
`argp.h`?

This obviously mean that it would make the next version of `gpg`
incompatible with the older versions but I really think it's worth the
effort.

I'd love to hear your opinions.
Improving the command line UI of gpg [ In reply to ]
Hello GnuPG developers,

I would like to discuss a subject that has been really bothering me and
I hope I'm not the only one.

I've been using `gpg` for a while. Honestly, I must say it's
command-line user interface is super uncomfortable. Let me explain:

The problem resides in the fact that it accepts only `options` (starting
with `--` or `-`. Shell completion engines are better built for commands
that accept both options and commands. This makes it easier for the user
(getting help either from the shell tab completion engine or the
program's manual) to distinguish between commands and the optional
flags.

Inspired by the (super comfortable IMO) command line user interface of
`git`, I've had a vision for a new set of `gpg` subcommands and the
corresponding arguments and options I think naming them so would be
comfortable enough.
I've attached a text file with the subcommands and the arguments and
options each one should accept. I hope the format is clear, it is still
a raw draft, I don't understand yet some of the options described in the
documentation.

I would really like to improve the usability of `gpg` and I think this
is a crucial step towards making it more user friendly. From reading the
source code, I've noticed GnuPG implements it's own command line
arguments parsing. Maybe it'll be better to use a standard library like
`argp.h`?

This obviously mean that it would make the next version of `gpg`
incompatible with the older versions but I really think it's worth the
effort.

I'd love to hear your opinions.
Re: Improving the command line UI of gpg [ In reply to ]
On Mon, Jul 23, 2018 at 9:34 PM Doron Behar <doron.behar@gmail.com> wrote:

> Hello GnuPG developers,
>
> I would like to discuss a subject that has been really bothering me and
> I hope I'm not the only one.
>

I am not a genuine GnuPG developer, I am rather a user.
I have noticed it as well that the commands and sub-commands of `gpg`
are not clearly distinguishable from their options, and this makes it
difficult
to use (or to understand a command in a script). So I think that your
proposal
is a good idea.

I also have noticed that `gpg` does more things that it needs to do. For
example,
why should it do compression, when there are lots of tools out there for
doing
compression? But maybe I am missing something, since I am not an expert
on cryptographic things.


>
> I've been using `gpg` for a while. Honestly, I must say it's
> command-line user interface is super uncomfortable. Let me explain:
>
> The problem resides in the fact that it accepts only `options` (starting
> with `--` or `-`. Shell completion engines are better built for commands
> that accept both options and commands. This makes it easier for the user
> (getting help either from the shell tab completion engine or the
> program's manual) to distinguish between commands and the optional
> flags.
>
> Inspired by the (super comfortable IMO) command line user interface of
> `git`, I've had a vision for a new set of `gpg` subcommands and the
> corresponding arguments and options I think naming them so would be
> comfortable enough. I've attached a text file with the subcommands and
> the arguments and options they should accept. I hope it's format is
> clear.
>
> I would really like to improve the usability of `gpg` and I think this
> is a crucial step towards making it more user friendly. From reading the
> source code, I've noticed GnuPG implements it's own command line
> arguments parsing. Maybe it'll be better to use a standard library like
> `argp.h`?
>
> This obviously mean that it would make the next version of `gpg`
> incompatible with the older versions but I really think it's worth the
> effort.
>

Maybe it can preserve the backwards compatibility, but the code will have
to be a little bit more complex.


>
> I'd love to hear your opinions.
>

By the way, can you have a look at this: https://github.com/EasyGnuPG/egpg
It is an attempt to make GnuPG easier for beginners, and it uses the model
of sub-commands that you describe.

Regards,
Dashamir
Re: Improving the command line UI of gpg [ In reply to ]
On Mon, 23 Jul 2018 20:22, doron.behar@gmail.com said:

> The problem resides in the fact that it accepts only `options` (starting
> with `--` or `-`. Shell completion engines are better built for commands

Right. That is how Unix programs work. Granted some tools have a
driver program which call different binaries depending on a keyword
(command) however they are rare and that is not how gpg works. For
example to have something like

gpg -v sign --detached FILE

the common thing would be for gpg to exec this

gpg-sign -v --detached FILE

That would require a lot of extra binaries for no good reason. It is
also not clear what should count as a global option (-v in the above
example) or as a command specific option (e.g. --detached). The matrix
would be quiet complicated so that in the end both would not be
distinguished.

There is only one fact which distinguishes options from commands: Only
one command is possible and gpg will complain about. However, it will
also warn about certain option combinations.

> that accept both options and commands. This makes it easier for the user
> (getting help either from the shell tab completion engine or the
> program's manual) to distinguish between commands and the optional

Why?

> Inspired by the (super comfortable IMO) command line user interface of
> `git`, I've had a vision for a new set of `gpg` subcommands and the
> corresponding arguments and options I think naming them so would be

We won't change the command line API of gpg it is a stable API for 20
years and you simply can't change that. Considere what would happend if
you chnage the API of tar.

> source code, I've noticed GnuPG implements it's own command line
> arguments parsing. Maybe it'll be better to use a standard library like
> `argp.h`?

Nope. argparse is much more flexible and includes a well designed help
interface as well as other goodies. Actually it would even be possibe
to add some kind of configuration to allow optional specification of
commands without the option prefix (--) to mimic the behaviour of, say,
git.

> This obviously mean that it would make the next version of `gpg`
> incompatible with the older versions but I really think it's worth the

No way.


Salam-Shalom,

Werner

--
# Please read: Daniel Ellsberg - The Doomsday Machine #
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
Re: Improving the command line UI of gpg [ In reply to ]
On Tue, Jul 24, 2018 at 12:22 AM Dashamir Hoxha <dashohoxha@gmail.com>
wrote:

> On Mon, Jul 23, 2018 at 9:34 PM Doron Behar <doron.behar@gmail.com> wrote:
>
>>
>> This obviously mean that it would make the next version of `gpg`
>> incompatible with the older versions but I really think it's worth the
>> effort.
>>
>
> Maybe it can preserve the backwards compatibility, but the code will have
> to be a little bit more complex.
>

I have another vision. It should be possible to create a wrapper program,
which accepts the commands and options in the format that is easy for the
users
(in this case Doron), and internally it just calls `gpg` with the commands
and
arguments in the current format. This would be fully backwards compatible
and at the same time offering users a novel usage that is supposed to be
easier
(with command-line completion etc.)

Actually this is such an easy task that even a good student can do it
(assuming
that he knows very well all the commands and options of `gpg`, their
meaning,
when they are used, etc.). It can even be a Bash script. For example one can
start from a copy of EasyGnuPG (mentioned below) and customize it for this
purpose.

>

> By the way, can you have a look at this: https://github.com/EasyGnuPG/egpg
> It is an attempt to make GnuPG easier for beginners, and it uses the model
> of sub-commands that you describe.
>

Dashamir
Re: Improving the command line UI of gpg [ In reply to ]
Hello

My opinion regarding this request: I completely follow Werner. Don't
extend the core GnuPG tool by adding a second user interface into the
core without urgent need, risiking unnecessary compatibility issues
and even unnecessary security vulnerabilities. If you want another
interface, feel free to write a wrapper, based either on the existing
command line interface or on GPGME.

Kind regards
--
Rainer Perske
System operations dept. and director of the certification authority (WWUCA)
Center for Information Processing (university computer center)

Westf?lische Wilhelms-Universit?t
Zentrum f?r Informationsverarbeitung
Rainer Perske
R?ntgenstra?e 7-13
48149 M?nster
Germany

phone: +49 251 83-31582
fax: +49 251 83-31555
e-mail: rainer.perske@uni-muenster.de
WWW: https://www.uni-muenster.de/ZIV/Mitarbeiter/RainerPerske.shtml
office: room 006, R?ntgenstra?e 11
site map: http://wwwuv2.uni-muenster.de/uniplan/?action=spot&gebnr=7474

Certification Authority of the University of M?nster (WWUCA):
phone: +49 251 83-31590
fax: +49 251 83-31555
e-mail: ca@uni-muenster.de
WWW: https://www.uni-muenster.de/WWUCA/

Center for Information Processing:
phone: +49 251 83-31600 (Mon-Fri 7:30-17:30)
fax: +49 251 83-31555
e-mail: ziv@uni-muenster.de
WWW: https://www.uni-muenster.de/ZIV/
Re: Improving the command line UI of gpg [ In reply to ]
On Tue, Jul 24, 2018 at 12:34 PM Rainer Perske <
rainer.perske@uni-muenster.de> wrote:

> Hello
>
> My opinion regarding this request: I completely follow Werner. Don't
> extend the core GnuPG tool by adding a second user interface into the
> core without urgent need, risiking unnecessary compatibility issues
> and even unnecessary security vulnerabilities. If you want another
> interface, feel free to write a wrapper, based either on the existing
> command line interface or on GPGME.
>

As far as I know, GPGME is not an option for this task, because it does not
cover all the functionality of `gpg`. Even if it did, you have to implement
your own logic with GPGME, which is a burden and also risky.
So, the only option is to use the `gpg` command itself.

Dashamir
Re: Improving the command line UI of gpg [ In reply to ]
On Tue, Jul 24, 2018 at 6:10 PM Holger Smolinski via [gnupg-devel] <
gpg-devel@nopicturesplease.de> wrote:

> [ . . . ]
> If you require a better usable CLI, feel free to create your personal
> wrapper script to implement one. It may turn out to be superior to the
> current one and people will start using it instead of the old one.
>

Thanks for the encouragement, but creating my "personal" wrapper script
does not seem like a compelling or a good idea to me. It can be successful
only if it has the support of the core developers and it is distributed
with the
official release.

Dashamir
Re: Improving the command line UI of gpg [ In reply to ]
Hello.

Am Mittwoch, den 25.07.2018, 03:04 +0200 schrieb Dashamir Hoxha:
> On Tue, Jul 24, 2018 at 6:10 PM Holger Smolinski via [gnupg-devel] <
> gpg-devel@nopicturesplease.de> wrote:
>
> > [ . . . ]
> > If you require a better usable CLI, feel free to create your
> > personal
> > wrapper script to implement one. It may turn out to be superior to
> > the
> > current one and people will start using it instead of the old one.
> >

> Thanks for the encouragement, but creating my "personal" wrapper
> script
> does not seem like a compelling or a good idea to me. It can be
> successful
> only if it has the support of the core developers and it is
> distributed
> with the
> official release.

I see no reason for a wrapper in the GnuPG release. That's something
what's up to the users usecase for gpg. most commands on the CLI which
are used on a regular basis are as easy to use as possible, I think.

Gpg is used in so many ways by it's users, I wouldn't wonder if even
Werner didn't think about some of them, before he heard of them.

Distributing wrapper scripts with gnupg is not a goof idea, they would
have to be provided for any platform. That means as shell scipts for
Linux/Unix, as batch file for windows and so an. Python would not be an
option because it would generate a dependency on python, what, for
example, means an additional installation for python on windows.

For long command line commands I created aliases, where this is enough,
or I wrote my own scripts, where it is neccessary.

There are even many GUI-Frontends for gpg out there, seahorse and GPA
for example, and much more.

Blowing up GnuPG itself, or the installation routine to install more
dependencies, is nut a good idea, in my opinion.

Regards,
Dirk


--
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen
Tel.: +49 1573 1152350
Re: Improving the command line UI of gpg [ In reply to ]
On Wed, Jul 25, 2018 at 2:03 PM Dirk Gottschalk via Gnupg-devel <
gnupg-devel@gnupg.org> wrote:

>
> I see no reason for a wrapper in the GnuPG release. That's something
> what's up to the users usecase for gpg. most commands on the CLI which
> are used on a regular basis are as easy to use as possible, I think.
>

I agree.


>
> Gpg is used in so many ways by it's users, I wouldn't wonder if even
> Werner didn't think about some of them, before he heard of them.
>
> Distributing wrapper scripts with gnupg is not a goof idea, they would
> have to be provided for any platform. That means as shell scipts for
> Linux/Unix, as batch file for windows and so an. Python would not be an
> option because it would generate a dependency on python, what, for
> example, means an additional installation for python on windows.
>

I don't agree that bash scripts for Linux should be converted to batch
files for windows. There are ways though to run bash scripts on windows.

For long command line commands I created aliases, where this is enough,
> or I wrote my own scripts, where it is neccessary.
>

In my opinion this confirms the need for making the CLI of GnuPG a bit
more user-friendly (or more comfortable, as some people say), so that
people don't have to write their own scripts all the time.

There are even many GUI-Frontends for gpg out there, seahorse and GPA
> for example, and much more.
>
> Blowing up GnuPG itself, or the installation routine to install more
> dependencies, is nut a good idea, in my opinion.
>

My idea was not to blow up GnuPG (or its installation), but to have
more support about this project (or mini-project, or feature, whatever it
is).
If there is no general consensus that implementing this wrapper would
be a good thing, and it can potentially make things a bit easier for the
users,
and if there is no support from the core developers (at least moral
support),
there is no point in spending time to implement it.

I have been foolish enough in the past to spend time implementing
ideas that seemed good and useful to me, and the result has been
that nobody has supported them, nobody has helped to implement them,
instead people have called them "single-man projects", so not worth
of being taken seriously or being trusted. I don't want it to happen again.
I don't even see any need for implementing a "personal" wrapper script,
if I have to be its only user. It can only be useful if it is meant to be
used
by lots of users.

Regards,
Dashamir
Re: Improving the command line UI of gpg [ In reply to ]
Hi.

Am Mittwoch, den 25.07.2018, 21:19 +0200 schrieb Dashamir Hoxha:
> On Wed, Jul 25, 2018 at 2:03 PM Dirk Gottschalk via Gnupg-devel <
> gnupg-devel@gnupg.org> wrote:
>
> >
> > I see no reason for a wrapper in the GnuPG release. That's
> > something
> > what's up to the users usecase for gpg. most commands on the CLI
> > which
> > are used on a regular basis are as easy to use as possible, I
> > think.
> >
>
> I agree.
>
>
> >
> > Gpg is used in so many ways by it's users, I wouldn't wonder if
> > even
> > Werner didn't think about some of them, before he heard of them.
> >
> > Distributing wrapper scripts with gnupg is not a goof idea, they
> > would
> > have to be provided for any platform. That means as shell scipts
> > for
> > Linux/Unix, as batch file for windows and so an. Python would not
> > be an
> > option because it would generate a dependency on python, what, for
> > example, means an additional installation for python on windows.
> >
>
> I don't agree that bash scripts for Linux should be converted to
> batch
> files for windows. There are ways though to run bash scripts on
> windows.

Yes, with additional software, that's what i talked about.


> > For long command line commands I created aliases, where this is
> > enough,
> > or I wrote my own scripts, where it is neccessary.
> >
>
> In my opinion this confirms the need for making the CLI of GnuPG a
> bit
> more user-friendly (or more comfortable, as some people say), so that
> people don't have to write their own scripts all the time.

That's the point. Every user has different claims about the work with
gpg. You can't write wrappers for all of them.

Sure, the moist used tasks could be wrapped in scripts, that's not a
bad idea, but i would offer them as optional add-on.
For this you could start a project on GitHub or something like that and
propagate it on this list. I think the GnuPG team would even add it to
the list of related software on the website, where the GUIs and MTAs
are listed, which support gpg.

>
> There are even many GUI-Frontends for gpg out there, seahorse and GPA
> > for example, and much more.
> >
> > Blowing up GnuPG itself, or the installation routine to install
> > more
> > dependencies, is nut a good idea, in my opinion.
> >
>
> My idea was not to blow up GnuPG (or its installation), but to have
> more support about this project (or mini-project, or feature,
> whatever it
> is).
> If there is no general consensus that implementing this wrapper would
> be a good thing, and it can potentially make things a bit easier for
> the
> users,
> and if there is no support from the core developers (at least moral
> support),
> there is no point in spending time to implement it.

Support should be not a problem. Here you get as much support as
possible. The development team is still there to help and open for
anything. At least on this list, or the users list, help is there as
much as possible. That is what I found out in the month I am now
following this list.

> I have been foolish enough in the past to spend time implementing
> ideas that seemed good and useful to me, and the result has been
> that nobody has supported them, nobody has helped to implement them,
> instead people have called them "single-man projects", so not worth
> of being taken seriously or being trusted. I don't want it to happen
> again.

As far as I know, a long time ago, even GnuPG was a one man show.
Yes, many people think this way, I know exactly what you mean, but not
all.

> I don't even see any need for implementing a "personal" wrapper
> script, if I have to be its only user. It can only be useful if it is
> meant to be used by lots of users.

Just a second. It ain't over, 'till the fat lady sings.
Have you any ideas what could or should be implemented in those
wrappers? Any suggestions? I think we should at least discuss those
things. IMHO this list is the right place for this discussions,
especially about things that are not good solved in GnuPG, ot what
could be improved with wrappers.

Regards,
Dirk



--
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen
Tel.: +49 1573 1152350
Re: Improving the command line UI of gpg [ In reply to ]
Hello Dashamir,

Am Mittwoch, den 25.07.2018, 23:01 +0200 schrieb Dashamir Hoxha:
> On Wed, Jul 25, 2018 at 9:53 PM Dirk Gottschalk <
> dirk.gottschalk1980@googlemail.com> wrote:
>
> >
> > Have you any ideas what could or should be implemented in those
> > wrappers? Any suggestions?
> >
>
> It is the idea proposed on the message that started this thread.
> Namely, trying to make GnuPG CLI as comfortable as `git` (or similar
> to it).
> This involves:
> - Commands that do not look like options.

This is a goot point and could be done with scripts, at least for the
long command lines.

> - Command line completion of commands and options.

I use ZSH with Antigen and various plug-ins and auto-completion with
<TAB> works well with gpg. But I didn't use bash for a long time so I
don't know if itz works there, too.

> - Separate man page for each command.

This could be part of the wrapper scripts package and would be good as
explaination for new users.

> - Contextual help and instructions that give the right directions
> when you don't know what you are doing.

This would also be good because the documentation of GnuPG itself is,
let's say, far away from complete and is hard to understand for new
users. May the main developers excuse me, but that's no secret. ;-)

> - As much automated tests as possible (with sharness).

What kind of tests do you mean?


> - etc.
>
> I think everyone has used `git`, so there is no need to go to much
> details.

Yes, as a developer I am a regular user og git. I know what are talking
of. The git-... commands. To be honest, I don't use them myself, I use
the "long" commands.

Regards,
Dirk

PS: I forgot the list in my last Mail. I forwardet this to the list and
added it right here again in the CC field.

--
Dirk Gottschalk
Paulusstrasse 6-8
52064 Aachen
Tel.: +49 1573 1152350
Re: Improving the command line UI of gpg [ In reply to ]
Hello,

> I have been foolish enough in the past to spend time implementing
> ideas that seemed good and useful to me, and the result has been
> that nobody has supported them, nobody has helped to implement them,
> instead people have called them "single-man projects", so not worth
> of being taken seriously or being trusted. I don't want it to happen again.

@Dashamir: I do understand your frustration; I have made similar
experiences earlier. Perhaps I may give you a piece of advice? :-)

> [...] It can only be useful if it is meant to be used by lots of users.

Exactly!

Improving usability is always a good idea, you are very welcome if you
want to contribute. But your current idea is thought far too short:
Only IT experts still use the command line, and experts have no problem
with the current interface, so they do not need the improvement you are
thinking of. Hence you are getting the negative reactions you are
experiencing now; you simply have no chance to address lots of users
by enhancing the command line interface.

So, if you want to improve usability for non-experts, it would be
wasting time to enhance the command line interface. Better invest your
time in one of the interfaces used by non-expert users: Apps for
smartphone and tablet users, graphical interfaces for desktop and
laptop users, perhaps better integration into e-mail software etc.

In this wide field you can certainly find a project that brings you
much more fun.

(The "wrapper" I wrote in the last decade is the complete integration
of OpenPGP and S/MIME into the webmailer of the university where I am
working, not a simple shell script. That webmailer is used by thousands
of people daily.)

Best wishes
--
Rainer Perske
System operations dept. and director of the certification authority (WWUCA)
Center for Information Processing (university computer center)

Westf?lische Wilhelms-Universit?t
Zentrum f?r Informationsverarbeitung
Rainer Perske
R?ntgenstra?e 7-13
48149 M?nster
Germany

phone: +49 251 83-31582
fax: +49 251 83-31555
e-mail: rainer.perske@uni-muenster.de
WWW: https://www.uni-muenster.de/ZIV/Mitarbeiter/RainerPerske.shtml
office: room 006, R?ntgenstra?e 11
site map: http://wwwuv2.uni-muenster.de/uniplan/?action=spot&gebnr=7474

Certification Authority of the University of M?nster (WWUCA):
phone: +49 251 83-31590
fax: +49 251 83-31555
e-mail: ca@uni-muenster.de
WWW: https://www.uni-muenster.de/WWUCA/

Center for Information Processing:
phone: +49 251 83-31600 (Mon-Fri 7:30-17:30)
fax: +49 251 83-31555
e-mail: ziv@uni-muenster.de
WWW: https://www.uni-muenster.de/ZIV/
Re: Improving the command line UI of gpg [ In reply to ]
On Tue, Jul 24, 2018 at 10:29:09AM +0200, Rainer Perske wrote:
> Hello
>
> My opinion regarding this request: I completely follow Werner. Don't
> extend the core GnuPG tool by adding a second user interface into
> the core without urgent need, risiking unnecessary compatibility
> issues and even unnecessary security vulnerabilities. If you want
> another interface, feel free to write a wrapper, based either on the
> existing command line interface or on GPGME.

Right ... except not via yet another wrapper to the existing command
line binaries. Use GPGME instead.


Regards,
Ben
Re: Improving the command line UI of gpg [ In reply to ]
On Wed, Jul 25, 2018 at 12:43:56PM +0200, Dirk Gottschalk via Gnupg-devel wrote:
>
> Distributing wrapper scripts with gnupg is not a goof idea, they would
> have to be provided for any platform.

Right.

> That means as shell scipts for Linux/Unix, as batch file for windows
> and so an. Python would not be an option because it would generate a
> dependency on python, what, for example, means an additional
> installation for python on windows.

Actually this doesn't necessarily rule out Python in the long run, it
would just take a bit more effort on the part of the developer,
depending on whether you wanted an embedded Python that was shippeed
with the wrapper interface or whether you used a compiler type module
to generate platform specific binaries from your wrappers, as is often
done with PyInstaller and similar things.

Caveats: There are currently other runtime issues with the Python
bindings on Windows which are still under investigation; and the
bindings did not play nicely with PyInstaller at all the last time I
checked, mainly because PyInstaller can only really handle pure
Python, ctypes and (maybe) cffi. I haven't checked all the
alternatives to PyInstaller either and generally an installation of
CPython is preferable anyway.

As for "problems" stemming from introducing Windows dependencies in
the form of installing Python. I'd say there's a fair argument that
anyone seeking an alternative command line interface for GPG on
Windows probably wouldn't bat an eyelid at installing Python, would
probably already have GPGShell, Kleopatra and GPA installed and be
somewhat further ahead of relying merely on a collection of .bat
files.

Python as a dependency isn't actually the problem for Windows users,
the real issue for them is whether GPGME and GPG were compiled with
the same runtime as the version of Python they installed. As for what
happens when those runtimes do match ... is pending confirmation.


Regards,
Ben
Re: Improving the command line UI of gpg [ In reply to ]
On 27/07/18 00:22, Ben McGinnes wrote:
> On Tue, Jul 24, 2018 at 10:29:09AM +0200, Rainer Perske wrote:
>> Hello
>>
>> My opinion regarding this request: I completely follow Werner. Don't
>> extend the core GnuPG tool by adding a second user interface into
>> the core without urgent need, risiking unnecessary compatibility
>> issues and even unnecessary security vulnerabilities. If you want
>> another interface, feel free to write a wrapper, based either on the
>> existing command line interface or on GPGME.
>
> Right ... except not via yet another wrapper to the existing command
> line binaries. Use GPGME instead.

If we're going to extol GPGME as the one stop shop for all wrappers,
then we had better make sure it's feature-complete - which it currently
is not. I speak as someone who wrote his own wrapper and found that
invoking the binaries by hand was the only solution... :-(

--
Andrew Gallagher
Re: Improving the command line UI of gpg [ In reply to ]
On 31/07/18 15:17, Andrew Gallagher wrote:
> If we're going to extol GPGME as the one stop shop for all wrappers,
> then we had better make sure it's feature-complete - which it currently
> is not.

In this specific context, though, the discussion is about a command-line
wrapper that simplifies the command line usage for certain tasks. If
something cannot be done through GPGME, you could wonder whether it
would be something that needs to be functionality of this "simpler"
command-line wrapper at all, or people should just use the gpg command line.

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>
Re: Improving the command line UI of gpg [ In reply to ]
2018-07-31 15:17 GMT+02:00 Andrew Gallagher <andrewg@andrewg.com>:

> On 27/07/18 00:22, Ben McGinnes wrote:
> > On Tue, Jul 24, 2018 at 10:29:09AM +0200, Rainer Perske wrote:
> >> Hello
> >>
> >> My opinion regarding this request: I completely follow Werner. Don't
> >> extend the core GnuPG tool by adding a second user interface into
> >> the core without urgent need, risiking unnecessary compatibility
> >> issues and even unnecessary security vulnerabilities. If you want
> >> another interface, feel free to write a wrapper, based either on the
> >> existing command line interface or on GPGME.
> >
> > Right ... except not via yet another wrapper to the existing command
> > line binaries. Use GPGME instead.
>
> If we're going to extol GPGME as the one stop shop for all wrappers,
> then we had better make sure it's feature-complete - which it currently
> is not. I speak as someone who wrote his own wrapper and found that
> invoking the binaries by hand was the only solution... :-(
>
>
Do we have a list of the missing features in gpgme (to fully support at
least gpg)? Looking at the TODO file in git as well as the git site at
dev.gnupg.org, I don't really find much that would indicate what needs to
be covered.
If the gpgme approach is the recommended interface for building wrappers,
then perhaps we should at least look at what is missing to make it usable.

--------------------------------------------------------------------
Best regards / Med vänlig hälsning / Med venlig hilsen /Cordialement

*Andreas Almroth*
Re: Improving the command line UI of gpg [ In reply to ]
On Tue, 2018-07-31 at 17:19 +0200, Andreas Almroth wrote:
> If the gpgme approach is the recommended interface for building
> wrappers, then perhaps we should at least look at what is missing to
> make it usable.
I guess the answer is that you must not do things that gpgme does not
allow you to do. Like generating revocations. Because... someone decided
that this is not a thing that any external program would ever
legitimately do.

Cheers,
Tobi

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Improving the command line UI of gpg [ In reply to ]
On 02/08/18 00:53, Tobias Mueller wrote:
> Because... someone decided that this is not a thing that any external
> program would ever legitimately do.

Or less flippantly, because you can always do the really uncommon things
on the GnuPG command line, supposing that anybody confident enough to
root around where most do not go would also be proficient in using a
command line. I don't see anything wrong with that supposition.

That a user conceivably might ever want to do something doesn't mean the
feature needs to be replicated in a bunch of frontends, at the cost of
development time spent elsewhere.

By the way, I've more than once seen Werner show a way to do something
with the underlying Assuan protocol that isn't directly available
through the API of GPGME, but in that way available to GPGME users anyway.

And sometimes it can be solved through --status-fd and friends.

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>
Re: Improving the command line UI of gpg [ In reply to ]
On Thu, 2 Aug 2018 00:53, muelli@cryptobitch.de said:

> I guess the answer is that you must not do things that gpgme does not
> allow you to do. Like generating revocations. Because... someone decided

Do you have a need for this for a real world project and not just for a
prototype? If that is the case we are fast to add a new interface.

Instead of blowing up the interface for all possible use cases, as we
did for gpg, we want to limit GPGME to be useful for real world use
cases.


Salam-Shalom,

Werner


--
# Please read: Daniel Ellsberg - The Doomsday Machine #
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.