@puiterwijk Is this still needed with gssapi merged into koji?

Rebases to current HEAD just fine

Is there a use case for allowing user =WELLKNOWN/ANONYMOUS? It looks like this would allow anyone to use anon auth and create or log in as that singular user in Koji.

Do we need the allowed_realms enforcement? Seems like that would be something that happens at the httpd layer.

koji.AuthError('Unparseable principal')

Please use raise Exception('msg') rather than raise Exception, 'msg'

Is there a use case for allowing user =WELLKNOWN/ANONYMOUS? It looks like this would allow anyone to use anon auth and create or log in as that singular user in Koji.

This would be allowed indeed if the current realm allows anonymous connections.
I just didn't want to break anything if people do happen to use it for some crazy reason.

Do we need the allowed_realms enforcement? Seems like that would be something that happens at the httpd layer.

The httpd layer may also accept trusted realms, for example from partners, that you do not want to allow access to the koji installation.

@puiterwijk Is this still needed with gssapi merged into koji?

Not for people that switch to gssapi.
However, not everyone might want to do so.

https://pagure.io/koji/issue/1557

This PR is over two years old and would only benefit users that haven't switched to gssapi. I haven't heard of anyone asking for this and suggest that we drop it. @mikem would you be ok with that?

I think it's risky to keep the non-gssapi code around, because it is security sensitive and it will get no attention with Python 2 going EOL. I think we should drop all the non-gssapi Kerberos paths.

FYI, we did a similar check in PR #1648 for both gssapi and non-gssapi auth

@julian8628 - so can we drop this one as #1648 obsoletes it?

@tkopecek, I think we can drop this unless the anonymous kerb is used in some instances.

Ok, let's drop this. I've also created #1906 for dropping krb code.