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