[openssl-project] constification on already released branches

[Richard Levitte]

In message <CAHEJ-S5q+2ccG7EGFrVVh2gw4-Ri4t5fVosXqnJbBj2jRaotww at mail.gmail.com> on Mon, 26 Mar 2018 08:36:17 +1000, Tim Hudson <tjh at cryptsoft.com> said:

tjh> https://github.com/openssl/openssl/pull/2181
tjh> and
tjh> https://github.com/openssl/openssl/pull/1603#issuecomment-248649700
tjh> 
tjh> One thing that should be noted is that if you are building with
tjh> -Wall -Werror (which many projects do) and you are using OpenSSL
tjh> and things change from a const perspective builds break - and
tjh> that then ends up people having to change code on released
tjh> versions.
tjh> 
tjh> Adding or removing const changes the API.

I would like to point out that we're looking at two different const
changes, and the distinction *is* important.

One constification is changing the constness of a function's input
parameter.
Another constification is changing a function's return type.

The impact of these two types of constification is very different (I
would say "obviously", but I might be wrong, it might not be obvious
to everyone), and they should be regarded different, not piled
together in one "we do / do not allow constification in released
branches".  I'm going to argue that even though there are cases where
one type of constification affects the other (such as constifying an
input parameter might force a constification of the return type), they
can still be looked at individually, and policy can be made on them
individually.

tjh> We should have a clear policy on doing this sort of thing in
tjh> released code - either it is okay to do and we should accept
tjh> patches - or it should never actually be done. I don't see this
tjh> as a case-by-case basis for determination at all - basically it
tjh> is a single type of API change we either should be allowing or
tjh> disallowing.

(a reminder: we're talking about *two* types of API changes that both
involve 'const', not a single API change).

I agree.  We currently have a kinda sorta policy that's quite vaguely
formulated in the FAQ (https://www.openssl.org/docs/faq.html#MISC7),
and we do have something formulated in the release strategy
(https://www.openssl.org/policies/releasestrat.html) as well.  I'll
note that none of them says "the API must not change".  As a matter of
fact, the release strategy only mentions binary compatibility (i.e.
talks exclusively about ABI compatibility).  The FAQ does mention
source (i.e. API) compatibility, formulated as an implication:

   Changes to the middle number are considered major releases and
   neither source nor binary compatibility is guaranteed.

This implies that we do guarantee source and binary compatibility.
What that means exactly is left for us to discuss and decide upon.
I would like to suggest that there should be a document where we
collect what we think "compatibility" means, i.e. what we allow and
disallow ourselves to do.  Kind of a declaration of intention, if you
will.  This should be a document that can be edited over time (but
with great care), and such changes should be voted on, of course.

tjh> There is a similar type of API change which is adding typedefs in
tjh> for callbacks - which technically also don't change the ABI - and
tjh> if we allow any form of API change that also could be
tjh> considered.
tjh> 
tjh> We should discuss this separate from any specific PR and vote to
tjh> set a policy one way or the other in my view.

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