found a bug in IdSSLOpenSSL.pas
procedure DumpCert(AOut: TStrings; AX509: PX509);
->
BIO_get_mem_data( LMem, LBufPtr);
if (LLen > 0) and Assigned(LBufPtr) then begin
BIO_get_mem_data expects pointer to pointer
fixed code;
'
var
LMem: PBIO;
LLen : TIdC_INT;
LBufPtr : Pointer;
lPBPtr : Pointer;
begin
if Assigned(X509_print) then begin
LMem := BIO_new(BIO_s_mem);
try
lPBPtr := @LBufPtr;
X509_print(LMem, AX509);
LLen := BIO_get_mem_data( LMem, lPBPtr);
if (LLen > 0) and Assigned(LBufPtr) then begin'
Found a few type errors in IdSSLOpenSSLHeaders.pas:
In definitions of EVP_DecryptUpdate, EVP_DecryptFinal, EVP_DecryptFinal_ex, EVP_CipherUpdate and EVP_OpenFinal, the type of outl parameter should not be TIdC_INT, but PIdC_INT.
The next_proto_select_cb function pointer field in the definition of SSL_CTX record: Its definition should be either 'outlen : PIdAnsiChar' or 'out outlen: TIdAnsiChar' .
In definitions of EVP_DecryptUpdate, EVP_DecryptFinal, EVP_DecryptFinal_ex, EVP_CipherUpdate and EVP_OpenFinal, the type of outl parameter should not be TIdC_INT, but PIdC_INT.
The next_proto_select_cb function pointer field in the definition of SSL_CTX record: Its definition should be either 'outlen : PIdAnsiChar' or 'out outlen: TIdAnsiChar' .
@rkmanaz the original
DumpCert code is fine. Look at the declaration of BIO_get_mem_data() in IdSSLOpenSSLHeaders.pas: function BIO_get_mem_data(b : PBIO; out pp : Pointer) : TIdC_INT; In Delphi, out: Pointer is equivilent to void** in C. The original code was already passing a pointer-to-pointer. Your change is passing a pointer-to-pointer-to-pointer instead
i checked it with d7 as well as with dx
OpenSSL 1.0.2j 26 Sep 2016(VC-WIN32) compiler: cl /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_SSL2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_WEAK_SSL_CIPHERS -DOPENSSL_NO_STATIC_ENGINE
the used indy lib is somewhat older and abit adjusted to make it work under linux as well
but i checkede with the indy trunk and the important parts are the same
the only way it does work is, when i have a pointer var that i point to another pointer var and which one i pass to BIO_get_mem_data
under d7 nothing happens under dx i get an EA
to make sure, i tested with OpenSSL 1.0.2n 7 Dec 2017(VC-WIN32) compiler: cl /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -WX -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -D_WINSOCK_DEPRECATED_NO_WARNINGS -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_SSL2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_WEAK_SSL_CIPHERS -DOPENSSL_NO_STATIC_ENGINE
downloaded from https://indy.fulgan.com/SSL/
same thing
@rkmanaz I found the problem, and it is not in
DumpCert() at all, its original code is fine. The real problem is in BIO_get_mem_data() itself in IdSSLOpenSSLHeaders.pas. When it calls BIO_ctrl(), it is not passing the correct output pointer - Result := BIO_ctrl(b,BIO_CTRL_INFO,0,pp); should be Result := BIO_ctrl(b,BIO_CTRL_INFO,0,@pp); Looks like other functions, like BIO_get_mem_ptr and BIO_get_ssl, are also affected by a similar bug
@jpluimers I updated IndySockets/Indy#49 with the link to Paul's implementation so I don't lose it
Indy has an SSPI implementation that it uses for
TIdSSPINTLMAuthentication for NTLM over HTTP, but last time I looked at it, I seem to recall that it is not generalized enough for reuse with SChannel, which also uses SSPI. If we can finish fleshing out the IdSSPI unit with some missing pieces, and maybe port some of the code from the IdAuthenticationSSPI unit into IdSSPI or another common unit, that would go a long way to making an SChannel IOHandler easier to implement within Indy. I'm sure there are pieces of Paul's implementation that duplicate pieces that Indy already has and should reuse. I was already working on learning the SSPI API for SChannel use, but that effort is still in test code and not in Indy yet.
why the IdSASL_NTLM.pas file is not in the tokyo installer?
Only Embarcadero knows the exact reason
was it in one of those paths?
Hm, my image upload does not work atm :(
File only in Indy SVN: 'Protocols\IdSASL_NTLM.pas'
@jaclas this is actually covered in Indy's installation notes. And no, the REST library does not use Indy, but DataSnap and LiveTiles do
Backing up a little.. Using a binding that's added at design time seems to be different to what I'm doing at runtime:
var
LBinding: TIdSocketHandle;
begin
IdIPMCastClient1.IPVersion := TIdIPVersion.Id_IPv6;
IdIPMCastClient1.DefaultPort := 6000;
IdIPMCastClient1.MulticastGroup := 'FF02::1';
IdIPMCastClient1.Bindings.Clear;
LBinding := IdIPMCastClient1.Bindings.Add;
LBinding.IPVersion := IdIPMCastClient1.IPVersion;
LBinding.IP := '::';
LBinding.Port := IdIPMCastClient1.DefaultPort;
IdIPMCastClient1.Active := True;
end;
When there are no connections to an IPv6 network, it crashes on the setSockOpt call (called from TIdStackVCLPosix.SetSocketOption) when AddMulticastMembership is called. If I use the bindings editor to do the same thing (at least I hope it's the same), it does not crash
I'm guessing I'm doing something in the wrong order
@rlebeau
Daily occurrance... often multiple times per day... and on all 3 of my PCs..... and this is just one of the issues.
Daily occurrance... often multiple times per day... and on all 3 of my PCs..... and this is just one of the issues.
Dont get me started on JS.. .one fo the worst designed langauges ever.. decades behind others yet they think its cutting edge...... they get a new fewature in ES2015 other langs have had for 20 years and they all crow like they are the most advanced thing out there.... but until they get a feature all they do is downplay it....
My personal goal is to use as little of it as possible.. meanwhile I do some Angular development for my main client :-(