On 28/12/2014 12:26, Kurt Roeckx wrote: > On Sun, Dec 28, 2014 at 01:31:38AM +0100, Jakob Bohm wrote: >> 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. > Can you give more details about this? Please note the binary > compatibility will only work if you used the same options to build > the library. (This is one of the reasons to make more structures > opaque.) Yep, I presume the distribution packagers used different compile options for the 1.0.x installed in /usr/lib, than I had used for the 1.0.1 installed in /usr/local/lib. >> 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 . > I assume you're talking about SSL_OP_NO_TLSv1_1? It's unfortunate > that SSL_OP_ALL already contained that in 1.0.0 while 1.0.0 > doesn't even know anything about TLS 1.1. But that only affects > people who compiled with 1.0.1 or 1.0.1a headers. Yes, that's exactly the one. > >> 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. > I think people should stop using both 0.9.8 and 1.0.0 as soon as > possible since they do not support TLS 1.2. You really want to use > TLS 1.2. I agree, that is why I had a locally compiled 1.0.1 on that particular system. > >> 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) > I don't think we intend to remove functions like AES_* yet but > might deprecate them in favour APIs that exist for a very long > time. Please note that for instance using the AES functions you > do not have AESNI acceleration but by using the EVP interfance you > do. Thing is that the AES_, DES_ etc. functions have long been a key part ofSSLeay/OpenSSL. Notably, the DES library had previously been distributedseparately, and the large integer library is a key componentfor people implementing new new crypto algorithms and methodsnot yet (or ever) in OpenSSL. And unlike higher level mechanisms, they tend not to bloat statically linkedapplications with lots unused code.(Though the use of EVP insidethe RNG forced me to do some patching to avoid pulling in the EVP RSA code). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20150107/6259da20/attachment.html>
