Does this separate thread connection need another as_req/rep pair?

[Chris Hecker]

I think was unclear.  I don't think there's a way to avoid a wasted
allocation here.  I'm happy to have separate keys per thread, but there are
three keyblocks allocated in this scenario:  there's the original, get
allocates a copy, set allocates a copy, then I have to free the one from
get because it's not used.  There should be a version of set that takes
ownership of the memory, I think.  Make sense?

Chris

On Sat, Jun 20, 2015 at 12:52 PM, Benjamin Kaduk <kaduk at mit.edu> wrote:

> On Sat, 13 Jun 2015, Chris Hecker wrote:
>
> >
> > Finally getting to this...
> >
> > > You might be able to make a new context and use
> > > krb5_auth_con_getsendsubkey(), krb5_auth_con_recvsubkey(),
> > > krb5_auth_con_setsendsubkey(), and krb5_auth_con_setrecvsubkey() to
> > > copy the keys. I don't think rd_priv and mk_priv use anything else in
> > > this configuration.
> >
> > I think I want the _k versions of the set functions, no?  It looks like
> > the gets malloc a block, so the sets can just set and ref it, right?
> > Hmm, no, it looks like create_key also copies the data.  Is there any
> > way to not do the wasted extra malloc?  It looks like krb5_key_st is
> > opaque, so I can't ref it and then use that to copy the keyblock even.
>
>  On May 8, 2015 8:41 AM, "Greg Hudson" <ghudson at mit.edu> wrote:
> % (Don't use the _k variants; they use reference counts rather than
> % copying, and krb5_keys are mutable and not internally locked..)
>
>
> > In other words, I want to get the keyblocks with the current API, but
> > then set the pointers without another call to krb5int_c_copy_keyblock.
> > I guess I could make a couple new APIs since this is all linked
> > statically in my app...
>
> See above.
>
> -Ben
>