Bug #1427


import libssl

Added by Igor Kozhukhov about 12 years ago. Updated over 6 years ago.

Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:
External Bug:


need import libssl to illumos tree and provide it by package because SSH from illumos-gate have dependency to this lib.

Actions #1

Updated by Rich Lowe about 12 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.

Actions #2

Updated by Gordon Ross about 12 years ago

See my general notes re. dependencies in

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.

Actions #3

Updated by Rich Lowe about 12 years ago

our libcrypto depends on it

libcrypto is part of OpenSSL. Our libcrypto is it.

Actions #4

Updated by Gary Mills over 8 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.

Actions #5

Updated by Gordon Ross over 8 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.

Actions #6

Updated by Gary Mills over 8 years ago

The webrev, containing all illumos changes, is here:

The modified openssl source, to be installed in usr/src/lib, is here:

Actions #7

Updated by Gary Mills over 8 years ago

I'm going to abandon this project and close the associated bug report. Most people seem to favour the current situation with illumos, where the openssl libraries are supplied by the build host.

Please close this bug report.

Actions #8

Updated by Yuri Pankov over 6 years ago

  • Status changed from Feedback to Closed
  • Assignee deleted (Gary Mills)

ssh is no longer in tree, and there's apparently no interest for this any longer.


Also available in: Atom PDF