Re: appl/simple/client/sim_client.c uses internal APIs

Thank you for your help regarding this matter. In the end, I could not fix the Authen::Krb5 Perl module because there are some fundamental reference counting problems in it. The code sort-of works today because it papers over these issues by using internal libkrb5 APIs, which I suspect happen to

Re: appl/simple/client/sim_client.c uses internal APIs

On 2/24/23 06:15, Florian Weimer wrote: I need to fix Authen::Krb5 (a Perl wrapper) not rely on this krb5 internals. Obviously, this is going to stay a krb5 wrapper, and won't switch to GSSAPI. So I'd really appreciate if someone would fix the appl/simple/client/sim_client.c example not to rely

Re: appl/simple/client/sim_client.c uses internal APIs

Simo Sorce writes: > On Fri, 2023-02-24 at 16:27 -0800, Russ Allbery wrote: >> Essentially everything that I don't like about GSSAPI is a direct >> consequence of the fact that it's a generic authentication protocol >> that in theory (although essentially never in practice outside of toys >> and

Re: appl/simple/client/sim_client.c uses internal APIs

On Fri, 2023-02-24 at 16:27 -0800, Russ Allbery wrote: > Essentially everything that I don't like about GSSAPI is a direct > consequence of the fact that it's a generic authentication protocol that > in theory (although essentially never in practice outside of toys and > science experiments) could

Re: appl/simple/client/sim_client.c uses internal APIs

On Fri, Feb 24, 2023 at 04:27:28PM -0800, Russ Allbery wrote: > Primarily what I'd want in a new mechanism is for it to be a protocol for > Kerberos authentication. (Or some other underlying authentication system > that we all use instead, although that would be off-topic for this group.) I'd set

Re: appl/simple/client/sim_client.c uses internal APIs

On Fri, Feb 24, 2023 at 04:27:28PM -0800, Russ Allbery wrote: > > (There is the other problem that all of the effort, hardware support, and > optimization work is going into TLS now, and it feels like a huge waste of > energy to try to compete with TLS in the secure transport business. But > that

Re: appl/simple/client/sim_client.c uses internal APIs

> "Ken" == Ken Hornstein via Kerberos writes: Ken> I can't argue your preference, and I'll be the first to admit Ken> that "simpler" can be subjective (although I would argue one Ken> metric, "lines of code", the krb5 API would win). But let me Ken> point out a few things:

Re: appl/simple/client/sim_client.c uses internal APIs

Nico Williams writes: > Which is why, for a new mechanism, I would much prefer that it support > Kerberos naming. Certainly I don't ever want to see a mechanism use > x.500 style naming again. Primarily what I'd want in a new mechanism is for it to be a protocol for Kerberos authentication. (O

Re: appl/simple/client/sim_client.c uses internal APIs

>As an alternative to the krb5 api, stick in the krb5 mechanism oid. >You can definitively design your protocol and implementation for a >single round trip by doing that. >You can have more code in common with applications that do support >multi-round-trip negotiations, while still getting your hal

Re: appl/simple/client/sim_client.c uses internal APIs

On Fri, Feb 24, 2023 at 05:57:22PM -0500, Ken Hornstein via Kerberos wrote: > I can't argue your preference, and I'll be the first to admit that > "simpler" can be subjective (although I would argue one metric, "lines > of code", the krb5 API would win). But let me point out a few things: Of cour

Re: appl/simple/client/sim_client.c uses internal APIs

Nico Williams writes: > RFC 7546 exists. Yes, I am well aware that this exists. If you can read this and come away thinking that the API that it describes is simpler than the krb5 API, I really don't know what to say. Perhaps GSSAPI reflects the way that you think more closely, so it seems sim

Re: appl/simple/client/sim_client.c uses internal APIs

>If you're using SPNEGO then you don't have to concern yourself with >negotiation. If you're implementing SSHv2 or SASL it's another story, >though not much more complicated because you're doing negotiation at a >layer that already does it and all you have to do is maybe pick a GSS >mechanism. > >

Re: appl/simple/client/sim_client.c uses internal APIs

On Fri, Feb 24, 2023 at 02:50:35PM -0600, Nico Williams wrote: > On Fri, Feb 24, 2023 at 12:19:53PM -0800, Russ Allbery wrote: > > Nico Williams writes: > > > If you're just trying to set up a GSS context between a client and a > > > server, then GSS is really simple, and much simpler than the krb

Re: appl/simple/client/sim_client.c uses internal APIs

On Fri, Feb 24, 2023 at 12:19:53PM -0800, Russ Allbery wrote: > Nico Williams writes: > > If you're just trying to set up a GSS context between a client and a > > server, then GSS is really simple, and much simpler than the krb5 API. > > I'm very dubious about this statement. The requirement to

Re: appl/simple/client/sim_client.c uses internal APIs

It has been a long time since I made this evaluation so I don’t remember the details, but I definitely do all sorts of stuff with ccaches and keytabs and profiles and threads and static linking and controlling memory allocations and controlling sockets and file usage and whatnot, it seemed like GSS

Re: appl/simple/client/sim_client.c uses internal APIs

Nico Williams writes: > If you're just trying to set up a GSS context between a client and a > server, then GSS is really simple, and much simpler than the krb5 API. I'm very dubious about this statement. The requirement to handle negotiation and potential multiple round trips and all the compl

Re: appl/simple/client/sim_client.c uses internal APIs

> "Florian" == Florian Weimer writes: Florian> The Perl translation is here: Florian> Florian> It's not an exact tranlation of the C because it creates a Florian> replay cache: Yeah, but it does

Re: appl/simple/client/sim_client.c uses internal APIs

On Fri, Feb 24, 2023 at 01:50:58PM -0500, Ken Hornstein via Kerberos wrote: > >I have said this before on the list and it’s not a very popular thing to > >say, but I program to the krb5 public API, and it is a nice and clean and > >performant and simple and portable and flexible API, and GSSAPI loo

Re: appl/simple/client/sim_client.c uses internal APIs

Sure, I agree with that rough breakdown, I just think the samples should show a hierarchy of techniques and show the flexibility, and be named appropriately. I mean, if a developer is thoughtless when using a crypto api then having messages be encrypted is not going to save them, so we need to ass

Re: appl/simple/client/sim_client.c uses internal APIs

> "Chris" == Chris Hecker writes: Chris> I guess if I’m on a tear saying forbidden things, sometimes Chris> identity is all you need, you don’t want all the samples to Chris> encrypt everything, because that makes it look like you have Chris> to, which you don’t? It is use-ca

Re: appl/simple/client/sim_client.c uses internal APIs

* Sam Hartman: >> "Florian" == Florian Weimer writes: > > Florian> * Sam Hartman: > >>> "Simo" == Simo Sorce writes: > >> > Simo> Wherever possible you should recommend people use GSSAPI and > Simo> not krb5 APIs directly, unless they are building tools > Simo> s

Re: appl/simple/client/sim_client.c uses internal APIs

>I guess if I’m on a tear saying forbidden things, sometimes identity is all >you need, you don’t want all the samples to encrypt everything, because >that makes it look like you have to, which you don’t? It is use-case >dependent, and krb5 is great because it is granular enough to let >developers

Re: appl/simple/client/sim_client.c uses internal APIs

I guess if I’m on a tear saying forbidden things, sometimes identity is all you need, you don’t want all the samples to encrypt everything, because that makes it look like you have to, which you don’t? It is use-case dependent, and krb5 is great because it is granular enough to let developers choo

Re: appl/simple/client/sim_client.c uses internal APIs

On 2/23/23 12:34, Sam Hartman wrote: I also think that the simple client referred to in the subject has a bunch of anti-patterns. As an example, I don't think it integrity protects or encrypts its exchanges I think appl/simple actually does protect messages but appl/sample does not. It looks l

Re: appl/simple/client/sim_client.c uses internal APIs

Yeah, by portable I meant I just compile the parts of krb5 client code I need when necessary. The krb5 client is very portable and fairly small. I strip out some stuff I don’t use, but not too much. Chris On Fri, Feb 24, 2023 at 11:51 Ken Hornstein wrote: > >I have said this before on the l

Re: appl/simple/client/sim_client.c uses internal APIs

>I have said this before on the list and it’s not a very popular thing to >say, but I program to the krb5 public API, and it is a nice and clean and >performant and simple and portable and flexible API, and GSSAPI looks like >none of those things, it looks like a mess to use (just from looking at i

Re: appl/simple/client/sim_client.c uses internal APIs

I have versions of both perl packages (krb5 and admin) that I work on locally and have assumed I’d contribute back at some point. It would be a shame to delete them from cpan, they work well after some fixes. I use my versions in production. I have said this before on the list and it’s not a ver

Re: appl/simple/client/sim_client.c uses internal APIs

> "Florian" == Florian Weimer writes: Florian> * Sam Hartman: >>> "Simo" == Simo Sorce writes: >> Simo> Wherever possible you should recommend people use GSSAPI and Simo> not krb5 APIs directly, unless they are building tools Simo> specifically to manage aspects

Re: appl/simple/client/sim_client.c uses internal APIs

* Sam Hartman: >> "Simo" == Simo Sorce writes: > > Simo> Wherever possible you should recommend people use GSSAPI and > Simo> not krb5 APIs directly, unless they are building tools > Simo> specifically to manage aspects of krb5 (acquiring tickets, > Simo> managing ccaches, etc

Re: appl/simple/client/sim_client.c uses internal APIs

> "Simo" == Simo Sorce writes: Simo> Wherever possible you should recommend people use GSSAPI and Simo> not krb5 APIs directly, unless they are building tools Simo> specifically to manage aspects of krb5 (acquiring tickets, Simo> managing ccaches, etc.) I agree with the above

Re: appl/simple/client/sim_client.c uses internal APIs

On Thu, 2023-02-23 at 10:20 +0100, Florian Weimer wrote: > The example program uses internal APIs not present in the public header > file (krb5_gen_portaddr, krb5_gen_replay_name; the THIS IS UGLY part). > Are there alternatives part of the public API? > > The issue here is that the example code h

appl/simple/client/sim_client.c uses internal APIs

The example program uses internal APIs not present in the public header file (krb5_gen_portaddr, krb5_gen_replay_name; the THIS IS UGLY part). Are there alternatives part of the public API? The issue here is that the example code has leaked outside of krb5 to other projects, and it only builds the