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

[Nicola Tuveri]

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
> >
> >