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

[Benjamin Kaduk]

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