<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi David,<br>
    <br>
    This sounds like a symbol visibility problem.<br>
    GemStone builds OpenSSL from source and ships it in a shared library
    in $GEMSTONE/lib, which we load when the libgcirpc is loaded.<br>
    In v3.6.x this was still OpenSSL v1.1.x  but in v3.7.x it's OpenSSL
    v3.0.x .<br>
    So probably what is happening is:<br>
    <br>
    1) GS OpenSSL lib (v1.1.x) gets loaded at login<br>
    2) VW resolves an OpenSSL symbol and expects v3.0.x but gets 1.1.x
    loaded in #1.<br>
    3) Things go sideways from there.<br>
    <br>
    Glad you found a simple workaround.<br>
    <br>
    Norm Green<br>
    <br>
    <div class="moz-cite-prefix">On 6/7/2024 8:53 AM, David Shaffer via
      GemStone-Smalltalk wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:AD512206-6E83-4531-984B-E8FDF8C887C0@acm.org">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      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.  
      <div><br>
      </div>
      <div>To reproduce the problem, make sure that your ubuntu install
        includes <a href="http://libcrypto.so" moz-do-not-send="true">libcrypto.so</a> and
        <a href="http://libssl.so" moz-do-not-send="true">libssl.so</a> and
        set up VW as instructed in the VW docs:
        <div><br>
        </div>
        <blockquote
          style="margin: 0 0 0 40px; border: none; padding: 0px;">
          <div>export VW_LIBCRYPTO=“/path/to/<a
              href="http://libcrypto.so" moz-do-not-send="true">libcrypto.so</a>”</div>
          <div>export LD_LIBRARY_PATH=“/path/to”</div>
        </blockquote>
        <div><br>
        </div>
        <div>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):</div>
        <div>
          <div><br>
          </div>
          <blockquote
            style="margin: 0 0 0 40px; border: none; padding: 0px;">
            <div>
              <div>GbsRuntime</div>
            </div>
            <div>
              <div>TLS-Plugin</div>
            </div>
            <div>
              <div>HTTPS</div>
            </div>
            <div>
              <div>GemBuilderPatches — attached, includes a fix for
                missing #connectorsList method</div>
            </div>
            <div>
              <div>External-Cryptography</div>
            </div>
            <div><br>
            </div>
          </blockquote>
          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.
          <div><br>
          </div>
          <blockquote
            style="margin: 0 0 0 40px; border: none; padding: 0px;">
            <div>
              <div>    |p|</div>
            </div>
            <div>
              <div>    Transcript</div>
            </div>
            <div>
              <div>       show: (Crypto.LibCryptoEVPInterface
                versionString ifNil: ['nil']); </div>
            </div>
            <div>
              <div>       cr; </div>
            </div>
            <div>
              <div>       show: (Crypto.LibCryptoEVPInterface openSSLDir
                ifNil: ['nil']); </div>
            </div>
            <div>
              <div>       cr.</div>
            </div>
            <div>
              <div>    TLSPlugin.TLSLinuxCertificate trustedCACerts:
                '/etc/ssl/certs/ca-certificates.crt’.    “Needed for
                HTTPS to google"</div>
            </div>
            <div>
              <div>    (GbsConfiguration default)</div>
            </div>
            <div>
              <div><span class="Apple-tab-span" style="white-space:pre">                </span>alwaysUseGemCursor:
                false;</div>
            </div>
            <div>
              <div><span class="Apple-tab-span" style="white-space:pre">                </span>confirm:
                false;</div>
            </div>
            <div>
              <div><span class="Apple-tab-span" style="white-space:pre">                </span>generateClassConnectors:
                false;</div>
            </div>
            <div>
              <div><span class="Apple-tab-span" style="white-space:pre">                </span>libraryName:
                './libgcirpc-3.6.5-64.so';</div>
            </div>
            <div>
              <div><span class="Apple-tab-span" style="white-space:pre">                </span>removeInvalidConnectors:
                true;</div>
            </div>
            <div>
              <div><span class="Apple-tab-span" style="white-space:pre">                </span>verbose:
                false;</div>
            </div>
            <div>
              <div><span class="Apple-tab-span" style="white-space:pre">                </span>apply.</div>
            </div>
            <div>
              <div>    p := GbsSessionParameters</div>
            </div>
            <div>
              <div><span class="Apple-tab-span" style="white-space:pre">                                </span>newWithGemStoneName:
                ‘!@localhost#netldi:40055!gs64stone'</div>
            </div>
            <div>
              <div><span class="Apple-tab-span" style="white-space:pre">                                </span>username:
                'SystemUser'</div>
            </div>
            <div>
              <div>                                password:
                'swordfish'.</div>
            </div>
            <div>
              <div>    p gemService:
                '!@172.17.0.3#netldi:40055!gemnetobject'.</div>
            </div>
            <div>
              <div>    p login.</div>
            </div>
            <div>
              <div>    Transcript show: '<a class="moz-txt-link-freetext" href="https://www.google.com">https://www.google.com</a>' asURI
                get printString; cr.</div>
            </div>
            <div>
              <div>    ObjectMemory quit.</div>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>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:</div>
          <div><br>
          </div>
          <div>1) copy the statement that causes HTTPS get request so
            that it occurs before the #login.  After that, all HTTPS
            requests will work fine.</div>
          <div><br>
          </div>
          <div>2) Remove the initial two references and message sends to
            Crypto.LibCryptoEVPInterface.</div>
          <div><br>
          </div>
          <div><br>
          </div>
          <div>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.</div>
          <div><br>
          </div>
          <div>If anyone else is experiencing these problems the
            workaround is simple: make a successful SSL request (to
            anywhere) before logging into a GemStone DB.</div>
          <div><br>
          </div>
          <div>Best,</div>
          <div><br>
          </div>
          <div>David</div>
          <div><br>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <br>
      <fieldset class="moz-mime-attachment-header"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
GemStone-Smalltalk mailing list
<a class="moz-txt-link-abbreviated" href="mailto:GemStone-Smalltalk@lists.gemtalksystems.com">GemStone-Smalltalk@lists.gemtalksystems.com</a>
<a class="moz-txt-link-freetext" href="https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk">https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>