[39572] in Kerberos

home help back first fref pref prev next nref lref last post

Re: Golang GSSAPI spec

daemon@ATHENA.MIT.EDU (Jake Scott)
Sat Oct 25 02:16:13 2025

MIME-Version: 1.0
In-Reply-To: <5b4afe2c95b51ca01638de61749e8ef90c9af29b.camel@redhat.com>
From: Jake Scott <jake@poptart.org>
Date: Fri, 24 Oct 2025 16:28:26 -0600
Message-ID: <CAExmWcj77d0vCohknAK4Zf_s_iKNAb_PjbTHW90jiOmRyBRKzg@mail.gmail.com>
To: Simo Sorce <simo@redhat.com>
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit

On Fri, Oct 24, 2025 at 7:55 AM Simo Sorce <simo@redhat.com> wrote:

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.
>

Thanks - the python bindings were one of the things I looked at actually.
Do you find
users making use of the low level API much?.. I wondered what the
motivation there
was.  I like the way the API deals with extensions and that influenced how
the Go bindings
do that also (not that they're all implemented yet)


> 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.
>

Thanks I'll look into that!


> 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.


I agree that a pure-Go implementation is likely never going to be
as complete or well tested as MIT or Heimdal.  What drove me to do this
project in the first place is the disconnect between the desire of Go
developers
in general for a pure-go solution vs the reality that the existing
implementation
was no where near production ready.  Having one standard we develop against
allows us some flexibility for future developments though..

I would guess that the vast majority of applications making use of GSSAPI
probably use a small subset of the functionality and probably a very large
percentage of users still use a file based credential cache.  So a cut-down
less complete provider might be of benefit for those folks esp. those who
just won't use C bindings to anything.  Honestly I think I would focus on
a decent SASL implemementation before thinking about any of that though.


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.
>
>
Absolutely - take a look at
https://github.com/golang-auth/gssapi-examples/tree/main/go


Thanks for the feedback!

Jake
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos


home help back first fref pref prev next nref lref last post