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 <k...@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 > >
