Golang GSSAPI spec

[Osipov, Michael (IN IT IN)]

On 2025-10-24 02:53, Jake Scott wrote:
> Hi there..
> 
> I've been working on a spec for GSSAPI on Go similar to RFC2744 and RFC2853
> for C and Java.  I have a working implementation of the described interface
> and a provider that wraps the MIT & Heimdal C libraries.  The idea is to
> provide an idomatic interface for Go developers that supports multiple
> providers (like the C provider or a pure Go provider at some point).

I forgot to mention regarding a pure Go provider: This would be the same 
situation as in Java. I highly do NOT recomment doing so for at least 
these reasons:
* You will constantly lag behind other providers
* You will either miss or be forced to implement custom ticket cache 
providers, e.g., SSSD comes with a memory-based one similar to Windows' 
LSASS, but JGSS does not support it, therefore Java cannot use it:
> ddsnvo at deblndw013x2v:~
> $ klist
> Ticket cache: KCM:1000:28297
> Default principal: uawetech at INNOMOTICS.NET
> 
> Valid starting     Expires            Service principal
> 24/10/25 09:41:55  24/10/25 19:41:55  krbtgt/INNOMOTICS.NET at INNOMOTICS.NET

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.
* If you consider to add SSPI to the might at some might you won't never 
be able to tap into the TGT because LSASS will never grant to direct 
access to it (this busted Java years ago). You have to go through direct 
APIs only. This might be the case with Apple Kerberos as well with a 
custom cache provider.

Michael