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 favourite application is littered with checks on > OPENSSL_VERSION_NUMBER, and the occasional call to SSLeay() to check > for things that were fixed at runtime without an ABI change. > > http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/openssl.c > http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/openssl-dtls.c > > A change to the versioning scheme is very much more than just another > thing that's been deprecated; it's a change to the very mechanism by > which we handle those deprecations. Changing that (and by extension, > rapidly deprecating it) requires a lot more work on the part of > application authors who want their code to build against whatever > version of OpenSSL may be present on the platforms they need to > support. -- Viktor.
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 mean? Essentially, it's a warning that at some > point in the future, the deprecated functionality will be removed. I > believe that part of the issue surrounding this is uncertainty about > when that removal will happen, so let me just remind you what's > written in our release strategy document: > > * No existing public interface can be removed until its replacement > has been in place in an LTS stable release. The original interface > must also have been documented as deprecated for at least 5 years. > A public interface is any function, structure or macro declared in > a public header file. > > Ref: https://www.openssl.org/policies/releasestrat.html > > I'd like to get this thread started with the following four questions, > for as many of us to answer as possible: > > 1. Why should we deprecate stuff > > 2. Why should we not deprecate stuff > > 3. When should we deprecate stuff > > 4. When should we not deprecate stuff > > Cheers, (I know -project won't accept my mail; you can choose to include it in a reply if you see fit). 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 favourite application is littered with checks on OPENSSL_VERSION_NUMBER, and the occasional call to SSLeay() to check for things that were fixed at runtime without an ABI change. http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/openssl.c http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/openssl-dtls.c A change to the versioning scheme is very much more than just another thing that's been deprecated; it's a change to the very mechanism by which we handle those deprecations. Changing that (and by extension, rapidly deprecating it) requires a lot more work on the part of application authors who want their code to build against whatever version of OpenSSL may be present on the platforms they need to support. smime.p7s Description: S/MIME cryptographic signature
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. > > > > What does deprecation mean? Essentially, it's a warning that at some > > point in the future, the deprecated functionality will be removed. I > > believe that part of the issue surrounding this is uncertainty about > > when that removal will happen, so let me just remind you what's > > written in our release strategy document: Actually, my issue was not timing, but whether the particular feature warrants eventual removal. I don't believe it does. > > 1. Why should we deprecate stuff > > Because keeping every legacy API/feature/option/... increases the > maintenance burden, attack surface, confuses users/developers, and in > general hinders the development. > > > 2. Why should we not deprecate stuff > > If something does not really have an adequate replacement, it does not > really increase the maintenance burden, does not significantly increase > the attack surface, and is still used widely in applications, it should > not be deprecated. This is essentially the basis of my objection, with less emphasis on "adequate replacement". Just because we *can* ask users to rewrite their code, does not mean we *should*. -- Viktor.
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 mean? Essentially, it's a warning that at some > point in the future, the deprecated functionality will be removed. I > believe that part of the issue surrounding this is uncertainty about > when that removal will happen, so let me just remind you what's > written in our release strategy document: > > * No existing public interface can be removed until its replacement > has been in place in an LTS stable release. The original > interface > must also have been documented as deprecated for at least 5 > years. > A public interface is any function, structure or macro declared > in > a public header file. > > Ref: https://www.openssl.org/policies/releasestrat.html > > I'd like to get this thread started with the following four > questions, > for as many of us to answer as possible: > > 1. Why should we deprecate stuff Because keeping every legacy API/feature/option/... increases the maintenance burden, attack surface, confuses users/developers, and in general hinders the development. > 2. Why should we not deprecate stuff If something does not really have an adequate replacement, it does not really increase the maintenance burden, does not significantly increase the attack surface, and is still used widely in applications, it should not be deprecated. > 3. When should we deprecate stuff As soon as possible when there is a better replacement for the stuff. I believe it is better to give the warning about future removal as soon as possible rather than to plan deprecating and later removing something anyway but delay the deprecation "to not scare someone early". > 4. When should we not deprecate stuff -- 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.]
Forthcoming OpenSSL Releases
The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.1.1d, 1.1.0l and 1.0.2t. These releases will be made available on 10th September 2019 between approximately 1200-1600 UTC. These are security fix releases. The highest severity security issue fixed by these releases is rated as LOW. Please note that this is expected to be the last release of 1.1.0 before it goes out of support on 11th September 2019. Yours The OpenSSL Project Team signature.asc Description: OpenPGP digital signature
