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