[37098] in Kerberos
Re: Does this separate thread connection need another as_req/rep pair?
daemon@ATHENA.MIT.EDU (Benjamin Kaduk)
Sat Jun 20 15:53:04 2015
Date: Sat, 20 Jun 2015 15:52:49 -0400 (EDT)
From: Benjamin Kaduk <kaduk@mit.edu>
To: Chris Hecker <checker@d6.com>
In-Reply-To: <557BEBE3.40500@d6.com>
Message-ID: <alpine.GSO.1.10.1506201551300.22210@multics.mit.edu>
MIME-Version: 1.0
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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
