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