Jump to content
philipp.hofmann

How to initialize OpenSSL with MacOS 64 (x86 and ARM)?

Recommended Posts

Hi,

I try to use the  TSSLSmtpCli component (created during lifetime) on MacOS 64 (x86 and ARM).

   

The files

   libcrypto.3.dylib
   libssl.3.dylib

are deployed to 
  Contents\MacOS\

 

So 

  FileExists(ExtractFilePath(ParamStr(0))+'/libcrypto.3.dylib')

  FileExists(ExtractFilePath(ParamStr(0))+'/libssl.3.dylib')

is true.

 

But
  OpenSSL_version(0)

returns an exception. So I assume the shared libraries are not initialized.

How I can do this?
For Windows this process works without any special requests beforehand.

Best regards, Philipp

Share this post


Link to post

Sorry, there is no official MacOS support for ICS, has not been for 10 years.  If someone fixes it, I'll update it for the next release.

 

Angus

 

Share this post


Link to post

The first thing I found now, you need:

        GSSL_PUBLIC_DIR:=TPath.GetDirectoryName(ParamStr(0));
        IcsLoadSsl();

And you need to deploy to 
   Contents\MacOS\usr\lib

But now I get the error
   Can not find: RAND_screen

Share this post


Link to post

RAND_screen is one of hundreds of entries loaded, it's been in OpenSSL for ever, but not actually used by ICS (I believe).  If the files loaded are incorrect, there is usually a much longer list of missing entries.

 

Angus

 

 

 

Share this post


Link to post

RAND_screen was deprecated in OpenSSL 1.1.0 and hidden behind compatibility macros. So it is possible that it doesn't even exist in your copy of the OpenSSL libs. 

Share this post


Link to post

The OpenSSL DLLs we supply still contain deprecated entries since older applications may use them.  But loading entries is table driven by version, so adding a literal to the table will stop it for v3. 

 

Was it just one missing entry, or many?

 

Angus

 

Share this post


Link to post

OverbyteIcsSSLEAY.pas: 
 

You should use the following file names for 300DLL_Name (so no /usr/lib-path in the filename plus adding version number):

            {$IFDEF POSIX}'libcrypto.3.dylib';{$ELSE}   { !!!! not tested, unknown file name }
            {$IFDEF POSIX}'libssl.3.dylib';{$ELSE}

 

OverbyteIcsLIBEAY.pas:
 

It works if I uncomment @@RAND_screen in the table (and reduce the number by 1):

    GLIBEAYImports1: array[0..852] of TOSSLImports = (
            
    //    (F: @@RAND_screen;   N: 'RAND_screen';   MI: OSSL_VER_MIN; MX: OSSL_VER_MAX),

I saw afterwards the correct OpenSSL-Version number with 

  OpenSSL_version(0) -> 3.2.1

But there is still a problem in initialization of 
   TSSLSmtpCli.create(nil);

It's working fine unter Windows again. So I will check this as the next point.
So I'm not sure if my idea to replace Indy-TIDSMTP with ICS-TSSLSmtpCli to support MacOS64-ARM was so good because I can't find MacOS-ARM-Libraries for OpenSSL-1.0.x.

  • Like 1

Share this post


Link to post
Posted (edited)

Now my problem is the request
  TSSLSmtpCli.create(nil);

or also

  TSSLSmtpCli.create(mainForm);
freezes in 

  procedure TIcsMessagePump.AfterConstruction;

with the following request:

  GlobalSync.BeginWrite;
 

But even if I remove GlobalSync.BeginWrite at all 
  SSLSmtpCli.connect

is not reacting as expected as "SSL handshake faild - No error returned, State: SSLv3/TLS write client hello, connection closed unexpectedly" is raise after 60 seconds.
The same implementation works fine under Windows.


P.S.: I was misleading by https://wiki.overbyte.eu/wiki/index.php/ICS_Download as there is a MacOS support mentioned for ICS-V9.

Edited by philipp.hofmann

Share this post


Link to post

I can fix the OpenSSL issues, however the GlobalSync functions are part of the Posix message handling unit which is MacOS only, so I can not debug it.  It was written many years ago and may need updating for newer MacOS versions. 

 

Other users have had the MacOS version of ICS working in recent years, and I do add changes they suggest.  But not heard from MacOS users in a couple of years.

 

Angus

 

Share this post


Link to post

I have deactivated GlobalSync now first. That's fine for me. But can you fix also the
"SSL handshake faild - No error returned, State: SSLv3/TLS write client hello, connection closed unexpectedly"

issue? This is currently my blocker.

Share this post


Link to post

Sorry, that error could be the result of dozens of issues, you need to know that messages are being processed correctly first, without a message pump ICS simply does not work, and that is the main difference between Windows and MacOS. 

 

Try accessing the same site using a Windows sample, to see if the problem is unrelated to MacOS.

 

Angus

 

Share this post


Link to post

Thanks, so almost certainly the Posix/MacOS messaging stuff. 

 

Another user did make some minor changes to the Ics.Posix.PXMessages unit in preparation for Linux support, you could try reverting to the V9.0 version of that unit in case it got broken. 

 

Angus

 

Share this post


Link to post

I've found only one difference here and this could not be an issue for MacOS:

{$IFDEF ANDROID}
  {$MESSAGE 'TODO processmessage loop'}
  Result := False; // Error                    { V9.1 }
{$ENDIF ANDROID}

But I've checked the reason for the blocker in 
  function TMultiReadExclusiveWriteSynchronizer.BeginWrite: Boolean;
is the line as here it's not coming back:
  WaitForWriteSignal;

P.S.: 
   TIcsMessagePump.ProcessMessage
is not reached under MacOS, if this could be an issue here.

P.P.S.: 
I assume it's an initialisation issue if such a central functionality as WaitForWriteSignal is not working and processMessage is not requested at all. But I don't know what to test further.

Share this post


Link to post

All I can suggest is trying an older ICS version, if I've broken something in recent versions.  Like https://wiki.overbyte.eu/arch/icsv868.zip 

 

There is a new Linux version V10 in SVN, but no SSL and only simple sockets at the moment, not tested on MacOS but it's uses a Delphi message pump which I assume works on MacOS, that version will be the long term cross platform version.  But MacOS will only be supported if contributors help, we can not test it, no Apple hardware.

 

Angus

 

Share this post


Link to post

Same effect with Version 8.68, so again I assume there is some additional piece of code necessary to initialize the MacOS-version of ICS but both of us don't know this part.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×