Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
OpenSSL binaries for Linux needed or not?
#1
I have a Delphi console project I am porting to Linux using FreePascal 3.0.4  and Lazarus 1.8.4.
It uses Indy10 email and FTP components with OpenSSL.

The port is towards Ubuntu Linux on x86_64. So it is now a 64 bit program.

I installed the IndyLaz package for Indy10 via OnlinePackageManager in Lazarus and it seems like it accepts all of my Indy calls during compile.
But this Delphi project relied on two dlls (libeay32.dll and ssleay32.dll) for SSL to operate on Windows.
Do I need to put some corresponding Linux binaries into my project directory and if so where can I get them?
Or is the fact that I installed OpenSSL into Ubuntu enough for Indy10 to be able to use SSL?

I have not yet reached the point where I can test run the application since it needs specific email data to work from.

EDIT after being able to test run application


It turns out that the SSL connection apparently needs something extra in Linux...
I am getting the following exception when connecting to the mail server to retrieve email using POP3:

[Image: SSL_FileNotFound.png]

Followed by this when I click No twice:

[Image: SSL_Error_Linux.png]


This happens in this code section:


Code:
   try
      IdGetMail.Connect; // This is an IdPop3 object. Exception thrown here
      MailCnt := IdGetMail.CheckMessages;
      if MailCnt = 0 then    {Nothing to process}
Reply
#2
It seems like there is not a problem with SSL because I received an exception email from the application and this is sent using SSL as well. And it worked apparently.
So the problem seems to be with this strange file "dl-error-skeleton.c" that cannot be located...
Is that supposed to be part of Indy10? If so it may be missing from the IndyLaz package sources that were retrieved using OnLine PackageManager?
Reply
#3
(10-24-2018, 06:45 AM)BosseB Wrote: I installed the IndyLaz package for Indy10 via OnlinePackageManager in Lazarus and it seems like it accepts all of my Indy calls during compile.
But this Delphi project relied on two dlls (libeay32.dll and ssleay32.dll) for SSL to operate on Windows.
Do I need to put some corresponding Linux binaries into my project directory

Yes, you need the corresponding .SO files for Linux.

(10-24-2018, 06:45 AM)BosseB Wrote: and if so where can I get them?

They might already be installed in your Linux distro. If so, then simply call Indy's IdOpenSSLSetLibPath() function at runtime to tell Indy where they are located. Otherwise, you will have to compile them yourself, or find a 3rd party download for them. Indy does not provide pre-compiled .SO files for Linux at this time.

(10-24-2018, 06:45 AM)BosseB Wrote: Or is the fact that I installed OpenSSL into Ubuntu enough for Indy10 to be able to use SSL?

It can, provided that installation is for OpenSSL 1.0.2 or earlier (Indy does not support OpenSSL 1.1.0+ yet), and you point Indy to the folder with the .SO files.

(10-24-2018, 06:45 AM)BosseB Wrote: It turns out that the SSL connection apparently needs something extra in Linux...
I am getting the following exception when connecting to the mail server to retrieve email using POP3:

[Image: SSL_FileNotFound.png]

I don't know what that is exactly, but it is not related to Indy. Probably something in how OpenSSL itself is loaded.

(10-24-2018, 06:45 AM)BosseB Wrote: Followed by this when I click No twice:

[Image: SSL_Error_Linux.png]

"EOF was observed that violates the protocol" is an OpenSSL error message, so OpenSSL is actually being loaded. It means the remote peer closed the socket connection while OpenSSL was still processing the SSL/TLS handshake, usually because the remote peer did not like something in the handshake and just closed the connection without sending a TLS alert back to your client first.

EIdOSSLConnectError() is an Indy exception class that is raised when OpenSSL fails to establish an outgoing handshake with the remote peer.

(10-24-2018, 10:58 AM)BosseB Wrote: So the problem seems to be with this strange file "dl-error-skeleton.c" that cannot be located...
Is that supposed to be part of Indy10?

No. It is actually part of the GNU C compiler/linker instead.

The same error, but relating to MySQL instead, was reported in the Lazarus forum earlier this year:

https://forum.lazarus.freepascal.org/ind...ic=40771.0

Reply
#4
Remy, thanks for explaining this.
Meanwhile I have discovered that the 'dl-error-skelaton.c' request only happens if I use the debugger in Lazarus to step through the code in the connection phase!
If I put a breakpoint a bit past the IdGetMail.Connect in the code and then just run up until it breaks there it works without showing this message!
Can it be that the message is related to the GNU debugger instead?
Anyway, now that I know this I can debug the application by avoiding the dangerous spots for breakpoints.

I also then found that the Indy mail components are able to work with SSL in talking to the mail server and retrieving the messages. I did not have to do anything like copying over so files or similar, that is good!
So the Ubuntu openSSL installation seems to take care of that.

I am now looking at the IdFTP component, which has trouble retrieving the .htpasswd file from the website when it needs to update its content (adding a new user login). I think it might be caused by the website server not allowing certain clients access to certain files. I have two FTP clients I use, FileZilla and the old WS_FTP95. The latter was what I used to manage the website years ago and it handled all files, but since some time now the .htpasswd and .htaccess files do no longer show up when I connect. But in FileZilla they are present and I can handle them.
I suspect that the IdFTP component somehow acts in ways similar to WS_FTP95 and that causes the server not to list these files.
But it might be something else entirely....

My Delphi2007 program (which I am now porting to Lazarus) runs fine on a Windows2003 server including update of .htpasswd, but not on a Windows 2016 server using the exact same binary....
But we are forced to shut down the W2003 server for security reasons, well past end-of-life...
Reply
#5
(10-24-2018, 10:09 PM)BosseB Wrote: I suspect that the IdFTP component somehow acts in ways similar to WS_FTP95 and that causes the server not to list these files.
But it might be something else entirely....

Just about anything WSFTP and FileZilla can do, TIdFTP can do too (with some work).  You are going to have to study the underlying FTP commands that WSFTP and FileZilla exchange with the server, and compare them to the commands that TIdFTP exchanges, and then tailor TIdFTP to mimic the same commands.

Most notably, have a look at the TIdFTP.ClientInfo property.  By default, it is empty, so TIdFTP identifies itself as Indy to any FTP server that supports the CLNT command.  You can change the ClientInfo values to make TIdFTP identify itself as other FTP clients if needed. That might be enough to get the behavior you are looking for.

Reply
#6
Well,
I decided to move .htpasswd out of the 3 demo directories on the webserver and place them in a single directory elsewhere. To differentiate between them I added a name to make the file like ei1d.htpasswd.
Then I had to modify the 3 .htaccess files in those directories to point authentication to the moved and renamed files.
This makes sense anyways because it seems like a security breach to have the auth files inside the protected directory...

Now the files are visible both in WS_FTP95 and FileZilla and my program has no problems dealing with the files either.
Now I am almost done, only fine tuning with different kinds of data thrown at it.
Thanks for your insight!
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)