Skip to content
  1. Jan 16, 2014
  2. Jan 15, 2014
  3. Jan 14, 2014
  4. Jan 13, 2014
  5. Jan 12, 2014
  6. Jan 11, 2014
    • Daniel Stenberg's avatar
      OpenSSL: deselect weak ciphers by default · 3b5c75ef
      Daniel Stenberg authored
      By default even recent versions of OpenSSL support and accept both
      "export strength" ciphers, small-bitsize ciphers as well as downright
      deprecated ones.
      
      This change sets a default cipher set that avoids the worst ciphers, and
      subsequently makes https://www.howsmyssl.com/a/check no longer grade
      curl/OpenSSL connects as 'Bad'.
      
      Bug: http://curl.haxx.se/bug/view.cgi?id=1323
      Reported-by: Jeff Hodges
      3b5c75ef
    • Daniel Stenberg's avatar
      multi: remove MULTI_TIMEOUT_INACCURACY · 3b183df9
      Daniel Stenberg authored
      With the recently added timeout "reminder" functionality, there's no
      reason left for us to execute timeout code before the time is
      ripe. Simplifies the handling too.
      
      This will make the *TIMEOUT and *CONNECTTIMEOUT options more accurate
      again, which probably is most important when the *_MS versions are used.
      
      In multi_socket, make sure to update 'now' after having handled activity
      on a socket.
      3b183df9
    • Steve Holme's avatar
      Makefile.dist: Added support for VC7 · 7cd45b29
      Steve Holme authored
      Currently VC7 and VC7.1 builds have to be ran with the VC variable set
      to vc6 which is not only inconsistent with the nmake winbuild system
      but also with newer versions of Visual Studio supported by this file.
      
      Note: This doesn't break the build for anyone still running with the
      VC variable set to vc6 or not set (which defaults to vc6).
      7cd45b29
  7. Jan 10, 2014
    • Steve Holme's avatar
      RELEASE-NOTES: Synced with 980659a2 · 9362603f
      Steve Holme authored
      9362603f
    • Daniel Stenberg's avatar
      multi_socket: remind app if timeout didn't run · 980659a2
      Daniel Stenberg authored
      BACKGROUND:
      
      We have learned that on some systems timeout timers are inaccurate and
      might occasionally fire off too early. To make the multi_socket API work
      with this, we made libcurl execute timeout actions a bit early too if
      they are within our MULTI_TIMEOUT_INACCURACY. (added in commit
      2c72732e, present since 7.21.0)
      
      Switching everything to the multi API made this inaccuracy problem
      slightly more notable as now everyone can be affected.
      
      Recently (commit 21091549) we tweaked that inaccuracy value to make
      timeouts more accurate and made it platform specific. We also figured
      out that we have code at places that check for fixed timeout values so
      they MUST NOT run too early as then they will not trigger at all (see
      commit be28223f and a691e044) - so there are definitately problems
      with running timeouts before they're supposed to run. (We've handled
      that so far by adding the inaccuracy margin to those specific timeouts.)
      
      The libcurl multi_socket API tells the application with a callback that
      a timeout expires in N milliseconds (and it explicitly will not tell it
      again for the same timeout), and the application is then supposed to
      call libcurl when that timeout expires. When libcurl subsequently gets
      called with curl_multi_socket_action(...CURL_SOCKET_TIMEOUT...), it
      knows that the application thinks the timeout expired - and alas, if it
      is within the inaccuracy level libcurl will run code handling that
      handle.
      
      If the application says CURL_SOCKET_TIMEOUT to libcurl and _isn't_
      within the inaccuracy level, libcurl will not consider the timeout
      expired and it will not tell the application again since the timeout
      value is still the same.
      
      NOW:
      
      This change introduces a modified behavior here. If the application says
      CURL_SOCKET_TIMEOUT and libcurl finds no timeout code to run, it will
      inform the application about the timeout value - *again* even if it is
      the same timeout that it already told about before (although libcurl
      will of course tell it the updated time so that it'll still get the
      correct remaining time). This way, we will not risk that the application
      believes it has done its job and libcurl thinks the time hasn't come yet
      to run any code and both just sit waiting. This also allows us to
      decrease the MULTI_TIMEOUT_INACCURACY margin, but that will be handled
      in a separate commit.
      
      A repeated timeout update to the application risk that the timeout will
      then fire again immediately and we have what basically is a busy-loop
      until the time is fine even for libcurl. If that becomes a problem, we
      need to address it.
      980659a2
    • Daniel Stenberg's avatar
      threaded-resolver: never use NULL hints with getaddrinfo · 041d1e14
      Daniel Stenberg authored
      The net effect of this bug as it appeared to users, would be that
      libcurl would timeout in the connect phase.
      
      When disabling IPv6 use but still using getaddrinfo, libcurl would
      wrongly not init the "hints" struct field in init_thread_sync() which
      would subsequently lead to a getaddrinfo() invoke with a zeroed hints
      with ai_socktype set to 0 instead of SOCK_STREAM. This would lead to
      different behaviors on different platforms but basically incorrect
      output.
      
      This code was introduced in 483ff1ca, released in curl 7.20.0.
      
      This bug became a problem now due to the happy eyeballs code and how
      libcurl now traverses the getaddrinfo() results differently.
      
      Bug: http://curl.haxx.se/mail/lib-2014-01/0061.html
      Reported-by: Fabian Frank
      Debugged-by: Fabian Frank
      041d1e14
  8. Jan 09, 2014
  9. Jan 08, 2014
  10. Jan 07, 2014