Indy add-on TaurusTLS 1.0.0.30 beta for OpenSSL 3.x

[J. Peter Mugaas]

I am pleased to announce that I have released an Indy (Internet Direct) add in called TaurusTLS.

This add provides Indy with the ability to use recent versions of OpenSSL such as OpenSSL 3.5.1.  Just use the IOHandlers provided by TaurusTLS instead of the OpenSSL IOHandlers provided by Indy.  There is a .CHM Help file reference that provides information on the properties, components, methods, and events that TaurusTLS provides.

You can download the latest beta at:
https://github.com/JPeterMugaas/TaurusTLS/releases/tag/1.0.0.30beta30

[DirkJ]

Has anyone managed to use this component with Lazarus 4.2?

I downloaded Lazarus 4.2 from the official SourceForge website and installed it. (https://sourceforge.net/projects/lazarus/files/Lazarus%20Windows%2064%20bits/Lazarus%204.2/ lazarus-4.2-fpc-3.2.2-win64.exe and lazarus-4.2 -fpc-3.2.2-cross-i386-win32-win64.exe)
Then I installed the indylaz package via the Online Package Manager. After recompiling the IDE, I opened the TaurusTLSRT package (version 1.0.0.31) in Lazarus and compiled it.

Then I created a new application and added the indylaz and TaurusTLSRT packages. When I try to compile the application now, I get:

Code: Text  [Select][+][-]

1. Projekt kompilieren, Ziel: C:\Users\XXX\Documents\TaurusTestOhneDsgn\project1.exe: Exit code 1, Fehler: 1, Warnungen: 1
2. Warning: Recompiling TaurusTLSHeaders_x509, checksum changed for C:\Users\Dirk\Documents\TaurusTLS-1.0.0.31beta31\TaurusTLS-1.0.0.31beta31\Packages\lazarus\lib\x86_64-win64\TaurusTLSHeaders_crypto.ppu
3. TaurusTLSHeaders_x509.pas(8,67) Error: Can't find unit TaurusTLSHeaders_x509 used by TaurusTLSHeaders_x509v3

The same thing happens with version 1.0.0.30.

[wp]

Has anyone managed to use this component with Lazarus 4.2?

I don't know how to use this package, so I cannot follow your steps. But I just tested it for adding it to OPM, and had some issues:

When I check TaurusTLS in OPM and click "Install", the download and compilation are running fine, but when the IDE is rebuilt compilation aborts with the same error that you are reporting. I then manually loaded the runtime package (taurustlsrt.lpk) into the IDE ("Package" >"Open package file (*.lpk)", compiled it, then loaded the designtime package (taurusrtldsgn.lpk) and installed it ("Use" > "Install"), and now it worked fine. I find two components on the "TaurusTLS" palette, a TTaurusTLSServerIOHandler and a TTaurusTLSIOHandlerSocket.

Then I tried to run a Lazarus demo project and found TaurusFTPConsole in the demos folder. Compilation aborted with a "not found" error for one of the Indy units. Looking at the project options I saw that on my system the Indy units are not at the locations specified in the "Other unit paths". This is not the Lazarus way of handling dependant packages, anyway, and I removed the Indy units from "Other unit paths" and added the indylaz package to the requirements of the project.

This was accepted by the compiler, but now there was another error talking about "undefined symbol: WSRegisterCustompage" and many similar ones. This is typical of a command line program using the LCL and not having the "Interfaces" unit in the unit clause. I don't know where this project exactly needs the LCL, but it is strange that the indy package unit is in the uses clause of the project although it is not directly needed in this file (and Indy does depend on LCL). Removing this unit finally made the TaurusFTPConsole project compile and run.

[DirkJ]

To test it, I simply created a new application and added the requirements "lazindy", "TaurusTLSRT" and "TaurusTLSDSGN".

After that, I couldn't compile the test application. The error I mentioned earlier occurred.

Now I tested the following again:

• Installed a fresh copy of Lazarus
• Installed indylaz via OPM and recompiled the IDE
• Installed TaurusTLS (both packages) via OPM
• When compiling the IDE, I still get the same error
• I Opened the TaurusTLSDSGN package via Package/Open Loaded Package and compiled the package twice (!)
• Recompiled the IDE via Tools/Build Lazarus. This works

The test programme described above works now.

btw: I noticed that the dependency on TaurusTLSRT is missing in the opm version of TaurusTLSDSGN.

[wp]

btw: I noticed that the dependency on TaurusTLSRT is missing in the opm version of TaurusTLSDSGN.

Sure? Not for me

[DirkJ]

It wasn't here at lunchtime today. Now it's here.

[J. Peter Mugaas]

I am aware of a bug that causes TaurusTLS to not compile reliably.  That report is at:

https://github.com/JPeterMugaas/TaurusTLS/issues/79

I'm not sure how to fix this and I need some help.

I have fixed the FTP Console Demo and the HTTP Server demos so it more closely follows that Lazarus conventions by depending upon the IndyLaz package.  The FTP Server demo is still only for Delphi namely because it depends upon the IOUtils unit in Delphi and is not portable to Linux.

There's a new beta version that I hope works better with OPM (fingers crossed) at:
https://github.com/JPeterMugaas/TaurusTLS/releases/tag/1.0.0.32beta32

[wp]

When the runtime package is added with custom compiler option -Ur installation succeeds. The version currently available on OPM has this option and should work.

It wasn't here at lunchtime today. Now it's here.

Yes, I had modified the package metadata shortly before my post. But TBH, I don't know whether the "Dependencies" line in the package metadata of OPM has any importance for installation. What's definitely important is whether the dependent packages are listed in the package editor.

[DirkJ]

When the runtime package is added with custom compiler option -Ur installation succeeds. The version currently available on OPM has this option and should work.

I will test the actual OPM version as soon as possible.

But TBH, I don't know whether the "Dependencies" line in the package metadata of OPM has any importance for installation.

If you only select one package for installation, the OPM will ask you if you would like to install the other package as well. If you select both, it does not matter.

[DirkJ]

When the runtime package is added with custom compiler option -Ur installation succeeds. The version currently available on OPM has this option and should work.

I have just tested the current OPM version under Linux. It seems to be working. Cross-compiling to Windows i386 and x64 also seems to be working.

I will test it again in detail tomorrow.

However, the current OPM version now lacks the OPM dependency between TaurusTLSDSGN and TaurusTLSRT.

[wp]

I have just tested the current OPM version under Linux. It seems to be working. Cross-compiling to Windows i386 and x64 also seems to be working.

Good to hear that. But I already have changed it again. Domingo proposed to disable inline, and this seems to be a better fix than using -Ur (which prevents automatic recompilation of the runtime package).

But TBH, I don't know whether the "Dependencies" line in the package metadata of OPM has any importance for installation.

If you only select one package for installation, the OPM will ask you if you would like to install the other package as well. If you select both, it does not matter.

I don't know. For testing the new OPM version (the one with disabled inline), I only checked the designtime package for installation, but the dependent runtime package was downloaded and compiled as well - everything working. Nevertheless, I'll try to investigate why the OPM packager does not detect this dependence for the meta data from the package file.

[EDIT]
Found the issue with the dependencies: In v2.2.0 the xml structure of lpk files had been changed, but it was forgotten to apply the change to OPM... Fixed in Laz/main, to be backported to Laz 4.4

[J. Peter Mugaas]

I wonder why inlining triggers a rebuild like it does.  I hate to scream, "Bug in the compiler" but that's all I can think.

Just a link for reference for FPC Compiler:
https://github.com/JPeterMugaas/TaurusTLS/issues/79

[DirkJ]

I tested with Lazarus Trunk and FPC 3.3.1 yesterday (before the last version), but is was the same issue.

So if this is a bug in the compiler it isn't fixed in the last version.

But I found this issues:
https://gitlab.com/freepascal.org/fpc/source/-/issues/24121
https://gitlab.com/freepascal.org/fpc/source/-/issues/19673

[wp]

I tested with Lazarus Trunk and FPC 3.3.1 yesterday (before the last version), but is was the same issue.

Checked installation of TaurusTLS from OPM (inline disabled, no -Ur) with Laz/main + FPC3.2.2, FPC/fixes, FPC/main on Windows and with Laz/main + FPC3.2.2 on Ubuntu. No more problems, except for FPC/main (3.3.1) where compilation of the runtime package does not come to an end (at least until a few minutes when I gave up). @DirkJ: Is this in agreement with your observation?

So if this is a bug in the compiler it isn't fixed in the last version.

Or another one... I have never seen such slow compilation of a package...

[DirkJ]

I tested with Lazarus Trunk and FPC 3.3.1 yesterday (before the last version), but is was the same issue.

Checked installation of TaurusTLS from OPM (inline disabled, no -Ur) with Laz/main + FPC3.2.2, FPC/fixes, FPC/main on Windows and with Laz/main + FPC3.2.2 on Ubuntu. No more problems, except for FPC/main (3.3.1) where compilation of the runtime package does not come to an end (at least until a few minutes when I gave up). @DirkJ: Is this in agreement with your observation?

I tested an older version in which the original error was still present because I wanted to know whether it was an error in FPC 3.2.2.

I did not test the version that works under FPC 3.2.2 with FPC 3.3.1. I will do that tonight or tomorrow with the current version from the OPM.

I have never seen such slow compilation of a package...

I agree