TLS v1.3

[baka0815 12]

Quote

 I might consider doing that for a future version of the .cmd script.  That would probably require making a separate .txt file of all the known Indy units and then have the .cmd script loop through that file for every platform.

Wouldn't that be something that could be automated in the CI of the Indy project (the creation of the cmd, without the txt file I mean)?

[DelphiUdIT 176]

5 hours ago, baka0815 said:

Wouldn't that be something that could be automated in the CI of the Indy project (the creation of the cmd, without the txt file I mean)?

In the Embarcadero release, Indy packages, components and other stuffs may be differ from GitHub maintained release. For example IndyIPServer, IndyIPClient and others are not present in the GitHub version.

EDIT: also the runtime version may be differ like 12.0 and 12.1 where in the 12.1 release the new WIN64X "platform" exists.

Edited April 18 by DelphiUdIT

[Remy Lebeau 1392]

14 hours ago, baka0815 said:

Wouldn't that be something that could be automated in the CI of the Indy project (the creation of the cmd, without the txt file I mean)?

Indy doesn't have a real CI system.  But yes, generation of the cmd script could be automated in some way using information that Indy already has (there is already some automation in place to generate the Package projects themselves).  To reduce duplication, I could auto-generate a separate cmd script that just deletes the known Indy files in the current directory, and then have Clean_IDE.cmd call that script where needed.

9 hours ago, DelphiUdIT said:

In the Embarcadero release, Indy packages, components and other stuffs may be differ from GitHub maintained release. For example IndyIPServer, IndyIPClient and others are not present in the GitHub version.

Those files are not part of Indy itself, they are part of an internal wrapper on top of Indy which Embarcadero uses to separate its use of Indy from other Embarcadero code.  But, there are other differences Embarcadero does make to Indy itself - most notably, the Packages are changed to use LIBSUFFIX, etc.

Edited April 18 by Remy Lebeau

[Remy Lebeau 1392]

Just FYI, PR 299 (https://github.com/IndySockets/Indy/pull/299) has been abandoned by the author.  Going forward, there is a new effort now to update Indy to the latest OpenSSL using a completely new and separate package as an add-on to indy:

 

https://github.com/IndySockets/IndyTLS-OpenSSL

 

The existing OpenSSL code in the main Indy library is being pulled out into this new package for a v1.0 release for existing users, and then it will be updated with the latest OpenSSL APIs in subsequent releases, independent of the main Indy library.

Edited September 16 by Remy Lebeau

[DelphiUdIT 176]

The "sasl-oauth" branch will also be useful to enable the use of the OAUTH protocol, especially for email client functions.

[Tommi Prami 130]

11 hours ago, Remy Lebeau said:

The existing OpenSSL code in the main Indy library is being pulled out into this new package for a v1.0 release for existing users, and then it will be updated with the latest OpenSSL APIs in subsequent releases, independent of the main Indy library.

Will get merged to main someday?`Right?

Quote

 But, there are other differences Embarcadero does make to Indy itself - most notably, the Packages are changed to use LIBSUFFIX, etc.

Would it be better to get closer to the Embarcadero version, where possible, because every difference will cause some problems and confusion, I think. 

Also it would make things easier for Embarcadero to merge fixes to their version. etc,... And finally the one with New OpenSSL-stuff...

Just my 0.02€

-tee-

[DelphiUdIT 176]

1 hour ago, Tommi Prami said:

Would it be better to get closer to the Embarcadero version, where possible, because every difference will cause some problems and confusion, I think. 

The Indy "Crew" sayd that this change will be done in the next version (Indy 11). By now you can only change (may be MUST) that at your hand.

 

This is necessary if you want maintain compatibility with Embarcadero tools and also some thirdy party components that use Indy.

 

But Embarcadero is interested in Indy's progression, so things will be fine (https://www.indyproject.org/2024/08/05/ongoing-work-in-indy-for-openssl-updates/)

[Remy Lebeau 1392]

9 hours ago, Tommi Prami said:

Will get merged to main someday?`Right?

The OpenSSL code that is currently in the main library is being pulled out completely into its own separate package that uses the main library.  This way, future updates to OpenSSL are more isolated and can be worked on and committed independently outside of the main library.

9 hours ago, Tommi Prami said:

Would it be better to get closer to the Embarcadero version, where possible, because every difference will cause some problems and confusion, I think.

 

Also it would make things easier for Embarcadero to merge fixes to their version. etc,... And finally the one with New OpenSSL-stuff...

Yes, that is the plan.  I've already asked Embarcadero for details about the changes they make to their bundled release of Indy.

[Remy Lebeau 1392]

7 hours ago, DelphiUdIT said:

The Indy "Crew" sayd that this change will be done in the next version (Indy 11). By now you can only change (may be MUST) that at your hand.

The "crew" is me.

Since Indy 11 has been pending for a very long time, I've been considering lately about updating Indy 10 just to bring it more inline with Embarcadero's releases (ie, adding LIBSUFFIX, etc) sooner rather than later. Dropping older compilers, etc will still wait for Indy 11 for now.