Why do we want to do this? Is there a particular reason you want to make it use krbV instead of python-requests for Kerberos?

@tkopecek was trying to help me resolve #249.

Firstly I was just trying to remove sslLogin errors from #249. Reason could be configuration with just mod_auth_kerb and not mod_auth_gssapi.
Nevertheless, it reveals problem that user can think he is using gssapi, while it fallbacks to kerberos. So, now I'm rethinking it to add also explicit option 'authtype=gssapi' to koji.conf to enforce gssapi and when it fails, don't try krbV.
Does it make sense, or do you think that it is something misleading/unwanted?

In the case we go with authtype=gssapi, I would suggest not havign the automatic fallback, and maybe adding authtype=gssapi+kerberos to indicate they want automatic failover.
The reason is that some deployments might setup both, while others don't.
(Fedora has both, but I can see cases where people want to use purely GSSAPI, as that's what Fedora would like to move to in time)

@puiterwijk is right, and I was a little confused in my comment on #249. In the current implementation there is no way to specify gssapi auth.

We need to be a little careful here as some users could be relying on the fallback (though luckily it sounds like plain krb will for for Fedora users at least).

Here's a case for concern: Fedora users that are using multiple kerberos tickets and relying on the gssapi code to find the right one without having to run kswitch all the time.

Without the fallback, those users would just get the original krb auth path, which will only consider their primary krb cache.

I like the idea of adding a new authtype, but I think a lot of Fedora users might need to update that. Though I guess that could be addressed with a fedora-packager update.

Is the linked issue #249 which was closed?

Ping @tkopecek , is this still needed?

There were no related issue filed for two years. So, maybe it makes sense to drop it.

:thumbsup: to dropping all non-gssapi Kerberos code.