It's good to look at the life cycle of these decrypted objects but I don't think it will help a lot if we would do otherwise. Generally decrypting the part and using the decrypted result are not the same place. The decrypted info will be used and passed to elsewhere. We need a place to hold the result so keeping it in the relevant class is a natural place. The whole object will be end of life after the request is processed, as it's per request.
Regards, Kai -----Original Message----- From: Emmanuel Lécharny [mailto:[email protected]] Sent: Monday, January 04, 2016 5:39 AM To: [email protected] Subject: Re: AP-REP message Le 03/01/16 22:30, Emmanuel Lécharny a écrit : > Le 03/01/16 21:50, Emmanuel Lécharny a écrit : >> Hi, >> >> another class, another question ;-) >> >> (Note that this class is currently not used in Kerby (it will be at >> some point, as this message is sent back to the client as a response >> to a KRB-AP-REQ message when the mutual authent AP-Options is set).) >> >> We have a private EncAPRepPart encRepPart; filed defined. What is it >> good for ? I suspect it's colliding with the ENC_PART field... if so, >> can we get rid of it ? > s/filed/field/ > > Otherwise, same question for the AP-REQ message, field authenticator, > which sounds spurious to me. > Looking a bit forward in teh code, I think (AFAOU) that those two fields are used to store the decrypted version fo the field. And it sounds like a bad idea ! The Authenticator is decrypted elsewhere, and immediately used, then discarded. I don't think it's reasonnable to keep the decrypted version in a data structure for a long time (here, as long as the message instance will last.
