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

[Nicola Tuveri]

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