Re: 3.0 beta 1 milestone

2020-09-17 Thread Dmitry Belyavsky
Dear Matt,

I think #12891 is a significant problem. I'd suggest fixing it before beta1
or at least discuss it.

Many thanks!

On Thu, Sep 17, 2020 at 3:48 PM Matt Caswell  wrote:

> There's been quite a number of PRs added to the 3.0 beta 1 milestone.
>
> Within the PRs there are a couple of bug fixes:
>
> https://github.com/openssl/openssl/pull/12884
> https://github.com/openssl/openssl/pull/12874
>
> IMO these would be really nice to get into beta 1, but they should not
> be considered blockers for it (i.e. if they didn't go in, it shouldn't
> stop us from releasing beta 1).
>
> There are also some nice-to-have items:
>
> https://github.com/openssl/openssl/pull/12777
> https://github.com/openssl/openssl/pull/12771
> https://github.com/openssl/openssl/pull/12726
> https://github.com/openssl/openssl/pull/12669
> https://github.com/openssl/openssl/pull/12072
>
> Again - these are nice-to-have, and if they happen to get merged in time
> for beta 1 then great. Otherwise, they should wait for 3.1 (possibly
> things which are just cleanup/minor refactoring could still be done
> within the beta period). So, IMO, these should not be considered
> blockers either.
>
> So - this leads me to the question - what is the milestone for? Does it
> means these things *must* go in before we can release beta 1? Or does it
> mean we would *like* to get these things in for beta 1?
>
> I actually don't mind either way - but if its the latter, then I need a
> way of identifying the "must haves". These are the top priority items,
> and at the moment I can't easily track their progress.
>
> Matt
>
>
>

-- 
SY, Dmitry Belyavsky


Re: Beta1 PR deadline

2020-09-10 Thread Dmitry Belyavsky
Dear Kurt,

I have 3 regression bugs, but I hope they can be dealt with after beta1.

On Wed, Sep 9, 2020 at 3:03 PM Kurt Roeckx  wrote:

> On Wed, Aug 26, 2020 at 04:58:26PM +0100, Matt Caswell wrote:
> > Please can anyone with PRs that they wish to have included in OpenSSL
> > 3.0 beta1 ensure that they are merged to master by 8th September.
>
> So that date has passed now. Can someone give an overview of what
> we think is still needed to be done before the beta 1 release? Are
> there open PRs for everything? Do we a milestone on github to
> indicate which PRs need to go in before beta1?
>
>
> Kurt
>
>

-- 
SY, Dmitry Belyavsky


Re: More GitHub labels

2020-09-10 Thread Dmitry Belyavsky
On Thu, Sep 10, 2020 at 9:20 AM Dr. Matthias St. Pierre <
matthias.st.pie...@ncp-e.com> wrote:

> > ... I think we should change that. This does not mean that a reviewer
> who made a change request
> > two months ago and lost interest is forced to re-review, only that such
> stale reviews must be dismissed
> > explicitly, if the reviewer does not respond to a re-review request
> within a certain time period.
>
> I would refine this procedure as follows: the team member who intends to
> do the merge (the "merger"),
> needs to issue re-review requests for all unresolved change requests
> (there is a spinning button next the
> name of the reviewer to do this). The person who receives the re-review
> request can either dismiss its
> review or indicate that it intends to review within x hours. Otherwise,
> the merger can dismiss the stale review.
>
> Sorry, it seems a bit overengineering for me.
I'd prefer a procedure with explicit hold and explanation in the comments.

-- 
SY, Dmitry Belyavsky


Re: OpenSSL Security Advisory

2020-09-09 Thread Dmitry Belyavsky
Many thanks!

On Wed, Sep 9, 2020 at 4:16 PM Mark J Cox  wrote:

> I just spotted it via twitter, https://raccoon-attack.com/
>
> Mark
>
> On Wed, Sep 9, 2020 at 2:08 PM Dmitry Belyavsky  wrote:
> >
> > Could you please let me know when it is available?
> >
> > On Wed, Sep 9, 2020 at 3:51 PM Mark J Cox  wrote:
> >>
> >> They should be releasing their paper very soon (today).
> >>
> >> Regards, Mark
> >>
> >> On Wed, Sep 9, 2020 at 1:45 PM Dmitry Belyavsky 
> wrote:
> >> >
> >> > Is the description of the attack publicly available?
> >> >
> >> > On Wed, Sep 9, 2020 at 3:39 PM OpenSSL  wrote:
> >> >>
> >> >> -BEGIN PGP SIGNED MESSAGE-
> >> >> Hash: SHA512
> >> >>
> >> >> OpenSSL Security Advisory [09 September 2020]
> >> >> =
> >> >>
> >> >> Raccoon Attack (CVE-2020-1968)
> >> >> ==
> >> >>
> >> >> Severity: Low
> >> >>
> >> >> The Raccoon attack exploits a flaw in the TLS specification which
> can lead to
> >> >> an attacker being able to compute the pre-master secret in
> connections which
> >> >> have used a Diffie-Hellman (DH) based ciphersuite. In such a case
> this would
> >> >> result in the attacker being able to eavesdrop on all encrypted
> communications
> >> >> sent over that TLS connection. The attack can only be exploited if an
> >> >> implementation re-uses a DH secret across multiple TLS connections.
> Note that
> >> >> this issue only impacts DH ciphersuites and not ECDH ciphersuites.
> >> >>
> >> >> OpenSSL 1.1.1 is not vulnerable to this issue: it never reuses a DH
> secret and
> >> >> does not implement any "static" DH ciphersuites.
> >> >>
> >> >> OpenSSL 1.0.2f and above will only reuse a DH secret if a "static" DH
> >> >> ciphersuite is used. These static "DH" ciphersuites are ones that
> start with the
> >> >> text "DH-" (for example "DH-RSA-AES256-SHA"). The standard IANA
> names for these
> >> >> ciphersuites all start with "TLS_DH_" but excludes those that start
> with
> >> >> "TLS_DH_anon_".
> >> >>
> >> >> OpenSSL 1.0.2e and below would reuse the DH secret across multiple
> TLS
> >> >> connections in server processes unless the SSL_OP_SINGLE_DH_USE
> option was
> >> >> explicitly configured. Therefore all ciphersuites that use DH in
> servers
> >> >> (including ephemeral DH) are vulnerable in these versions. In
> OpenSSL 1.0.2f
> >> >> SSL_OP_SINGLE_DH_USE was made the default and it could not be turned
> off as a
> >> >> response to CVE-2016-0701.
> >> >>
> >> >> Since the vulnerability lies in the TLS specification, fixing the
> affected
> >> >> ciphersuites is not viable. For this reason 1.0.2w moves the affected
> >> >> ciphersuites into the "weak-ssl-ciphers" list. Support for the
> >> >> "weak-ssl-ciphers" is not compiled in by default. This is unlikely
> to cause
> >> >> interoperability problems in most cases since use of these
> ciphersuites is rare.
> >> >> Support for the "weak-ssl-ciphers" can be added back by configuring
> OpenSSL at
> >> >> compile time with the "enable-weak-ssl-ciphers" option. This is not
> recommended.
> >> >>
> >> >> OpenSSL 1.0.2 is out of support and no longer receiving public
> updates.
> >> >>
> >> >> Premium support customers of OpenSSL 1.0.2 should upgrade to
> 1.0.2w.  If
> >> >> upgrading is not viable then users of OpenSSL 1.0.2v or below should
> ensure
> >> >> that affected ciphersuites are disabled through runtime
> configuration. Also
> >> >> note that the affected ciphersuites are only available on the server
> side if a
> >> >> DH certificate has been configured. These certificates are very
> rarely used and
> >> >> for this reason this issue has been classified as LOW severity.
> >> >>
> >> >> This issue was found by Robert Merget, Marcus Brinkmann, Nimrod
> Aviram and Juraj
> >> >> Somorovsky and report

Re: OpenSSL Security Advisory

2020-09-09 Thread Dmitry Belyavsky
Could you please let me know when it is available?

On Wed, Sep 9, 2020 at 3:51 PM Mark J Cox  wrote:

> They should be releasing their paper very soon (today).
>
> Regards, Mark
>
> On Wed, Sep 9, 2020 at 1:45 PM Dmitry Belyavsky  wrote:
> >
> > Is the description of the attack publicly available?
> >
> > On Wed, Sep 9, 2020 at 3:39 PM OpenSSL  wrote:
> >>
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA512
> >>
> >> OpenSSL Security Advisory [09 September 2020]
> >> =
> >>
> >> Raccoon Attack (CVE-2020-1968)
> >> ==
> >>
> >> Severity: Low
> >>
> >> The Raccoon attack exploits a flaw in the TLS specification which can
> lead to
> >> an attacker being able to compute the pre-master secret in connections
> which
> >> have used a Diffie-Hellman (DH) based ciphersuite. In such a case this
> would
> >> result in the attacker being able to eavesdrop on all encrypted
> communications
> >> sent over that TLS connection. The attack can only be exploited if an
> >> implementation re-uses a DH secret across multiple TLS connections.
> Note that
> >> this issue only impacts DH ciphersuites and not ECDH ciphersuites.
> >>
> >> OpenSSL 1.1.1 is not vulnerable to this issue: it never reuses a DH
> secret and
> >> does not implement any "static" DH ciphersuites.
> >>
> >> OpenSSL 1.0.2f and above will only reuse a DH secret if a "static" DH
> >> ciphersuite is used. These static "DH" ciphersuites are ones that start
> with the
> >> text "DH-" (for example "DH-RSA-AES256-SHA"). The standard IANA names
> for these
> >> ciphersuites all start with "TLS_DH_" but excludes those that start with
> >> "TLS_DH_anon_".
> >>
> >> OpenSSL 1.0.2e and below would reuse the DH secret across multiple TLS
> >> connections in server processes unless the SSL_OP_SINGLE_DH_USE option
> was
> >> explicitly configured. Therefore all ciphersuites that use DH in servers
> >> (including ephemeral DH) are vulnerable in these versions. In OpenSSL
> 1.0.2f
> >> SSL_OP_SINGLE_DH_USE was made the default and it could not be turned
> off as a
> >> response to CVE-2016-0701.
> >>
> >> Since the vulnerability lies in the TLS specification, fixing the
> affected
> >> ciphersuites is not viable. For this reason 1.0.2w moves the affected
> >> ciphersuites into the "weak-ssl-ciphers" list. Support for the
> >> "weak-ssl-ciphers" is not compiled in by default. This is unlikely to
> cause
> >> interoperability problems in most cases since use of these ciphersuites
> is rare.
> >> Support for the "weak-ssl-ciphers" can be added back by configuring
> OpenSSL at
> >> compile time with the "enable-weak-ssl-ciphers" option. This is not
> recommended.
> >>
> >> OpenSSL 1.0.2 is out of support and no longer receiving public updates.
> >>
> >> Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2w.  If
> >> upgrading is not viable then users of OpenSSL 1.0.2v or below should
> ensure
> >> that affected ciphersuites are disabled through runtime configuration.
> Also
> >> note that the affected ciphersuites are only available on the server
> side if a
> >> DH certificate has been configured. These certificates are very rarely
> used and
> >> for this reason this issue has been classified as LOW severity.
> >>
> >> This issue was found by Robert Merget, Marcus Brinkmann, Nimrod Aviram
> and Juraj
> >> Somorovsky and reported to OpenSSL on 28th May 2020 under embargo in
> order to
> >> allow co-ordinated disclosure with other implementations.
> >>
> >> Note
> >> 
> >>
> >> OpenSSL 1.0.2 is out of support and no longer receiving public updates.
> Extended
> >> support is available for premium support customers:
> >> https://www.openssl.org/support/contracts.html
> >>
> >> OpenSSL 1.1.0 is out of support and no longer receiving updates of any
> kind.
> >> The impact of this issue on OpenSSL 1.1.0 has not been analysed.
> >>
> >> Users of these versions should upgrade to OpenSSL 1.1.1.
> >>
> >> References
> >> ==
> >>
> >> URL for this Security Advisory:
> &

Re: OpenSSL Security Advisory

2020-09-09 Thread Dmitry Belyavsky
Is the description of the attack publicly available?

On Wed, Sep 9, 2020 at 3:39 PM OpenSSL  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> OpenSSL Security Advisory [09 September 2020]
> =
>
> Raccoon Attack (CVE-2020-1968)
> ==
>
> Severity: Low
>
> The Raccoon attack exploits a flaw in the TLS specification which can lead
> to
> an attacker being able to compute the pre-master secret in connections
> which
> have used a Diffie-Hellman (DH) based ciphersuite. In such a case this
> would
> result in the attacker being able to eavesdrop on all encrypted
> communications
> sent over that TLS connection. The attack can only be exploited if an
> implementation re-uses a DH secret across multiple TLS connections. Note
> that
> this issue only impacts DH ciphersuites and not ECDH ciphersuites.
>
> OpenSSL 1.1.1 is not vulnerable to this issue: it never reuses a DH secret
> and
> does not implement any "static" DH ciphersuites.
>
> OpenSSL 1.0.2f and above will only reuse a DH secret if a "static" DH
> ciphersuite is used. These static "DH" ciphersuites are ones that start
> with the
> text "DH-" (for example "DH-RSA-AES256-SHA"). The standard IANA names for
> these
> ciphersuites all start with "TLS_DH_" but excludes those that start with
> "TLS_DH_anon_".
>
> OpenSSL 1.0.2e and below would reuse the DH secret across multiple TLS
> connections in server processes unless the SSL_OP_SINGLE_DH_USE option was
> explicitly configured. Therefore all ciphersuites that use DH in servers
> (including ephemeral DH) are vulnerable in these versions. In OpenSSL
> 1.0.2f
> SSL_OP_SINGLE_DH_USE was made the default and it could not be turned off
> as a
> response to CVE-2016-0701.
>
> Since the vulnerability lies in the TLS specification, fixing the affected
> ciphersuites is not viable. For this reason 1.0.2w moves the affected
> ciphersuites into the "weak-ssl-ciphers" list. Support for the
> "weak-ssl-ciphers" is not compiled in by default. This is unlikely to cause
> interoperability problems in most cases since use of these ciphersuites is
> rare.
> Support for the "weak-ssl-ciphers" can be added back by configuring
> OpenSSL at
> compile time with the "enable-weak-ssl-ciphers" option. This is not
> recommended.
>
> OpenSSL 1.0.2 is out of support and no longer receiving public updates.
>
> Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2w.  If
> upgrading is not viable then users of OpenSSL 1.0.2v or below should ensure
> that affected ciphersuites are disabled through runtime configuration. Also
> note that the affected ciphersuites are only available on the server side
> if a
> DH certificate has been configured. These certificates are very rarely
> used and
> for this reason this issue has been classified as LOW severity.
>
> This issue was found by Robert Merget, Marcus Brinkmann, Nimrod Aviram and
> Juraj
> Somorovsky and reported to OpenSSL on 28th May 2020 under embargo in order
> to
> allow co-ordinated disclosure with other implementations.
>
> Note
> 
>
> OpenSSL 1.0.2 is out of support and no longer receiving public updates.
> Extended
> support is available for premium support customers:
> https://www.openssl.org/support/contracts.html
>
> OpenSSL 1.1.0 is out of support and no longer receiving updates of any
> kind.
> The impact of this issue on OpenSSL 1.1.0 has not been analysed.
>
> Users of these versions should upgrade to OpenSSL 1.1.1.
>
> References
> ==
>
> URL for this Security Advisory:
> https://www.openssl.org/news/secadv/20200909.txt
>
> Note: the online version of the advisory may be updated with additional
> details
> over time.
>
> For details of OpenSSL severity classifications please see:
> https://www.openssl.org/policies/secpolicy.html
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEeVOsH7w9yLOykjk+1enkP3357owFAl9YzBsACgkQ1enkP335
> 7oyIxg/9FWuca3/s/lY6g6a5VTPIekZMOLRUnDyzS3YePQu/sEd1w81mKoTqU+6F
> KQmliGqdRDk+KN8HDVd14kcLBukto8UKmkp9FpB5J4d2KK1I/Fg/DofJs6xUQYKb
> 5rHRLB3DDoyHEBzEEIjcqYTTThXW9ZSByVK9SKpC78IRM/B2dfd0+j4hIB/kDC/E
> G+wieFzexHQVdleVYT/VaJ6qS8AwvohBbt8h7yK0P6v/4vEm0spDbUmjWJBVUlUu
> QZyELjj8XZR3YFxt3axSuJg3JSGYlaMzkt2+DVq4qEzeJLIydLK9J8p6RNwPhsJk
> Rx0ez8P4N+5O7XmA0nHv3HyompdMgHlvykj8Ks4lNHVS02KKLi1jDtmOxl3Fm/hb
> ZNOmjn7lulV1342pw4rWL3Nge3x0s0Q5zgBCm1mqLzzu/V1ksx8FJwGA1w2cH280
> dU9VedkC2wvFQije8pFrWH9l6N9Bh41DIEOnlBl0AL7IrbPdO6yMcD6vpR7hWjr3
> fx4hNJSAGzJ3i/NXlSj4eR/47zkjfJyEc8Drc2QgewyqXFrK20X/LOj8MqJlc+ry
> pXZseh+XC8WaYDMV1ltrKvE2Ld9/0f3Ydc04AcDeu5SXPJG79ogzVnchZok7+XCj
> RT+a3/ES45+CTfL5v27t5QJxJcxg4siLVsILfi0rIUv0IYgH2fU=
> =U7OO
> -END PGP SIGNATURE-
>


-- 
SY, Dmitry Belyavsky


My vacation

2020-07-23 Thread Dmitry Belyavsky
Hello,

I go on my vacation from July 24 to August 5. On vacation, my internet
access is very limited.
If you have smth urgent, please let me know via direct email.

Many thanks!
-- 
SY, Dmitry Belyavsky


Detecting Bad OpenSSL Usage

2020-05-31 Thread Dmitry Belyavsky
Hello,

Here is a nice article about a tool desired to catch misuse of the OpenSSL
API.

https://blog.trailofbits.com/2020/05/29/detecting-bad-openssl-usage/

I'm not sure whether it's worth using by the team but maybe it's worth
mentioning in OpenSSL Wiki.

-- 
SY, Dmitry Belyavsky


Re: Unexpected EOF handling

2020-05-11 Thread Dmitry Belyavsky
Dear Tomas,

On Mon, May 11, 2020 at 2:07 PM Tomas Mraz  wrote:

> On Fri, 2020-05-08 at 12:09 +0200, Kurt Roeckx wrote:
> > On Thu, May 07, 2020 at 02:31:24PM +0200, Tomas Mraz wrote:
> > > 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 is an excellent summary of the current situation.
> > > >
> > > > I am not keen on maintaining the SSL_ERROR_SYSCALL with 0 errno
> > > > as a
> > > > long term solution. It's a very confusing API for new
> > > > applications to
> > > > use. Effectively it means SSL_ERROR_SYSCALL is a fatal error -
> > > > except
> > > > when its not. SSL_ERROR_SYSCALL should mean fatal error.
> > > >
> > > > That said I also recognise that it is apparently commonplace to
> > > > shut
> > > > down a TLS connection without sending close_notify - despite what
> > > > the
> > > > standards may say about it (and TBH we can hardly claim the moral
> > > > high
> > > > ground here since s_server does exactly this - or at least it
> > > > does in
> > > > 1.1.1 and did until very recently in master).
> > > >
> > > > But we do have to consider usages beyond HTTPS. I have no idea if
> > > > this
> > > > occurs in other settings or not.
> > > >
> > > > Perhaps what we need is an option for "strict shutdown". With
> > > > strict
> > > > shutdown "off" we could treat EOF as if we had received a
> > > > close_notify
> > > > gracefully (and don't invalidate the session). Presumably
> > > > existing
> > > > code
> > > > would be able to cope with that???
> > >
> > > Yes, existing code would be able to cope with that with one
> > > important
> > > exception that I am going to talk about below.
> > >
> > > > With strict shutdown "on" we treat it as SSL_ERROR_SSL (as now in
> > > > master).
> > > >
> > > > I'm not sure though what the default should be.
> > >
> > > In case we go with this solution, which would be acceptable I
> > > think, we
> > > MUST NOT EVER make it the default because existing applications
> > > that
> > > depend on the existing way how the unclean EOF condition is
> > > returned
> > > might actually depend on it to detect the truncation attack.
> >
> > I agree that we should not return SSL_ERROR_ZERO_RETURN by default
> > on an unexpected EOF.
> >
> > If the default behaviour should be to make it a non-fatal error,
> > like the old behaviour is, I would really prefer a different
> > error, one that's not SSL_ERROR_SYSCALL or SSL_ERROR_SSL.
> >
> > So I think the suggestion is to have this:
> > - By default, SSL_ERROR_SSL is returned with
> >   SSL_R_UNEXPECTED_EOF_WHILE_READING, the session will be
> >   marked invalid.
> > - With an option, SSL_ERROR_ZERO_RETURN is returned, the session
> >   will stay valid.
>
> +1
>
> And my suggestion for the SSL_OP name is SSL_OP_IGNORE_UNEXPECTED_EOF.
>
> Dmitry, I think this solution should be working well for nginx and
> similar http related applications. They just need to use the
> SSL_OP_IGNORE_UNEXPECTED_EOF and the peers that do not properly
> terminate the TLS session will just appear as if they properly
> terminated it.
>

I'm not sure this is the best possible solution because it makes the
application developers doing extra compile-time checks.

But anyway, is it a final decision and the patch can be amended or we are
waiting for objections some more time?

-- 
SY, Dmitry Belyavsky


Re: Some more extra tests

2020-05-11 Thread Dmitry Belyavsky
Dear Nicola,

Please see https://github.com/openssl/openssl/pull/11792

It currently does not enable TCL and Perl tests, but the C tests also
helped me to find regression in the master branch.

On Thu, May 7, 2020 at 10:55 PM Dmitry Belyavsky  wrote:

> 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 more thoroughly to ensure we are not
>> breaking the engine API!
>>
>>
>> Nicola
>>
>> On Thu, May 7, 2020, 21:08 Dmitry Belyavsky  wrote:
>>
>>> 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. It contains a rather eclectic set of
>>> C, Perl, and TCL(!) tests that are used by me on a regular basis.
>>>
>>> If these tests are included in the project extended test suite, they
>>> could reduce some regression that sometimes occurs (see
>>> https://github.com/gost-engine/engine/issues/232 as a current list of
>>> known problems).
>>>
>>> I will be happy to assist in enabling these tests as a part of openssl
>>> test suites.
>>> Many thanks!
>>>
>>> --
>>> SY, Dmitry Belyavsky
>>>
>>
>
> --
> SY, Dmitry Belyavsky
>


-- 
SY, Dmitry Belyavsky


Re: Alpha2

2020-05-08 Thread Dmitry Belyavsky
Dear Matt,

The workaround for the 11763 is implemented, 11764 seems to be fixed now,
so no objections from my side.
Happy weekend!

On Fri, May 8, 2020 at 11:58 AM Dmitry Belyavsky  wrote:

> Dear Matt,
>
> I kindly ask not to make release until issues raised in #11763 and #11764
> are fixed.
>
> On Fri, May 8, 2020 at 11:55 AM Matt Caswell  wrote:
>
>> Various OpenSSL 3.0 developers met (virtually) on Tuesday to discuss
>> current progress. It was proposed that we should do the Alpha 2 release
>> next week (on Thursday 14th May). Unless I hear objections otherwise, I
>> plan to go with that.
>>
>> Matt
>>
>
>
> --
> SY, Dmitry Belyavsky
>


-- 
SY, Dmitry Belyavsky


Re: Unexpected EOF handling

2020-05-08 Thread Dmitry Belyavsky
Dear Kurt

On Fri, May 8, 2020 at 1:10 PM Kurt Roeckx  wrote:

> On Thu, May 07, 2020 at 02:31:24PM +0200, Tomas Mraz wrote:
> > 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 is an excellent summary of the current situation.
> > >
> > > I am not keen on maintaining the SSL_ERROR_SYSCALL with 0 errno as a
> > > long term solution. It's a very confusing API for new applications to
> > > use. Effectively it means SSL_ERROR_SYSCALL is a fatal error - except
> > > when its not. SSL_ERROR_SYSCALL should mean fatal error.
> > >
> > > That said I also recognise that it is apparently commonplace to shut
> > > down a TLS connection without sending close_notify - despite what the
> > > standards may say about it (and TBH we can hardly claim the moral
> > > high
> > > ground here since s_server does exactly this - or at least it does in
> > > 1.1.1 and did until very recently in master).
> > >
> > > But we do have to consider usages beyond HTTPS. I have no idea if
> > > this
> > > occurs in other settings or not.
> > >
> > > Perhaps what we need is an option for "strict shutdown". With strict
> > > shutdown "off" we could treat EOF as if we had received a
> > > close_notify
> > > gracefully (and don't invalidate the session). Presumably existing
> > > code
> > > would be able to cope with that???
> >
> > Yes, existing code would be able to cope with that with one important
> > exception that I am going to talk about below.
> >
> > > With strict shutdown "on" we treat it as SSL_ERROR_SSL (as now in
> > > master).
> > >
> > > I'm not sure though what the default should be.
> >
> > In case we go with this solution, which would be acceptable I think, we
> > MUST NOT EVER make it the default because existing applications that
> > depend on the existing way how the unclean EOF condition is returned
> > might actually depend on it to detect the truncation attack.
>
> I agree that we should not return SSL_ERROR_ZERO_RETURN by default
> on an unexpected EOF.
>
> If the default behaviour should be to make it a non-fatal error,
> like the old behaviour is, I would really prefer a different
> error, one that's not SSL_ERROR_SYSCALL or SSL_ERROR_SSL.
>
> So I think the suggestion is to have this:
> - By default, SSL_ERROR_SSL is returned with
>   SSL_R_UNEXPECTED_EOF_WHILE_READING, the session will be
>   marked invalid.
> - With an option, SSL_ERROR_ZERO_RETURN is returned, the session
>   will stay valid.
>

If I remember correctly, session resumption is a way to significantly
reduce a server's workload.
So I think that by default (and maybe the only option) we should prefer the
old behaviour.

-- 
SY, Dmitry Belyavsky


Re: Alpha2

2020-05-08 Thread Dmitry Belyavsky
Dear Matt,

I kindly ask not to make release until issues raised in #11763 and #11764
are fixed.

On Fri, May 8, 2020 at 11:55 AM Matt Caswell  wrote:

> Various OpenSSL 3.0 developers met (virtually) on Tuesday to discuss
> current progress. It was proposed that we should do the Alpha 2 release
> next week (on Thursday 14th May). Unless I hear objections otherwise, I
> plan to go with that.
>
> Matt
>


-- 
SY, Dmitry Belyavsky


Re: Some more extra tests

2020-05-07 Thread Dmitry Belyavsky
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 more thoroughly to ensure we are not
> breaking the engine API!
>
>
> Nicola
>
> On Thu, May 7, 2020, 21:08 Dmitry Belyavsky  wrote:
>
>> 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. It contains a rather eclectic set of C,
>> Perl, and TCL(!) tests that are used by me on a regular basis.
>>
>> If these tests are included in the project extended test suite, they
>> could reduce some regression that sometimes occurs (see
>> https://github.com/gost-engine/engine/issues/232 as a current list of
>> known problems).
>>
>> I will be happy to assist in enabling these tests as a part of openssl
>> test suites.
>> Many thanks!
>>
>> --
>> SY, Dmitry Belyavsky
>>
>

-- 
SY, Dmitry Belyavsky


Re: Unexpected EOF handling

2020-05-07 Thread Dmitry Belyavsky
ted EOF either a fatal
> >   error or a non-fatal error?
> > - Which error should we return?
>
> 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. Switching on a SSL_OP if that newly provided OP is a
> trivial change to an application that needs to accommodate various
> versions of OpenSSL (and I am not talking about forks), however
> switching on a SSL_OP and also add another special error case is much
> more complicated change and has potential for bringing regressions in
> the applications that need to do it.
>
> It is also an API break, however we would do it anyway unless we make
> the legacy behavior the default one, so that is not really relevant
> here.
>
> Is there really another situation where SSL_ERROR_SYSCALL with errno 0
> could be returned apart from the unclean EOF condition?
>
> I can't really think of any.
>
> So I would be just for properly documenting the condition and keeping
> it as is if the SSL_OP to ignore unclean EOF is in effect.
>
> --
> Tomáš Mráz
> No matter how far down the wrong road you've gone, turn back.
>   Turkish proverb
> [You'll know whether the road is wrong if you carefully listen to your
> conscience.]
>
>
>

-- 
SY, Dmitry Belyavsky


Some more extra tests

2020-05-07 Thread Dmitry Belyavsky
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. It contains a rather eclectic set of C,
Perl, and TCL(!) tests that are used by me on a regular basis.

If these tests are included in the project extended test suite, they could
reduce some regression that sometimes occurs (see
https://github.com/gost-engine/engine/issues/232 as a current list of known
problems).

I will be happy to assist in enabling these tests as a part of openssl test
suites.
Many thanks!

-- 
SY, Dmitry Belyavsky


Re: Stale PR stats @May01

2020-05-01 Thread Dmitry Belyavsky
On Fri, May 1, 2020 at 6:19 PM Mark J Cox  wrote:

> On Fri, May 1, 2020 at 3:30 PM Dmitry Belyavsky  wrote:
> ..
> > And I also got an idea that ping comment leaves PRs out of this
> statistics :)
>
> Thanks!  The script is designed to ignore the automated pings that it
> creates itself so they themselves don't reset the dates and
> artificially stop things being stale.  Instead they will hopefully
> nudge folks into taking some action that will actually stop the PRs
> being stale :))
>

Well, I see some Catch-22 elements here...

-- 
SY, Dmitry Belyavsky


Re: Stale PR stats @May01

2020-05-01 Thread Dmitry Belyavsky
862  days:330
> 8835  days:370
> 8743 branch: master,  days:381
> 8668  days:392
> 8455  days:394
> 8420  days:395
> 8333  days:430
> 8309 branch: master, reviewed:commented days:316
> 8024 reviewed:commented days:81
> 7688  days:516
> 7615  days:520
> 7454 reviewed:commented days:471
> 7274 reviewed:approved days:322
> 7225 reviewed:commented days:587
> 6725 milestone:Assessed, reviewed:approved days:330
> 6518 milestone:Assessed, reviewed:approved days:681
> 6516 branch: 1.1.1, branch: master, milestone:Assessed,  days:681
> 6448 milestone:Assessed,  days:188
> 6219 milestone:Assessed, reviewed:approved days:719
> 5427 branch: master, milestone:Assessed, reviewed:commented days:481
> 4487 milestone:Assessed,  days:658
>


-- 
SY, Dmitry Belyavsky


Re: Deprecating misleading GOST names

2020-03-30 Thread Dmitry Belyavsky
Dear Hubert,

Done:
https://github.com/openssl/openssl/pull/11440

On Fri, Mar 20, 2020 at 6:27 PM Hubert Kario  wrote:

> On Friday, 20 March 2020 13:17:48 CET, Dmitry Belyavsky wrote:
> > Hello,
> >
> > I came across wrong naming for some GOST-related stuff in object.txt. As
> > all this stuff was introduced by me, it's a separate problem.
> >
> > First, I've erroneously translated the name of the Russian "Кузнечик"
> > algorithm as "grasshopper" instead of transliterating it as 'kuznyechik".
> > The transliteration has appeared as an official after the changes were
> > accepted into openssl.
> >
> > Second, some other algorithm and parameter names were introduced with
> their
> > official names instead of reasonable short names. When they are used in
> the
> > command line applications, it's very inconvenient.
> >
> > I'd like to fix these issues in the upcoming 3.0 release, so any ideas
> > about how to deal with it are welcome. Some of this stuff can be fixed on
> > the engine level, but it's better to avoid misleading naming.
>
> how about introducing the new names as aliases and keeping the old ones
> active?
>
> (maybe with exception of "kuznyechik", but still support both at the same
> time)
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
>
>

-- 
SY, Dmitry Belyavsky


Re: 1.1.1f

2020-03-26 Thread Dmitry Belyavsky
On Thu, Mar 26, 2020 at 5:14 PM Matt Caswell  wrote:

> The EOF issue (https://github.com/openssl/openssl/issues/11378) has
> resulted in us reverting the original EOF change in the 1.1.1 branch
> (https://github.com/openssl/openssl/pull/11400).
>
> Given that this seems to have broken quite a bit of stuff, I propose
> that we do a 1.1.1f soon (possibly next Tuesday - 31st March).
>
> Thoughts?
>

I strongly support this idea.

-- 
SY, Dmitry Belyavsky


Deprecating misleading GOST names

2020-03-20 Thread Dmitry Belyavsky
Hello,

I came across wrong naming for some GOST-related stuff in object.txt. As
all this stuff was introduced by me, it's a separate problem.

First, I've erroneously translated the name of the Russian "Кузнечик"
algorithm as "grasshopper" instead of transliterating it as 'kuznyechik".
The transliteration has appeared as an official after the changes were
accepted into openssl.

Second, some other algorithm and parameter names were introduced with their
official names instead of reasonable short names. When they are used in the
command line applications, it's very inconvenient.

I'd like to fix these issues in the upcoming 3.0 release, so any ideas
about how to deal with it are welcome. Some of this stuff can be fixed on
the engine level, but it's better to avoid misleading naming.

-- 
SY, Dmitry Belyavsky


Re: New GitHub Project Landing Page

2020-02-26 Thread Dmitry Belyavsky
Looks great! Many thanks for your efforts!

On Wed, Feb 26, 2020 at 11:13 PM Dr. Matthias St. Pierre <
matthias.st.pie...@ncp-e.com> wrote:

> The OpenSSL Project GitHub has a new landing page:
>
> https://github.com/openssl/openssl
>
> Scroll down. Enjoy.
>
>
> Matthias
>
>
>

-- 
SY, Dmitry Belyavsky


Re: Deprecation

2020-02-14 Thread Dmitry Belyavsky
Dear Richard,

On Fri, Feb 14, 2020 at 1:37 PM Richard Levitte  wrote:

> On Fri, 14 Feb 2020 10:41:05 +0100,
> Dmitry Belyavsky wrote:
> >
> >
> > Hello,
> >
> > On Fri, Feb 14, 2020 at 5:30 AM Dr Paul Dale 
> wrote:
> >
> > There is some pushback against the deprecations going on in various
> PRs.
> >
> > The plan has always been to deprecate engines in 3.0 and removing
> support for them 5+ years later.
> > Originally, the path was to have included an engine provider that
> could load engines and make them appear
> > to be a provider.  After a fair amount of investigation, this was
> deemed to be too difficult in the 3.0
> > time frame.
> >
> > Do we still want to deprecate engines in 3.0?
> > Should we defer until 4.0 instead?
> >
> > I think we should delay the deprecation of engine stuff to 4.0.
> Personally I don't have sense of stability of
> > provider API.
>
> It should be pointed out that the engine stuff isn't as stable as you
> might think, because it shares internal structures with libcrypto.
> Even if we handle those structures via function calls, all it takes is
> loading an engine linked against - say - 1.1.0 in 1.1.1 to run a real
> risk of a spectacular KABOOM if any of the structure that are touched
> changed between those OpenSSL versions.
>

Does ABI compatibility cover a significant share of these cases?


> This is a consequence of making structures opaque and feeling much
> more liberty in changing them, and we didn't quite pay attention.
>
> The whole model around providers is intentionally designed to allow
> providers to run flexibly with any OpenSSL version, even if they are
> linked with some (possibly different) libcrypto version.
>
> So the question of stability depends on what you look at.
>

Agreed.

It's true that some parts of the provider API is fluctuating a bit, as
> early designs need modifications to better meet demands.  We're still
> in development.  Come beta1 (schedule for June), I expect that it will
> have stabilized.  Come the release, it must have.
>

Sure.

> The main benefits seem to boil down to continuing to support existing
> engines vs removing the legacy code
> > paths and switching to the provider model.
> >
> > For me, both as open-source and commercial engine developer seems
> > reasonable to delay conversion from engines to providers at least
> > until 3.0.0 feature freeze happens.
>
> According to our policy, a deprecation starts at the release that has
> those deprecations, and removal of deprecated stuff can only happen 5
> years later at the earliest.  Seeing deprecations in the source now
> doesn't change that, the clock will start ticking when we release
> 3.0, so consider what you see happening on github as a pre-deprecation
> warning.
>

Yes.


> > But some features I'm interested in imply engine model (and it will
> > be great if somebody else could look at PR 10904 to avoid it when
> > possible).
>
> Apart from a few details, that PR looks rather innocuous.  I frankly
> haven't had time to look at it too deeply (I just discovered that I
> was prompted), as I haven't dived in the CMS code yet...
>

Well, the problem is introducing some new control values. I don't feel
policy here very well.
I also plan to submit at least one TLS-related PR significantly more
innocent...

-- 
SY, Dmitry Belyavsky


Re: Deprecation

2020-02-14 Thread Dmitry Belyavsky
Dear Matt,

On Fri, Feb 14, 2020 at 12:48 PM Matt Caswell  wrote:

>
>
> On 14/02/2020 09:41, Dmitry Belyavsky wrote:
> > Hello,
> >
> > On Fri, Feb 14, 2020 at 5:30 AM Dr Paul Dale  > <mailto:paul.d...@oracle.com>> wrote:
> >
> > There is some pushback against the deprecations going on in various
> PRs.
> >
> > The plan has always been to deprecate engines in 3.0 and removing
> > support for them 5+ years later.  Originally, the path was to have
> > included an engine provider that could load engines and make them
> > appear to be a provider.  After a fair amount of investigation, this
> > was deemed to be too difficult in the 3.0 time frame.
> >
> > Do we still want to deprecate engines in 3.0?
> > Should we defer until 4.0 instead?
> >
> >
> > I think we should delay the deprecation of engine stuff to 4.0.
> > Personally I don't have sense of stability of provider API.
>
> Well - it isn't stable *right now*. Its in development. But moving
> forward the provider model *is* the way we intend to go. By the time of
> the 3.0 release the provider stuff had better be stable, otherwise we've
> gone wrong.
>

Totally agree. Though the conversion between engines and providers is not
as straightforward as I want, so I prefer to wait for some time.

>
> As has been pointed out many times. Deprecation does not mean removal
> (yet). Its just a signal that at some later time we will remove it.
>

Sure.

>
> And the 3.0 is the right time to signal that. We don't want to hold on
> the "legacy" codepaths for any longer than we have to. They were only
> ever originally intended to be temporary, and to be removed before 3.0
> got released. However it now looks like they will live beyond the 3.0
> release. They should not live for any longer than absolutely necessary.
>

Hmmm. Not sure here. I remember the introduction of EVP_PKEY_ameth/pmeth
currently moving to providers.

> The main benefits seem to boil down to continuing to support
> > existing engines vs removing the legacy code paths and switching to
> > the provider model.
>

It's worth explaining the benefits to engine authors :)
I understand the benefits of OpenSSL as a product and still now don't have
a firm understanding of benefits for the surrounding ecosystem. Though I
did not dive into the providers deeply.

I still have a suspicion that we will not have function signatures for
callbacks in providers.
Do we? If don't, we'll have a set of errors implementing it.

> For me, both as open-source and commercial engine developer seems
> > reasonable to delay conversion from engines to providers at least until
> > 3.0.0 feature freeze happens.
>
> That's a perfectly reasonable strategy. But this decision is independent
> of whether we deprecate the ENGINE APIs in 3.0 or not. It would be
> perfectly ok for people to continue to *use* engines in 3.0 even though
> they are deprecated.
>

Sure.


> > But some features I'm interested in imply engine model (and it will be
> > great if somebody else could look at PR 10904 to avoid it when possible).
>
> If there are gaps then we need to plug them. The provider model should
> be able to do everything that you can do now in ENGINEs.
>

Totally agree.

-- 
SY, Dmitry Belyavsky


Re: Deprecation

2020-02-14 Thread Dmitry Belyavsky
Hello,

On Fri, Feb 14, 2020 at 5:30 AM Dr Paul Dale  wrote:

> There is some pushback against the deprecations going on in various PRs.
>
> The plan has always been to deprecate engines in 3.0 and removing support
> for them 5+ years later.  Originally, the path was to have included an
> engine provider that could load engines and make them appear to be a
> provider.  After a fair amount of investigation, this was deemed to be too
> difficult in the 3.0 time frame.
>
> Do we still want to deprecate engines in 3.0?
> Should we defer until 4.0 instead?
>

I think we should delay the deprecation of engine stuff to 4.0. Personally
I don't have sense of stability of provider API.

The main benefits seem to boil down to continuing to support existing
> engines vs removing the legacy code paths and switching to the provider
> model.
>

For me, both as open-source and commercial engine developer seems
reasonable to delay conversion from engines to providers at least until
3.0.0 feature freeze happens.
But some features I'm interested in imply engine model (and it will be
great if somebody else could look at PR 10904 to avoid it when possible).


-- 
SY, Dmitry Belyavsky


Re: Deprecation

2020-02-14 Thread Dmitry Belyavsky
Hello,

I think OPENSSL_NO_DEPRECATED_1_0_2 should be added to this list too.


On Fri, Feb 14, 2020 at 12:31 PM Matthias St. Pierre <
matthias.st.pie...@ncp-e.com> wrote:

>
>
> On 14.02.20 10:21, Matthias St. Pierre wrote:
> >
> > Because deprecation without removal is futile, it increases complexity
> of the code
> > instead of reducing it.
> >
> > Matthias
> >
>
> To underlinie my last statement, I added the initial release dates:
>
>  OPENSSL_NO_DEPRECATED_0_9_8  # 05 Jul 2005
>  OPENSSL_NO_DEPRECATED_1_0_0  # 29 Mar 2010
>  OPENSSL_NO_DEPRECATED_1_0_1  # 14 Mar 2012
>


-- 
SY, Dmitry Belyavsky


Re: Github PR label automation

2020-02-08 Thread Dmitry Belyavsky
Dear Mark,

Thank you for a nice job!

As the reviewers are expected to commit the PRs, could you also add the
reviewers' names as a part of the notification?

On Sat, Feb 8, 2020 at 6:56 PM Mark J Cox  wrote:

> I've currently got a cron job running every hour that looks at open PR
> requests against github openssl repo and does various actions.  So if
> you were wondering why I was altering labels and making comments at
> 4am, now you know.  No doubt we'll use some tool user for this in the
> future.
>
> So right now here's what it does:
>
> Every hour it looks at open PRs that are labelled "approval: done".
> If 24 hours has elapsed since that label was assigned and if there
> have been no comments made to the PR since the label was assigned then
> it is automatically moved to "approval: ready to merge" with a comment
> added to trigger notifications.  So if you want to stop something
> going to "ready to merge" just add any comment to the PR.
>
> I'm thinking of using this script also to 1) collect interesting stats
> and 2) do some other actions.  So if there's some automation you'd
> like to see just add an enhancement issue against the openssl/tools
> repo.
>
> 1 Matt already asked for committer notification trigger for anything
> labelled Urgent.
>
> 2 If there were comments made after "approval: done" then I think we
> really ought to drop the "approval: done" label as the comments likely
> invalidated the approval.  So I'll likely add that next week (if
> "approval: done" label and has comments since that label then remove
> the label and add a comment 'please review if this is really approval:
> done'.  If the approval: done label gets set again then after 24 hours
> the existing automation will trigger.  #10786 is a good example of
> this.
>
> Mark
>


-- 
SY, Dmitry Belyavsky


Re: New Committer

2020-01-31 Thread Dmitry Belyavsky
Great news!

On Fri, Jan 31, 2020 at 5:48 PM Matt Caswell  wrote:

> I'd like to announce that David von Oheimb has joined our team of
> committers! David has been particularly active recently with the CMP
> contribution - but also has numerous other PRs and commits to his name.
>
> Welcome David!
>
> Matt
>


-- 
SY, Dmitry Belyavsky


Re: crypt(3)

2020-01-16 Thread Dmitry Belyavsky
Dear Paul,

The KDF variant seems the best one.

On Fri, Jan 17, 2020 at 9:33 AM Dr Paul Dale  wrote:

> In the deprecation efforts for 3.0, I’ve hit something in the DES code
> that I’d appreciate input on.
>
> There are two functions (DES_crypt and DES_fcrypt) which implement the old
> crypt(3) password algorithm.  Once these are deprecated, they will no
> longer be reachable via EVP.  The confounding point is that they aren’t
> quite DES — close but not identical.  I would be surprised if they aren’t
> still in use for /etc/passwd files on old and/or embedded systems.
>
> I’ve got several choices:
>
>1. Leave them public and unchanged — that is, don’t deprecate these
>two functions yet.
>2. Deprecate them and add KDFs to replace them.
>3. Deprecate them, leave them alone and hope they go away painlessly
>at some point.
>
>
> The apps/password.c applet calls these which is how I stumbled over the
> complication.  I’m fine refactoring this based on the solution chosen.  I’d
> also be okay with factoring out all the password derivation functions into
> KDFs if necessary.
>
>
> Thoughts?  Other alternatives?
>
>
> Pauli
> --
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
> Phone +61 7 3031 7217
> Oracle Australia
>
>

-- 
SY, Dmitry Belyavsky


Re: 3.0 release timeline proposal

2020-01-07 Thread Dmitry Belyavsky
Sorry. My fault :(

On Tue, 7 Jan 2020, 16:35 Matt Caswell,  wrote:

>
>
> On 07/01/2020 13:26, Dmitry Belyavsky wrote:
> > Many thanks!
> >
> > Got it, and I think this should be directly written.
>
> It was!!
>
> beta1, 2020-06-02: Code complete (API stable, feature freeze)
>
>
> Matt
>
>
> >
> > On Tue, 7 Jan 2020, 16:05 Matt Caswell,  > <mailto:m...@openssl.org>> wrote:
> >
> >
> >
> > On 07/01/2020 13:00, Dmitry Belyavsky wrote:
> > > When does the feature freeze happen?
> > > I'm interested in publishing as much GOST support as possible.
> >
> > According to my proposal feature freeze would happen on release of
> > beta1, i.e. 2020-06-02.
> >
> > Matt
> >
> >
> > >
> > > On Tue, 7 Jan 2020, 14:13 Matt Caswell,  > <mailto:m...@openssl.org>
> > > <mailto:m...@openssl.org <mailto:m...@openssl.org>>> wrote:
> > >
> > > Hi all
> > >
> > > Myself, Paul, Shane, Richard and Nicola had a conf call today
> > to discuss
> > > the outstanding tasks and effort required to get us to a final
> > release.
> > >
> > > We've previously said this about that timeline:
> > >
> > > "We are now not expecting code completion to occur until the
> > end of Q2
> > > 2020 with a final release in early Q4 2020."
> > > (https://www.openssl.org/blog/blog/2019/11/07/3.0-update/)
> > >
> > >
> > > With that in mind we came up with the following proposal for a
> > release
> > > timetable which we think is a challenging but achievable
> timeline:
> > >
> > > alpha1, 2020-03-31: Basic functionality plus basic FIPS module
> > > alpha2, 2020-04-21: Complete external provider support
> > (serialization,
> > > support for new algs, support for providers which only include
> > > operations in a class)
> > > alpha3, 2020-05-21: Almost there (aiming to test the API
> > completeness
> > > before beta1 freezes it)
> > > beta1, 2020-06-02: Code complete (API stable, feature freeze)
> > > betaN: Other beta TBD
> > > Final: 2020 early Q4
> > >
> > > The idea here is to set some intermediate deadlines to focus
> > attention
> > > on the final remaining tasks, with a series of 3 alphas prior
> > to the
> > > first beta release where each alpha release comes
> > approximately every 3
> > > weeks. We can have some flexibility to adjust this timetable
> > if we think
> > > it is necessary (such as by including an additional alpha
> > release if
> > > required).
> > >
> > > Please let me know your thoughts. This would probably need to
> > go to an
> > > OMC vote to get approved.
> > >
> > > Matt
> > >
> >
>


Re: 3.0 release timeline proposal

2020-01-07 Thread Dmitry Belyavsky
Many thanks!

Got it, and I think this should be directly written.

On Tue, 7 Jan 2020, 16:05 Matt Caswell,  wrote:

>
>
> On 07/01/2020 13:00, Dmitry Belyavsky wrote:
> > When does the feature freeze happen?
> > I'm interested in publishing as much GOST support as possible.
>
> According to my proposal feature freeze would happen on release of
> beta1, i.e. 2020-06-02.
>
> Matt
>
>
> >
> > On Tue, 7 Jan 2020, 14:13 Matt Caswell,  > <mailto:m...@openssl.org>> wrote:
> >
> > Hi all
> >
> > Myself, Paul, Shane, Richard and Nicola had a conf call today to
> discuss
> > the outstanding tasks and effort required to get us to a final
> release.
> >
> > We've previously said this about that timeline:
> >
> > "We are now not expecting code completion to occur until the end of
> Q2
> > 2020 with a final release in early Q4 2020."
> > (https://www.openssl.org/blog/blog/2019/11/07/3.0-update/)
> >
> >
> > With that in mind we came up with the following proposal for a
> release
> > timetable which we think is a challenging but achievable timeline:
> >
> > alpha1, 2020-03-31: Basic functionality plus basic FIPS module
> > alpha2, 2020-04-21: Complete external provider support
> (serialization,
> > support for new algs, support for providers which only include
> > operations in a class)
> > alpha3, 2020-05-21: Almost there (aiming to test the API completeness
> > before beta1 freezes it)
> > beta1, 2020-06-02: Code complete (API stable, feature freeze)
> > betaN: Other beta TBD
> > Final: 2020 early Q4
> >
> > The idea here is to set some intermediate deadlines to focus
> attention
> > on the final remaining tasks, with a series of 3 alphas prior to the
> > first beta release where each alpha release comes approximately
> every 3
> > weeks. We can have some flexibility to adjust this timetable if we
> think
> > it is necessary (such as by including an additional alpha release if
> > required).
> >
> > Please let me know your thoughts. This would probably need to go to
> an
> > OMC vote to get approved.
> >
> > Matt
> >
>


Re: 3.0 release timeline proposal

2020-01-07 Thread Dmitry Belyavsky
When does the feature freeze happen?
I'm interested in publishing as much GOST support as possible.

On Tue, 7 Jan 2020, 14:13 Matt Caswell,  wrote:

> Hi all
>
> Myself, Paul, Shane, Richard and Nicola had a conf call today to discuss
> the outstanding tasks and effort required to get us to a final release.
>
> We've previously said this about that timeline:
>
> "We are now not expecting code completion to occur until the end of Q2
> 2020 with a final release in early Q4 2020."
> (https://www.openssl.org/blog/blog/2019/11/07/3.0-update/)
>
>
> With that in mind we came up with the following proposal for a release
> timetable which we think is a challenging but achievable timeline:
>
> alpha1, 2020-03-31: Basic functionality plus basic FIPS module
> alpha2, 2020-04-21: Complete external provider support (serialization,
> support for new algs, support for providers which only include
> operations in a class)
> alpha3, 2020-05-21: Almost there (aiming to test the API completeness
> before beta1 freezes it)
> beta1, 2020-06-02: Code complete (API stable, feature freeze)
> betaN: Other beta TBD
> Final: 2020 early Q4
>
> The idea here is to set some intermediate deadlines to focus attention
> on the final remaining tasks, with a series of 3 alphas prior to the
> first beta release where each alpha release comes approximately every 3
> weeks. We can have some flexibility to adjust this timetable if we think
> it is necessary (such as by including an additional alpha release if
> required).
>
> Please let me know your thoughts. This would probably need to go to an
> OMC vote to get approved.
>
> Matt
>


Re: Flaw in our process for dealing with trivial changes

2019-12-12 Thread Dmitry Belyavsky
Great idea.

пт, 13 дек. 2019 г., 0:31 Dr Paul Dale :

> A red blocker along the lines of: “Triviality Unconfirmed”. One of the
> reviewers needs to remove this before the PR can be merged.
>
> It’s in our face, it prevent accidental merges and its low overhead.
>
>
> Pauli
> --
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
> Phone +61 7 3031 7217
> Oracle Australia
>
>
>
>
> On 13 Dec 2019, at 7:06 am, Dr Paul Dale  wrote:
>
> Before we start over engineering a solution, how about we try just having
> an automatic visual indicator for trivial PRs.
>
>
> Pauli
> --
> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations
> Phone +61 7 3031 7217
> Oracle Australia
>
>
>
>
> On 13 Dec 2019, at 3:24 am, Kurt Roeckx  wrote:
>
> On Thu, Dec 12, 2019 at 12:10:35PM +, Matt Caswell wrote:
>
>
> But in principle I agree that addrev could be used to do this. It's not
> quite as robust as doing it in the commit hook - because you don't
> *have* to use addrev. But, AFAIK, everyone does - so that's probably
> good enough.
>
>
> I have never used addrev.
>
>
> Kurt
>
>
>
>


Re: Flaw in our process for dealing with trivial changes

2019-12-12 Thread Dmitry Belyavsky
Dear Matt,

On Thu, Dec 12, 2019 at 1:25 PM Matt Caswell  wrote:

>
> On 12/12/2019 09:29, Dmitry Belyavsky wrote:
> > - the contributor agreed to sign the CLA and
> > - there was a mark that CLA is signed and
> > - all the necessary approves were present
> > I decided that there is no problem to merge.
>
> The only thing I could see in that PR was a message from the author
> saying that they would submit a CLA. There doesn't seem to be a message
> saying that the CLA had actually been processed.
>

Well, then it's my misinterpretation. I saw a author's words and green
checkbox related to CLA.
My fault, sorry.


> It's not sufficient for the author to *say* they have submitted a CLA.
> It must actually have been submitted, and accepted and be on file.
> Sometimes there are problems with submitted CLAs (e.g. missing fields,
> or a user sends an ICLA when they really also need a CCLA, etc).
> Normally the git hooks would not allow you to push a commit where the
> author does not have a CLA. However those checks are suppressed where
> "CLA: trivial" appears in the commit description. So we need to be extra
> careful in that case, i.e. perhaps we should insist that commits
> containing "CLA: trivial" have the line removed if we don't think the
> commit really is trivial. This ensures that the git hooks do their job
> and we can be absolutely sure that the author has a registered CLA.
>
> Matt
>
> >
> > Regards,
> >
> > Paul Yang
> >
> >> On Dec 12, 2019, at 5:29 PM, Dmitry Belyavsky  >> <mailto:beld...@gmail.com>> wrote:
> >>
> >> Dear Matt,
> >>
> >> As
> >> - the contributor agreed to sign the CLA and
> >> - there was a mark that CLA is signed and
> >> - all the necessary approves were present
> >> I decided that there is no problem to merge.
> >>
> >> BTW, I am not sure the PR was trivial enough.
> >>
> >> Anyway, the responsibility was mine, not the git one :)
> >>
> >>
> >> On Thu, Dec 12, 2019 at 12:20 PM Matt Caswell  >> <mailto:m...@openssl.org>> wrote:
> >>
> >> I notice that PR 10594 (Add support for otherName:NAIRealm in
> output)
> >> got merged yesterday:
> >> https://github.com/openssl/openssl/pull/10594
> >>
> >> The commit description contained "CLA: trivial" and so the "hold:
> cla
> >> required" label was not automatically applied to the PR. But the
> >> discussion in the PR suggested a CLA should be submitted. But it got
> >> merged anyway! Fortunately the CLA had already been processed -
> >> just not
> >> noted in the PR. So, in this case, it makes no difference.
> >>
> >> I think this points to a possible flaw in our workflow for dealing
> >> with
> >> trivial changes. Because the "CLA: trivial" header suppresses the
> >> "hold:
> >> cla required" label and the git hooks don't complain when commits
> get
> >> pushed with the "CLA: trivial" header and no CLA on file, it seems
> >> possible to me that we could push commit all the way through the
> >> process
> >> without the reviewers even realising that the author is claiming
> >> triviality on the commit.
> >>
> >> Not sure what the solution to that is.
> >>
> >> Matt
> >>
> >>
> >>
> >> --
> >> SY, Dmitry Belyavsky
> >
>


-- 
SY, Dmitry Belyavsky


Re: Flaw in our process for dealing with trivial changes

2019-12-12 Thread Dmitry Belyavsky
Dear Matt,

As
- the contributor agreed to sign the CLA and
- there was a mark that CLA is signed and
- all the necessary approves were present
I decided that there is no problem to merge.

BTW, I am not sure the PR was trivial enough.

Anyway, the responsibility was mine, not the git one :)


On Thu, Dec 12, 2019 at 12:20 PM Matt Caswell  wrote:

> I notice that PR 10594 (Add support for otherName:NAIRealm in output)
> got merged yesterday:
> https://github.com/openssl/openssl/pull/10594
>
> The commit description contained "CLA: trivial" and so the "hold: cla
> required" label was not automatically applied to the PR. But the
> discussion in the PR suggested a CLA should be submitted. But it got
> merged anyway! Fortunately the CLA had already been processed - just not
> noted in the PR. So, in this case, it makes no difference.
>
> I think this points to a possible flaw in our workflow for dealing with
> trivial changes. Because the "CLA: trivial" header suppresses the "hold:
> cla required" label and the git hooks don't complain when commits get
> pushed with the "CLA: trivial" header and no CLA on file, it seems
> possible to me that we could push commit all the way through the process
> without the reviewers even realising that the author is claiming
> triviality on the commit.
>
> Not sure what the solution to that is.
>
> Matt
>


-- 
SY, Dmitry Belyavsky


Re: Malloc failures check

2019-11-21 Thread Dmitry Belyavsky
Unfortunately, it is not a compile-time check...

I mean smth like
https://github.com/openssl/openssl/blob/ab5c77b4766e0992751d86560193ca42b49cf316/include/openssl/e_os2.h#L198-L202
but not sure it is applicable to external functions...

On Thu, Nov 21, 2019 at 1:42 PM Salz, Rich  wrote:

>
>- It would be possible to implement a malloc failure feature in the
>test suite that systematically runs a test many times, failing successive
>malloc calls.
>
>
>
> It’s there; look crypto/mem.c, shouldfail() and FAILTEST.
>
>
>
> More detail, from off-list discusson:
>
>
>
> i=0
>
> while : ; do
>
>((i++))
>
>export MALLOC_FAILURE_CHECKS=${i}@100 openssl foo etc…
>
>test -f core && echo crashed && exit 1
>
>  done
>
>
>
>
>


-- 
SY, Dmitry Belyavsky


Malloc failures check

2019-11-20 Thread Dmitry Belyavsky
Hello,

Observing a series of similar bugs related to a lack of checks of the
malloc return values, I wonder if we could automate the search of these
errors on the compile level (e.g. similar to the __owur macro)?

-- 
SY, Dmitry Belyavsky


Re: punycode licensing

2019-08-05 Thread Dmitry Belyavsky
Dear Tim,

Sorry for the delay with the response.

On Thu, Jul 11, 2019 at 2:44 AM Tim Hudson  wrote:

> On Thu, Jul 11, 2019 at 12:37 AM Dmitry Belyavsky 
> wrote:
>
>> Dear Tim,
>>
>> Formally I am a contributor with a signed CLA.
>> I took a code definitely permitting any usage without any feedback,
>> slightly modified it (at least by openssl-format-source and splitting
>> between header and source), and submitted it as my feedback to OpenSSL.
>>
>> I still think that it will be a good idea if Adam signs the CLA, but if
>> he declines, we still have a correct interpretation.
>>
>
> In your ICLA it contains the instructions you have to follow (reproduced
> here to save you time):
>
> 7. Should You wish to submit work that is not Your original creation, You
> may submit it to the Foundation separately from any Contribution,
> identifying the complete details of its source and of any license or other
> restriction (including, but not limited to, related patents, trademarks,
> and license agreements) of which you are personally aware, and
> conspicuously marking the work as "Submitted on behalf of a third-party:
> [named here]".
>
>
> Your current PR at https://github.com/openssl/openssl/pull/9199  does not
> actually do this - basically you have to have punycode.c, punycode.h in a
> separate submission not intermixed with anything else.
>
> The reason for not intermixing the code should be pretty clear - as we
> need to know which parts belong to someone else and aren't covered by your
> ICLA and which parts are - with no possibility of confusion.
>
> You would also need to include the *license* that those files are under
> which you have not done so - which according to the RFC is:
>
> Regarding this entire document or any portion of it (including
> the pseudocode and C code), the author makes no guarantees and
> is not responsible for any damage resulting from its use.  The
> author grants irrevocable permission to anyone to use, modify,
> and distribute it in any way that does not diminish the rights
> of anyone else to use, modify, and distribute it, provided that
> redistributed derivative works do not contain misleading author or
> version information.  Derivative works need not be licensed under
> similar terms.
>
> Separately, Rich Salz indicated he had email from the author with respect to 
> being willing to license under the Apache License 2.0 which you would need to 
> get directly from the author (or Rich would need to be the submitter). Only 
> the author (actually copyright owner) can change the license terms of code 
> they create. This isn't about the license.
>
> You really should reach out to the author to ask if he is willing to sign an 
> ICLA - that is the normal steps involved.
> There is nothing particularly onerous in the ICLAs - they are basically there 
> to provide certainty and a legal background for the project to be able to 
> provide the code that it does.
>
> You should also note that the license noted in the RFC misses many of the 
> provisions within the ICLA and within the Apache License 2.0 itself and is 
> incompatible with the Apache License 2.0 because it contains restrictions and 
> conditions beyond those stated in this license.
>
> After all the work that the project did to be able to move to its current 
> license (and a lot of that work was Rich Salz's efforts) it is important that 
> we maintain the foundation of the clear license terms for the entire code 
> base.
>
> Unfortunately, the author of the code did not respond to my letter in
which I asked him whether he agrees to sign the ICLA and close the
discussion.

Do I correctly understand that for now, the best solution is just
reimplementing the punycode encoding/decoding myself to avoid all the
conflicts?
It's a solution I do not like, but if OMC insists, I will do it.

Thank you!

-- 
SY, Dmitry Belyavsky


Re: punycode licensing

2019-07-10 Thread Dmitry Belyavsky
Dear Tim,

Formally I am a contributor with a signed CLA.
I took a code definitely permitting any usage without any feedback,
slightly modified it (at least by openssl-format-source and splitting
between header and source), and submitted it as my feedback to OpenSSL.

I still think that it will be a good idea if Adam signs the CLA, but if he
declines, we still have a correct interpretation.

On Wed, Jul 10, 2019 at 1:43 PM Tim Hudson  wrote:

> Previous assertions that if the license was compatible that we don't need
> a CLA in order to accept a contribution were incorrect.
> You are now questioning the entire purpose of contributor agreements and
> effectively arguing they are superfluous and that our policy should be
> different.
>
> You are (of course) entitled to your opinion on the topic - however the
> project view and policy on this is both clear and consistent even if it is
> different from what you would like to see.
>
> If someone else wants to create a derivative of the software and combine
> in packages under other licenses (Apache License or otherwise) without
> having CLAs in place then that is their choice to do so as long as they
> adhere to the license agreement.
> Again, all of this is use under the license. What our policies cover is
> for contributions that the project itself will distribute - and entirely
> separate context for what others can do with the resulting package.
>
> The CLAs are not the same as code being contributed under an Apache
> License 2.0.
> There are many sound reasons for CLAs existing, and discussion of those
> reasons isn't an appropriate topic IMHO for openssl-project.
>
> Tim.
>
>
>
> On Wed, Jul 10, 2019 at 8:08 PM Salz, Rich  wrote:
>
>> Thank you for the reply.
>>
>>
>>
>> *>*The license under which the OpenSSL software is provided does not
>> require "permission" to be sought for use of the software.
>>
>> See https://www.openssl.org/source/apache-license-2.0.txt
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_source_apache-2Dlicense-2D2.0.txt=DwMFaQ=96ZbZZcaMF4w0F4jpN6LZg=4LM0GbR0h9Fvx86FtsKI-w=xXRygChGgiK1BqBdOliLUVY3TL3voFi6oS6EUcMdAaU=g7Itj8LyezH-cDY2PLhFY6RkrbcX4b3xX5A7_f9MQvE=>
>>
>>
>>
>> Use, as defined by the license, doesn’t just mean end-users, and it is
>> not limited to compiling, linking, and running executables.  A recipient
>> can make derivative items, redistribute, and so on. All of those things are
>> what OpenSSL would do if it “took in” code into the source base.
>>
>>
>>
>> So why does the project require permission from other Apache-licensed
>> licensed software? In other words, why will the project not accept and use
>> the rights, covered by copyright and license, that it grants to others?
>>
>>
>>
>

-- 
SY, Dmitry Belyavsky


Re: Cleaning up include file inconsistencies

2019-07-06 Thread Dmitry Belyavsky
Hello,

I'd like either _lcl.h or _local.h.
_locl.h seems weird to me :)


On Sat, Jul 6, 2019 at 10:32 AM Dr. Matthias St. Pierre <
matthias.st.pie...@ncp-e.com> wrote:

> Hi all,
>
> pull request #9274 started out as a task to clean up inconsistencies in
> the naming
> of the include guards. It turned out that there are also some
> inconsistencies in the
> naming of the include files.
>
> Please take a look at the general discussion starting at
> https://github.com/openssl/openssl/pull/9274#issuecomment-508824668
> between Bernd and me.
>
> In particular, in
> https://github.com/openssl/openssl/pull/9274#issuecomment-508826903 and
> following the question was raised whether all local `*_lcl.h` files should
> be renamed
> to `*_locl.h` for consistency reasons, and the pros and cons discussed.
> The latter choice was suggested by a source tree vote:
>
>~/src/openssl$ find -name '*_lcl.h' | wc -l
>19
> ~/src/openssl$ find -name '*_locl.h' | wc -l
> 30
>
> What's your opinion about renaming of those files?
>
> Matthias
>
>

-- 
SY, Dmitry Belyavsky


Re: Welcoming our new committers

2019-05-21 Thread Dmitry Belyavsky
Many thanks for a great honor to become an OpenSSL committer!

I hope to be useful after I understand the procedures.

On Tue, May 21, 2019 at 12:58 AM Paul Dale  wrote:

> Welcome to the team.
>
>
> Pauli
> --
> Oracle
> Dr Paul Dale | Cryptographer | Network Security & Encryption
> Phone +61 7 3031 7217
> Oracle Australia
>
>
> -Original Message-
> From: Matt Caswell [mailto:m...@openssl.org]
> Sent: Monday, 20 May 2019 8:31 PM
> To: openssl-project@openssl.org
> Subject: Welcoming our new committers
>
> Please welcome our four new committers as announced here:
>
> https://www.openssl.org/blog/blog/2019/05/20/committers/
>
> The new committers are:
>
> Dmitry Belyavsky, Shane Lontis, Tomáš Mráz and Patrick Steuer.
>
> Welcome all!
>
> Matt
>


-- 
SY, Dmitry Belyavsky