[tor-commits] [tor/release-0.3.2] Return -1 from our PEM password callback

[nickm@xxxxxxxxxxxxxx]

commit 881f7157f648eb8a39e5dfd3efb95951ee7ac215
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
Date:   Wed May 16 11:39:42 2018 -0400

    Return -1 from our PEM password callback
    
    Apparently, contrary to its documentation, this is how OpenSSL now
    wants us to report an error.
    
    Fixes bug 26116; bugfix on 0.2.5.16.
---
 changes/bug26116    | 7 +++++++
 src/common/crypto.c | 7 ++++++-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/changes/bug26116 b/changes/bug26116
new file mode 100644
index 000000000..3bfde74f7
--- /dev/null
+++ b/changes/bug26116
@@ -0,0 +1,7 @@
+  o Minor bugfixes (compatibility, openssl):
+    - Work around a change in OpenSSL 1.1.1 where
+      return values that would previously indicate "no password" now
+      indicate an empty password. Without this workaround, Tor instances
+      running with OpenSSL 1.1.1 would accept descriptors that other Tor
+      instances would reject. Fixes bug 26116; bugfix on 0.2.5.16.
+      
diff --git a/src/common/crypto.c b/src/common/crypto.c
index 39c8cc2b0..f8495bb10 100644
--- a/src/common/crypto.c
+++ b/src/common/crypto.c
@@ -653,7 +653,12 @@ pem_no_password_cb(char *buf, int size, int rwflag, void *u)
   (void)size;
   (void)rwflag;
   (void)u;
-  return 0;
+  /* The openssl documentation says that a callback "must" return 0 if an
+   * error occurred.  But during the 1.1.1 series (commit c82c3462267afdbbaa5
+   * they changed the interpretation so that 0 indicates an empty password and
+   * -1 indicates an error. We want to reject any encrypted PEM buffers, so we
+   * return -1.  This will work on older OpenSSL versions and LibreSSL too. */
+  return -1;
 }
 
 /** Read a PEM-encoded private key from the <b>len</b>-byte string <b>s</b>



_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits