Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2014-04

https support; call for testers

32 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Michael Van Canneyt

Hello,

I've just committed support for SSL in the ssockets unit of FPC. I also made the OpenSSL unit more thread-safe.

One consequence of this is that the fphttpclient unit now has support for the https:// protocol.

I have tested on windows and unix, the support for client-side SSL support works. Server-side support (as could be done in the embedded httpserver) is not yet tested.

I would like to invite people to test and report if they find problems or missing features.

That this support is released around the same time as the heartbleed leak issue, is entirely coincidental and definitely not intended.

Michael.

Reply by email

Dimitrios Chr. Ioannidis
to Michael Van Canneyt

Hi,

Στις 11/4/2014 4:00 μμ, ο/η Michael Van Canneyt έγραψε:

Show quoted text 6 lines
Hello, I've just committed support for SSL in the ssockets unit of FPC. I also made the OpenSSL unit more thread-safe.

Great News !!! Thx a lot.

Did you backported it to barnch fixes_2.6 also ?

I needed for a project starting Monday but i have to use 2.6.4 ( prefer fixes_2.6 branch ) so i'll definitely test it to avoid using synapse ...

That this support is released around the same time as the heartbleed leak issue, is entirely coincidental and definitely not intended.

;)

Regards,

Dimitrios Chr. Ioannidis

Reply by email

Dimitrios Chr. Ioannidis
to Michael Van Canneyt: I've just committed support for SSL in the ssockets unit of FPC. I also made the OpenSSL…

Hi,

Στις 11/4/2014 4:00 μμ, ο/η Michael Van Canneyt έγραψε:

Show quoted text 6 lines
Hello, I've just committed support for SSL in the ssockets unit of FPC. I also made the OpenSSL unit more thread-safe.

Great News !!! Thx a lot.

Did you backported it to barnch fixes_2.6 also ?

I needed for a project starting Monday but i have to use 2.6.4 ( prefer fixes_2.6 branch ) so i'll definitely test it to avoid using synapse ...

That this support is released around the same time as the heartbleed leak issue, is entirely coincidental and definitely not intended.

;)

Regards,

Dimitrios Chr. Ioannidis

Reply by email

Michael Van Canneyt
to Dimitrios Chr. Ioannidis: Στις 11/4/2014 4:00 μμ, ο/η Michael Van Canneyt έγραψε: Great News !!! Thx…
Dimitrios Chr. Ioannidis wrote 13 lines
Hi, Στις 11/4/2014 4:00 μμ, ο/η Michael Van Canneyt έγραψε: > > Hello, > > I've just committed support for SSL in the ssockets unit of FPC. > I also made the OpenSSL unit more thread-safe. > Great News !!! Thx a lot. Did you backported it to barnch fixes_2.6 also ?

No. Even if this would be the intention in the future, it is too early for that. The units need some testing first.

I needed for a project starting Monday but i have to use 2.6.4 ( prefer fixes_2.6 branch ) so i'll definitely test it to avoid using synapse ...

I doubt there will be a 2.6.x release still.

But I compiled everything with 2.6.4, and it worked. You should be able to copy the following units from trunk to your projects directory:

openssl/src/openssl.pas
openssl/src/fpopenssl.pp
fcl-net/src/ssockets.pp
fcl-net/src/sslsockets.pp
fcl-web/src/fphttpclient.pp

and it should function.

Michael.

Reply by email

Dimitrios Chr. Ioannidis
to Michael Van Canneyt

Hi,

Στις 11/4/2014 4:26 μμ, ο/η Michael Van Canneyt έγραψε:

Show quoted text 36 lines
On Fri, 11 Apr 2014, Dimitrios Chr. Ioannidis wrote: > Hi, > > Στις 11/4/2014 4:00 μμ, ο/η Michael Van Canneyt έγραψε: >> >> Hello, >> >> I've just committed support for SSL in the ssockets unit of FPC. >> I also made the OpenSSL unit more thread-safe. >> > > Great News !!! Thx a lot. > > Did you backported it to barnch fixes_2.6 also ? No. Even if this would be the intention in the future, it is too early for that. The units need some testing first. > I needed for a project starting Monday but i have to use 2.6.4 ( > prefer fixes_2.6 branch ) so i'll definitely test it to avoid using > synapse ... I doubt there will be a 2.6.x release still. But I compiled everything with 2.6.4, and it worked. You should be able to copy the following units from trunk to your projects directory: openssl/src/openssl.pas openssl/src/fpopenssl.pp fcl-net/src/ssockets.pp fcl-net/src/sslsockets.pp fcl-web/src/fphttpclient.pp

I already done that and started to test it ...

Thx again ...

regards,

Dimitrios Chr. Ioannidis

Reply by email

Dimitrios Chr. Ioannidis
to Michael Van Canneyt: No. Even if this would be the intention in the future, it is too early for that. The…

Hi,

i had to add support for client side Server Name Indication (SNI) TLS extension which is supported in OpenSSL from version 0.9.8 ( k ? ) ( http://en.wikipedia.org/wiki/Server_Name_Indication ) .

It's a trivial change ( doesn't break anything, i think ... ) so can you review it for inclusion ?

Regarding the absense of a switch ( at least ) for the SSCtrl call i read in the net that "... but looking at the OpenSSL code there is no harm done calling SSL_ctrl using undefined cmd parameters. Support for the SSL_CTRL_SET_TLSEXT_HOSTNAME can also be disabled when compiling openssl which confirms the no harm done."

   Index: fcl-net/src/sslsockets.pp
===================================================================
--- fcl-net/src/sslsockets.pp    (revision 27686)
+++ fcl-net/src/sslsockets.pp    (working copy)
@@ -226,6 +226,8 @@
      Result:=CheckSSL(FSSL.SetFD(FSocket.Handle));
      if Result then
       begin
+     SSLCtrl(FSSL.SSL, SSL_CTRL_SET_TLSEXT_HOSTNAME,
TLSEXT_NAMETYPE_host_name,
+       PAnsiChar(AnsiString(TInetSocket(FSocket).Host)));
       Result:=CheckSSL(FSSL.Connect);
       if Result and VerifyPeerCert then
         Result:=(FSSL.VerifyResult0) or (not DoVerifyCert);
Index: openssl/src/openssl.pas
===================================================================
--- openssl/src/openssl.pas    (revision 27686)
+++ openssl/src/openssl.pas    (working copy)
@@ -642,7 +642,10 @@
  //DES modes
    DES_ENCRYPT = 1;
    DES_DECRYPT = 0;
-
+
+  SSL_CTRL_SET_TLSEXT_HOSTNAME = 55;
+  TLSEXT_NAMETYPE_host_name = 0;
+
  var
    SSLLibHandle: TLibHandle = 0;
    SSLUtilHandle: TLibHandle = 0;

Regards,

Dimitrios Chr. Ioannidis

Reply by email

Michael Van Canneyt
to Dimitrios Chr. Ioannidis
Dimitrios Chr. Ioannidis wrote 14 lines
Hi, i had to add support for client side Server Name Indication (SNI) TLS extension which is supported in OpenSSL from version 0.9.8 ( k ? ) ( http://en.wikipedia.org/wiki/Server_Name_Indication ) . It's a trivial change ( doesn't break anything, i think ... ) so can you review it for inclusion ? Regarding the absense of a switch ( at least ) for the SSCtrl call i read in the net that "... but looking at the OpenSSL code there is no harm done calling SSL_ctrl using undefined cmd parameters. Support for the SSL_CTRL_SET_TLSEXT_HOSTNAME can also be disabled when compiling openssl which confirms the no harm done."

I implemented the support, but did it differently.
- Added some more missing constants
- Added Ctrl() method to TSSL object
- Added SendHostAsSNI : boolean property to TSSLHandler. By default it is set to true.

Thanks for your addition.
Definite proof that open source is still the best way for software development.

Michael.

Reply by email

Tomas Hajny
to Michael Van Canneyt
Michael Van Canneyt wrote 24 lines
On Wed, 30 Apr 2014, Dimitrios Chr. Ioannidis wrote: > Hi, > > i had to add support for client side Server Name Indication (SNI) TLS > extension which is supported in OpenSSL from version 0.9.8 ( k ? ) ( > http://en.wikipedia.org/wiki/Server_Name_Indication ) . > > It's a trivial change ( doesn't break anything, i think ... ) so can you > review it for inclusion ? > > Regarding the absense of a switch ( at least ) for the SSCtrl call i read > in the net that "... but looking at the OpenSSL code there is no harm done > calling SSL_ctrl using undefined cmd parameters. Support for the > SSL_CTRL_SET_TLSEXT_HOSTNAME can also be disabled when compiling openssl > which confirms the no harm done." I implemented the support, but did it differently. - Added some more missing constants - Added Ctrl() method to TSSL object - Added SendHostAsSNI : boolean property to TSSLHandler. By default it is set to true. Thanks for your addition. Definite proof that open source is still the best way for software development.

Well, yes. Unfortunately, there's also a proof of certain open source inefficiency if not following the open source approach fully (in particular by forking the original source instead of pushing improvements and extensions upstream). :-( The OpenSSL library originally comes from Synapse. It was apparently forked by Ales Katona back in 2006. Since then, different changes (fixes, improvements and extensions) have been performed independently on both sides. Would it be better if there's only one version containing fixes from both projects (even if this version is located on two different places)? Yes, of course, but noone takes care about this... :-(

Tomas

Reply by email

Michael Van Canneyt
to Tomas Hajny
Tomas Hajny wrote 37 lines
On 1 May 14, at 16:36, Michael Van Canneyt wrote: > On Wed, 30 Apr 2014, Dimitrios Chr. Ioannidis wrote: > >> Hi, >> >> i had to add support for client side Server Name Indication (SNI) TLS >> extension which is supported in OpenSSL from version 0.9.8 ( k ? ) ( >> http://en.wikipedia.org/wiki/Server_Name_Indication ) . >> >> It's a trivial change ( doesn't break anything, i think ... ) so can you >> review it for inclusion ? >> >> Regarding the absense of a switch ( at least ) for the SSCtrl call i read >> in the net that "... but looking at the OpenSSL code there is no harm done >> calling SSL_ctrl using undefined cmd parameters. Support for the >> SSL_CTRL_SET_TLSEXT_HOSTNAME can also be disabled when compiling openssl >> which confirms the no harm done." > > I implemented the support, but did it differently. > - Added some more missing constants > - Added Ctrl() method to TSSL object > - Added SendHostAsSNI : boolean property to TSSLHandler. By default it is set to true. > > Thanks for your addition. > Definite proof that open source is still the best way for software development. Well, yes. Unfortunately, there's also a proof of certain open source inefficiency if not following the open source approach fully (in particular by forking the original source instead of pushing improvements and extensions upstream). :-( The OpenSSL library originally comes from Synapse. It was apparently forked by Ales Katona back in 2006. Since then, different changes (fixes, improvements and extensions) have been performed independently on both sides. Would it be better if there's only one version containing fixes from both projects (even if this version is located on two different places)? Yes, of course, but noone takes care about this... :-(

I had thought about this. In general, I try to take care of this concern, since it is my concern as well.

But do not forget that synapse is also meant to be compileable with Delphi. That complicates matters somewhat.

In this particular case I even started on a complete port of the openssl headers (synapse contains only a part). But the openSSL code is really, really messy. Lots of macros. So I dropped it.

As a side note:
I'm not really surprised to hear about the heartbleed bug: even C programmers should get scared looking at the code. I was therefor glad to hear that the BSD team started on a rewrite (libreSSL). Maybe it will result in cleaner code.

Michael.

Reply by email

Tomas Hajny
to Michael Van Canneyt
Michael Van Canneyt wrote
On Thu, 1 May 2014, Tomas Hajny wrote: > On 1 May 14, at 16:36, Michael Van Canneyt wrote:

.
.

Show quoted text 17 lines
>> Thanks for your addition. >> Definite proof that open source is still the best way for software development. > > Well, yes. Unfortunately, there's also a proof of certain open source > inefficiency if not following the open source approach fully (in > particular by forking the original source instead of pushing > improvements and extensions upstream). :-( The OpenSSL library > originally comes from Synapse. It was apparently forked by Ales > Katona back in 2006. Since then, different changes (fixes, > improvements and extensions) have been performed independently on > both sides. Would it be better if there's only one version containing > fixes from both projects (even if this version is located on two > different places)? Yes, of course, but noone takes care about this... > :-( I had thought about this. In general, I try to take care of this concern, since it is my concern as well.

What do you mean that you try to take care? Will you try to re-align the two and e.g. send the latest improvements to Lukas Gebauer? I'm ready to test proper working of my OS/2 support related changes added earlier to Synapse once they get merged to the FPC tree. ;-)

But do not forget that synapse is also meant to be compileable with Delphi. That complicates matters somewhat.

Yes, it does to certain level. However, it isn't so bad in my point of view:

1) I believe that Lukas would happily take care about maintaining compatibility of provided changes to other compilers.

2) I don't see a big issue with keeping support for other compilers inside a unit within the FPC tree as long as this part is maintained by someone else.

3) I believe that it shouldn't be difficult to avoid using constructs absolutely specific to FPC in a unit which was primarily meant as means for accessing and using OpenSSL library functionality.

.
.

As a side note: I'm not really surprised to hear about the heartbleed bug: even C programmers should get scared looking at the code. I was therefor glad to hear that the BSD team started on a rewrite (libreSSL). Maybe it will result in cleaner code.

Maybe. Or it is wishful thinking. ;-)

Tomas

Reply by email

Michael Van Canneyt
to Tomas Hajny: . . What do you mean that you try to take care? Will you try to re-align the two and e.g.…
Tomas Hajny wrote 8 lines
> > I had thought about this. In general, I try to take care of this concern, > since it is my concern as well. What do you mean that you try to take care? Will you try to re-align the two and e.g. send the latest improvements to Lukas Gebauer? I'm ready to test proper working of my OS/2 support related changes added earlier to Synapse once they get merged to the FPC tree. ;-)

I merged the synapse version to the FPC tree; that took some work. The FPC tree differs meanwhile too much, it would break existing code if we just copied over the file.

Show quoted text 16 lines
> But do not forget that synapse is also meant to be compileable with Delphi. > That complicates matters somewhat. Yes, it does to certain level. However, it isn't so bad in my point of view: 1) I believe that Lukas would happily take care about maintaining compatibility of provided changes to other compilers. 2) I don't see a big issue with keeping support for other compilers inside a unit within the FPC tree as long as this part is maintained by someone else. 3) I believe that it shouldn't be difficult to avoid using constructs absolutely specific to FPC in a unit which was primarily meant as means for accessing and using OpenSSL library functionality.

Yes, if you start from scratch: absolutely agreed. It is too late for this, and that is why I didn't copy over.

Show quoted text 6 lines
> As a side note: > I'm not really surprised to hear about the heartbleed bug: even C programmers > should get scared looking at the code. I was therefor glad to hear that the > BSD team started on a rewrite (libreSSL). Maybe it will result in cleaner code. Maybe. Or it is wishful thinking. ;-)

Well: first reports are good, so there is hope.

And hope dies last...

Michael.

Reply by email

Tomas Hajny
to Michael Van Canneyt
Michael Van Canneyt wrote 15 lines
On Thu, 1 May 2014, Tomas Hajny wrote: >> >> I had thought about this. In general, I try to take care of this >> concern, >> since it is my concern as well. > > What do you mean that you try to take care? Will you try to re-align > the two and e.g. send the latest improvements to Lukas Gebauer? I'm > ready to test proper working of my OS/2 support related changes added > earlier to Synapse once they get merged to the FPC tree. ;-) I merged the synapse version to the FPC tree; that took some work. The FPC tree differs meanwhile too much, it would break existing code if we just copied over the file.

Sure, I understand that just copying the file over isn't the right solution now. If I may suggest, I'd at least mention in comments the Synapse SVN revision to which the synchronization has been performed so that future re-sync efforts may be limited only to differences since the mentioned revision.

What was your key for deciding which changes to include and which not? As an example, the OS/2 support mentioned above has apparently not been merged by you. I can obviously do that part myself, but I wonder if there is some other stuff which you decided not to include.

Do I understand it correctly that you do not intend to provide the FPC extensions to Lukas Gebauer? I would probably try to do it myself in that case.

Tomas

Reply by email

Michael Van Canneyt
to Tomas Hajny
Tomas Hajny wrote 22 lines
On Fri, May 2, 2014 08:47, Michael Van Canneyt wrote: > On Thu, 1 May 2014, Tomas Hajny wrote: > >>> >>> I had thought about this. In general, I try to take care of this >>> concern, >>> since it is my concern as well. >> >> What do you mean that you try to take care? Will you try to re-align >> the two and e.g. send the latest improvements to Lukas Gebauer? I'm >> ready to test proper working of my OS/2 support related changes added >> earlier to Synapse once they get merged to the FPC tree. ;-) > > I merged the synapse version to the FPC tree; that took some work. > The FPC tree differs meanwhile too much, it would break existing > code if we just copied over the file. Sure, I understand that just copying the file over isn't the right solution now. If I may suggest, I'd at least mention in comments the Synapse SVN revision to which the synchronization has been performed so that future re-sync efforts may be limited only to differences since the mentioned revision.

Now you are assuming that I know this version :-)

Show quoted text 5 lines
What was your key for deciding which changes to include and which not? As an example, the OS/2 support mentioned above has apparently not been merged by you. I can obviously do that part myself, but I wonder if there is some other stuff which you decided not to include.

I merged what I needed. It was not a 'concerted effort'.

Do I understand it correctly that you do not intend to provide the FPC extensions to Lukas Gebauer? I would probably try to do it myself in that case.

They are not so much extensions (although there are a couple, I assume), just some cases where things have been done differently.

Michael.

Reply by email

Tomas Hajny
to Michael Van Canneyt
Michael Van Canneyt wrote 25 lines
On Fri, 2 May 2014, Tomas Hajny wrote: > On Fri, May 2, 2014 08:47, Michael Van Canneyt wrote: >> On Thu, 1 May 2014, Tomas Hajny wrote: >> >>>> >>>> I had thought about this. In general, I try to take care of this >>>> concern, >>>> since it is my concern as well. >>> >>> What do you mean that you try to take care? Will you try to re-align >>> the two and e.g. send the latest improvements to Lukas Gebauer? I'm >>> ready to test proper working of my OS/2 support related changes added >>> earlier to Synapse once they get merged to the FPC tree. ;-) >> >> I merged the synapse version to the FPC tree; that took some work. >> The FPC tree differs meanwhile too much, it would break existing >> code if we just copied over the file. > > Sure, I understand that just copying the file over isn't the right > solution now. If I may suggest, I'd at least mention in comments the > Synapse SVN revision to which the synchronization has been performed so > that future re-sync efforts may be limited only to differences since the > mentioned revision. Now you are assuming that I know this version :-)

I thought that you had used the Synapse SVN repository (https://svn.code.sf.net/p/synalist/code/trunk) as your source.

.
.

Show quoted text 7 lines
> Do I understand it correctly that you do not intend to provide the FPC > extensions to Lukas Gebauer? I would probably try to do it myself in > that > case. They are not so much extensions (although there are a couple, I assume), just some cases where things have been done differently.

As far as I can see, there are quite a few additional function imports and constants added in the FPC version. You can find references to such added blocks / groups in the "changelog" included in comments at the top (RAND functions, x509 related declarations); obviously, some sort of graphical diff & merge tool helps finding the details fairly well.

Tomas

Reply by email

Dimitrios Chr. Ioannidis
to Dimitrios Chr. Ioannidis: Στις 11/4/2014 4:26 μμ, ο/η Michael Van Canneyt έγραψε: I already done that…

Hi,

Στις 11/4/2014 4:26 μμ, ο/η Michael Van Canneyt έγραψε: >

<snip>

Show quoted text 13 lines
> But I compiled everything with 2.6.4, and it worked. > You should be able to copy the following units from trunk to your > projects directory: > > openssl/src/openssl.pas > openssl/src/fpopenssl.pp > fcl-net/src/ssockets.pp > fcl-net/src/sslsockets.pp > fcl-web/src/fphttpclient.pp I already done that and started to test it ... Thx again ...

i didn't test in trunk but in fpc 2.6.4 i always get this mem leak

Show quoted text 40 lines
C:\Users\dimitris\Programming\Projects\prjTestFPSSL\bin\prjTestFPSSL.exe Heap dump by heaptrc unit 1453 memory blocks allocated : 1627489/1631184 1451 memory blocks freed : 1627473/1631168 2 unfreed memory blocks : 16 True heap size : 655360 (128 used in System startup) True free heap : 655072 Should be : 655088 Call trace for block $00317B80 size 8 $0040B976 file: objpas.inc : 345; $0056D46F TSSL__CREATE, line 361 of C:/Users/dimitris/Programming/Projects/prjTestFPSSL/source/fpopenssl.pp $00569705 TSSLSOCKETHANDLER__INITCONTEXT, line 367 of C:/Users/dimitris/Programming/Projects/prjTestFPSSL/source/sslsockets.pp $00568F76 TSSLSOCKETHANDLER__CONNECT, line 227 of C:/Users/dimitris/Programming/Projects/prjTestFPSSL/source/sslsockets.pp $00566C6A TINETSOCKET__CONNECT, line 868 of C:/Users/dimitris/Programming/Projects/prjTestFPSSL/source/ssockets.pp $00562E73 TFPCUSTOMHTTPCLIENT__CONNECTTOSERVER, line 449 of C:/Users/dimitris/Programming/Projects/prjTestFPSSL/source/fphttpclient.pp $005651D5 TFPCUSTOMHTTPCLIENT__DOMETHOD, line 932 of C:/Users/dimitris/Programming/Projects/prjTestFPSSL/source/fphttpclient.pp $00565AFA TFPCUSTOMHTTPCLIENT__HTTPMETHOD, line 1030 of C:/Users/dimitris/Programming/Projects/prjTestFPSSL/source/fphttpclient.pp Call trace for block $00317B30 size 8 $0040B976 file: objpas.inc : 345; $0056C8DF TSSLCONTEXT__CREATE, line 142 of C:/Users/dimitris/Programming/Projects/prjTestFPSSL/source/fpopenssl.pp $00569538 TSSLSOCKETHANDLER__INITCONTEXT, line 344 of C:/Users/dimitris/Programming/Projects/prjTestFPSSL/source/sslsockets.pp $00568F76 TSSLSOCKETHANDLER__CONNECT, line 227 of C:/Users/dimitris/Programming/Projects/prjTestFPSSL/source/sslsockets.pp $00566C6A TINETSOCKET__CONNECT, line 868 of C:/Users/dimitris/Programming/Projects/prjTestFPSSL/source/ssockets.pp $00562E73 TFPCUSTOMHTTPCLIENT__CONNECTTOSERVER, line 449 of C:/Users/dimitris/Programming/Projects/prjTestFPSSL/source/fphttpclient.pp $005651D5 TFPCUSTOMHTTPCLIENT__DOMETHOD, line 932 of C:/Users/dimitris/Programming/Projects/prjTestFPSSL/source/fphttpclient.pp $00565AFA TFPCUSTOMHTTPCLIENT__HTTPMETHOD, line 1030 of C:/Users/dimitris/Programming/Projects/prjTestFPSSL/source/fphttpclient.pp

all the latest file from trunk copied to project dir.

Using fpc latest fpc 2.6 fixes branch on windows 7 64 .

Any hint ?

regards,

Dimitrios Chr. Ioannidis

Reply by email

Michael Van Canneyt
to Dimitrios Chr. Ioannidis
Dimitrios Chr. Ioannidis wrote 11 lines
Hi, > Στις 11/4/2014 4:26 μμ, ο/η Michael Van Canneyt έγραψε: > C:/Users/dimitris/Programming/Projects/prjTestFPSSL/source/fphttpclient.pp all the latest file from trunk copied to project dir. Using fpc latest fpc 2.6 fixes branch on windows 7 64 . Any hint ?

There was indeed such a memory leak, but I already fixed that. You should take the latest version of ssockets.pp

Michael.

Reply by email

Dimitrios Chr. Ioannidis
to Michael Van Canneyt

Hi Michael,

Στις 8/5/2014 10:58 πμ, ο/η Michael Van Canneyt έγραψε:

Show quoted text 19 lines
On Wed, 7 May 2014, Dimitrios Chr. Ioannidis wrote: > Hi, > >> Στις 11/4/2014 4:26 μμ, ο/η Michael Van Canneyt έγραψε: >> C:/Users/dimitris/Programming/Projects/prjTestFPSSL/source/fphttpclient.pp >> > > > all the latest file from trunk copied to project dir. > > Using fpc latest fpc 2.6 fixes branch on windows 7 64 . > > Any hint ? There was indeed such a memory leak, but I already fixed that. You should take the latest version of ssockets.pp

i can confirm that for the non ssl is ok. When someone enables the ssl the mem leak appears.

Plz try with https.

regards,

Dimitrios Chr. Ioannidis

Reply by email

Michael Van Canneyt
to Dimitrios Chr. Ioannidis
Dimitrios Chr. Ioannidis wrote 26 lines
Hi Michael, Στις 8/5/2014 10:58 πμ, ο/η Michael Van Canneyt έγραψε: > > > On Wed, 7 May 2014, Dimitrios Chr. Ioannidis wrote: > >> Hi, >> >>> Στις 11/4/2014 4:26 μμ, ο/η Michael Van Canneyt έγραψε: >>> C:/Users/dimitris/Programming/Projects/prjTestFPSSL/source/fphttpclient.pp >> >> >> all the latest file from trunk copied to project dir. >> >> Using fpc latest fpc 2.6 fixes branch on windows 7 64 . >> >> Any hint ? > > There was indeed such a memory leak, but I already fixed that. > You should take the latest version of ssockets.pp i can confirm that for the non ssl is ok. When someone enables the ssl the mem leak appears. Plz try with https.

Hm. OK, I will have a look today.

Michael.

Reply by email

Michael Van Canneyt
to Michael Van Canneyt
Michael Van Canneyt wrote 14 lines
>>> >>> Using fpc latest fpc 2.6 fixes branch on windows 7 64 . >>> >>> Any hint ? >> >> There was indeed such a memory leak, but I already fixed that. >> You should take the latest version of ssockets.pp > > i can confirm that for the non ssl is ok. When someone enables the ssl the > mem leak appears. > > Plz try with https. Hm. OK, I will have a look today.

Identified, fixed and committed. Thanks for reporting this.

Michael.

Reply by email

Dimitrios Chr. Ioannidis
to Dimitrios Chr. Ioannidis: Στις 11/4/2014 4:26 μμ, ο/η Michael Van Canneyt έγραψε: I already done that…

Ηι,

Στις 11/4/2014 4:26 μμ, ο/η Michael Van Canneyt έγραψε: >

<snip>

Show quoted text 13 lines
> But I compiled everything with 2.6.4, and it worked. > You should be able to copy the following units from trunk to your > projects directory: > > openssl/src/openssl.pas > openssl/src/fpopenssl.pp > fcl-net/src/ssockets.pp > fcl-net/src/sslsockets.pp > fcl-web/src/fphttpclient.pp I already done that and started to test it ... Thx again ...

i'm getting an range check error with not properly configured https sites.

I know that the https infrastructure isn't properly configured but shouldn't the ssl socket raise an error reg. wrong certificate ( or somethink like that ) instead of throw a range check error and of course new mem leaks ?

You can check the following address https://www.zougla.gr ( which is in an akamai ).

regards,

Dimitrios Chr. Ioannidis

Reply by email

Michael Van Canneyt
to Dimitrios Chr. Ioannidis
Dimitrios Chr. Ioannidis wrote 27 lines
Ηι, > Στις 11/4/2014 4:26 μμ, ο/η Michael Van Canneyt έγραψε: >> <snip> >> But I compiled everything with 2.6.4, and it worked. >> You should be able to copy the following units from trunk to your projects >> directory: >> >> openssl/src/openssl.pas >> openssl/src/fpopenssl.pp >> fcl-net/src/ssockets.pp >> fcl-net/src/sslsockets.pp >> fcl-web/src/fphttpclient.pp > > I already done that and started to test it ... > > Thx again ... i'm getting an range check error with not properly configured https sites. I know that the https infrastructure isn't properly configured but shouldn't the ssl socket raise an error reg. wrong certificate ( or somethink like that ) instead of throw a range check error and of course new mem leaks ? You can check the following address https://www.zougla.gr ( which is in an akamai ).

I can't reproduce this. I get a 504 error.

Michael.

Reply by email

Dimitrios Chr. Ioannidis
to Michael Van Canneyt

Hi,

Στις 10/5/2014 5:30 μμ, ο/η Michael Van Canneyt έγραψε:

Show quoted text 35 lines
On Sat, 10 May 2014, Dimitrios Chr. Ioannidis wrote: > Ηι, > >> Στις 11/4/2014 4:26 μμ, ο/η Michael Van Canneyt έγραψε: >>> > <snip> >>> But I compiled everything with 2.6.4, and it worked. >>> You should be able to copy the following units from trunk to your >>> projects directory: >>> >>> openssl/src/openssl.pas >>> openssl/src/fpopenssl.pp >>> fcl-net/src/ssockets.pp >>> fcl-net/src/sslsockets.pp >>> fcl-web/src/fphttpclient.pp >> >> I already done that and started to test it ... >> >> Thx again ... > > i'm getting an range check error with not properly configured https > sites. > > I know that the https infrastructure isn't properly configured but > shouldn't the ssl socket raise an error reg. wrong certificate ( or > somethink like that ) instead of throw a range check error and of > course new mem leaks ? > > You can check the following address https://www.zougla.gr ( which is > in an akamai ). I can't reproduce this. I get a 504 error.

i'm still getting range check error but after you fixed bug id 0026130 i no longer have mem leaks.

thx

regards,

Dimitrios Chr. Ioannidis

Reply by email

Michael Van Canneyt
to Dimitrios Chr. Ioannidis
Dimitrios Chr. Ioannidis wrote 40 lines
Hi, Στις 10/5/2014 5:30 μμ, ο/η Michael Van Canneyt έγραψε: > > > On Sat, 10 May 2014, Dimitrios Chr. Ioannidis wrote: > >> Ηι, >> >>> Στις 11/4/2014 4:26 μμ, ο/η Michael Van Canneyt έγραψε: >>>> >> <snip> >>>> But I compiled everything with 2.6.4, and it worked. >>>> You should be able to copy the following units from trunk to your >>>> projects directory: >>>> >>>> openssl/src/openssl.pas >>>> openssl/src/fpopenssl.pp >>>> fcl-net/src/ssockets.pp >>>> fcl-net/src/sslsockets.pp >>>> fcl-web/src/fphttpclient.pp >>> >>> I already done that and started to test it ... >>> >>> Thx again ... >> >> i'm getting an range check error with not properly configured https sites. >> >> I know that the https infrastructure isn't properly configured but >> shouldn't the ssl socket raise an error reg. wrong certificate ( or >> somethink like that ) instead of throw a range check error and of course >> new mem leaks ? >> >> You can check the following address https://www.zougla.gr ( which is in an >> akamai ). > > I can't reproduce this. I get a 504 error. i'm still getting range check error but after you fixed bug id 0026130 i no longer have mem leaks.

Can you post a test program please, or at least a GDB backtrace so I can track the error ?

Michael.

Reply by email

Dimitrios Chr. Ioannidis
to Michael Van Canneyt

Hi,

Στις 11/5/2014 9:10 μμ, ο/η Michael Van Canneyt έγραψε:

Show quoted text 48 lines
On Sun, 11 May 2014, Dimitrios Chr. Ioannidis wrote: > Hi, > > Στις 10/5/2014 5:30 μμ, ο/η Michael Van Canneyt έγραψε: >> >> >> On Sat, 10 May 2014, Dimitrios Chr. Ioannidis wrote: >> >>> Ηι, >>> >>>> Στις 11/4/2014 4:26 μμ, ο/η Michael Van Canneyt έγραψε: >>>>> >>> <snip> >>>>> But I compiled everything with 2.6.4, and it worked. >>>>> You should be able to copy the following units from trunk to your >>>>> projects directory: >>>>> >>>>> openssl/src/openssl.pas >>>>> openssl/src/fpopenssl.pp >>>>> fcl-net/src/ssockets.pp >>>>> fcl-net/src/sslsockets.pp >>>>> fcl-web/src/fphttpclient.pp >>>> >>>> I already done that and started to test it ... >>>> >>>> Thx again ... >>> >>> i'm getting an range check error with not properly configured https >>> sites. >>> >>> I know that the https infrastructure isn't properly configured but >>> shouldn't the ssl socket raise an error reg. wrong certificate ( or >>> somethink like that ) instead of throw a range check error and of >>> course new mem leaks ? >>> >>> You can check the following address https://www.zougla.gr ( which >>> is in an akamai ). >> >> I can't reproduce this. I get a 504 error. > > i'm still getting range check error but after you fixed bug id > 0026130 i no longer have mem leaks. Can you post a test program please, or at least a GDB backtrace so I can track the error ?

fpc latest 2.6.x fixes branch and latest lazarus 1.2.3 .

Test program is very simple :

Show quoted text 50 lines
unit uAppMain; {$mode objfpc}{$H+} interface uses Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, StdCtrls; type { TForm1 } TForm1 = class(TForm) Button1: TButton; Edit1: TEdit; Memo1: TMemo; procedure Button1Click(Sender: TObject); private { private declarations } public { public declarations } end; var Form1: TForm1; implementation {$R *.lfm} uses fphttpclient; { TForm1 } procedure TForm1.Button1Click(Sender: TObject); var WebClient: TFPHttpClient; begin Memo1.Clear; WebClient := TFPHttpClient.Create(Nil); try Memo1.Append(WebClient.Get(edit1.Text)); finally FreeAndnil(WebClient); end; end; end.

BackTrace

#0 HANDLEERRORADDRFRAME(201, 0x15ff0dc, 0x2e2f48) at ..\inc\system.inc:962 #1 HANDLEERRORFRAME(201, 0x15ff0dc) at ..\inc\system.inc:992 #2 fpc_rangeerror at ..\inc\system.inc:653
#3 CONNECT(0x2e72a8) at ..\source\ssockets.pp:860
#4 CONNECTTOSERVER(0x3248120, 0x2e2f48 'www.zougla.gr', 443, true) at ..\source\fphttpclient.pp:449
#5 DOMETHOD(0x3248120, 0x5c28d0 'GET', 0x355e78
'https://www.zougla.gr/', 0x2e3840, 0x15ff31c, 0) at ..\source\fphttpclient.pp:932
#6 HTTPMETHOD(0x3248120, 0x5c28d0 'GET', 0x355e78
'https://www.zougla.gr/', 0x2e3840, 0x15ff31c, 0) at ..\source\fphttpclient.pp:1030
#7 GET(0x3248120, 0x355e78 'https://www.zougla.gr/', 0x2e3840) at ..\source\fphttpclient.pp:1066
#8 GET(0x3248120, 0x355e78 'https://www.zougla.gr/') at ..\source\fphttpclient.pp:1097
#9 BUTTON1CLICK(0x343a28, 0x3448e8) at ..\source\uappmain.pas:53 #10 CONTROLS_TCONTROL_$__CLICK at :0
#11 STDCTRLS_TBUTTONCONTROL_$__CLICK at :0
#12 STDCTRLS_TCUSTOMBUTTON_$__CLICK at :0
#13 STDCTRLS_TBUTTONCONTROL_$__WMDEFAULTCLICKED$TMESSAGE at :0 #14 DISPATCH(0x3448e8, 0) at ..\inc\objpas.inc:592 #15 CONTROLS_TCONTROL_$__WNDPROC$TMESSAGE at :0
#16 CONTROLS_TWINCONTROL_$__WNDPROC$TMESSAGE at :0 #17 LCLMESSAGEGLUE_DELIVERMESSAGE$TOBJECT$formal$$LONGINT at :0 #18 WIN32INT_WINDOWPROC$LONGWORD$LONGWORD$LONGINT$LONGINT$$LONGINT at :0 #19
WIN32WSFORMS_CUSTOMFORMWNDPROC$LONGWORD$LONGWORD$LONGINT$LONGINT$$LONGINT at :0
#20 gapfnScSendMessage at :0
#21 ?? at :0
#22 USER32!GetThreadDesktop at :0
#23 WIN32WSFORMS_ADJUSTFORMBOUNDS$TCUSTOMFORM$RECT at :0 #24 USER32!GetWindow at :0
#25 ?? at :0

regards,

Dimitrios Chr. Ioannidis

Reply by email

Michael Van Canneyt
to Dimitrios Chr. Ioannidis
Dimitrios Chr. Ioannidis wrote 6 lines
BackTrace #0 HANDLEERRORADDRFRAME(201, 0x15ff0dc, 0x2e2f48) at ..\inc\system.inc:962 #1 HANDLEERRORFRAME(201, 0x15ff0dc) at ..\inc\system.inc:992 #2 fpc_rangeerror at ..\inc\system.inc:653 #3 CONNECT(0x2e72a8) at ..\source\ssockets.pp:860

That is the line:

   addr.sin_addr.s_addr := HostToNet(a.s_addr);

Which has nothing to do with SSL.

I have no idea why this causes an error.

Michael.

Reply by email

Marco van de Voort
to Michael Van Canneyt

In our previous episode, Michael Van Canneyt said:

Show quoted text 9 lines
> > #0 HANDLEERRORADDRFRAME(201, 0x15ff0dc, 0x2e2f48) at ..\inc\system.inc:962 > #1 HANDLEERRORFRAME(201, 0x15ff0dc) at ..\inc\system.inc:992 > #2 fpc_rangeerror at ..\inc\system.inc:653 > #3 CONNECT(0x2e72a8) at ..\source\ssockets.pp:860 That is the line: addr.sin_addr.s_addr := HostToNet(a.s_addr);

HostToNet is only defined for in_addr and longint, and s_addr is cuint32.

Reply by email

Michael Van Canneyt
to Marco van de Voort
Marco van de Voort wrote 12 lines
In our previous episode, Michael Van Canneyt said: >> >> #0 HANDLEERRORADDRFRAME(201, 0x15ff0dc, 0x2e2f48) at ..\inc\system.inc:962 >> #1 HANDLEERRORFRAME(201, 0x15ff0dc) at ..\inc\system.inc:992 >> #2 fpc_rangeerror at ..\inc\system.inc:653 >> #3 CONNECT(0x2e72a8) at ..\source\ssockets.pp:860 > > That is the line: > > addr.sin_addr.s_addr := HostToNet(a.s_addr); HostToNet is only defined for in_addr and longint, and s_addr is cuint32.

On all platforms ?

Strange then that this error didn't happen before. Well, a simple typecast will solve this.

Michael.

Reply by email

Dimitrios Chr. Ioannidis
to Michael Van Canneyt

Hi,

Στις 12/5/2014 10:11 πμ, ο/η Michael Van Canneyt έγραψε:

Show quoted text 23 lines
On Mon, 12 May 2014, Marco van de Voort wrote: > In our previous episode, Michael Van Canneyt said: >>> >>> #0 HANDLEERRORADDRFRAME(201, 0x15ff0dc, 0x2e2f48) at >>> ..\inc\system.inc:962 >>> #1 HANDLEERRORFRAME(201, 0x15ff0dc) at ..\inc\system.inc:992 >>> #2 fpc_rangeerror at ..\inc\system.inc:653 >>> #3 CONNECT(0x2e72a8) at ..\source\ssockets.pp:860 >> >> That is the line: >> >> addr.sin_addr.s_addr := HostToNet(a.s_addr); > > HostToNet is only defined for in_addr and longint, and s_addr is > cuint32. On all platforms ? Strange then that this error didn't happen before. Well, a simple typecast will solve this.

you're correct if changed it to

addr.sin_addr.s_addr := HostToNet(LongInt(a.s_addr));

i get a 504 Error also.

regards,

Dimitrios Chr. Ioannidis

Reply by email

Marco van de Voort
to Michael Van Canneyt: On all platforms ? Strange then that this error didn't happen before. Well, a simple…

In our previous episode, Michael Van Canneyt said:

Show quoted text 6 lines
> HostToNet is only defined for in_addr and longint, and s_addr is cuint32. On all platforms ? Strange then that this error didn't happen before. Well, a simple typecast will solve this.

They are old, and carry this comment:

{ these for are for netdb legacy compat}

IIRC they were kept for 1.0.x compatibility, and the 32-bit unsigned support of that was not so great. Moreover I didn't care enough to deprecate them, but maybe we should.

The newer (1.9.2+) htons etc functions (introduced with that name for Kylix compat) are unsigned.

Reply by email

Michael Van Canneyt
to Marco van de Voort
Marco van de Voort wrote 15 lines
In our previous episode, Michael Van Canneyt said: >> HostToNet is only defined for in_addr and longint, and s_addr is cuint32. > > On all platforms ? > > Strange then that this error didn't happen before. > Well, a simple typecast will solve this. They are old, and carry this comment: { these for are for netdb legacy compat} IIRC they were kept for 1.0.x compatibility, and the 32-bit unsigned support of that was not so great. Moreover I didn't care enough to deprecate them, but maybe we should.

Eh, what are you talking about ? HostToNet ?
The 'On all platforms' was referring to 's_addr is cuint32'.

The newer (1.9.2+) htons etc functions (introduced with that name for Kylix compat) are unsigned.

We could deprecate HostToNet and let it call htons.

Michael.

Reply by email

Marco van de Voort
to Michael Van Canneyt

In our previous episode, Michael Van Canneyt said:

Show quoted text 8 lines
> > { these for are for netdb legacy compat} > > IIRC they were kept for 1.0.x compatibility, and the 32-bit unsigned support > of that was not so great. Moreover I didn't care enough to deprecate them, > but maybe we should. Eh, what are you talking about ? HostToNet ?

Yes. That's also the part that carried the "netdb legacy" comment.

Show quoted text 6 lines
The 'On all platforms' was referring to 's_addr is cuint32'. > The newer (1.9.2+) htons etc functions (introduced with that name for Kylix > compat) are unsigned. We could deprecate HostToNet and let it call htons.

Yup. Same for short* etc. I'll deprecate them when I have time somewhere today, and then will try to fix all warnings to the new ones.

Reply by email