Mailing List Archive

GSoC project idea
Hi,

Last year we discussed a request/proposal for improving the command line UI
of gnupg:
https://lists.gnupg.org/pipermail/gnupg-devel/2018-July/033857.html

We decided that making radical changes to the current UI of gnupg is a huge
task, risky, unfeasible, and in general not worth the trouble.

However I came up with a proposal for writing just a wrapper to the current
gpg command, that organizes the commands and options in a different way,
presumably more easy and intuitive. This wrapper will not affect in no way
the gpg command itself, it will be just like "syntactic sugar", and in the
end it will call the gpg command itself, with the proper arguments and
options.

This wrapper can be written in Bash, Python, Go, etc. It should be very
easy to develop such a wrapper, assuming that we already know all the
details about the commands and options of gnupg, and we have a clear idea
about the new system of commands and options that we want to build. This
new system of commands and options doesn't have to cover 100% of the
functionality of the gpg command; for the few things that may remain
unimplemented the user may use the gpg command directly.

I think this is suitable task for a GSoC project that can be developed in
2-3 months by a good student, with help and guidance from mentors. It can
be submitted to GNU, which acts as an ombrella organization on GSoC for all
the gnu projects:
https://www.gnu.org/software/soc-projects/ideas-2019.html
I think it is worth a try, there is nothing to risk or to loose.

Anybody interested or willing to be a mentor for this project? I might be a
mentor as well, if needed, since I do have some mentoring experience from
the last year GSoC.

Regards,
Dashamir
Re: GSoC project idea [ In reply to ]
Sorry, the proper link to the archived message is this one:
https://lists.gnupg.org/pipermail/gnupg-devel/2018-July/033854.html

On Sun, Mar 17, 2019 at 6:13 PM Dashamir Hoxha <dashohoxha@gmail.com> wrote:

> Hi,
>
> Last year we discussed a request/proposal for improving the command line
> UI of gnupg:
> https://lists.gnupg.org/pipermail/gnupg-devel/2018-July/033857.html
>
> We decided that making radical changes to the current UI of gnupg is a
> huge task, risky, unfeasible, and in general not worth the trouble.
>
> However I came up with a proposal for writing just a wrapper to the
> current gpg command, that organizes the commands and options in a different
> way, presumably more easy and intuitive. This wrapper will not affect in no
> way the gpg command itself, it will be just like "syntactic sugar", and in
> the end it will call the gpg command itself, with the proper arguments and
> options.
>
> This wrapper can be written in Bash, Python, Go, etc. It should be very
> easy to develop such a wrapper, assuming that we already know all the
> details about the commands and options of gnupg, and we have a clear idea
> about the new system of commands and options that we want to build. This
> new system of commands and options doesn't have to cover 100% of the
> functionality of the gpg command; for the few things that may remain
> unimplemented the user may use the gpg command directly.
>
> I think this is suitable task for a GSoC project that can be developed in
> 2-3 months by a good student, with help and guidance from mentors. It can
> be submitted to GNU, which acts as an ombrella organization on GSoC for all
> the gnu projects:
> https://www.gnu.org/software/soc-projects/ideas-2019.html
> I think it is worth a try, there is nothing to risk or to loose.
>
> Anybody interested or willing to be a mentor for this project? I might be
> a mentor as well, if needed, since I do have some mentoring experience from
> the last year GSoC.
>
> Regards,
> Dashamir
>
Re: GSoC project idea [ In reply to ]
Hello Dashamir,

Thanks for showing your interest in this idea. I thought more about it
after I've sent the email to the mailing list and I reached the
conclusion that it might be more efficient to _fork_ the existing
code-base and use the same existing functions and only bind them to a
different executable that will have a different use of argparse.
Actually, I've already created a prototype of this and the missing work
to be done is connecting everything to the already existing functions
available in the code-base.

It is indeed a good project for a student. Only I'm not sure I'll be
able to do it myself, although my motivation is rather high. I'm
preparing myself for the 1st year of Computer Science studies in
university these days so I don't have a lot of spare time.

On Sun, Mar 17, 2019 at 06:13:32PM +0100, Dashamir Hoxha wrote:
> Hi,
>
> Last year we discussed a request/proposal for improving the command line UI
> of gnupg:
> https://lists.gnupg.org/pipermail/gnupg-devel/2018-July/033857.html
>
> We decided that making radical changes to the current UI of gnupg is a huge
> task, risky, unfeasible, and in general not worth the trouble.
>
> However I came up with a proposal for writing just a wrapper to the current
> gpg command, that organizes the commands and options in a different way,
> presumably more easy and intuitive. This wrapper will not affect in no way
> the gpg command itself, it will be just like "syntactic sugar", and in the
> end it will call the gpg command itself, with the proper arguments and
> options.
>
> This wrapper can be written in Bash, Python, Go, etc. It should be very
> easy to develop such a wrapper, assuming that we already know all the
> details about the commands and options of gnupg, and we have a clear idea
> about the new system of commands and options that we want to build. This
> new system of commands and options doesn't have to cover 100% of the
> functionality of the gpg command; for the few things that may remain
> unimplemented the user may use the gpg command directly.
>
> I think this is suitable task for a GSoC project that can be developed in
> 2-3 months by a good student, with help and guidance from mentors. It can
> be submitted to GNU, which acts as an ombrella organization on GSoC for all
> the gnu projects:
> https://www.gnu.org/software/soc-projects/ideas-2019.html
> I think it is worth a try, there is nothing to risk or to loose.
>
> Anybody interested or willing to be a mentor for this project? I might be a
> mentor as well, if needed, since I do have some mentoring experience from
> the last year GSoC.
>
> Regards,
> Dashamir

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: GSoC project idea [ In reply to ]
On Mon, Mar 18, 2019 at 12:21 PM Doron Behar <doron.behar@gmail.com> wrote:

> Hello Dashamir,
>
> Thanks for showing your interest in this idea. I thought more about it
> after I've sent the email to the mailing list and I reached the
> conclusion that it might be more efficient to _fork_ the existing
> code-base and use the same existing functions and only bind them to a
> different executable that will have a different use of argparse.
>

Do you preserve the existing commands and options of `gpg`, for backwards
compatibility? If yes, maybe there is some chance that your changes will be
merged some day to the main project. Otherwise I think that it is going
nowhere. Neither the developers nor the users will accept radical changes
to the CLI of `gpg`. I don't think your aim is to maintain it forever as an
alternative to `gpg` because this is a huge task.


> Actually, I've already created a prototype of this and the missing work
> to be done is connecting everything to the already existing functions
> available in the code-base.
>

It does not seem so easy to me because you may need some feedback from more
experienced people, although you may think that you have organized the
commands and their options properly.


>
> It is indeed a good project for a student. Only I'm not sure I'll be
> able to do it myself, although my motivation is rather high. I'm
> preparing myself for the 1st year of Computer Science studies in
> university these days so I don't have a lot of spare time.
>

You can be one of the mentors, which hopefully should not be very time
consuming.
Re: GSoC project idea [ In reply to ]
On Mon, Mar 18, 2019 at 01:31:23PM +0100, Dashamir Hoxha wrote:
> On Mon, Mar 18, 2019 at 12:21 PM Doron Behar <doron.behar@gmail.com> wrote:
>
> > Hello Dashamir,
> >
> > Thanks for showing your interest in this idea. I thought more about it
> > after I've sent the email to the mailing list and I reached the
> > conclusion that it might be more efficient to _fork_ the existing
> > code-base and use the same existing functions and only bind them to a
> > different executable that will have a different use of argparse.
> >
>
> Do you preserve the existing commands and options of `gpg`, for backwards
> compatibility? If yes, maybe there is some chance that your changes will be
> merged some day to the main project. Otherwise I think that it is going
> nowhere. Neither the developers nor the users will accept radical changes
> to the CLI of `gpg`. I don't think your aim is to maintain it forever as an
> alternative to `gpg` because this is a huge task.

In my fork I didn't modify anything, only added. The idea is to add only
a directory named ipg (Acronym for improved privacy guard) and in it all
the code that will use the functions that already exist in the source
tree; So when a user builds my version from the git source (autoreconf
&& ./configure && make && make install), he will a get another
executable installed called `ipg` that will be equivalent to `gpg` in
it's use but will have a nicer CLI syntax.

Both executables (gpg & ipg) installed by my version will be equally
updated to use the latest version of the C code that implements the
actual encryption and decryption etc.

>
>
> > Actually, I've already created a prototype of this and the missing work
> > to be done is connecting everything to the already existing functions
> > available in the code-base.
> >
>
> It does not seem so easy to me because you may need some feedback from more
> experienced people, although you may think that you have organized the
> commands and their options properly.

I think the only difficult part in this design (and please correct me if
you think I'm wrong) is making sure that when the upstream source is
updated and functions change their names etc., my fork updates the names
of the functions it calls.

Also, according to my design, almost every sub-command and it's optional
flags have their equivalent in the current syntax, strictly according to
the documentation. The only difference is that some sub-commands
naturally don't accept all options that may be accepted (but ignored!)
in the current syntax. Most importantly, this should also prove to be
more comfortable for shell completions to not overwhelm users with
options most of which are irrelevant for the current _action_ they want
to perform.

>
>
> >
> > It is indeed a good project for a student. Only I'm not sure I'll be
> > able to do it myself, although my motivation is rather high. I'm
> > preparing myself for the 1st year of Computer Science studies in
> > university these days so I don't have a lot of spare time.
> >
>
> You can be one of the mentors, which hopefully should not be very time
> consuming.

As a mentor, am I not obliged to be an experienced C programmer? If so,
that could be an excellent idea.

> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: GSoC project idea [ In reply to ]
On Mon, Mar 18, 2019 at 4:07 PM Doron Behar <doron.behar@gmail.com> wrote:

>
> In my fork I didn't modify anything, only added. The idea is to add only
> a directory named ipg (Acronym for improved privacy guard) and in it all
> the code that will use the functions that already exist in the source
> tree; So when a user builds my version from the git source (autoreconf
> && ./configure && make && make install), he will a get another
> executable installed called `ipg` that will be equivalent to `gpg` in
> it's use but will have a nicer CLI syntax.
>
> Both executables (gpg & ipg) installed by my version will be equally
> updated to use the latest version of the C code that implements the
> actual encryption and decryption etc.
>

In my opinion, it might be better if there was a single executable (gpg)
that can accept both sets of CLI commands. If this is possible.

In any case, I think that the aim should be to finally submit a patch to
the mainstream code, and hopefully it gets accepted. Distributing it
separately as an improved version of gpg is not going to work for many
reasons.


>
> > It does not seem so easy to me because you may need some feedback from
> more
> > experienced people, although you may think that you have organized the
> > commands and their options properly.
>
> I think the only difficult part in this design (and please correct me if
> you think I'm wrong) is making sure that when the upstream source is
> updated and functions change their names etc., my fork updates the names
> of the functions it calls.
>
> Also, according to my design, almost every sub-command and it's optional
> flags have their equivalent in the current syntax, strictly according to
> the documentation. The only difference is that some sub-commands
> naturally don't accept all options that may be accepted (but ignored!)
> in the current syntax. Most importantly, this should also prove to be
> more comfortable for shell completions to not overwhelm users with
> options most of which are irrelevant for the current _action_ they want
> to perform.
>

I understand your design and its advantages, but I am not sure wheather you
understand all the details about `gpg` commands and options. Maybe you do,
myself I don't.

> You can be one of the mentors, which hopefully should not be very time
> > consuming.
>
> As a mentor, am I not obliged to be an experienced C programmer? If so,
> that could be an excellent idea.
>

If you are an experienced C programmer that's great. But you don't have to
be. You can also be an experienced `gpg` user. And anyway, the idea of
reorganizing the commands is yours and you know what you are aiming for
better than anyone. So, you can definitely be one of the mentors, if you
have time and if you want to be.

Dashamir
Re: GSoC project idea [ In reply to ]
Hi,

Am Sonntag 17 März 2019 18:13:32 schrieb Dashamir Hoxha:
> However I came up with a proposal for writing just a wrapper to the current
> gpg command, that organizes the commands and options in a different way,
> presumably more easy and intuitive.

to document it, I've just written a reply to one of the threads last year
writing about technical drawbacks and the problems that some perceive with
GSoC.

The main problems I see with the idea:
a) How long and by whom would this wrapper be maintained?
It is hard enough to maintain the current gpg as it is.
If the perspective is only up to three years, then we cannot really
recommand anyone to learn the new interface as it is likely to go away
after that time and the original gpg will stay. It would be just for
experimentation.

b) There are many better ideas how to help end to end encryption with GnuPG
to provide a better user experience. For example implementing automatic
encryption after a WKD request in more email clients. Writing instructions
how to set up simple WKD on the server.

> I think this is suitable task for a GSoC project that can be developed in
> 2-3 months by a good student, with help and guidance from mentors.

If it would be clear what each option would do, the implementation time would
be enough, but the assumptions of the current interactive command line
interface and all its bells and whistles are many and interact in a complex
way, so to me it is doubtful that a student can handle this in 3 months.

Best Regards,
Bernhard

--
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
Re: GSoC project idea [ In reply to ]
On Tue, Mar 19, 2019 at 12:53 PM Bernhard Reiter <bernhard@intevation.de>
wrote:

>
> The main problems I see with the idea:
> a) How long and by whom would this wrapper be maintained?
> It is hard enough to maintain the current gpg as it is.
> If the perspective is only up to three years, then we cannot really
> recommand anyone to learn the new interface as it is likely to go away
> after that time and the original gpg will stay. It would be just for
> experimentation.
>

Is it more acceptable to submit a patch that adds the new functionality,
rather than building a wrapper? Of course you don't have to accept it
unless it is done properly.
I think that experimentation is worthy too. A wrapper might be easier and
more flexible if we want to experiment just to get a better feeling about
the new interface. However Donor has already started working on the C code
and it might be a bit easier to just continue in that direction.


>
> b) There are many better ideas how to help end to end encryption with GnuPG
> to provide a better user experience. For example implementing automatic
> encryption after a WKD request in more email clients. Writing
> instructions
> how to set up simple WKD on the server.
>

I agree but I don't have any idea about how to recruit new developers for
these tasks.
By the way, Google Season of Docs is around the corner:
https://developers.google.com/season-of-docs/
Maybe this can be a good opportunity to improve the docs (about WKD etc.)
The best part of GSoD is that it is not limited to the students, so
hopefully the quality of the resulting work will be better.


>
> > I think this is suitable task for a GSoC project that can be developed in
> > 2-3 months by a good student, with help and guidance from mentors.
>
> If it would be clear what each option would do, the implementation time
> would
> be enough, but the assumptions of the current interactive command line
> interface and all its bells and whistles are many and interact in a
> complex
> way, so to me it is doubtful that a student can handle this in 3 months.
>

That's why the mentors are needed. This may also be a good reason for
considering the new interface as experimental, which may initially change
frequently.

Best regards,
Dashamir
Re: GSoC project idea [ In reply to ]
On Mon, Mar 18, 2019 at 04:49:11PM +0100, Dashamir Hoxha wrote:
> On Mon, Mar 18, 2019 at 4:07 PM Doron Behar <doron.behar@gmail.com> wrote:
>
> >
> > In my fork I didn't modify anything, only added. The idea is to add only
> > a directory named ipg (Acronym for improved privacy guard) and in it all
> > the code that will use the functions that already exist in the source
> > tree; So when a user builds my version from the git source (autoreconf
> > && ./configure && make && make install), he will a get another
> > executable installed called `ipg` that will be equivalent to `gpg` in
> > it's use but will have a nicer CLI syntax.
> >
> > Both executables (gpg & ipg) installed by my version will be equally
> > updated to use the latest version of the C code that implements the
> > actual encryption and decryption etc.
> >
>
> In my opinion, it might be better if there was a single executable (gpg)
> that can accept both sets of CLI commands. If this is possible.
>
> In any case, I think that the aim should be to finally submit a patch to
> the mainstream code, and hopefully it gets accepted. Distributing it
> separately as an improved version of gpg is not going to work for many
> reasons.

I agree but say that building a single executable that will accept both
CLI syntaxes won't be easy to implement, even submitting a patch to the
mainstream code with the additional `ipg` executable would be a good as
well right?

>
>
> >
> > > It does not seem so easy to me because you may need some feedback from
> > more
> > > experienced people, although you may think that you have organized the
> > > commands and their options properly.
> >
> > I think the only difficult part in this design (and please correct me if
> > you think I'm wrong) is making sure that when the upstream source is
> > updated and functions change their names etc., my fork updates the names
> > of the functions it calls.
> >
> > Also, according to my design, almost every sub-command and it's optional
> > flags have their equivalent in the current syntax, strictly according to
> > the documentation. The only difference is that some sub-commands
> > naturally don't accept all options that may be accepted (but ignored!)
> > in the current syntax. Most importantly, this should also prove to be
> > more comfortable for shell completions to not overwhelm users with
> > options most of which are irrelevant for the current _action_ they want
> > to perform.
> >
>
> I understand your design and its advantages, but I am not sure wheather you
> understand all the details about `gpg` commands and options. Maybe you do,
> myself I don't.
>
> > You can be one of the mentors, which hopefully should not be very time
> > > consuming.
> >
> > As a mentor, am I not obliged to be an experienced C programmer? If so,
> > that could be an excellent idea.
> >
>
> If you are an experienced C programmer that's great. But you don't have to
> be. You can also be an experienced `gpg` user. And anyway, the idea of
> reorganizing the commands is yours and you know what you are aiming for
> better than anyone. So, you can definitely be one of the mentors, if you
> have time and if you want to be.

I just wanted to notify you that today I've found out that I won't be
able to submit this project to the next GSOC since I'm not a student yet
and therefor I don't have a proof of enrollment. I wonder whether I can
register as a mentor without being a student, if so it's probably not
possible only yet.

>
> Dashamir

> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: GSoC project idea [ In reply to ]
On Tue, Mar 26, 2019 at 3:00 PM Doron Behar <doron.behar@gmail.com> wrote:

>
> > In my opinion, it might be better if there was a single executable (gpg)
> > that can accept both sets of CLI commands. If this is possible.
> >
> > In any case, I think that the aim should be to finally submit a patch to
> > the mainstream code, and hopefully it gets accepted. Distributing it
> > separately as an improved version of gpg is not going to work for many
> > reasons.
>
> I agree but say that building a single executable that will accept both
> CLI syntaxes won't be easy to implement, even submitting a patch to the
> mainstream code with the additional `ipg` executable would be a good as
> well right?
>

I would say this is acceptable, especially if we view this GSoC project as
an experimentation. The code produced by a GSoC project is not required to
be accepted by the main project, even if the GSoC project is successfull
(meets its objectives etc.)
However I am not a gnupg developer and I have no saying on this matter. If
the developers are firmly against the idea of this GSoC project, let them
speak and put an end to this story.

> If you are an experienced C programmer that's great. But you don't have to
> > be. You can also be an experienced `gpg` user. And anyway, the idea of
> > reorganizing the commands is yours and you know what you are aiming for
> > better than anyone. So, you can definitely be one of the mentors, if you
> > have time and if you want to be.
>
> I just wanted to notify you that today I've found out that I won't be
> able to submit this project to the next GSOC since I'm not a student yet
> and therefor I don't have a proof of enrollment. I wonder whether I can
> register as a mentor without being a student, if so it's probably not
> possible only yet.
>

According to the GSoC rules, there are no special requirements about the
mentors. It is the organization admins that decide whether you can be a
mentor of a project or not. In this case the organization is GNU. I don't
think they will refuse to make you a mentor, unless there is some oposition
from gnupg developers. This page has more details:
https://www.gnu.org/software/soc-projects/guidelines.html

However the period that students submit project proposals has already
started, and this project idea is not published yet anywhere. Even if it is
published now, I wonder if any students will notice it and apply for it. If
you know some student that could work on this project you can let them know
personally. Then either you or the student can mail the project idea to:
summer-of-code@gnu.org Maybe you should hurry up a bit because on April 9
is the student application deadline (
https://developers.google.com/open-source/gsoc/timeline). I would be
willing to advice you, if nothing else, at least about the rules and
requirements of GSoC.

Dashamir