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

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: Deprecation

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: Deprecation

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

* 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: Errored: openssl/openssl#31939 (master - 34b1676)

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: Errored: openssl/openssl#31939 (master - 34b1676)

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: Errored: openssl/openssl#31939 (master - 34b1676)

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: Deprecation

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

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

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

Roumen in https://github.com/openssl/openssl/pull/10977#issuecomment-584818517 Dmitry in https://github.com/openssl/openssl/pull/11082#issuecomment-585603911

Re: Deprecation

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

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

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

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

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

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