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
