Skip to content
  1. Aug 28, 2016
  2. Aug 27, 2016
  3. Aug 26, 2016
  4. Aug 25, 2016
  5. Aug 23, 2016
    • Ales Novak's avatar
      ftp: fix wrong poll on the secondary socket · 7ad50a61
      Ales Novak authored
      
      
      When we're uploading using FTP and the server issues a tiny pause
      between opening the connection to the client's secondary socket, the
      client's initial poll() times out, which leads to second poll() which
      does not wait for POLLIN on the secondary socket. So that poll() also
      has to time out, creating a long (200ms) pause.
      
      This patch adds the correct flag to the secondary socket, making the
      second poll() correctly wait for the connection there too.
      
      Signed-off-by: default avatarAles Novak <alnovak@suse.cz>
      
      Closes #978
      7ad50a61
  6. Aug 22, 2016
  7. Aug 21, 2016
  8. Aug 20, 2016
  9. Aug 19, 2016
  10. Aug 18, 2016
  11. Aug 17, 2016
    • Steve Holme's avatar
      RELEASE-PROCEDURE: Added some more future release dates · cf582d7b
      Steve Holme authored
      ...and removed some old ones
      cf582d7b
    • 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.
      01f69232
    • Daniel Stenberg's avatar
      nss: make the global variables static · 667fcb04
      Daniel Stenberg authored
      667fcb04