[OTC VOTE PROPOSAL] Fixing missing failure exit status is a bug fix

[Nicola Tuveri]

I just opened the vote using the latest version of the vote text
proposed in this thread.

Here is the link to the vote:
https://www.mail-archive.com/openssl-project@openssl.org/msg02286.html


Cheers,

Nicola

On Tue, Nov 24, 2020 at 10:29 PM Nicola Tuveri <nic.tuv at gmail.com> wrote:
>
> Off-list I received a suggestion to use "unhandled" (thanks again!).
>
> I am not sure about it (I actually originally discarded in my first
> draft of this proposal) because I am afraid that talking of "unhandled
> return value" from a function might be misinterpreted as cases in
> which we are ignoring the return value of a callee or in which we are
> not considering the whole set of possible return values.
>
> Anyway, now that I disclaimed my doubts about it, I would submit to
> your consideration this alternative to the original vote text:
>
>         In the context of the OpenSSL apps, we qualify as bug fixes the
>         changes to return a failure exit status when a called function
>         fails with an unhandled return value.
>         Even when these bug fixes change the apps behavior triggering
>         early exits (compared to previous versions of the apps), as bug
>         fixes, they do not qualify as behavior changes that require an
>         explicit OMC approval.
>
>
> Would this be preferable to the original proposal?
>
>
> Cheers,
>
> Nicola
>
> On Tue, Nov 24, 2020 at 7:33 PM Nicola Tuveri <nic.tuv at gmail.com> wrote:
> >
> > Uhm, thanks Kurt! I think you have a point here, "unrecoverably" might
> > be a poor choice.
> >
> > Do you have a proposal to qualify these cases in general? Or a better
> > way to rephrase it?
> >
> > I wasn't happy with "In the context of the OpenSSL apps, we qualify as
> > bug fixes the changes to return a failure exit status when a called
> > function fails." (i.e., omitting unrecoverably or a better term): it
> > is not uncommon to have function failures that are intended to be
> > handled, taking a different course of action.
> >
> >
> > @tjh, as the main driver of a more generic vote like this, do you have
> > a better vote text proposal?
> >
> >
> > Nicola
> >
> >
> > On Tue, Nov 24, 2020, 19:18 Kurt Roeckx <kurt at roeckx.be> wrote:
> > >
> > > On Tue, Nov 24, 2020 at 01:51:44PM +0200, Nicola Tuveri wrote:
> > > > Background
> > > > ----------
> > > >
> > > > This follows up on a [previous proposal] that was abandoned in favor of
> > > > an OMC vote on the behavior change introduced in [PR#13359].
> > > > Within today's OTC meeting this was further discussed with the attending
> > > > members that also sit in the OMC.
> > > >
> > > > The suggestion was to improve the separation of the OTC and OMC domains
> > > > here, by having a more generic OTC vote to qualify as bug fixes the
> > > > changes to let any OpenSSL app return an (early) failure exit status
> > > > when a called function fails.
> > > >
> > > > The idea is that, if we agree on this technical definition, then no OMC
> > > > vote to allow a behavior change in the apps would be required in
> > > > general, unless, on a case-by-case basis, the "OMC hold" process is
> > > > invoked for whatever reason on the specific bug fix, triggering the
> > > > usual OMC decision process.
> > > >
> > > > Proposed vote text
> > > > ------------------
> > > >
> > > >         In the context of the OpenSSL apps, we qualify as bug fixes the
> > > >         changes to return a failure exit status when a called function
> > > >         fails unrecoverably.
> > >
> > > I'm not sure the unrecoverably should be there. I think this was
> > > about verifying is a public or private key was valid. If such a
> > > function returns it's not valid, I don't call that an
> > > unrecoverable error. But I do expect the application to return an
> > > error exit code.
> > >
> > > An other example is s_client, which ignores verification errors by
> > > default. You can change that behaviour with -verify_return_error. If
> > > you do that, s_client will actually exit with return value 1 in case
> > > of a verification error.
> > >
> > >
> > > Kurt
> > >
> > >