lhash statistics functions deprecation

Topic: lhash statistics functions to always report 0 in both master and 3.0.    In addition we should deprecate the functions in master. details: PR https://github.com/openssl/openssl/pull/17931 Proposed by: Pauli Issue link: https://github.com/openssl/technical-policies/issues/35 Public: yes

Re: Additional things for deprecation

Hmmm, are we going to start marking types for deprecation? I would advise against it on a general level, 'cause that's likely to cause an implosion. See for example marking ENGINE for deprecation, i.e. this: diff --git a/include/openssl/types.h b/include/openssl/types.h index ee024cef29

Re: OMC Vote on deprecation of command line apps

they are easier to use than the pkey replacements > a web search will likely result in thees commands not the pkey replacements. > > The reason for removing them is one of maintenance: having duplicate commands > means having to make changes in two places and this has been missed in t

OMC Vote on deprecation of command line apps

thees commands not the pkey replacements. The reason for removing them is one of maintenance: having duplicate commands means having to make changes in two places and this has been missed in the past and will be in the future. Other random notes: Deprecation of these commands does not m

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

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 i

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

ke 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? >

Re: Deprecation

ad 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? &

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

he 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 po

Re: Deprecation

ad? > 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,

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 remo

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

Re: Deprecation

> 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. I do not understand the pushback too much - Perhaps it could be resolved by proper explanation that deprecation does not mean a rem

Deprecation

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

Re: Deprecation of stuff

+1 (and more) to the below! > On Sep 4, 2019, at 10:15 AM, David Woodhouse wrote: > > I'd note that the question of *versioning* mechanisms is a very very > special case of "when to deprecate stuff". So much so as to almost make > it a completely separate question altogether. > > My own

Re: Deprecation of stuff

On Mon, 2019-09-02 at 08:38 +0200, Richard Levitte wrote: > The dispute in PR https://github.com/openssl/openssl/pull/7853 has > made it quote obvious that we have some very different ideas on when > and why we should or shouldn't deprecate stuff. > > What does deprecation mea

Re: Deprecation of stuff

On Wed, Sep 04, 2019 at 02:43:34PM +0200, Tomas Mraz wrote: > > The dispute in PR https://github.com/openssl/openssl/pull/7853 has > > made it quote obvious that we have some very different ideas on when > > and why we should or shouldn't deprecate stuff. > > > &

Re: Deprecation of stuff

On Mon, 2019-09-02 at 08:38 +0200, Richard Levitte wrote: > The dispute in PR https://github.com/openssl/openssl/pull/7853 has > made it quote obvious that we have some very different ideas on when > and why we should or shouldn't deprecate stuff. > > What does deprecation mea

Deprecation of stuff

The dispute in PR https://github.com/openssl/openssl/pull/7853 has made it quote obvious that we have some very different ideas on when and why we should or shouldn't deprecate stuff. What does deprecation mean? Essentially, it's a warning that at some point in the future, the deprecated