On 24-12-2014 00:49, Matt Caswell wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
You will have noticed that the OpenSSL 1.0.0 End Of Life Announcement
contained a link to the recently published OpenSSL Release Strategy that
is available here:
https://www.openssl.org/about/releasestrat.html
I have put up a blog post on the thinking behind this strategy on the
newly created OpenSSL Blog that you may (or may not!) find interesting.
It can be found here:
https://www.openssl.org/blog/blog/2014/12/23/the-new-release-strategy/
I am afraid that this is a somewhat rush decision, with insufficient
consideration for the impact on others:
1. Because this was announced during the Xmas/New year holidays, many
parties will not see this until the beginning of 2015.
2. The decision that 1.0.0 and 1.0.1 should both be classed as a STS
releases seems new, and is unlikely to have been anticipated by many
"users". Many will have naturally assumed that 1.0.0 would last as
long as 0.9.8 lasted.
So announcing the imminent death of 1.0.0 at the same time as 0.9.8
is going to be a nasty surprise to anyone who already froze their
projects on the 1.0.0 series rather than the new and more unstable
1.0.1 series.
3. The 1.0.x binary compatibility promise seems to not have been
completely kept. As recently as just this December, As a practical
example: I had an OS upgrade partially fail due to the presence of
a self-compiled up to date 1.0.1* library that conflicted with an
OS supplied 1.0.x library that was frozen earlier while relying on
your promise.
Also the 1.0.1 changelog includes at least one change of binary
flag values to get a different compatibility behavior than
previous 1.0.1 releases, thus there is not even binary
compatibility within 1.0.1 .
4. LTS release periods have an absolute need to overlap, such that
at any given date, there is at least one active LTS release known
not to end within the next many years, otherwise the whole concept
is useless. On any given day of the year (except, perhaps, holidays),
a project somewhere is going to look at available tool and library
releases and decide which one is most likely to be supportable for
the next N years, then irreversibly freeze on that version. So if
OpenSSL has no active long term release with at least 3 to 5 years
left, then OpenSSL is not viable or projects will have to incur the
cost of having security-novices backport security fixes manually
to an unsupported version for the remainder of the needed N years.
Accordingly the policy should be that there will always be at least
one LTS release which is at least one year old and has at least 5
years left before security support ends. For comparison, Microsoft
usually promises security fixes for 10 years after release, non-
critical fixes for only 5, and people still complain loudly when the
10 year period is up for e.g. NT 4.0 and XP.
Since you have already announced the upcoming end of 0.9.8, you
must choose one of the stabilized 1.0.x releases (1.0.0 or 1.0.1)
as the new LTS release, and you need to deal with the fact that
since the 0.9.8 end-of-life announcement, you have been unclear
which of the two existing 1.0.x releases would be LTS-security,
causing some projects (not mine, fortunately) to irreversibly
pick a different one than you did.
5. Since its original release as part of SSLeay, libcrypt has become
the dominant BSD-licensed library of raw crypto primitives for all
sorts of uses, such as (but not at all limited to), openssh, the
SRP reference implementation, the NTP cryptographic support etc.
Limiting the capabilities, transparency or other aspects at this
point in time is way, way too late. It is as futile as when the
ANSI/ISO C committee tried to remove the UNIX-like file handle APIs
(io.h) in favor of the FILE* API (stdio.h) at a time when the C
language was about the current age of OpenSSL.
The best you can do is to split libcrypt into two or tree well
defined layers, that can be mixed in applications but do not break
their layering internally. These could be: rawalgs (non-opaque
software primitives, bignums etc. with CPU acceleration but
nothing more fancy), EVP-api (opaque structures with hidden heap
allocations, engine and FIPS support, but no forced loading of
unused algorithms, except for the all-or-nothing-ness of fips and
other engine blobs), and NID-API (algorithms referable by numeric
IDs, large bundles of algorithms loaded by master-init functions,
automatic X.509 checking/use based on embedded algorithm OIDs etc.).
Ideally, the rawalgs level should never make its own heap
allocations, except in compatibility functions for older APIs that
did, and should be usable in deeply embedded systems, such as OS
loaders and door locks.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
openssl-users mailing list
openssl-users@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
