Switch to kerberos instead of pykerberos

[toabctl]

Distributions (openSUSE, Debian, Ubuntu, Fedora) already ship python-kerberos but nobody ships python-pykerberos . And both have the same kerberos.so so they are not installable in parallel.
Can you please switch to kerberos (from pypi) instead of using pykerberos? Looks anyway that pykerberos is just a fork of kerberos. Or am I missing something?

[Lukasa]

@toabctl The switch to PyKerberos was required because of limited support for Python 3 in the Kerberos library for a long time.

However, we can safely switch back.

[toabctl]

@Lukasa So py3 support is now good in kerberos? Should I prepare a PR ?

[Lukasa]

I believe it is, yes.

[carsonyl]

There had been multiple requests and attempts at making the switch to PyKerberos: see #32, #38, #52, #56, #57. One of the claims was that PyKerberos is more actively maintained than python-kerberos, which certainly seemed true at the time.

[toabctl]

@rbcarson hm. so are you saying that we should stay with pykerberos? And is it just changing the requirements.txt line or is there more todo for a switch?

[carsonyl]

@toabctl I have no preference. Are you able to test the change? We don't have any automated tests against a real server.

In addition to requirements.txt, it's also listed in setup.py's extras_require.

[behackett]

Apple is developing the kerberos package again. They just did a release on pypi in January. It appears to fully support python 3 now.

[behackett]

Scratch that. You can't currently switch to Apple's kerberos module. The context object it creates has to be explicitly freed by calling authGSSClientClean when you are done with it. Sadly, that causes issues under python 3.x:

https://www.calendarserver.org/ticket/936

[carsonyl]

Note #76 from yesterday, in which Apple's Kerberos 1.2.4 has a bug involving the explicit principal support that was recently added to requests-kerberos (it would have been possible to avoid the issue with some refactoring requests-kerberos in though).

[danc86]

Is there any open issue against Apple's Kerberos for the problem observed in #76?

[carsonyl]

Not that I know of, though their issue tracker is tricky to dig through. I don't think it's fixed in trunk.

[danc86]

Okay I filed: https://www.calendarserver.org/ticket/942

[spaetow]

Just be careful not to switch to a kerberos/gssapi object that does not fully support the GSSAPI standards. Using one that just does a subset does everyone a great disservice.

[tuukkamustonen]

apple/ccs-pykerberos#49 (https://www.calendarserver.org/ticket/942) was merged in apple/ccs-pykerberos#52 and the fix is in 1.2.5. Nothing blocking the change then?

[behackett]

I've sent two pull requests to ccs-pykerberos that, once merged, would allow requests-kerberos to switch with no code changes.

See apple/ccs-pykerberos#60 and apple/ccs-pykerberos#61.

[behackett]

With the release of ccs-pykerberos 1.3.0 this change should be unblocked.

[jmehnle]

Has a decision been made? Is requests-kerberos going to keep depending on pykerberos or switch to Apple's kerberos module?

[0xkag]

Can this be revisited?

Today I observed both pip install kerberos and pip install pykerberos (installed automatically as a dependency of requests_kerberos) dropping the same kerberos.so in site-packages. It happens silently, which is a bit dangerous. So then I googled and found this ticket.

My requirements.txt contains:

kerberos==1.3.0
requests==2.19.1
requests_kerberos==0.12.0

Given that it seems like pykerberos is abandoned (? I think) in favor of kerberos in PyPi, it seems worthwhile to resolve this conflict.

I suppose I can remove kerberos==1.3.0 and just use pykerberos installed by requests_kerberos but this is not a long-term solution.

[mkomitee]

The same one, or conflicting ones?

[mkomitee]

With the release of ccs-pykerberos 1.3.0 this change should be unblocked.

Did that include apple/ccs-pykerberos#70 as you noted was needed in #97?

[twosigmajab]

Hi @Lukasa, interested in this too. Anything we can do to help make progress?

[nonsleepr]

It seems that right now kerberos package maintained better than pykerberos. The latter wasn't updated in 3 years while the former had fixed this year. It might be the time!

[jborean93]

Ultimately both kerberos and pykerberos are old projects and should be avoided where possible. If you are running on Linux I highly recommend you use requests-gssapi which uses a similar API to this library but is based on the newer and definitely maintained gssapi project.

[jborean93]

This library will use pyspnego in the upcoming 0.13.x release which uses python-gssapi on Linux and it's own SSPI provider for Windows.