Hi Michael thanks for your reply. Didn't receive it in email for reason; found it on the mailing list archive..
On Thu, Oct 23, 2025 at 6:53 PM Osipov, Michael (IN IT IN) < [email protected]> wrote: > * Have you looked into py-gssapi? It is a very clean, yet convenient > wrapper your C GSS-API. I have been using it at low-level and high-level > with please without the need to resort to C? > I did - its a very nice to use API that I have made use of myself and influenced some of the Go API design. I'm not sure of the reason for the low level part though - certianly in Go there are idiomatic ways to do things and I don't know that exposing the GSS calls directly fits that bill. I am no Python developer though - I assumed the same would be true there so I'm certainly interested in why someone might want to use the lower level APIs from a high level language like that.. * The JGSS RFC is very dated and lacks a lot of features which have been > introduced in the C API in the past decade. There is now also an > ExtendedJGSSContext you might want to check. > * You should write to security-dev at openjdk mailing list and ask Max > (Weijun Wang). He is the lead guy for JGSS impl at Oracle. Feel free to > mention my name. Thanks that's useful info - I didn't know about the extended context and will certainly chat to the Java guys. * Since you support Apple Kerberos, see > https://github.com/curl/curl/issues/19109. This might be interesting for > you. That is interesting - why would you enable channel bindings by default. I will do some more MacOS testing.. * FreeBSD base Kerbros: The ancient Heimdal has been replaced with MIT > Kerberos 1.22.1 in the base system for 15. You might want to check that. Great news and about to install a FBSD 15 system to test with, thanks! Does it easily plug into Go's URL transport library, e.g., > py-requests-gssapi to authenticate via SPENGO? Yes I've already used it for that purpose. But I think its not a bad idea to ship something that makes this simple for developers - I would guess that Negotiate is probably the primary usecase. Thanks fot the suggestion. ** Python uses OpenLDAP libs with Cyrus SASL where SASL GSSAPI mech > comes for free, I have seen that you provide LDAP examples as well, how > trivial is it to make this happen in the Go impl too? This might get > interesting for us as well (LDAP calls to Active Directory)? So I wrote a very bare bones SASL library for Go a number of years ago that I am not very proud of (https://github.com/golang-auth/go-sasl if you're brave enough). I intend on moving on to actually making this something I'm happy to use 'next' and talking to folks that have Go libraries that fudge SASL to integrate that instead (including the nice people at https://github.com/go-ldap/ldap) Java's ticket cache is pure memory which means pure crap. I need to > change and fiddle with the Subject between threads in a thread pool > executor while MIT Kerberos does this nicely either with a file-based or > KCM-based cache. The Java approach leads to more code or a cache > per-thread which is slow to populate. That is also the approach to the old pure-go Kerberos implemetation. I did write a patch that used a file CCcache in a way that was compatible with MIT but just abandoned it in favour of this project eventually. You might be pleasantly surprised to hear that a colleage of mine is close to submitting a PR that will introduce KCM support for Java. We use KCM at my place of work with a custom KCM daemon (which I'm told we're also going to open source, just don't hold me to that). Many thanks, Jake ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
