Re: OpenSSL and Bug #1716

2006-08-26 Thread Guido Serassio

Hi Henrik,

Il 23.49 26/08/2006 Henrik Nordstrom ha scritto:


lör 2006-08-26 klockan 17:58 +0200 skrev Guido Serassio:

> /* Write out the SSL session details.. actually the call below, but
>   * OpenSSL headers do strange typecasts confusing GCC.. */
> /* PEM_write_SSL_SESSION(debug_log, SSL_get_session(ssl)); */
>
> For testing, I have replaced PEM_ASN1_write() call with the
> PEM_write_SSL_SESSION() macro, and this seems to fix all the errors
> that I have listed in bug #1716.

It depends on the version of OpenSSL I think. And maybe GCC warning
flags...

Which version of OpenSSL are you using?


A mix of OpenSSL 0.9.7b, 0.9.7d, 0.9.7e and 
0.9.7g with a  mix of gcc 3.4.2, 3.4.3, and 3.3.5.
All on different platforms: Solaris x86 9 & 10, 
OpenBDS 3.8, FreeBSD 5.3, Irix 6.5, HP Tru64 and Debian Linux 3.1.




If I do this here then I get the following errors:

squid-2.6/src/client_side.c: In function 'clientNegotiateSSL':
squid-2.6/src/client_side.c:4616: warning: 
function declaration isn't a prototype


squid-3/src/client_side.cc: In function 'void clientNegotiateSSL(int, void*)':
squid-3/src/client_side.cc:2933: error: invalid 
conversion from 'int (*)()' to 'int (*)(void*, unsigned char**)'
squid-3/src/client_side.cc:2933: 
error:   initializing argument 1 of 'int 
PEM_ASN1_write(int (*)(void*, unsigned char**), 
const char*, FILE*, char*, const EVP_CIPHER*, 
unsigned char*, int, int (*)(char*, int, int, void*), void*)'


This will make me crazy  :-(
It seems that it works only with OpenSSL 0.9.7.



Fedora Core 5 Linux on x86_64
OpenSSL 0.9.8a-5.2
gcc-4.1.1-1.fc5


I'm just configuring now a Fedora Core 5 Linux 
x86 virtual machine for testing purpose.


Tomorrow morning I will try to define a complete 
test suite, still I don't have found a rule of 
how this diabolic function prototype "works" ... :-)


Regards

Guido



-

Guido Serassio
Acme Consulting S.r.l. - Microsoft Certified Partner
Via Lucia Savarino, 1   10098 - Rivoli (TO) - ITALY
Tel. : +39.011.9530135  Fax. : +39.011.9781115
Email: [EMAIL PROTECTED]
WWW: http://www.acmeconsulting.it/



Re: [PATCH] Make URN support an optional component

2006-08-26 Thread Robert Collins
On Sun, 2006-08-27 at 00:51 +1000, Robert Collins wrote:
> This rather large patch starts breakout apart the bidirectional
> dependencies between the forwarding logic and the protocol
> implementations. The current result is that the URN protocol is now
> utterly invisible to all of the code except for the url parser which
> dispatches based on finding a matching scheme at runtime.

...

btw, its available as a bzr branch if you want to build it without
fiddling with patches - 

bzr branch
http://squid-cache.org/~robertc/bzr/squid/3.0/decouple-depends 

will get you a copy.

Cheers,
Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part


Re: OpenSSL and Bug #1716

2006-08-26 Thread Henrik Nordstrom
lör 2006-08-26 klockan 17:58 +0200 skrev Guido Serassio:

> For testing, I have replaced PEM_ASN1_write() call with the 
> PEM_write_SSL_SESSION() macro, and this seems to fix all the errors 
> that I have listed in bug #1716.
> 
> What is the history of this comment ?

It depends on the version of OpenSSL I think. And maybe GCC warning
flags...

Which version of OpenSSL are you using?


If I do this here then I get the following errors:

squid-2.6/src/client_side.c: In function 'clientNegotiateSSL':
squid-2.6/src/client_side.c:4616: warning: function declaration isn't a 
prototype

squid-3/src/client_side.cc: In function 'void clientNegotiateSSL(int, void*)':
squid-3/src/client_side.cc:2933: error: invalid conversion from 'int (*)()' to 
'int (*)(void*, unsigned char**)'
squid-3/src/client_side.cc:2933: error:   initializing argument 1 of 'int 
PEM_ASN1_write(int (*)(void*, unsigned char**), const char*, FILE*, char*, 
const EVP_CIPHER*, unsigned char*, int, int (*)(char*, int, int, void*), void*)'


Fedora Core 5 Linux on x86_64
OpenSSL 0.9.8a-5.2
gcc-4.1.1-1.fc5

Regards
Henrik


signature.asc
Description: Detta är en digitalt signerad	meddelandedel


OpenSSL and Bug #1716

2006-08-26 Thread Guido Serassio

Hi Henrik,

I'm trying to fix the C++ related problem of bug #1716, but I have one doubt.

At line 2930 of client_side.cc there is this comment:

/* Write out the SSL session details.. actually the call below, but
 * OpenSSL headers do strange typecasts confusing GCC.. */
/* PEM_write_SSL_SESSION(debug_log, SSL_get_session(ssl)); */

For testing, I have replaced PEM_ASN1_write() call with the 
PEM_write_SSL_SESSION() macro, and this seems to fix all the errors 
that I have listed in bug #1716.


What is the history of this comment ?

Regards

Guido


-

Guido Serassio
Acme Consulting S.r.l. - Microsoft Certified Partner
Via Lucia Savarino, 1   10098 - Rivoli (TO) - ITALY
Tel. : +39.011.9530135  Fax. : +39.011.9781115
Email: [EMAIL PROTECTED]
WWW: http://www.acmeconsulting.it/



[PATCH] Make URN support an optional component

2006-08-26 Thread Robert Collins
This rather large patch starts breakout apart the bidirectional
dependencies between the forwarding logic and the protocol
implementations. The current result is that the URN protocol is now
utterly invisible to all of the code except for the url parser which
dispatches based on finding a matching scheme at runtime.

The patch isn't ready to merge yet. To merge it three things need to
happen:
 * Someone needs to confirm I haven't broken URN support - or document
how it should be routinely tested so I can do so.
 * We should discuss what the default for urn support should be - I vote
for off.
 * I need to put a performance benchmark in place for the new scheme
lookup, its likely very slow at the moment (one function call per url
per scheme) - but the interface should be entirely compatible with the
trie based mapper I put together a ways back, or even just a vanilla STL
map - if we were to start using the stl.

I'd love feedback on this. Its a fairly significant step towards making
the core of squid unaware of the specific modules to forward via, and
that will make the connections between modules much tighter and easily
understandable -> easier to test, easier to fix, and easier to tune for
speed.

Cheers,
Rob
-- 
GPG key available at: .


signature.asc
Description: This is a digitally signed message part


Re: file == ftp ?!?!

2006-08-26 Thread Henrik Nordstrom
lör 2006-08-26 klockan 13:48 +1000 skrev Robert Collins:
> Currently squid treats a request for file:// as an alias to ftp://. I
> think this is bogus as all browsers I know of treat file:// as the local
> file scheme.
> 
> I'd like to remove this alias support from squid. Any objections?

No objection, I just don't see the point.

file: is an odd scheme. The official (RFC1738) syntax is

   file:///

   As a special case,  can be the string "localhost" or the empty
   string; this is interpreted as `the machine from which the URL is
   being interpreted'.

Many implementations also accept file:/path to refer to files on the
local host, even if not technically correct syntax per the RFC.

the difference from the other schemes is that there is no communication
method defined on how to transfer the file and it's up to the
implementation to define how to transfer the requested object from the
requested host. So there is nothing wrong with us mapping file:// to
ftp://, but not much use either as clients really shouldn't be sending
us file:// URLs under normal conditions.

Regards
Henrik


signature.asc
Description: Detta är en digitalt signerad	meddelandedel


Re: file == ftp ?!?!

2006-08-26 Thread Guido Serassio

Hi,

At 05.48 26/08/2006, Robert Collins wrote:


Currently squid treats a request for file:// as an alias to ftp://. I
think this is bogus as all browsers I know of treat file:// as the local
file scheme.


I agree.


I'd like to remove this alias support from squid. Any objections?


The same is also in 2.6.

Regards

Guido



-

Guido Serassio
Acme Consulting S.r.l. - Microsoft Certified Partner
Via Lucia Savarino, 1   10098 - Rivoli (TO) - ITALY
Tel. : +39.011.9530135  Fax. : +39.011.9781115
Email: [EMAIL PROTECTED]
WWW: http://www.acmeconsulting.it/