From danm at prime.gushi.org Thu Oct 2 19:03:58 2025 From: danm at prime.gushi.org (Dan Mahoney) Date: Thu, 2 Oct 2025 16:03:58 -0700 Subject: Quick Q: Web-based password utility Message-ID: <1244567D-6083-4703-ACF3-4726F15C71E8@prime.gushi.org> Hey there folks, Quick Q for the dayjob. We have some non technical users, for whom ?Okay, now ssh in to this box and run these commands over ssh? are asking a bit much. Has anyone seen any sort of lightweight gui for doing simple things like password management (i.e. allow a user to change their password?) I don?t want a full keycloak-like thing, I just am looking for a web-based kpassword, effectively. -Dan From kenh at cmf.nrl.navy.mil Thu Oct 2 19:48:38 2025 From: kenh at cmf.nrl.navy.mil (Ken Hornstein) Date: Thu, 02 Oct 2025 19:48:38 -0400 Subject: Quick Q: Web-based password utility In-Reply-To: <1244567D-6083-4703-ACF3-4726F15C71E8@prime.gushi.org> References: <1244567D-6083-4703-ACF3-4726F15C71E8@prime.gushi.org> Message-ID: <202510022348.592NmcL7017214@hedwig.cmf.nrl.navy.mil> >Quick Q for the dayjob. We have some non technical users, for whom >?Okay, now ssh in to this box and run these commands over ssh? are >asking a bit much. Has anyone seen any sort of lightweight gui for >doing simple things like password management (i.e. allow a user to >change their password?) I don?t want a full keycloak-like thing, I >just am looking for a web-based kpassword, effectively. I am familiar with some things that do that, but they are homegrown applications; I am not aware of any open-source things to do that. It seems like it would be easy enough to code up. --Ken From jake at poptart.org Thu Oct 23 20:53:46 2025 From: jake at poptart.org (Jake Scott) Date: Thu, 23 Oct 2025 18:53:46 -0600 Subject: Golang GSSAPI spec Message-ID: 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! Jake From michael.osipov at innomotics.com Fri Oct 24 04:06:30 2025 From: michael.osipov at innomotics.com (Osipov, Michael (IN IT IN)) Date: Fri, 24 Oct 2025 10:06:30 +0200 Subject: Golang GSSAPI spec In-Reply-To: References: Message-ID: 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 would love some feedback before launching this on the world! It is > currently in beta, and the docs/code are at: > >... > 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. Hi Jake, this is a pleasant surprise to see this for Go as well. We've been using Go for some smaller projects at $work and it might get interesting/required, though my personal knowledge/understanding in/of Go is very limited. I have strong knowledge especially in Java (JGSS) and py-gssapi. I have a few questions/pointers for you: * 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? * 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. * You should not make the API public too soon, stuff like this takes time and will then set to stone. Every change can break people's stuff. * Since you support Apple Kerberos, see https://github.com/curl/curl/issues/19109. This might be interesting for you. * 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. * Being spoiled from the Python integration I want to ask you this: ** Does it easily plug into Go's URL transport library, e.g., py-requests-gssapi to authenticate via SPENGO? ** 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)? Thank you! PS: I truly like https://github.com/golang-auth/go-gssapi-c?tab=readme-ov-file#go-gssapi-c-bindings-provider you really did your homework. Kudos to your professionalism! From michael.osipov at innomotics.com Fri Oct 24 04:14:26 2025 From: michael.osipov at innomotics.com (Osipov, Michael (IN IT IN)) Date: Fri, 24 Oct 2025 10:14:26 +0200 Subject: Golang GSSAPI spec In-Reply-To: References: Message-ID: <3246238c-d4e2-4a72-a4fd-855ec9cfdbee@innomotics.com> 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 From simo at redhat.com Fri Oct 24 09:55:33 2025 From: simo at redhat.com (Simo Sorce) Date: Fri, 24 Oct 2025 09:55:33 -0400 Subject: Golang GSSAPI spec In-Reply-To: References: Message-ID: <5b4afe2c95b51ca01638de61749e8ef90c9af29b.camel@redhat.com> 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 From jake at poptart.org Fri Oct 24 18:28:26 2025 From: jake at poptart.org (Jake Scott) Date: Fri, 24 Oct 2025 16:28:26 -0600 Subject: Golang GSSAPI spec In-Reply-To: <5b4afe2c95b51ca01638de61749e8ef90c9af29b.camel@redhat.com> References: <5b4afe2c95b51ca01638de61749e8ef90c9af29b.camel@redhat.com> Message-ID: On Fri, Oct 24, 2025 at 7:55?AM Simo Sorce 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 From jake at poptart.org Fri Oct 24 19:13:53 2025 From: jake at poptart.org (Jake Scott) Date: Fri, 24 Oct 2025 17:13:53 -0600 Subject: Golang GSSAPI spec In-Reply-To: References: Message-ID: 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) < michael.osipov at innomotics.com> 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