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
_______________________________________________
openssl-users mailing list
openssl-users@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
