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