Closed TravisEz13 closed 5 years ago
Thanks for reporting this issue. I will investigate it. To support MacPorts in MacOS, I will add path /opt/local/lib which is used by MacPorts.
macOS comes with SSL libraries installed by default.
In /usr/lib
there are a few different versions:
/usr/lib/libssl.0.9.8.dylib
/usr/lib/libssl.dylib
/usr/lib/libssl.35.dylib
/usr/lib/libssl.0.9.7.dylib
/usr/lib/libssl.43.dylib
/usr/lib/libssl.44.dylib
/usr/lib/libssl.dylib is a symlink to libssl.35.dylib so this is the system default library.
In my very limited testing, this SSL library also works with PowerShell. https://github.com/PowerShell/PowerShell/issues/8004#issuecomment-434131056
The OpenSSL libraries installed by MacPorts or Homebrew will likely be newe than the macOS installed versions, but it would be good if PowerShell worked straight out of the box with the default system installed libraries - thereby reducing it's dependancies on 3rd party software.
If MacPorts or Homebrew libraries are installed, it would probably be worth using them as they will be more up-to-date, but this should not stop PowerShell working with the Apple installed libraries.
so in MacOS, even the openssl has been installed by MacPorts, you prefer to use default apple installed libraries, right?
@BingyuLiu - this is a tricky question. It would be good if PowerShell could work out-of-the-box on macOS with no third party dependancies needing to be installed manually - as long as the libraries you need are installed by Apple. macOS has had ssh
installed by default since day 0, as far as I know, so this means that Apple have been shipping SSL libraries for macOS for a very long time now.
If, however, the end user has installed Homebrew or MacPorts, then the OpenSSL libraries installed by either of these systems would most likely be more up-to-date, so people may prefer to use them instead.
won't fix.
@JumpingYang001 So to be clear, we are going to leave it where it depends on the location used by brew, which brew no longer installs to?
There are other components of PowerShell that correctly look at the entire library path and pick the right libraries. It is incorrect, and inconsistent, for one component to have a hard-coded path when other components use rpath correctly. This could lead to unwanted or insecure behaviour if there is a significant mismatch between the versions of the OpenSSL libraries that are loaded by each component.
PowerShell is out of omi scope now.
@TravisEz13 you can new a PR to fix it, the PR to merge or not depends on my MSFT lead and manager as it also need extra testing and efforts for omi team.
Will this ever be fixed?
@flowl See https://github.com/Microsoft/omi/issues/596#issuecomment-489385957
Out of scope
Out of scope means this project does not support the scenario. I don't believe this will be fixed any in this project.
Porting issue found in
omi
from the powershell/powershell repo, https://github.com/PowerShell/PowerShell/issues/8004#issuecomment-434132441The code here uses the exact path when it probably should use
rpath
.Other libraries which use this, work:
I believe the code is here: https://github.com/Microsoft/omi/blob/6725abfcc71eaeb25ded69c754483d30001fe1b5/Unix/buildtool#L1565