On Fri, Apr 1, 2016 at 10:02 PM, Daniel Shahaf <[email protected]> wrote:
> Greg Stein wrote on Fri, Apr 01, 2016 at 04:38:00 -0500: > > On Fri, Apr 1, 2016 at 12:36 AM, Daniel <[email protected]> wrote: > > > > > ... > > > However, if we make this change, API callers that depend on the > > > implemented (unpromised) behaviour — that is, API callers that assume > > > the output parameter will be initialized even on error returns — will > > > then decide whether to save the plaintext password to disk according to > > > the value of uninitialized memory. > > > > > > > no no no ... we've always said that OUT parameters are not dependable > when > > an error occurs. I see no reason to change here. > > I don't dispute that. We do not promise to initialize the value of an > output argument on error. > > > Especially no reason to claim an API change/errata. > > Suppose an API consumer's code assumes the output variable would be > initialized on error. (Yes, it is a bug for the API consumer to make > that assumption.) Making the change Julian suggested might cause users > of that API consumer to have their passwords stored in plain text on > disk.¹ I do not consider that an acceptable result of a code > simplification. > In this situation ... I would concur. The safe/conservative position is appropriate when we're talking about passwords. Very good point. Thx, -g
