Viktor Dukhovni openssl-users at dukhovni.org
Thu Nov 14 19:40:31 UTC 2019

> On Nov 14, 2019, at 9:15 AM, Matt Caswell <matt at openssl.org> wrote:
> "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."
> So the functions we're talking about don't yet have a replacement -
> there will be one in 3.0. So presumably they will be documented as
> deprecated in 3.0. So we have to support them for at least 5 years from
> the release of 3.0.

I think that when we're deprecating an entire family of *related* accessors
(for the same structure) that have been in place for some time, the addition
of a missing member of that family is reasonably interpreted as not resetting
the support clock on the entire family.  We can still remove them all as though
the missing members of the family had been in place all along.

That is, we should (and if that requires a policy update and vote so be it) be
able to interpret the rules based on the "spirit" (intent) without getting
unduly burdened by the "letter", where common sense would suggest that we're
getting the intended outcome.


More information about the openssl-project mailing list