On Sat, 24 Aug 2002 00:09, Nick Gimbrone wrote:
> If I understand your desire here correctly, you are attempting to make it
> such that insecure sites that used to work still work unless the user (or
> developer using lib curl) does something explicit to close this security
> hole (by setting the additional option).

> Now, normally for an incompatible change like this, such an approach would
> be wonderful. But, when security issues are involved I think it is the
> wrong approach. The hole should be closed by default, even if that means
> that something that used to work by default nolonger does so. It should
> take an explicit setting of an "I don't care about security" option to
> cause insecure behaviour... and upward compatibility should not take
> precidence over security

I think I have to agree with Nick on this one - Users should have to
specifically disable security measures, because they almost never choose to
specifically enable them. A potential slight incompatibility would be a small
price to pay for an all-round security improvement.

If curl was distributed with (and used by default) a standard ca-bundle, the
practical impact of the change would be pretty small, and any issues could be
fixed by admin changes (adding the appropriate CA or site cert to the default
bundle) rather than by forcing a change in libcurl using code. (Whilst, of
course, still adding a command line option to explicitly skip cert checking.)

Just my $0.02

Cris

-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
Received on 2002-08-23