Matěj Cepl wrote:
> When Fedora enabled Kerberos on id.fedoraproject.org, I have
> immediately started to use it, and I am suspicious I am now
> member of rather exclusive group of people with multiple Kerberos
> tickets on their system (my completely unevidenced suspicion is
> that 99% of Kerberos users have only one ticket from their
> employer/school).
>
> On the advice of somebody (or some Mojo document, not sure) I
> have added configuration files like (also similar ones for
> REDHAT.COM realm)
>
> mitmanek:~# cat /etc/krb5.conf.d/fedoraproject_org
> [realms]
> FEDORAPROJECT.ORG = {
> kdc = https://id.fedoraproject.org/KdcProxy
> }
> [domain_realm]
> .fedoraproject.org = FEDORAPROJECT.ORG
> fedoraproject.org = FEDORAPROJECT.ORG
> mitmanek:~#
Hi Matěj,
I think that is quite a typical setup, I had similar things in my
krb5.conf while still working at a University that used Kerberos, and
managed several domains, too (albeit with a hierarchical LDAP behind).
> Some programs (Gnome apps after some small amount of torture of
> the glib-networking maintainer, Firefox) seems to work perfectly
> well, using the right ticket for the right domain, but some other
> apps are hopelessly lost facing multiple Kerberos tickets.
[...]
> When I presented one of my colleagues working with Kerberos (I
> work for Red Hat), he answered me with these notes:
>
[...]
> 2. If fetchmail is using exclusively GSSAPI calls, then you
> should open ugs against our krb5 packages (as gssapi is provided
> by those) at first. There are some ways to use GSSAPI that work
> better than others, but in general clients should just work.
Fetchmail has code in place for three ways of using Kerberos:
* Kerberos IV (4), which is deemed obsolete and I won't make any
promises that it works
* Kerberos V (5), of which I am somewhat suspicious function-wise, which
would be calling krb5_*() functions, and is broken on some of the KRB5
implementations, for instance, I marked it b0rked on Heimdal.
* GSS-API, with whatever providers it will use and which I'd say is the
thing that should work, and which I would be willing to help with. The
code is self-contained in gssapi.c, with a few calls into it from pop3.c
or imap.c, the guts of the code are, however, 14...17 years old.
For any debugging and fixing, I propose to look at the "legacy_64"
branch for now, since it has several I'd say worthwhile fixes, OpenSSL
overhaul, and I will forward-port potential GSSAPI fixes for ticket
selection from that branch to the master branch.
Repositories at:
https://sourceforge.net/p/fetchmail/git/ci/legacy_64/tree/
https://gitlab.com/fetchmail/fetchmail
> 3. If fetchmail is doing any direct libkrb5 calls, or running any
> kinit/klist command line tools then yeah they should stop.
Yup, configure --without-kerberos --without-kerberos5 --with-gssapi then
to fix this part.
> 4. In general IMAP/POP use SASL, and most software uses cyrus-
> sasl to deal with it. Cyrus sasl will use only GSSAPI calls in
> this case. However if upstream built their own SASL
> library/wrappers ... then I would perhaps rather consider
> dropping its use rather than try to fix it ... they probably
> have way bigger security issues.
fetchmail does not use SASL libraries, authentication protocols are
implemented inside fetchmail, leaving aside most of the crypto stuff
(fetchmail uses the KRB, GSSAPI, and OpenSSL libraries).
HTH
Matthias
|
