Re: [Evolution] Evolution Caldav SSO Access via GSSAPI/Kerberos - again

[torsten finke igh de]

Dear Milan, 

On Tue, Aug 31, 2021 at 02:33:09PM +0200, Milan Crha via evolution-list wrote:
> On Tue, 2021-08-31 at 13:57 +0200, Torsten Finke via evolution-list
> wrote:
> > I have not been subscribed to the list when I sent my original issue.
>
>       Hi,
> ah, I see, no problem. I've been wondering what happened, I'd not blame
> Mutt doing things wrong.

you are welcome - I love mutt for being quick and simple. Most of my
friends prefer evolution a lot :-)

> > After launching a new evolution session it asks immediately for
> > credentials, although I had prepared a kerberos ticket (kinit, checked
> > by klist).
>
> I tried it here, and it works like a charm.

that's good news! So I will try further. 

> It is a little cumbersome, due to no GUI element for the
> authentication method, but otherwise it just worked here.

since the .source files are plain text, that's no problem at all. 

> I use a newer libsoup as well, and from the version
> of the Evolution you have installed in the system I'd guess the libsoup
> will be behind as well. It's only a guess. The GSSAPI support for the
> libsoup had been added in 2.54, in 2016, with some fixes added
> meanwhile. You probably have it.

on my system a libsoup-2_4 is installed. That may explain the
problem. I will try to build a newer one on my own. 


> What I've done:
> a) in Evolution: File->New->Calendar->CalDAV, filled the URL, the user
>    name as expected by the server (it's not the same as the one I use
>    on the machine) and then clicked OK
> b) been asked to enter credentials, which I cancelled
> c) closed Evolution
> d) killed the background processes
> e) went to the ~/.config/evolution/sources/ and found the new calendar,
>    where I changed the Method to GSSAPI
> f) re-run the background processes and the Evolution itself
>
> Result: no password prompt, calendar content shown.

great - so I am optimistic to reproduce that. 

> > Because GSSAPI works for e-mail, may I ask, how authentication differs
> > between e-mail and calender access? 
>
> Email does it on its own, with its own code. Calendar/book uses libsoup
> or other libraries.

I see - so it will not be of any use to compare both (e.g. in sources). 

> > I have read this as well but did not understand how to make evolution
> > debug the interpretation of the calendar sources, and - more important
> > - how to debug authentication.
>
> There is no specific debug option for the authentication itself, you
> can enable the overall debugging for the related part. I suppose you
> created a CalDAV calendar, which is handled on the calendar factory
> side, thus you can run it as:
>
>    $ CALDAV_DEBUG=1 /usr/libexec/evolution-calendar-factory -w
>
> To see debugging information (raw communication between the server and
> the client) for all your CalDAV calendars.

I think I have tried that, but maybe my libsoup prevented GSSAPI
authentication without comment.


> > Unfortunately version 3.41.2 seems not to be backward compatible to my
> > production version 3.34.4. It has scrumbled my e-mail configuration
> > somehow.
>
> Ouch, that's pretty bad. I'm sorry.

I did not complain and normally one cannot expect backward
compatibility. 

> > Also I could not manage to keep the eco systems of the installed and
> > the newly built systems apart. There are some cross effects concerning
> > libs, schemas and systemd. So now I will set up a virtual machine for
> > testing.
>
> Ah, right, I didn't think of this aspect, I'm sorry.

not at all - you did great work and definitively do not one to
criticise. Maybe I can distribute some information concerning the
post-build process. 

> You might need to
> override the XDG directories to avoid the clash between the two, but I
> agree with you it's easier, and safer, to just use a virtual machine,
> if there is enough disk space. I'd even use some more recent distro.

In principle you are right, but that's an ugly discussion. In my
environment it is more important to have a reproducable setup (even if
issues exist) rather than to have a recent system with often unknown
behaviour. Besides that also recent distros often show remarkable
delay against development states. 


> You can eventually use Flatpak, which will bring more recent libraries
> as well. Some info can be found here:
> https://wiki.gnome.org/Apps/Evolution/Flatpak

I do not have best experiences with Flatpak, AppImage and so on.
I would consider it a workaround, although sandboxing has it's
advantages. 

> These run in a separate space. You can find the related files either
> when you "log in" to the Flatpak sandbox (`flatpak run --command sh
> org.gnome.Evolution`) or under ~/.var/app/org.gnome.Evolution/. Using
> Flatpak has its caveats/limitations. Hmm, I'm not sure whether the
> Kerberos tickets are propagated to the Flatpak sandbox.

That would be my objection.

Given your hints I will go on and send my results. May take some
days. 


Thank you very much and best regards



Torsten 




-- 
------------------------------------------------------------------------
Torsten Finke
torsten finke igh de
------------------------------------------------------------------------