1. 21 Aug, 2016 6 commits
  2. 20 Aug, 2016 9 commits
  3. 19 Aug, 2016 2 commits
  4. 18 Aug, 2016 2 commits
  5. 17 Aug, 2016 3 commits
    • Steve Holme's avatar
      RELEASE-PROCEDURE: Added some more future release dates · cf582d7b
      Steve Holme authored
      ...and removed some old ones
    • David Woodhouse's avatar
      curl: allow "pkcs11:" prefix for client certificates · 01f69232
      David Woodhouse authored
      RFC7512 provides a standard method to reference certificates in PKCS#11
      tokens, by means of a URI starting 'pkcs11:'.
      We're working on fixing various applications so that whenever they would
      have been able to use certificates from a file, users can simply insert
      a PKCS#11 URI instead and expect it to work. This expectation is now a
      part of the Fedora packaging guidelines, for example.
      This doesn't work with cURL because of the way that the colon is used
      to separate the certificate argument from the passphrase. So instead of
         curl -E 'pkcs11:manufacturer=piv_II;id=%01' …
      I instead need to invoke cURL with the colon escaped, like this:
         curl -E 'pkcs11\:manufacturer=piv_II;id=%01' …
      This is suboptimal because we want *consistency* — the URI should be
      usable in place of a filename anywhere, without having strange
      differences for different applications.
      This patch therefore disables the processing in parse_cert_parameter()
      when the string starts with 'pkcs11:'. It means you can't pass a
      passphrase with an unescaped PKCS#11 URI, but there's no need to do so
      because RFC7512 allows a PIN to be given as a 'pin-value' attribute in
      the URI itself.
      Also, if users are already using RFC7512 URIs with the colon escaped as
      in the above example — even providing a passphrase for cURL to handling
      instead of using a pin-value attribute, that will continue to work
      because their string will start 'pkcs11\:' and won't match the check.
      What *does* break with this patch is the extremely unlikely case that a
      user has a file which is in the local directory and literally named
      just "pkcs11", and they have a passphrase on it. If that ever happened,
      the user would need to refer to it as './pkcs11:<passphrase>' instead.
    • Daniel Stenberg's avatar
      nss: make the global variables static · 667fcb04
      Daniel Stenberg authored
  6. 16 Aug, 2016 3 commits
  7. 15 Aug, 2016 7 commits
  8. 14 Aug, 2016 3 commits
  9. 13 Aug, 2016 2 commits
  10. 12 Aug, 2016 1 commit
  11. 11 Aug, 2016 2 commits
    • Daniel Stenberg's avatar
      rtsp: ignore whitespace in session id · 2c8ccdac
      Daniel Stenberg authored
      Follow-up to e577c43b to fix test case 569 brekage: stop the parser at
      whitespace as well.
      Help-by: Erik Janssen
    • Daniel Stenberg's avatar
      HTTP: retry failed HEAD requests too · 31e33a9a
      Daniel Stenberg authored
      Mark's new document about HTTP Retries
      (https://mnot.github.io/I-D/httpbis-retry/) made me check our code and I
      spotted that we don't retry failed HEAD requests which seems totally
      inconsistent and I can't see any reason for that separate treatment.
      So, no separate treatment for HEAD starting now. A HTTP request sent
      over a reused connection that gets cut off before a single byte is
      received will be retried on a fresh connection.
      Made-aware-by: Mark Nottingham