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 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos