On Fri, Apr 1, 2016 at 10:02 PM, Daniel Shahaf <danielsh_at_apache.org> wrote:
> Greg Stein wrote on Fri, Apr 01, 2016 at 04:38:00 -0500:
> > On Fri, Apr 1, 2016 at 12:36 AM, Daniel <danielsh_at_apache.org> 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
Received on 2016-04-02 07:25:17 CEST