need import libssl to illumos tree and provide it by package because SSH from illumos-gate have dependency to this lib.
Updated by Rich Lowe almost 8 years ago
OpenSSL is not in illumos for a couple of reasons. The first is that adapting things correctly to the illumos build system is a lot of work, and it's almost never worth doing for 3rd party software. Another is that there is no interface boundary with ON that actually makes it work keeping in there. A 3rd is build time (this one is less important).
however Not that we already have openssl in illumos, for the sake of wanboot, and that any attempt to "add openssl" should, instead, fix that one, update wanboot to keep working, and generally do it correctly.
This is not easy, and I doubt it's actually worthwhile at all.
A 3rd issue, unique to illumos (as opposed to the old ONNV) is that in doing so we pin distributors to whichever openssl we happen to ship, despite us being the least well placed to keep it up-to-date, patched for CVEs, etc.
Updated by Gordon Ross almost 8 years ago
See my general notes re. dependencies in https://www.illumos.org/issues/1428.
Now openssl in particular has some tricky issues. Our libcrypto depends on it,
and we have multi-thread consumers of libcrypto (i.e. smbd) that have to hack
around the lack of MT locking in openssl. Part of this is how we build openssl.
Here are some notes from OpenSolaris bug 6971899, captured here:
smbd appears to crash in libcrypto but this is scenario appears similar to issues covered by 6938188 (libcrypto is not MT safe by default). This crash is probably called by two threads calling lh_insert() at the same time with no locking callbacks. Similar crashes have been observed with idmapd - caused by the pkinit plugin's use of libcrypto. Unfortunately, it is not convenient for an application to set the locking callbacks if it is not a direct consumer of OpenSSL. For smbd, OpenSSL is called as a consequence of pkinit and libcups using libcrypto.
I've heard that other systems (i.e. IBM's AIX?) build openssl with full
MT support. It would help if we could find a way to do that in illumos.
Updated by Gary Mills over 4 years ago
- Status changed from New to Feedback
- Assignee set to Gary Mills
- % Done changed from 0 to 90
I'm just completing development of a private version of openssl that's part of illumos. I'm using Keith Wesolowski's design with contributions from Alexander Pyhalov. It compiles on both x86 and SPARC. I've also tested it successfully with ssh on x86. Changes to illumos are minimal. Expect a webrev soon.
Updated by Gordon Ross over 4 years ago
I want to go on record here requesting that the "symbol renaming" part of Keith's proposal should be optional (preferably via a build-time variable). This will allow constrained distributions (i.e. appliances) to provide the integrated OpenSSL as the only ssl.
I'm very well aware of the problems that would cause on system that must allow arbitrary third party software, and how Keith's proposal solves that with two independent versions of OpenSSL. I'd very much prefer that simpler (constrained) distributions that don't need to solve this problem should not be forced to "pay for" a problem they don't have, as in being forced to carry two versions of OpenSSL.
I believe this can be accomplished simply by making all the symbol renaming stuff optional.