Angus Robertson

530 5.7.0 Must issue a STARTTLS command first. - this simply means the server requires an SSL/TLS connection, and you have not sent the command to start it. You are using the old sample that does not support SSL, you should be using OverbyteIcsSslMailSnd.dpr or OverbyteIcsMailQuTst.dpr (but that may not be in old versions). The ncrypt.dll missing error means new versions of ICS are no longer supported on Windows XP, sorry. I recently added some functions to access SSL certificates and private keys that needed newer Windows APIs not in Windows XP. ICS V8.66 is probably the last that supported Windows XP, I'll update the documentation. Angus

Since XP has been obsolete for several years, we don't test ICS against it, only Windows 7 and later, and that will be dropped soon. But there shouldn't be anything specific in ICS to stop it installing. What specific errors did you get with V8.58, and with V8.68? Angus

ICS V8.68 is now also available from GetIt in RAD Studio 11.0. Angus

Did a quick Google search for the error, seems the developer has messing with this 'security feature' for years causing a lot of problems, and recently with TLSv1.3 that changed how sessions are created. and in fixing 1.3 probably broke 1.2. What is really needed is the tick box to turn off the feature, which seems to have gone. I'm removing the port from the session cache name anyway, since conceptually it is wrong even if it does not fix this particular bug, it should save one TLS session set-up. Angus

You said you did not get the error with Indy, was that using TLSv1.3? If this is down to re-using TLS sessions, it might our caching is broken, despite the logging suggesting it is attempting to re-use an old session. Without tracing TLS packets, which is tedious, hard to know if caching really works. Angus

Okay, I can reproduce it by forcing ICS to use TLSv1.2. So not sure if this is really a FileZilla bug given it works on the older versions that did not support TLSv1.3. The old version also has a configuration option 'require TLS session resumption of data connection when using PROT P' which sound like the error message, but I have that ticked on the old beta, and that setting and lots of other interesting and useful ones have disappeared from the new version. Seems like users should go back to the reliable beta rather than the 'release' version <g> Angus

I can find no problem accessing my own FileZilla servers. My hosted server had v0.9.60 beta from a year ago: > PASV < 227 Entering Passive Mode (217,146,102,143,82,95) ! Passive connection requested to: 217.146.102.143:21087, control channel: 217.146.102.143 > MLSD /webapps/telerest/templates/testing/ Check for Old SSL Session Old SSL Session Found Cached < 150 Opening data channel for directory listing of "/webapps/telerest/templates/testing" ! SSL Connected OK with TLSv1.2, cipher ECDHE-ECDSA-AES256-GCM-SHA384, key auth ECDSA, key exchange ECDH, encryption AESGCM(256), message auth AEAD filezilla.ftptest.org SSL Connected OK with TLSv1.2, cipher ECDHE-ECDSA-AES256-GCM-SHA384, key auth ECDSA, key exchange ECDH, encryption AESGCM(256), message auth AEAD < 226 Successfully transferred "/webapps/telerest/templates/testing" It seems after a decade of beta releases, v1 finally came out this summer, so I installed v1.2.0 on my hosted server, unfortunately Windows Firewall blocks it, despite it being added manually, so installed it locally, and it also works. 15:05:41:693 > PASV 15:05:41:693 Starting SSL Session 15:05:41:693 Cache SSL Session: New 15:05:41:693 < 227 Entering Passive Mode (192,168,1,105,251,19) 15:05:41:693 ! Passive connection requested to: 192.168.1.105:64275, control channel: 192.168.1.105 15:05:41:693 > LIST 15:05:41:694 Check for Old SSL Session 15:05:41:695 Old SSL Session Found Cached 15:05:41:695 < 150 Starting data transfer. 15:05:41:697 ! SSL Connected OK with TLSv1.3, cipher TLS_AES_256_GCM_SHA384, encryption AESGCM(256), message auth AEAD 15:05:41:697 pc21-web5.magenta SSL Connected OK with TLSv1.3, cipher TLS_AES_256_GCM_SHA384, encryption AESGCM(256), message auth AEAD So no idea why you are seeing error 425, is there something more useful in the FileZilla server log? If this is something to do with re-using SSL sessions, when ICS caches a session it adds the port number to the IP address when saving it, to prevent different services being accessed by the same session, but this is effectively what happens with the FTP data channel. So in TIcsFtpMulti you could try removing FtpCli.ControlSocket.PeerPort from xxNewSession and xxGetSession and see that improves matters. I'm not going to change this until I find out how FileZilla is configured to cause the error. Angus

Thanks, I already have FileZilla installed, albeit an older version, will test later and see what FileZilla has broken. Angus

OverbyteIcsXferTst.dpr is a complete ready to build testing project, takes a couple of minutes to start downloading stuff, with logs. I have FileZilla on one of my public servers, will test it later. Angus

The ICS FTP components have been tested regularly against FileZilla Server since 0.9.10 beta 15 years ago as you can read in the source code, can not recall testing it for a while, since I don't recall it every being broken. If FileZilla has re-invented the FTP protocol in some non-standard way, I'll look at it, once I see full logs from OverbyteIcsXferTst. Angus

You should never use TDateTime for duration calculations, users can change the system time, and summer time saving changes it twice a year (unless you use UTC time). Always use the difference between two GetTickCount64 Int64 values. Angus

No real idea what that response means, ICS does not share TLS sessions, they are new for each connection. Which ICS component are you using? It should be TIcsFtpMulti for which there is a sample OverbyteIcsXferTst.dpr which will allow you to test again FileZilla saving a proper log that may show the error. Angus

Can you please try and install the latest ICS from SVN or the overnight zip, we've made various C++ package changes (CPP 11.0 only) this week that should resolve the lib files not being updated, and fixes some CPP warnings. Same applies for any other CPP users, V8.68 is finished and will be released next week, so now is the time to test it installs correctly. V8.68 is a minor release, mainly install problems, added OpenSSL 3.0.1, and support for new HTTP request and response methods to help caching (Entity Tags), the REST component will now download files of any size, including resuming failed partial downloads, and HTTP error reporting is improved, as illustrated in the previous post here that previously would have said just Abort without any explanation. Angus

Probably unrelated, but just been reading an article in PC Pro magazine about the new Intel 12th generation processors, which have two types of core, performance and efficiency, something ARM has had for a while. Only Windows 11 has the extra code to receive telemetry from the Intel Thread Director in the CPU to negotiate on which cores processes should run. Windows 10 application performance may be more random, and different each time you run it. Which is slightly frightening. So just saying modern CPUs may affect applications in ways you have not considered. VMs are even worse. Angus

All I can say is you must build the common and vcl packages before the design package. But as you say, if you don't put any components on forms you don't need any packages, just build the units that your application actually uses. Angus

BTW, for C++ you should be using the early version of V8.68 from SVN or the overnight zip (same wiki page as the stable version), I fixed a load of C++ package and sample issues back in October so that 10.4 and 11.0 build again, including the ones you mention, sorry only just remembered. Angus

Sorry, I don't support C++, I just distribute files updated by other ICS C++ users. Hopefully one of them will be along shortly to help. OverbyteIcsSslThrdLock.pas has long gone, just remove any reference to it. ICS builds with Delphi 11.0 without any warning, if C++ gives warnings just ignore them. Angus

All that happens internally within the ICS TRestOAuth component, it holds the expiry date so knows when to refresh the access token. Getting a new refresh token has various options since many applications are used unattended, not just Windows services, so it will notify an administrator that a new OAuth2 login us required, but API access will fail until it happens. It is unfortunate that OAuth2 was designed without a refresh expiry date being known, so things could be planned better. Angus

Provided you have set the RefrToken or RefreshToken property, you won't see a login window. It;'s expiry is unknown to the application, but can happen if the account secrets are changed, if you invalidate it through the online console, or at the whim of Google or Microsoft. So applications need to handle token failure, as I mentioned a couple of days ago. The same refresh token can be used on multiple computers, at least for Gmail which is the service I use regularly as a backup when my own SMTP server is down. This why the ICS MailQueue component handles multiple email servers, with OAuth2. Angus

I think you are confusing the two tokens that OAuth2 should return. In ICS, AccToken property is the short lived token used for HTTP requests. The RefreshToken property is a long lived token that you should store safely like a password, and may be used repeatedly by the component to refresh AccToken, in background without any interaction. I tested GMail yesterday, and the saved refresh token meant it just worked without a new login. So you need to check if Azure is returning a refresh token and whether you are saving it for re-use. You may need to provide specific scope settings to get a refresh token, see the constant OAuthUriMSRest. Angus

The ICS packages all build okay with FMX and YuOpenSSL, why do you think it is incompatible? Or at least only with lots of deprecated warnings from OpenSSL, that we never see when using the DLLs. Just built one of the FMX samples and that works fine, once I'd commented out a couple of old lines. Need to update those old samples. Angus

I only removed TSuperWriterSock last year, perhaps there are references to it in an old HPP file built from an earlier ICS version? We don't distribute HPP files, maybe deleting it would cause it to be rebuilt correctly - but I know almost nothing about C++. I'd prefer not to restore unused code. Angus

I assume you are referring to an OAuth2 login page appearing in a browser during authentication. For Google, the Refresh Token you receive after an interactive OAuth2 login remains effective for several months or longer, generally, so can be used by services, believe this is the case with Microsoft as well, but don't recall from testing. Your service can email an admin to update the token manually if it expires. You must store the Refresh Token securely as if it were a password, because that's really what it is, it is used by OAuth2 to get a new 12 hour or something Application Token which is the one you use to access APIs. If you set AuthType to OAuthTypeMan, an event will be called in which you can send the email. The event could launch an interactive application, if the service is running on PC with someone watching the screen. Angus

I only remember one security patch for Delphi, well over 10 years ago, relating to a graphics function that did not check a PChar string length properly. Have there been any others? Angus

Sorry, never done any testing with THttpTunnelWSocket, it does seem to be used by the FTP components as a proxy option, but not tested that feature for a long time either. Angus