Re: Errored: openssl/openssl#31939 (master - 34b1676)

2020-02-14 Thread Matt Caswell
On 14/02/2020 12:23, Nicola Tuveri wrote: > If ASAN is too slow to run in the CI should we restore the previous > homemade checks for memory leaks as an alternative to be run in regular > CI runs and leave ASAN builds to run-checker on the master branch only? To be clear the build that is

Re: Deprecation

2020-02-14 Thread Salz, Rich
* I think we should delay the deprecation of engine stuff to 4.0. Personally I don't have sense of stability of provider API. I share this concern. This is the first release of the provider infrastructure, and while it will be known to work for FIPS modules, it’s hubris to think OpenSSL

Re: Deprecation

2020-02-14 Thread Tomas Mraz
On Fri, 2020-02-14 at 16:17 +, Salz, Rich wrote: > I think we should delay the deprecation of engine stuff to 4.0. > Personally I don't have sense of stability of provider API. > > I share this concern. This is the first release of the provider > infrastructure, and while it will be known

Re: Deprecation

2020-02-14 Thread Benjamin Kaduk
On Fri, Feb 14, 2020 at 05:59:32PM +0100, Tomas Mraz wrote: > On Fri, 2020-02-14 at 16:17 +, Salz, Rich wrote: > > I think we should delay the deprecation of engine stuff to 4.0. > > Personally I don't have sense of stability of provider API. > > > > I share this concern. This is the first

Re: Errored: openssl/openssl#31939 (master - 34b1676)

2020-02-14 Thread Dr Paul Dale
An alternative would be to only run a cut down selection of tests with msan. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 14 Feb 2020, at 11:00 pm, Matt Caswell wrote: > > > > On 14/02/2020 12:23, Nicola Tuveri

Re: Errored: openssl/openssl#31939 (master - 34b1676)

2020-02-14 Thread Nicola Tuveri
If ASAN is too slow to run in the CI should we restore the previous homemade checks for memory leaks as an alternative to be run in regular CI runs and leave ASAN builds to run-checker on the master branch only? Here is another idea that would be interesting if we restore the previous checks: I

Re: Errored: openssl/openssl#31939 (master - 34b1676)

2020-02-14 Thread Nicola Tuveri
On Fri, 14 Feb 2020 at 14:00, Matt Caswell wrote: > > To be clear the build that is timing out uses *msan* not *asan*. > As I understand it msan detects unitialised reads. whereas asan detects > memory corruption, buffer overflows, use-after-free bugs, and memory leaks. > > The previous

Re: Deprecation

2020-02-14 Thread Matt Caswell
On 14/02/2020 10:46, Dr Paul Dale wrote: > Roumen in > https://github.com/openssl/openssl/pull/10977#issuecomment-584818517 > Dmitry > in https://github.com/openssl/openssl/pull/11082#issuecomment-585603911 Thanks. Having re-read the comments and the thread here, I am still of the opinion

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 > > wrote: > > > > There is some pushback against the deprecations going on in

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

Re: Deprecation

2020-02-14 Thread Richard Levitte
On Fri, 14 Feb 2020 12:17:30 +0100, Dmitry Belyavsky wrote: > > > Dear Richard, > > On Fri, Feb 14, 2020 at 1:37 PM Richard Levitte wrote: > > It should be pointed out that the engine stuff isn't as stable as you > might think, because it shares internal structures with libcrypto. >

Re: Deprecation

2020-02-14 Thread Matthias St. Pierre
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    

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

Re: Deprecation

2020-02-14 Thread Matt Caswell
On 14/02/2020 02:30, Dr Paul Dale wrote: > There is some pushback against the deprecations going on in various PRs. I've not followed all of the PRs. Can you point at some specific comments you've received pushing back on this? Matt > > The plan has always been to deprecate engines in 3.0

Re: Deprecation

2020-02-14 Thread Richard Levitte
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

Re: Deprecation

2020-02-14 Thread Matthias St. Pierre
On 14.02.20 08:24, Tomas Mraz wrote: I do not understand the pushback too much - Perhaps it could be resolved by proper explanation that deprecation does not mean a removal? Also even if some stuff deprecated in 3.0 is removed in 4.0, it does not necessarily mean that engines must be

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

Re: Deprecation

2020-02-14 Thread Dr Paul Dale
Roumen in https://github.com/openssl/openssl/pull/10977#issuecomment-584818517 Dmitry in https://github.com/openssl/openssl/pull/11082#issuecomment-585603911