[39570] in Kerberos
Re: Golang GSSAPI spec
daemon@ATHENA.MIT.EDU (Simo Sorce via Kerberos)
Fri Oct 24 09:55:51 2025
Message-ID: <5b4afe2c95b51ca01638de61749e8ef90c9af29b.camel@redhat.com>
To: Jake Scott <jake@poptart.org>, kerberos@mit.edu
Date: Fri, 24 Oct 2025 09:55:33 -0400
In-Reply-To: <CAExmWcgo0ZHmJB4or0isZtwy=an7tD+SpzQ=_ymYd6RfZBEtSA@mail.gmail.com>
MIME-Version: 1.0
From: Simo Sorce via Kerberos <kerberos@mit.edu>
Reply-To: Simo Sorce <simo@redhat.com>
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Thu, 2025-10-23 at 18:53 -0600, 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 would love some feedback before launching this on the world! It is
> currently in beta, and the docs/code are at:
>
> The interface spec: https://github.com/golang-auth/go-gssapi/wiki
> .. and the code for the interface and provider register:
> https://github.com/golang-auth/go-gssapi
>
> And the C provider: https://github.com/golang-auth/go-gssapi-c
>
> I know the C folks probably won't be keen on the more OO approach - would
> be interested to know how people think this compares with the Java
> interface though and whether there have been any issues to be aware of with
> this approach.
>
> Many thanks!
Very nice work Jake,
if you haven't already looked at it I would carefully comb through
https://github.com/pythongssapi/python-gssapi (and its documentation)
to see how we did split things between a higher level and a lower
level (raw) API.
This will push your users to avoid falling in some traps.
I would strongly suggest you implement the CredStore extension
(original project:
https://k5wiki.kerberos.org/wiki/Projects/Credential_Store_extensions
) as it makes some use case much easier to deal with than trying to
manually juggle credentials, with less side effects.
And as Michael mentioned, I would strongly suggest avoiding trying to
build a native implementation, it would be a huge time-sink with hard
to achieve maturity. It may seem fun initially bug both libkrb5 and
libgssapi have devilish details that you won't see when testing simple
applications (including support for out of tree plugins
like https://github.com/gssapi/gss-ntlmssp and support for cache types
that require exact semantic to interoperate correctly (and some of
those differ between C implementations already).
That said given this API allow users to easily switch between a
naive/incomplete and a good implementation somewhat easily that is less
of a concern to me.
Finally I am not super-familiar with Go APIs so it would be easier to
judge the API if you had a code example of a full GSSAPI context
establishment loop on the client and on the server side separately.
Error handling and continuations being important to get right to be
usable in real scenario.
HTH,
Simo.
--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
