Leaderboard

Hi, when you read the title, you probably already had the standard answer in your head: "Does not work with Indy, supports only OpenSSL 1.0.2 at most and thus no TLS 1.3". I can reassure you, that is not my point. Or actually even more precisely: That is exactly my point 😉 I've spent "a little" time writing the Indy support for OpenSSL 1.1.1 and TLS 1.3, and added a push request to Indy: #299. At the same time I have fixed a few issues that have been posted to GitHub (see PR). I wrote 2 new IO handlers ( one for server and one for client), the old ones are unchanged to avoid conflicts. Everything was written and tested in Delphi Berlin 10.1.2 on Win32 and Win64. I have neither macOS nor iOS nor Linux nor Android, nor FreePascal, nor older (or newer) Delphi versions. I have tried to keep older Delphi versions in mind to ensure that it will run on them, but there have been no tests on my part. I have tested it extensively in small test applications with other servers/clients. In addition, I built it into a large Real World program with TCP server/client, SMTP/IMAP/POP clients, FTP client, HTTP client, and it also ran there without problems. Unfortunately the nice man, who has provided new binary files of OpenSSL under indy.fulgan.com has said that he does not offer versions > 1.0.2 anymore. So I used the versions of slWebPro in the beginning (they even still work on WinXP), later I used the versions of Overbyte, because they do not have any external dependencies (and are digitally signed, but no XP anymore^^). But both worked without problems. All files are located in the subfolder "Lib/Protocols/OpenSSL". There are also subfolders "static" and "dynamic" which offers quite extensive imports of the OpenSSL API, once for static linking, once for dynamic loading/unloading. For dynamic loading there are also possibilities in the "IdOpenSSLLoader.pas" to trigger the loading/unloading itself, if you need the API outside of the IO handler (e.g. for your own x509 generation). To save me the double writing of the imports, I wrote a kind of intermediate code in the folder "Intermediate", which I let generate with "GenerateCode" to the two variants. The tool "GenerateCode" is only a simple string customization and actually only designed for Berlin, so I didn't bother about downward compatibility. As a normal user of the IO handlers you don't need them, only if you make changes to the API implementation. So and now comes your. It would be nice if one or the other would test this, so that it is not only WOMM certified, but can withstand more real situations. For me it also works with the Indy, which comes with Delphi Berlin, when I create another unit, which provides some new Indy types and functions. Of course some units have to be adapted locally to use the new unit.

I explained how in the third line: nStatCode := RestRequest(httpPOST, 'https://xx', False, astrJSON.Text); You can also look at the new OverbyteIcsSnippets sample in ICS v9 which has working examples of many ICS functions, just click a button and watch it happen, although you are almost there already. But do use the debugs options, you'd then have seen the modified Json being sent, and the problem should have been glaringly obvious. Angus

You can start from here: https://github.com/IndySockets/Indy/wiki/Updating-Indy

I wrote on the PR a comment some days ago. tl;dr: Stopped on that PR, currently working on OpenSSL 3, will create a new PR when its done.

https://github.com/CloudDelphi/RTC-Portal-VCL

Maybe you are rembring/talking about RealThinClient Portal built on top of the RTC SDK (iirc) - not totally sure about that) which is still available as is/was in the customer area of NexusDB. The release date indicates a version 3.72 made public on 09/24/2012. It's a Standard version an no idea if all source code is included, e.g. the gateway and so on. As far as remote control is concerned you are there, but for file transfer it's not required and HTTP is used directly. Coming back to RealThinClient SDK. Allow me to mention one sentence found in the RTC Forum taken from a thread named File transfer question. Danijel replied: ... Just use a TRtcDataProvider component on the Server and TRtcDataRequest on the Client side. If you need examples, check BrowserUpload, ClientUpload and ServerLesson1 - 4 in the QuickStart folder (included in the RealThinClientSDK zip file). Regards Mike

You may have noticed that the OpenSSL 1.1.1 series will reach End of Life (EOL) next Monday... Most sensible options are to switch to 3.0 or 3.1 as soon as possible. But we also discovered that switching to OpenSSL 3.0 could led into big performance regressions... so which version do we need to use? 😮 I just published a blog article about this, and also how we tried to leverage any incompatibility issue within the mORMot OpenSSL layer: https://blog.synopse.info/?post/2023/09/08/End-Of-Live-OpenSSL-1.1-vs-Slow-OpenSSL-3.0

It is resolved. It was not locating the file in the Service folder. The resolution was to get the complete folder name at run time (Service start) where this PEM file resides and assign it to the RootCert property. Thanks

As a solo maintainer of an open-source library myself I can say this: if that person does not have a working dev environment installed anymore and does not have time to work on it - I personally consider that project being de facto dead. That is not an offense but there has to be taken action. Nobody can blame you for not working on a spare time project if you got no time or the mood to. But if that project is of fundamental importance - and I consider Indy as a crucial piece of the 3rd party ecosystem for Delphi - there needs to be something done about it. Not having an up-to-date networking library available (yes I know there are several others, but Indy always has been out of the box and freely available) is one of the many reasons that make Delphi unappealing for decision-makers.