The case currently is I can not crawl SSL sites using Indy (not those I have tested anyway) ...
I am thinking maybe pointing Indy explicitly to OpenSSL 0.9.8 dylibs (which I believe is actually newer/patched versions of OpenSSL but have kept their file names for not breaking compability)
I also sent you a PM - but I do not see it in my sent PMs list - but I have sen you an URL - if you can scan that using Synapse
Maybe Synapse added support for LibreSSL? But knowing what .dylib files you have in your usr/lib/ would help clarify that :)
(I rather use built-in openssl/libressl instead of shipping those files myself)
Here are the following exceptions I get with HEAD/GET requests to multiple https sites
Synapse just uses whatever libssl.dylib is pointing to.
Just did a test, seems libssl.35.dylib is indeed LibreSSL 2.2.7 (Synapse provides this info).
IdSSLOpenSSLHeaders.pas
defines
SSLDLLVers : array [0..7] of string = ('.10','.1.0.2','.1.0.1','.1.0.0','0.9.9','.0.9.8','.0.9.7','0.9.6');
Note: I think '0.9.9' should probably have been '.0.9.9' in the above, but that is a lesser... bug?
IdGlobal
On non-Windows HackLoad is used to load ssl (which iterates through SSLDLLVers list) while On Windows HackLoad is not used since the dll is not versioned in filename.
IdSSLOpenSSLHeaders.pas
routine LoadSSLCyrptography
- on windows loads the nonversioned lib file directly
- else if symbolic links supported uses HackLoad - but passes en empty versions array (This does nothing? since HackLoad only does any actions on passed array items)
- else if above fails it expands SSLDLLVers with letters (a,b,c etc.) then uses HackLoad
This means on Mac - Indy never reads the non-versioned file name - i.e. libsll.dylib
var
GIdLoadSymLinksFirst: Boolean = True;
...
if GIdLoadSymLinksFirst then begin
Result := {$IFNDEF KYLIXCOMPAT}HMODULE({$ENDIF}
HackLoad(GIdOpenSSLPath + SSLCLIB_DLL_name, [])
{$IFNDEF KYLIXCOMPAT}){$ENDIF};
end;
if Result = 0 then begin
for i := Low(SSLDLLVers) to High(SSLDLLVers) do begin
for j := Low(SSLDLLVersChar) to High(SSLDLLVersChar) do begin
LLibVersions[j] := SSLDLLVers[i] + SSLDLLVersChar[j];
end;
Result := {$IFNDEF KYLIXCOMPAT}HMODULE({$ENDIF}
HackLoad(GIdOpenSSLPath + SSLCLIB_DLL_name, LLibVersions)
{$IFNDEF KYLIXCOMPAT}){$ENDIF};
if Result <> 0 then begin
Break;
end;
end;
end;
if (Result = 0) and (not GIdLoadSymLinksFirst) then begin
Result := {$IFNDEF KYLIXCOMPAT}HMODULE({$ENDIF}
HackLoad(GIdOpenSSLPath + SSLCLIB_DLL_name, [])
{$IFNDEF KYLIXCOMPAT}){$ENDIF};
end;
Indy also seems grab pointers to all routines in the lib - and not as needed. I saw this by checking the source code TODO comments.)
I will try test the LibreSSL binaries shipped with Mac OS now by inserting their file name versions in the SSLDLLVers const.
var
GIdLoadSymLinksFirst: Boolean = True;
...
if GIdLoadSymLinksFirst then begin
Result := {$IFNDEF KYLIXCOMPAT}HMODULE({$ENDIF}
HackLoad(GIdOpenSSLPath + SSLCLIB_DLL_name, [])
{$IFNDEF KYLIXCOMPAT}){$ENDIF};
end;
By default, Indy first loads the non-versioned files, in case symlinks are present.
Just to make 100% sure: You are talking about the call to HackLoad in the above code where you are passing empty array []?
If yes, this is the code of HackLoad:
...
There is no code in HackLoad outside the loop... So if it is passed empty array then nothing happens? But I am tired, so if I missing something then...
IdSSLOpenSSLHeaders.pas(19571,10) Error: function header doesn't match the previous declaration "GetCryptLibHandle:Int64;"
IdSSLOpenSSLHeaders.pas(18191,10) Error: Found declaration: GetCryptLibHandle:QWord;
I am getting funky compile time error:QuoteIdSSLOpenSSLHeaders.pas(19571,10) Error: function header doesn't match the previous declaration "GetCryptLibHandle:Int64;"
IdSSLOpenSSLHeaders.pas(18191,10) Error: Found declaration: GetCryptLibHandle:QWord;
This error implies that one of the units in the 'uses' clause of the 'implementation' section is likely redeclaring HMODULE. The only non-Indy units in that clause are Classes and DynLibs. So I'm guessing DynLibs is at fault. But then, I would expect a similar error in the IdGlobal unit as well, as it defines HackLoad() in the 'interface' section to return an HMODULE (in which case, I guess I should remove the type-casts when IdSSLOpenSSLHeaders calls HackLoad()), and DynLibs is used in the 'implementation' section.
IdSSLOpenSSLHeaders.pas
defines
SSLDLLVers : array [0..7] of string = ('.10','.1.0.2','.1.0.1','.1.0.0','0.9.9','.0.9.8','.0.9.7','0.9.6');
Note: I think '0.9.9' should probably have been '.0.9.9' in the above, but that is a lesser... bug?
Fixed.
I just checked the what onlinepackagemanager addin in Lazarus downloads - and it downloads an old version - at least on Lazarus Trunk on Mojave
I inspected it by looking at the above - and the .0.9.9 / 0.9.9 issues is no fixed in the version it uses. (I assume that means it uses an old version)
Not sure where to report but... Now I have posted it here...
Update: Yup, turrns out that the DynLibs unit does define its own HModule type, as an alias for TLibHandle, which is an alias for PtrInt. Whereas System.HMODULE is defined as an alias for PtrUInt instead. Why isn't DynLibs using System.HMODULE instead of defining its own type?