On Sat, 24 Aug 2002, Cris Bailiff wrote:

> 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.

Thank you guys for your patience with me in this issue.

I'm slowly being convinced that you guys are preaching the right religion,
and due to this fact I'm currently working on this:

$ curl https:[URL hidden to save the innocent]
curl: (58) Insecure SSL connect attempted without explicit permission granted
      Since SSL doesn't offer any true security if you don't use a CA
      certificate to verify the peer certificate with, you must either
      provide one to make sure that the server really is the server you
      think it is, or you must explicitly tell curl that insecure SSL
      connects are fine.
      Allow insecure SSL operations with -k/--insecure

... which in turn is controlled by the CURLOPT_SSL_INSECURE option to
libcurl. If that isn't set TRUE, this kind of insecure connections will
immediately return CURLE_SSL_INSECURE. Using -k will of course make curl work
as before (like 7.9.8 and all previous versions).

The particular verbose error message above is this verbose to help users
around the problems that this might introduce. I of course as always
appreciate your help on putting the words in a better order or entirely
different way to make end-users understand this better and faster.

I'm quite sure that the next release of curl and libcurl will be 7.10 if
these changes go in, as I think this is a significant change to motivate this
bump.

-- 
 Daniel Stenberg -- curl related mails on curl related mailing lists please
-------------------------------------------------------
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