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

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
I have not been subscribed to the list when I sent my original issue.

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

Ouch, that's pretty bad. I'm sorry.

I did not complain and normally one cannot expect backward

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

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:

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

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

Thank you very much and best regards


Torsten Finke
torsten finke igh de

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]