On 28/12/14 00:31, Jakob Bohm wrote: > 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: Not at all. This decision has been under consideration for some considerable period of time with much discussion of the impacts. > > 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. 1.0.0 will have been around for over 5.5 years by the time it is finally retired. That's quite a healthy lifetime for any product. We are giving a whole year of notice before it is withdrawn. We have committed to continue to support 1.0.1 for another 2 years - and it has already been out for over 2.5 years. Calling either of these STS releases seems quite unfair. > > 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. I'm not sure what you are referring to here. However as Kurt has pointed out the same options have to be applied for binary compatibility to work. > > 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. We are simply unable to provide that level of support - we just don't have the resources to do it. We're not Microsoft or anything remotely like it in terms of resources. At the same time as we have a set of users demanding long term support, we also have other users demanding the latest functionality and releases much more frequently. No matter what we decide we are never going to please everyone. This is our best attempt at balancing all of the various demands. We were keenly aware of the impacts that it would have and these decisions have caused us much debate about how best to balance things. No decisions were taken lightly. > > 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. I respectfully disagree. I firmly believe it as an absolute must have for us to be able to take the library forward. Without it we will be continually hampered by our inability to change anything. With all of the internals exposed we can do very little to improve things. At the same time as doing this though we are also intending to make a 1.0.x release available for the next 5 years - so anyone who absolutely cannot make the changes required (which actually I do not believe will be that difficult) will still have support for quite some time to come. Matt
