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

[Milan Crha <mcrha redhat com>]

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.

> 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. It is a little cumbersome,
due to no GUI element for the authentication method, but otherwise it
just worked here. 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.

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.

> 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 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.

> 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.

> 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. 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.

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
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.

        Bye,
        Milan