<div dir="auto">I could see reasons to vote negatively for such a resolution in generic terms if I was voting on it: often the OpenSSL apps are part of critical PKI procedures and scripts.<div dir="auto">Such scripts might very well rely on the fact that this or that openssl command does not return a failure exit status in certain cases even if it reports the failure in its output or that as a side effect of reporting a failure some output file is not produced or created empty.</div><div dir="auto">A breaking change in such context can be strategically very bad for the project, with unintentional negative publicity consequences.</div><div dir="auto">A one by one decision on the mailing list would ring more bells and potentially trigger feedback about things that are going to be broken we were not aware of, compared to a silent change in a PR based on the generic decision, that could either inform the vote to decide to adopt different technical solutions or make the new breaking behavior opt-in, or give an opportunity to give more visibility to a breaking change and adapt the critical scripts and procedures to the new behavior before mayhem happens. </div><div dir="auto"><br></div><div dir="auto">Also the formulating a decision with "error checks like this" (or a more formal text description) has the risk of being difficult to apply: it shifts the responsibility of deciding if the case is similar enough onto the reviewers of the individual PR. </div><div dir="auto"><br></div><div dir="auto">Anyway, I agree that general or specific there should be an OMC vote about this rather than an OTC vote: I'll drop my  OTC vote proposal and wait for a OMC resolution on the matter.</div><div dir="auto">Can someone from the OMC take the initiative to propose the OMC vote that they believe is the more appropriate and move this forward? (can that person also covert the OTC hold label I put on #13359 into an OMC hold label?) </div><div dir="auto"><br></div><div dir="auto"><br></div>Cheers, <div dir="auto"><br></div><div dir="auto">Nicola <br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Wed, Nov 11, 2020, 11:16 Dr Paul Dale <<a href="mailto:paul.dale@oracle.com">paul.dale@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">An OMC vote deeming that adding error checks like this are or are not considered breaking changes.<div><br></div><div>My view is that detecting an error condition and returning an error code is a bug fix rather than a breaking change.</div><div><br></div><div><br></div><div>Pauli<br><div>
<div dir="auto" style="word-wrap:break-word;line-break:after-white-space"><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">-- <br>Dr Paul Dale | Distinguished Architect | Cryptographic Foundations <br>Phone +61 7 3031 7217<br>Oracle Australia</div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br></div><br></div><br>
</div>
<div><br><blockquote type="cite"><div>On 11 Nov 2020, at 7:10 pm, Matt Caswell <<a href="mailto:matt@openssl.org" target="_blank" rel="noreferrer">matt@openssl.org</a>> wrote:</div><br><div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">I have no problem  with the proposal or the vote text. I only wonder</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">whether, as a breaking change an OMC vote is required? Or is an OTC vote</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">sufficient?</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">Matt</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline!important">On 10/11/2020 16:15, Nicola Tuveri wrote:</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">## 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://urldefense.com/v3/__https://github.com/openssl/openssl/issues/8435__;!!GqivPVa7Brio!Iiq8eSK65cKttwL_M-jL1JwQw-V9roGNZaxYAPw08zcLEiuEMvGtYPDvrBSYf2E$" target="_blank" rel="noreferrer">https://urldefense.com/v3/__https://github.com/openssl/openssl/issues/8435__;!!GqivPVa7Brio!Iiq8eSK65cKttwL_M-jL1JwQw-V9roGNZaxYAPw08zcLEiuEMvGtYPDvrBSYf2E$</a><span> </span>><br>[PR 13359]: <<a href="https://urldefense.com/v3/__https://github.com/openssl/openssl/pull/13359__;!!GqivPVa7Brio!Iiq8eSK65cKttwL_M-jL1JwQw-V9roGNZaxYAPw08zcLEiuEMvGtYPDvd5hDbWk$" target="_blank" rel="noreferrer">https://urldefense.com/v3/__https://github.com/openssl/openssl/pull/13359__;!!GqivPVa7Brio!Iiq8eSK65cKttwL_M-jL1JwQw-V9roGNZaxYAPw08zcLEiuEMvGtYPDvd5hDbWk$</a><span> </span>><br>[apps/pkey.c changes]:<br><<a href="https://urldefense.com/v3/__https://github.com/openssl/openssl/pull/13359/files*diff-810c047ab642e686cab85b16802e9190bbc9f2f9bfce8a55fb8d6b744caa9091__;Iw!!GqivPVa7Brio!Iiq8eSK65cKttwL_M-jL1JwQw-V9roGNZaxYAPw08zcLEiuEMvGtYPDv8zOO9ys$" target="_blank" rel="noreferrer">https://urldefense.com/v3/__https://github.com/openssl/openssl/pull/13359/files*diff-810c047ab642e686cab85b16802e9190bbc9f2f9bfce8a55fb8d6b744caa9091__;Iw!!GqivPVa7Brio!Iiq8eSK65cKttwL_M-jL1JwQw-V9roGNZaxYAPw08zcLEiuEMvGtYPDv8zOO9ys$</a><span> </span>></blockquote></div></blockquote></div><br></div></div></blockquote></div></div></div>