[GemStone-Smalltalk] GBS8.7.1 + VW 9.3.1 + TLS/SSL external library conflicts on linux?

[Norm Green]

Hi David,

This sounds like a symbol visibility problem.
GemStone builds OpenSSL from source and ships it in a shared library in 
$GEMSTONE/lib, which we load when the libgcirpc is loaded.
In v3.6.x this was still OpenSSL v1.1.x  but in v3.7.x it's OpenSSL v3.0.x .
So probably what is happening is:

1) GS OpenSSL lib (v1.1.x) gets loaded at login
2) VW resolves an OpenSSL symbol and expects v3.0.x but gets 1.1.x 
loaded in #1.
3) Things go sideways from there.

Glad you found a simple workaround.

Norm Green

On 6/7/2024 8:53 AM, David Shaffer via GemStone-Smalltalk wrote:
> I’m getting a walkback when making TLS/SSL requests in an image that 
> also happens to be interacting with GemStone via RPC.  I’ve included a 
> Smalltalk code fragment that reliably reproduces the problem in the 
> latest Ubuntu docker image but I’m guessing that it has nothing to do 
> with docker or ubuntu, in particular.
>
> To reproduce the problem, make sure that your ubuntu install includes 
> libcrypto.so <http://libcrypto.so> and libssl.so 
> <http://libssl.so> and set up VW as instructed in the VW docs:
>
>     export VW_LIBCRYPTO=“/path/to/libcrypto.so <http://libcrypto.so>”
>     export LD_LIBRARY_PATH=“/path/to”
>
>
> Note that setting LD_LIBRARY_PATH is required so that the version of 
> libcrypto that VW loads will correctly load libssl.  In my experience 
> this problem is not sensitive to these settings so as long as you have 
> HTTPS working in your VW image, you can probably still reproduce this 
> problem.  Run a fresh VW 9.3.1 image and load the following parcels 
> (the error does not seem sensitive to which parcels are loaded but for 
> reproducibility’s sake best to load them as listed):
>
>     GbsRuntime
>     TLS-Plugin
>     HTTPS
>     GemBuilderPatches — attached, includes a fix for missing
>     #connectorsList method
>     External-Cryptography
>
> Start up a fresh GemStone database (version doesn’t seem to matter, 
> I’m using 3.6.5 in production so I mostly tested there).  Run the 
> following adjusting host names, ports and library names as needed.
>
>         |p|
>         Transcript
>            show: (Crypto.LibCryptoEVPInterface versionString ifNil:
>     ['nil']);
>            cr;
>            show: (Crypto.LibCryptoEVPInterface openSSLDir ifNil:
>     ['nil']);
>            cr.
>         TLSPlugin.TLSLinuxCertificate trustedCACerts:
>     '/etc/ssl/certs/ca-certificates.crt’.    “Needed for HTTPS to google"
>         (GbsConfiguration default)
>     alwaysUseGemCursor: false;
>     confirm: false;
>     generateClassConnectors: false;
>     libraryName: './libgcirpc-3.6.5-64.so';
>     removeInvalidConnectors: true;
>     verbose: false;
>     apply.
>         p := GbsSessionParameters
>     newWithGemStoneName: ‘!@localhost#netldi:40055!gs64stone'
>     username: 'SystemUser'
>                                     password: 'swordfish'.
>         p gemService: '!@172.17.0.3#netldi:40055!gemnetobject'.
>         p login.
>         Transcript show: 'https://www.google.com' asURI get
>     printString; cr.
>         ObjectMemory quit.
>
>
> You should get an error during closing of the HTTPS socket connected 
> to google.  This problem is not particular to who you are making the 
> HTTPS connection to so I just used google for simplicity.  In my 
> experimentation, making EITHER of the following changes fixes the problem:
>
> 1) copy the statement that causes HTTPS get request so that it occurs 
> before the #login.  After that, all HTTPS requests will work fine.
>
> 2) Remove the initial two references and message sends to 
> Crypto.LibCryptoEVPInterface.
>
>
> This problem does not seem to occur in VW 9.1.1 and Cincom updated VW 
> to use openssl3 somewhere between 9.1.1 and 9.3.1 so my /guess/ is 
> that there is now an issue in resolution of external function calls to 
> the libssl loaded by VW and the one loaded by GBS.
>
> If anyone else is experiencing these problems the workaround is 
> simple: make a successful SSL request (to anywhere) before logging 
> into a GemStone DB.
>
> Best,
>
> David
>
>
>
>
> _______________________________________________
> GemStone-Smalltalk mailing list
> GemStone-Smalltalk at lists.gemtalksystems.com
> https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/archives/gemstone-smalltalk/attachments/20240607/6af02146/attachment.htm>