That is a very good point I completely missed! Would you be available do "adopt" my vote and raise it as an OMC vote?
Nicola On Wed, Nov 11, 2020, 11:10 Matt Caswell <m...@openssl.org> wrote: > I have no problem with the proposal or the vote text. I only wonder > whether, as a breaking change an OMC vote is required? Or is an OTC vote > sufficient? > > Matt > > > On 10/11/2020 16:15, Nicola Tuveri wrote: > > ## Background > > > > As part of the discussion in [issue #8435], it was highlighted that both > > in 1.1.1 and master we are missing tests to validate decoded SM2 keys. > > The `openssl pkey -check` (or `pkey -pubcheck` to validate only the > > public key component) command allows to explicitly execute the > > validation checks, while on regular operations (e.g., using `pkeyutl` or > > `dgst`) no validation of the input keys is normally done (probably by > > design). > > > > In [PR 13359] I am adding new tests, using `openssl pkey -check` to > > validate specific key corner cases, for P-256 as an exemplar for EC keys > > and for SM2 keys. > > Unfortunately `openssl pkey -check` behavior currently shows the result > > of the validation only in the text output, so parsing of `stdout` would > > require measuring the test results. > > In the PR I am proposing to change the behavior of `openssl pkey` so > > that an early exit is triggered if `-check` or `-pubcheck` validation > > fails, exiting with a failure exit status: [apps/pkey.c changes]. > > > > This is a breaking change in the behavior of `openssl pkey` and the > > reason why I am planning to raise a vote to approve this change. > > > > Note that during our OTC meeting today it was proposed as an alternative > > to have a more generic vote on approving this kind of change in general > > for all similar situations across all the apps. > > While I am not opposed to such a decision, I am afraid having such a > > generic vote might be quite difficult: > > > > - I am not sure I can express in a clear and unambiguous what are the > > conditions to fall within "similar situations", making such a > > decision hard to execute in practical terms; > > - I personally cannot commit to execute such vote across all apps and > > all relevant conditions: doing so requires extensive review of the > > apps logic in parsing the CLI switches, of conformity with existing > > documentation and an exploration of existing use patterns in the user > > codebase to see what are the expectations and estimate the impact of > > such changes. It would also require writing an extensive battery of > > tests to ensure we behave as documented/expected across apps and CLI > > switches. > > - The amount of work to which we would commit after such a generic > > decision, and the impact it could have on the behavior consistency > > w.r.t. 3.0 and 1.1.1, would make me think such a decision is more in > > the realm of strategic objectives, for which an OMC vote would be more > > appropriate. > > > > For these reasons, at this time, I am opting to propose an OTC vote on > > the single case of the behavior change of `pkey -check`/`pkey -pubcheck` > > rather than a more generic one, and I will let others decide if a more > > generic vote is also required/appropriate and if it can be framed > > exclusively within the technical prerogatives of the OTC decision > > process. > > > > ## Proposed vote text > > > > Change the behavior of `pkey -check` > > and `pkey -pubcheck` in 3.0 to trigger an > > early exit if validation fails, returning a > > failure exit status to the parent process. > > > > --- > > > > Please leave feedback relevant to the proposed vote text and the scope > > of the vote. > > In absence of feedback I plan to open the actual vote in 24h. > > > > > > > > Cheers, > > > > Nicola > > > > --- > > > > [issue #8435]: <https://github.com/openssl/openssl/issues/8435> > > [PR 13359]: <https://github.com/openssl/openssl/pull/13359> > > [apps/pkey.c changes]: > > < > https://github.com/openssl/openssl/pull/13359/files#diff-810c047ab642e686cab85b16802e9190bbc9f2f9bfce8a55fb8d6b744caa9091 > > > > >