Angus Robertson

If you have found and fixed a problem in ICS, please let others have it. Angus

ICS V9.3 is now available from GetIt, for Delphi 11 and 12. Angus

You should have been using IcsBase64UrlDecodeA to return an AnsiString, or IcsBase64UrlDecodeTB for TBytes, to allow binary to be handled without loss. No idea why PBIGNUM is here, not used for digests, only raw keys. The function you show seems to be copied from IcsJoseJWKGetPKey, but our version casts to AnsiString and uses IcsBase64UrlDecodeA. Angus

The FTP server never sends command, only responses to commands from the client. Each response starts with a three digit number, so once connected the server will send one or more lines like: Connect/Logon to FTP Server: magpub5.magsys.co.uk:21 < 220-magpub5.magsys.co.uk < 220-Magenta File Server Release 2.9/ICS V9.3 - 16th September 2024 < 220-ICS TFtpServer (c) 1998-2023 F. Piette V9.1 < 220 Server: MAGPUB5 at 2024-10-03T17:39:18 The client should then respond with one of several commands, HOST, USER, TLS, FEAT, etc. If you can not build the Delphi FTP sample OverbyteIcsSslMultiFtpServ.dproj, I suggest you download and run the prebuilt version from https://wiki.overbyte.eu/arch/icsdemos-servers.zip and have your client connect to it, see what happens. Or look at whatever logs your client produces,. Or use the ICS Xfer sample to connect to your C++ server and look at the log. Angus

Which Windows version are you using? What was the last OpenSSL version that worked? Angus

The ICS low level debugging in not really designed for protocols, but SSL handling. You should add your own logging in the various FTP events, as the Delphi sample does, so you know exactly what stage of the session it stalls. Angus

One other thing you could check before verify is the length of the digest. It varies depending on your private key type and signing hash, but is generally the length of the key, so an RSA 2048 SHA256 digest will be 256 bytes long, binary. The JoseTst sample reports the hash length for all combinations of keys and hashes. This could be a simple check for the digest not being corrupted at some point. I might do some investigation to see if I can reliably add such a check to verify. Angus

So you are saying you've saved a TBytes digest created by IcsAsymSignDigestTB and used it with IcsAsymVerifyDigestTB without any string, encoding or base64 conversions, and it fails? Specifically,as in the function doTestSignClick in the JoseTst sample which displays the digest in hex and base64? I will convert that sample to FMX, as I said earlier, but it is not a priority. Angus

In this function. ICS does not use PAnsiChar as a null terminated string, it passes the actual TBytes length to the OpenSSL API, since the hash or digest is binary data. It would seem the old digest is being corrupted before verification. Angus

I missed the IcsAsymVerifyDigestTB name, it takes a TBytes binary digest (base 0) and casts it to PAnsiChar to pass to an OpenSSL API. ICS does not use TEncoding anywhere since it's not in old compilers, so I've no idea of the purpose of that line. ICS only uses base 1 for strings, not TBytes. Angus

You don't say what type OldDigest is, or which Jose function you are using, but casting and TEncoding is probably corrupting it. Try using IcsStringToTBytes instead, which is what the Jose unit uses. Angus

OK, QueryPerformanceCounter 'was' more accurate in the days before CPU speed could be changed dynamically <g> And might still be over a few seconds timing an algorithm. And Ticks are probably more accurate than 20 years ago with faster motherboards. Angus

ICS has a unit that emulates GetTickCount64 using QueryPerformanceCounter on older OSs, meaning it does not wrap at 49 days as using GetTickCount instead would. QueryPerformanceCounter is also more accurate than ticks if you are timing milliseconds. But 49 days running is rare nowadays, even for servers which Microsoft will forcibly reboot to load Windows Updates unless you take severe measures to stop it. Angus

Suggesting you support an OS you don't at least test once is not a good idea. I have a Windows 7 VM that has Delphi 6 to XE installed, and I build and run stuff with a few of those compilers occasionally, so I know it still works. Trying to support anything older is dangerous. That VM still gets some Windows security updates, so has minimal support from Microsoft. One common API to avoid for Windows 7 is GetTickCount64 which was added with Vista and Windows 2008, don't think Delphi uses it internally. Angus

The short answer is not easily with the ICS HTTP client components, they don't built a request nor buffer a response before processing it. The 'proper' solution would be to use the ICS proxy component as an intermediary to handle the encryption, which does give access to headers and content, but would still need changes since it would ignore the encrypted reply. If you are only taking to a specific server with limited requirements and error handling, it would be easier to write your own HTTP client I wrote a simple application 'Simple TCP Client Testing, ie HTTP headers' that uses the TIcsIpStrmLog component to send a simple HTTPS request to a server repeatedly, for heavy testing. TIcsIpStrmLog expects to send and receive text lines as used by most protocols, if your encrypted headers and content arr binary, you would need to use a simple TWSocket instead. Angus

One common issue using the Jose functions is they use binary arguments, originally AnsiString, now TBytes, not Base64, so you need to decode Base64 first, that might explain the wrong length. I'll put an FMX version of the Jose sample on my list. Angus

Sorry, no idea off hand. I did build V9.3 with D7, D2007, XE7, D10.3, D11 and D12 last week, so it builds OK for the different generations of compiler, but I can not test on every compiler. Not sure my D2010 licence still works. Angus

The Ics.Posix.PXMessages unit was written many years ago for 32-bit MacOS, and has never been updated for 64-bit, nor tested properly with Linux. It is now obsolete, so I'll remove it from ICS shortly. No idea why I put it into the Jose unit, no messages there. Angus

As I said earlier, ICS has never had a working message pump for Linux, so no functions dependent on messages will work. Some changes were made to TIcsEventQueue to try and support Linux in V9.2 but did not work and were disabled for V9.3 so at least the non-message stuff loaded. So making THttpClient work is not trivial with V9.3. Angus

It seems six (or more) EC_Group functions were deprecated in OpenSSL 3, and some builds exclude deprecated functions. In OverbyteIcsLIBEAY.pas, suppress four lines in the table with @@EC_GROUP_set_curve_GF , @@EC_GROUP_new and EC_GROUP_clear_free and change the array size to [0..841], that will stop these four exports loading. If you get new names appearing in the exception, do the same thing. ICS now only uses EC_GROUP_get_curve_name, not the dozens of others we load. I agree only loading those exports we use would be ideal, but working out which of those 842 are not used is not trivial, and many are there for future use, or use by end user applications. Angus

That exception happens when ICS attempts to load all the OpenSSL exports, it would appear the OpenSSL version is missing certain EC_GROUP exports that are available in the standard 3.0 library. Unfortunately, the screen short truncates the error list, there may be lots more missing. They may be logged, can not recall if that sample has a log. Not sure if ICS uses EC_GROUPs, if not we can simply avoid loading them and the problem goes away. I've done that before. I guess I need to build a Hyper-V RedHat VM to test in my copious spare time, the issue is what other important stuff do I ignore to do that? Angus

I fixed all the Linux resource file build issues and wincrypt problems two months ago, and built the Linux test package yesterday with V9.3 without errors, so it sounds like your version is V9.2, try the final release. Provided your Linux project does not include TWSocket, it should work. Try building the new IcsPemTest FMX sample on Red Hat provided it has OpenSSL 3 libraries in the same path as Ubuntu. I will install Red Hat at some point, but only once most of ICS is working on Ubuntu. My testing showed putting TWSocket on a Linux format prevented that form appearing in Linux, some library function it brings in that just stops apps running, which is why I created the new IcsPemTest sample so at least something would run. Angus

I'm not clear which ICS version you are using, only V9.3 released yesterday builds for Linux with SSL, but only utility functions work, like creating and reading SSL/TLS certificates. I've only tested against Ubuntu 22.04, not Red Hat. ICS does not yet support TWSocket for Linux, so no protocols will work. A new cross platform message pump supporting Windows and Linus has been written, but has not yet been added to ICS V9, probably within the next six months. I'm planning to make this conditional, so Windows applications can use the existing or new message pumps. Previously ICS had a second message pump that was only supported MacOS, not Windows, which I've just removed ready for the new pump. Another ICS user tried to make the MacOS pump work under Linux, but I never managed to build ICS with the changes he submitted. Angus

I've just tested the OverbyteIcsSslMailSnd sample in V9,3 and it's sending content and attached files as expected with the correct encoding headings. But it is not attempting to send HTML emails. BTW, the component expects String content and will convert to whatever encoding is specified, no idea what will happen if you encode UTF8 and it then encodes it again. Angus Angus

SVN for ICS V9 is https://svn.overbyte.be/svn/icsv9/ Do we have the old URL for V8 somewhere? Angus