OMC Vote on deprecation of command line apps

PR 11575 has been blocking awaiting decision for a while now. Time for a vote: topic: Merge #11575 for 3.0. comment: This PR removes the notes indicating that a number of the command line utilities are deprecated. Not merging it will

Re: Unexpected EOF handling

On 07/05/2020 20:28, Dmitry Belyavsky wrote: > From my point of view, if we don't revert the change for the sake of API > clarity, we need to provide an option restoring old behaviour at least > for test purposes. Presumably nginx can already handle the situation where a close_notify *is*

Re: Some more extra tests

Dear Nicola, I feel a significant lack of knowledge of preparing such a PR. If I was able to submit it, I would. On Thu, May 7, 2020 at 10:38 PM Nicola Tuveri wrote: > I would be interested in seeing a PR to see what enabling these tests > would require! > > I believe we do indeed need to test

Re: Unexpected EOF handling

Hello, I want to draw everybody's attention to the position (and argumentation) of Nginx developers: === As already mentioned by Dmitry, we here at nginx don't think the change was necessary. As Matt already said above in the comments to SSL_CONF_cmd.pod change, the error was always

Some more extra tests

Dear colleagues, Let me draw your attention to a potentially reasonable set of extended tests for the openssl engines. The gost-engine project (https://github.com/gost-engine/engine) has some test scenarios robust enough for testing engine-provided algorithms and some basic RSA regression tests.

Monthly Status Report (April)

As well as normal reviews, responding to user queries, wiki user requests, OMC business, handling security reports, etc., key activities this month: - Ongoing review work on the CMP contribution - Fixed some issues with the XTS documentation - Updated WPACKET to be able to do "end first" writing

Re: Technically an API break

On 07/05/2020 16:02, Brian Smith wrote: > This kind of change might cause memory unsafety issues unless the > application is recompiled. At least, it's worth investigating that. > > On most platforms the ABI of a function that returns `void` and one that > returns `int` is the same, from the

Re: Technically an API break

Matt Caswell wrote: > PR11589 makes a change to the public API function > `SSL_set_record_padding_callback` to change its return type from void to > int: > > https://github.com/openssl/openssl/pull/11589 > > This is technically an API break - but it doesn't seem too serious. It's > possible, I

Re: Unexpected EOF handling

On Thu, 2020-05-07 at 15:45 +0200, Kurt Roeckx wrote: > On Thu, May 07, 2020 at 03:15:22PM +0200, Tomas Mraz wrote: > > Actually the coincidence is that the errno is set to 0 on EOF. So > > yes, > > we should explicitly clear the errno on EOF so any leftover value > > from > > previous calls does

Re: Unexpected EOF handling

On Thu, May 07, 2020 at 03:15:22PM +0200, Tomas Mraz wrote: > > Actually the coincidence is that the errno is set to 0 on EOF. So yes, > we should explicitly clear the errno on EOF so any leftover value from > previous calls does not affect this. On EOF, errno is normally not modified. It's

Re: Unexpected EOF handling

On Thu, 2020-05-07 at 14:53 +0200, Kurt Roeckx wrote: > On Thu, May 07, 2020 at 01:46:05PM +0200, Tomas Mraz wrote: > > From application developer side of view for protocols that do not > > depend on SSL detecting the truncation I think inventing a > > different > > behavior for this condition

Re: Unexpected EOF handling

On Thu, May 07, 2020 at 01:46:05PM +0200, Tomas Mraz wrote: > From application developer side of view for protocols that do not > depend on SSL detecting the truncation I think inventing a different > behavior for this condition than the existing one as of 1.1.1f would be > clearly wrong.

Re: Unexpected EOF handling

On Thu, 2020-05-07 at 12:47 +0100, Matt Caswell wrote: > > On 07/05/2020 12:22, Kurt Roeckx wrote: > > So I think we need at least to agree on: > > - Do we want an option that makes the unexpected EOF either a fatal > > error or a non-fatal error? > > - Which error should we return? > > This

Re: Unexpected EOF handling

On Thu, 2020-05-07 at 13:22 +0200, Kurt Roeckx wrote: > Hi, > > We introduced a change in the 1.1.1e release that changed how we > handled an unexpected EOF. This broke various software which > resulted in the release of 1.1.1f that reverted that change. > In master we still have the 1.1.1e

Re: Unexpected EOF handling

On 07/05/2020 12:22, Kurt Roeckx wrote: > So I think we need at least to agree on: > - Do we want an option that makes the unexpected EOF either a fatal > error or a non-fatal error? > - Which error should we return? This is an excellent summary of the current situation. I am not keen on

Unexpected EOF handling

Hi, We introduced a change in the 1.1.1e release that changed how we handled an unexpected EOF. This broke various software which resulted in the release of 1.1.1f that reverted that change. In master we still have the 1.1.1e behaviour. The change itself is small, it just calls SSLfatal() with a

Re: Technically an API break

On Thu, 07 May 2020 10:31:42 +0200, Tomas Mraz wrote: > > On Thu, 2020-05-07 at 09:24 +0100, Matt Caswell wrote: > > PR11589 makes a change to the public API function > > `SSL_set_record_padding_callback` to change its return type from void > > to > > int: > > > >

Re: Technically an API break

On Thu, 2020-05-07 at 09:24 +0100, Matt Caswell wrote: > PR11589 makes a change to the public API function > `SSL_set_record_padding_callback` to change its return type from void > to > int: > > https://github.com/openssl/openssl/pull/11589 > > This is technically an API break - but it doesn't

Technically an API break

PR11589 makes a change to the public API function `SSL_set_record_padding_callback` to change its return type from void to int: https://github.com/openssl/openssl/pull/11589 This is technically an API break - but it doesn't seem too serious. It's possible, I suppose, that existing applications