subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: svn commit: r1735826 - in /subversion/trunk: ./ subversion/libsvn_subr/prompt.c
Date Sat, 02 Apr 2016 05:25:12 GMT
On Fri, Apr 1, 2016 at 10:02 PM, Daniel Shahaf <danielsh@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@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

Mime
View raw message