Angus Robertson

All the old samples archived from V9 are still available from a different SVN repository https://svn.overbyte.be/svn/icsdev/arch-samples/

I update them minimally to build for each new release. 

Angus

I have never used ICS components in a Data Module.  I always create components in code for non-GUI applications.,

Angus

I'll restore and update the OverbyteIcsDll1.dpr sample for V9.

Angus

Your loop is crazy, you connect, immediately test for a connection, then wait two seconds and connect again, without testing for a connection.  It would be a little better if you connect before the loop. 

But you are using the wrong method anyway, for WebSockets it should be WSConnect and it's a blocking method, so no loop needed.  

Look at the doWebSocketClick function in OverbyteIcsSnippets1.pas

Angus

It would be good if GetIt kept a 'previously installed' list when it uninstalls stuff, which is not cleared during a new install, and that list had a re-install button.

It would also be good if GetIt properly uninstalled Parnassus and FmxLinux so the new install does not just fail with a load of DLL errors. 

Angus

Sorry, no idea what are doing here, you will need to clarify your problem. 

I'm not aware of any 'list' of ICS components that is different for Win32/64, they are all Win32 on the palette, and all build for Win64.

Angus

I installed D12.2 into a new W11 24H2 VM today, and installed ICS VCL/FMX from GetIt.  It failed with 'Never build RTL must be built'.

I then opened the usual IcsIinstallVclFmx group, and got the same build error, but the package seemed to default to Win64, changed back to Win32, and used the Build Group that does all versions in a known order, and all packages built without error.  So maybe Delphi needs Win32 packages before Win64. 

Unfortunately, none of this is relevant to installs over old versions, and certain not the missing constant error. 

Angus

Not sure the Get helper is relevant to the current problem, but it should be seen in the Getit script log: 

Downloading Library xx
Extracting Library xx
Launching 'c:\users\..\install\iceremoldpacks.exe -D12'

The source is install\icsremoldpacks.dpr.  It searches and removes packages with version numbers for 10.4 and later, since they now use common 'new' names.  I've seen it in logs for VCL only installs, but neither of the two screen shots for VCL/FMX install show it running, will need to check that.  But this is a one-off, updating from V9.0 or V8. 

The constant DefMaxIpLogLine was added to OverbyteIcsIpStreamLog.pas for V9.3, so if missing there may be an old OverbyteIcsIpStream.dcu somewhere in the path the compiler is finding rather than building the new version.  DCUs sometimes appear in the library or application source directories, depending on the Options paths, and can cause problems debugging and compiling unless removed and the paths corrected.  The ICS sample paths were only all corrected for V9.1 so before that DCUs would appear in the sample directories. 

All this cleaning up of 25 year old ICS is taking time, and causing some problems along the way, but ICS today is easier to maintain and install than two or three years ago.

Angus

Strangely I just got the same error 'undeclared identifier DefMax', building D2007, it was because that constant was added recently, and I was upgrading an earlier version, removed the packages, restarted D2007, and it compiled without error.  A little surprised, thought even D2007 was better behaved.  

Guess I need a new sacrificial D12 install for testing, just trashed my old Win10 VM to upgrade to Win11.

Angus

I installed ICS from GetIt on D11 myself last week without any errors, and D12 uses the same packages. 

The usual reason for install failures is remnants of old ICS releases being found, I wrote a small app for GetIt that uninstalls old version packages which conflicted with the current versions, but perhaps you have an old ICS version in the path somewhere, thus the errors.

If it continues to fail from GetIt, try the zipped version, tested that on D12 last week. 

Not really using D12 at the moment, too many missing FmxLinux errors whenever I do anything. 

Angus

The main issue with the various Base64 functions is they are mostly used for ASCII functions in protocols with strings, and having only AnsiString versions means lots of string casts to avoid warnings. 

I've been reworking a lot of low level stuff, tried to remove the String versions, but got so many warnings from dozens of units, had to restore them.  

But I have improved the code comments to suggest which functions can be used with binary, ideally TB versions, and which for text only. 

Angus

ICS has a new Application Monitoring client and server system, I have it running on all my public servers monitoring my web, FTP, proxy Windows Services, and restarting them if they halt on or request if they experience critical errors.   Have a read of: https://wiki.overbyte.eu/wiki/index.php/FAQ_ICS_Application_Monitoring

The client part just sends simple TCP PING packets, the hard part is knowing when to send those pings, my first attempt just used a timer, but that started before the server started and did not check it ever started, things got better over the weeks.

The server is currently basic, running on the same machine since it needs to restart the Windows Services if they stop, but I'm going to add remote monitoring of that server with a websocket API so a remote PC could monitor sereveral servers.

Angus

A little searching suggests OPENSSL_LH_set_thunks is in the other DLL and has been for years. 

So I guess the extraction of the two DLLs from the ICS resources has been corrupted, try deleting all files in directory 3302, they should re-appear when you run your app again. 

This is the first report of a DLL issue in the nine months since I implemented these resource files.

Angus

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