Hello,

It's probably time to ask for help with long standing problem with SSL support for dlang-requests under Windows.

dlang requests is HTTP/FTP client library, inspired by python-requests. For long time it have support for ssl using dynamic load of openssl library version 1.0 or 1.1 (whatever user have in system). This works fine under Linux and OSX, but not under Windows.

The problem: in Windows to use OpenSSL you have to find, download and install openssl package from some thirtd party site. Library user is not always have enough skills to perform every step successfully, and what is worse - dlang requests have not enough skills to find installed library at runtime, so sometimes it succeed with SSL under Windows and sometimes - not.

I'd like to fix this problem using Windows native SecureChannel, but I know too little about windows programming and even less about secure channel. I need a person  skilled in both topics, who I can ask questions. I don't ask to write code for me, I just need some expertise.

If you feel you can help - please ping me on the project page - https://github.com/ikod/dlang-requests or by email igor.khasilev at gmail.com

Thanks!

On Monday, 24 August 2020 at 04:06:27 UTC, ikod wrote:
> Hello,
>
> It's probably time to ask for help with long standing problem with SSL support for dlang-requests under Windows.

Since https://www.openssl.org/ is also open source, just wondering if you can link to static OpenSSL library (i.e directly provide the lib in https://github.com/ikod/dlang-requests/tree/master/lib, I saw win-i386 there already)?

On Monday, 24 August 2020 at 04:06:27 UTC, ikod wrote:
> The problem: in Windows to use OpenSSL you have to find, download and install openssl package from some thirtd party

may be, link openssl statically?

On Monday, 24 August 2020 at 05:29:25 UTC, novice3 wrote:
> On Monday, 24 August 2020 at 04:06:27 UTC, ikod wrote:
>> The problem: in Windows to use OpenSSL you have to find, download and install openssl package from some thirtd party
>
> may be, link openssl statically?

Thanks for your reply!

I use dynamic linking because at OpenSSL have interface incompatibilities between version 1.0 and 1.1, and at the time of transition between these versions there were no clean and reliable way for dub to detect which version installed in system (so I was unable to select proper openssl calls at compile time). So I decided to load library dynamicaly and check which interfaces available during runtime. Here is details: https://github.com/ikod/dlang-requests/issues/45

Also, will static linking work reliable? I'm open to return back to static linking if this can be confirmed: 1) static linking will work ok for third-party packages installed on Windows, 2) with dub I can at compile time detect openssl version installed in system

On Monday, 24 August 2020 at 06:28:26 UTC, ikod wrote:
> Also, will static linking work reliable? I'm open to return back to static linking if this can be confirmed: 1) static

static link means the generated exe will physically contain all the binary code which is pulled in from the static OpenSSL lib, and the exe will not depends on any other external files.

E.g. if the exe is linked with 1.1 OpenSSL static lib, even the user's machine only has 1.0 OpenSSL dll, it has nothing to do with the generated exe, won't affect its running.

> linking will work ok for third-party packages installed on Windows, 2) with dub I can at compile time detect openssl version installed in system

On Monday, 24 August 2020 at 07:11:14 UTC, mw wrote:
> On Monday, 24 August 2020 at 06:28:26 UTC, ikod wrote:
>> Also, will static linking work reliable? I'm open to return back to static linking if this can be confirmed: 1) static
>
> static link means the generated exe will physically contain all the binary code which is pulled in from the static OpenSSL lib, and the exe will not depends on any other external files.
>
> E.g. if the exe is linked with 1.1 OpenSSL static lib, even the user's machine only has 1.0 OpenSSL dll, it has nothing to do with the generated exe, won't affect its running.
>
>> linking will work ok for third-party packages installed on Windows, 2) with dub I can at compile time detect openssl version installed in system

Yes, but I'm not distribute .exe, I'm distribute sources of the library which have to be compiled on the target machine.

Or I'm missed something?

On Monday, 24 August 2020 at 07:22:45 UTC, ikod wrote:
> On Monday, 24 August 2020 at 07:11:14 UTC, mw wrote:
>> On Monday, 24 August 2020 at 06:28:26 UTC, ikod wrote:
>>> Also, will static linking work reliable? I'm open to return back to static linking if this can be confirmed: 1) static
>>
>> static link means the generated exe will physically contain all the binary code which is pulled in from the static OpenSSL lib, and the exe will not depends on any other external files.
>>
>> E.g. if the exe is linked with 1.1 OpenSSL static lib, even the user's machine only has 1.0 OpenSSL dll, it has nothing to do with the generated exe, won't affect its running.
>>
>>> linking will work ok for third-party packages installed on Windows, 2) with dub I can at compile time detect openssl version installed in system
>
> Yes, but I'm not distribute .exe, I'm distribute sources of the library which have to be compiled on the target machine.

Just tell your library user also use static linking (and with the OpenSSL version you provided).

Actually I don't know what your worry is.

On Monday, 24 August 2020 at 07:27:14 UTC, mw wrote:
> On Monday, 24 August 2020 at 07:22:45 UTC, ikod wrote:
>> On Monday, 24 August 2020 at 07:11:14 UTC, mw wrote:
>>> On Monday, 24 August 2020 at 06:28:26 UTC, ikod wrote:
>>>> Also, will static linking work reliable? I'm open to return
...
>> the library which have to be compiled on the target machine.
>
> Just tell your library user also use static linking (and with the OpenSSL version you provided).
>
> Actually I don't know what your worry is.

Here is list of issues for windows + ssl
https://github.com/ikod/dlang-requests/issues/127
https://github.com/ikod/dlang-requests/issues/121 - altough solved by experienced user
https://github.com/ikod/dlang-requests/issues/52

I'd be really happy if this problem is not real and I'll forget about it.

On Monday, 24 August 2020 at 04:06:27 UTC, ikod wrote:
> Hello,
>
> It's probably time to ask for help with long standing problem with SSL support for dlang-requests under Windows.
>
> dlang requests is HTTP/FTP client library, inspired by python-requests. For long time it have support for ssl using dynamic load of openssl library version 1.0 or 1.1 (whatever user have in system). This works fine under Linux and OSX, but not under Windows.
>
> The problem: in Windows to use OpenSSL you have to find, download and install openssl package from some thirtd party site. Library user is not always have enough skills to perform every step successfully, and what is worse - dlang requests have not enough skills to find installed library at runtime, so sometimes it succeed with SSL under Windows and sometimes - not.
>
> I'd like to fix this problem using Windows native SecureChannel, but I know too little about windows programming and even less about secure channel. I need a person  skilled in both topics, who I can ask questions. I don't ask to write code for me, I just need some expertise.
>
> If you feel you can help - please ping me on the project page - https://github.com/ikod/dlang-requests or by email igor.khasilev at gmail.com
>
> Thanks!

From a security point of view this is fantastic. Because in case of a security issue, Microsoft will solve it automatically via the windows updates.

Security issues in OpenSSL causes the developers to distribute new software packages to their customers.

SecureChannel would be a huge improvement. Maybe a recommendation, maybe you can join forces with vibe-d developers on this topic?

Kind regards
Andre

On Monday, 24 August 2020 at 04:06:27 UTC, ikod wrote:

> dlang requests is HTTP/FTP client library, inspired by python-requests. For long time it have support for ssl using dynamic load of openssl library version 1.0 or 1.1 (whatever user have in system). This works fine under Linux and OSX, but not under Windows.

It's the same problem on macOS. Although, OpenSSL ships on macOS, it's been deprecated since at least nine major versions ago. The recommendation is if you want to use OpenSSL you should ship it with the application. One major reason being it's not ABI compatible between even minor versions. IIRC, OpenSSL doesn't ship on iOS at all.

I would love a version on macOS that uses platform provided TLS/SSL implementation.

--
/Jacob Carlborg