GNUS Kerberos support, native GSSAPI?

GNUS Kerberos support, native GSSAPI?

[Elias Mårtenson]

[-- Attachment #1: Type: text/plain, Size: 600 bytes --]

Hello Lars, Gnus and Emacs-devel,

I've been hacking on an Emacs module to provide native GSSAPI support in
Emacs (essentially providing the same functionality as my cl-gss[1] library
for Common Lisp).

I've reached the point where I now know that it will work and my intention
is now to integrate this into Gnus so that I can finally avoid putting my
password in .authinfo.gpg.

I'm now wondering if this is a contribution that would be acceptable to
Gnus, or is there a philosophical argument against the use of a native
module to accomplish this?

Footnotes:
[1] https://github.com/lokedhs/cl-gss

[-- Attachment #2: Type: text/html, Size: 789 bytes --]

Re: GNUS Kerberos support, native GSSAPI?

[Stefan Monnier]

> I've been hacking on an Emacs module to provide native GSSAPI support in
> Emacs (essentially providing the same functionality as my cl-gss[1] library
> for Common Lisp).
> I've reached the point where I now know that it will work and my intention
> is now to integrate this into Gnus so that I can finally avoid putting my
> password in .authinfo.gpg.

Ooohh... yes, please, please, pretty please,


        Stefan "who instead repeatedly types his password because he
                doesn't want to put it into .authinfo.gpg"

Re: GNUS Kerberos support, native GSSAPI?

[Elias Mårtenson]

[-- Attachment #1: Type: text/plain, Size: 881 bytes --]

On 6 February 2017 at 22:22, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > I've been hacking on an Emacs module to provide native GSSAPI support in
> > Emacs (essentially providing the same functionality as my cl-gss[1]
> library
> > for Common Lisp).
> > I've reached the point where I now know that it will work and my
> intention
> > is now to integrate this into Gnus so that I can finally avoid putting my
> > password in .authinfo.gpg.
>
> Ooohh... yes, please, please, pretty please,
>
>
>         Stefan "who instead repeatedly types his password because he
>                 doesn't want to put it into .authinfo.gpg"
>

I'm glad to see that there are people who are interested in this other than
myself. I'm continuously working on this, but I don't have much time to
spare for it. I'm hoping to have something in a week or so, but no
guarantees.

Regards,
Elias

[-- Attachment #2: Type: text/html, Size: 1353 bytes --]

Re: GNUS Kerberos support, native GSSAPI?

[Stefan Monnier]

> I'm glad to see that there are people who are interested in this other than
> myself.  I'm continuously working on this, but I don't have much time to
> spare for it.  I'm hoping to have something in a week or so, but no
> guarantees.

I've only been waiting for it for the last what... 10 years?  So really,
there's no hurry,


        Stefan

Re: GNUS Kerberos support, native GSSAPI?

[Elias Mårtenson]

[-- Attachment #1: Type: text/plain, Size: 699 bytes --]

On 7 February 2017 at 22:16, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > I'm glad to see that there are people who are interested in this other
> than
> > myself.  I'm continuously working on this, but I don't have much time to
> > spare for it.  I'm hoping to have something in a week or so, but no
> > guarantees.
>
> I've only been waiting for it for the last what... 10 years?  So really,
> there's no hurry,
>

I have now built a working Emacs module that can access basic GSSAPI
functionality. It should be enough to authenticate to an IMAP server. Code
can be found here: https://github.com/lokedhs/emacs-gssapi

The next step is to look into the GSS IMAP protocol.

Regards,
Elias

[-- Attachment #2: Type: text/html, Size: 1231 bytes --]

Re: GNUS Kerberos support, native GSSAPI?

[Joakim Jalap]

Elias Mårtenson <lokedhs@gmail.com> writes:

> I have now built a working Emacs module that can access basic GSSAPI functionality. It should be enough to authenticate to an IMAP server. Code can be found here:
> https://github.com/lokedhs/emacs-gssapi
>
> The next step is to look into the GSS IMAP protocol.

This is really cool :) Just looking over the code quickly it seems like
it would be useful to extract some of the functions in your module as a
sort of "emacs module lib". I mean things like bind_function, xcar,
xcdr, lisp_push (which is cons) and so on. Shouldn't everybody who
writes a module want most of these?

Just a thought :)

-- Joakim

Re: GNUS Kerberos support, native GSSAPI?

[Elias Mårtenson]

[-- Attachment #1: Type: text/plain, Size: 1294 bytes --]

On 9 February 2017 at 19:55, Joakim Jalap <joakim.jalap@fastmail.com> wrote:

This is really cool :) Just looking over the code quickly it seems like
> it would be useful to extract some of the functions in your module as a
> sort of "emacs module lib". I mean things like bind_function, xcar,
> xcdr, lisp_push (which is cons) and so on. Shouldn't everybody who
> writes a module want most of these?
>
> Just a thought :)
>

Thanks! And yes, I agree. This is my first attempt at writing something
that uses the module API, and these are definitely functions that I cannot
see anyone writing a module would not end up reimplementing.

In fact, I'd go as far as suggesting that some of the boilerplate should be
provided by emacs-module itself. In particular, having to do
env->intern(env, "nil") just to get a reference to nil is a bit crazy.

I tried putting all the interned symbols in a struct and passing specifying
it as a data pointer when constructing the functions. However, this did not
work as the emacs_value objects does not seem to have a lifetime outside of
the invocation of a native function. I haven't seen this documented
anywhere, so that was a bit surprising at first. The fact that this failed
is the reason you see all the calls to env->intern everywhere.

Regards,
Elias

[-- Attachment #2: Type: text/html, Size: 1785 bytes --]

Re: GNUS Kerberos support, native GSSAPI?

[Aurélien Aptel]

On Thu, Feb 9, 2017 at 2:02 PM, Elias Mårtenson <lokedhs@gmail.com> wrote:
> In fact, I'd go as far as suggesting that some of the boilerplate should be
> provided by emacs-module itself. In particular, having to do
> env->intern(env, "nil") just to get a reference to nil is a bit crazy.

The module API is kept simple on purpose. We don't won't to clutter
the raw interface. I agree that the boiler-plate should be provided as
lib that provides utils built on top of the API.

> I tried putting all the interned symbols in a struct and passing specifying
> it as a data pointer when constructing the functions. However, this did not
> work as the emacs_value objects does not seem to have a lifetime outside of
> the invocation of a native function. I haven't seen this documented
> anywhere, so that was a bit surprising at first. The fact that this failed
> is the reason you see all the calls to env->intern everywhere.

This was not always the case: the behaviour was changed by Philipp at
some point. We still have the make_global_ref and free_global_ref
functions in the API, which serve no purpose as a result (correct me
if I'm wrong).

Re: GNUS Kerberos support, native GSSAPI?

[Philipp Stephani]

[-- Attachment #1: Type: text/plain, Size: 1299 bytes --]

Aurélien Aptel <aurelien.aptel+emacs@gmail.com> schrieb am Fr., 10. Feb.
2017 um 19:21 Uhr:

>
> > I tried putting all the interned symbols in a struct and passing
> specifying
> > it as a data pointer when constructing the functions. However, this did
> not
> > work as the emacs_value objects does not seem to have a lifetime outside
> of
> > the invocation of a native function. I haven't seen this documented
> > anywhere, so that was a bit surprising at first. The fact that this
> failed
> > is the reason you see all the calls to env->intern everywhere.
>
> This was not always the case: the behaviour was changed by Philipp at
> some point. We still have the make_global_ref and free_global_ref
> functions in the API, which serve no purpose as a result (correct me
> if I'm wrong).
>

Using make_global_ref is definitely intended to make objects usable across
environments (i.e. you should be able to use them in any thread whenever
any environment is active). If that's not the case, please report a bug.
The alternative of using intern everywhere is also not too bad because it's
much simpler and more obvious (no global state that you have to track
carefully). I'd recommend only switching to global references if there is a
significant performance penalty.

[-- Attachment #2: Type: text/html, Size: 1635 bytes --]

Re: GNUS Kerberos support, native GSSAPI?

[Elias Mårtenson]

[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]

On 24 April 2017 at 01:31, Philipp Stephani <p.stephani2@gmail.com> wrote:


> Aurélien Aptel <aurelien.aptel+emacs@gmail.com> schrieb am Fr., 10. Feb.
> 2017 um 19:21 Uhr:
>
>>
>> This was not always the case: the behaviour was changed by Philipp at
>> some point. We still have the make_global_ref and free_global_ref
>> functions in the API, which serve no purpose as a result (correct me
>> if I'm wrong).
>>
>
> Using make_global_ref is definitely intended to make objects usable across
> environments (i.e. you should be able to use them in any thread whenever
> any environment is active). If that's not the case, please report a bug.
> The alternative of using intern everywhere is also not too bad because
> it's much simpler and more obvious (no global state that you have to track
> carefully). I'd recommend only switching to global references if there is a
> significant performance penalty.
>

Thanks. I'll stick with env->intern then. :-)

I'll also keep your point in mind, and if I see the issue again I'll send a
bug report.

[-- Attachment #2: Type: text/html, Size: 1781 bytes --]