Re: Deprecation of stuff

2019-09-04 Thread Viktor Dukhovni
+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

2019-09-04 Thread David Woodhouse
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

2019-09-04 Thread Viktor Dukhovni
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

2019-09-04 Thread Tomas Mraz
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.]




Deprecation of stuff

2019-09-02 Thread Richard Levitte
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,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/