[Python-Dev] Controlling the cipher list for SSL connections

2009-09-07 Thread Chris Frantz
Greetings,

I would like to be able to set the cipher list when creating an SSL
connection.  It appears that the current SSL module doesn't provide
this functionality.

The attached patch (against trunk) adds this ability to SSLSocket.

Thank you,
--Chris

PS: Please reply directly to me, as I'm not subscribed to this list.

Index: Python-2.7/Lib/ssl.py
===
--- Python-2.7/Lib/ssl.py    (revision 74703)
+++ Python-2.7/Lib/ssl.py    (working copy)
@@ -88,7 +88,7 @@
  server_side=False, cert_reqs=CERT_NONE,
  ssl_version=PROTOCOL_SSLv23, ca_certs=None,
  do_handshake_on_connect=True,
- suppress_ragged_eofs=True):
+ suppress_ragged_eofs=True, cipher_list=None):
 socket.__init__(self, _sock=sock._sock)
 # the initializer for socket trashes the methods (tsk, tsk), so...
 self.send = lambda data, flags=0: SSLSocket.send(self, data, flags)
@@ -110,7 +110,8 @@
 # yes, create the SSL object
 self._sslobj = _ssl.sslwrap(self._sock, server_side,
 keyfile, certfile,
-    cert_reqs, ssl_version, ca_certs)
+    cert_reqs, ssl_version,
+    ca_certs, cipher_list)
 if do_handshake_on_connect:
 timeout = self.gettimeout()
 try:
Index: Python-2.7/Modules/_ssl.c
===
--- Python-2.7/Modules/_ssl.c    (revision 74703)
+++ Python-2.7/Modules/_ssl.c    (working copy)
@@ -261,7 +261,8 @@
    enum py_ssl_server_or_client socket_type,
    enum py_ssl_cert_requirements certreq,
    enum py_ssl_version proto_version,
-       char *cacerts_file)
+       char *cacerts_file,
+       char *cipher_list)
 {
 PySSLObject *self;
 char *errstr = NULL;
@@ -366,6 +367,9 @@
 SSL_CTX_set_verify(self->ctx, verification_mode,
            NULL); /* set verify lvl */

+    if (cipher_list)
+        SSL_CTX_set_cipher_list(self->ctx, cipher_list);
+
 PySSL_BEGIN_ALLOW_THREADS
 self->ssl = SSL_new(self->ctx); /* New ssl struct */
 PySSL_END_ALLOW_THREADS
@@ -407,14 +411,17 @@
 char *key_file = NULL;
 char *cert_file = NULL;
 char *cacerts_file = NULL;
+    char *cipher_list = NULL;

-    if (!PyArg_ParseTuple(args, "O!i|zziiz:sslwrap",
+
+    if (!PyArg_ParseTuple(args, "O!i|zziizz:sslwrap",
           PySocketModule.Sock_Type,
           &Sock,
           &server_side,
           &key_file, &cert_file,
           &verification_mode, &protocol,
-              &cacerts_file))
+              &cacerts_file,
+              &cipher_list))
     return NULL;

 /*
@@ -427,12 +434,12 @@

 return (PyObject *) newPySSLObject(Sock, key_file, cert_file,
                    server_side, verification_mode,
-                       protocol, cacerts_file);
+                       protocol, cacerts_file, cipher_list);
 }

 PyDoc_STRVAR(ssl_doc,
 "sslwrap(socket, server_side, [keyfile, certfile, certs_mode, protocol,\n"
-"  cacertsfile]) -> sslobject");
+"  cacertsfile, cipherlist]) -> sslobject");

 /* SSL object methods */
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Controlling the cipher list for SSL connections

2009-09-07 Thread Michael Foord

Hello Chris,

Can you post your patch to the Python bug tracker please - 
http://bugs.python.org


Patches posted to this list tend to get lost...

Thanks

Michael

Chris Frantz wrote:

Greetings,

I would like to be able to set the cipher list when creating an SSL
connection.  It appears that the current SSL module doesn't provide
this functionality.

The attached patch (against trunk) adds this ability to SSLSocket.

Thank you,
--Chris

PS: Please reply directly to me, as I'm not subscribed to this list.

Index: Python-2.7/Lib/ssl.py
===
--- Python-2.7/Lib/ssl.py(revision 74703)
+++ Python-2.7/Lib/ssl.py(working copy)
@@ -88,7 +88,7 @@
  server_side=False, cert_reqs=CERT_NONE,
  ssl_version=PROTOCOL_SSLv23, ca_certs=None,
  do_handshake_on_connect=True,
- suppress_ragged_eofs=True):
+ suppress_ragged_eofs=True, cipher_list=None):
 socket.__init__(self, _sock=sock._sock)
 # the initializer for socket trashes the methods (tsk, tsk), so...
 self.send = lambda data, flags=0: SSLSocket.send(self, data, flags)
@@ -110,7 +110,8 @@
 # yes, create the SSL object
 self._sslobj = _ssl.sslwrap(self._sock, server_side,
 keyfile, certfile,
-cert_reqs, ssl_version, ca_certs)
+cert_reqs, ssl_version,
+ca_certs, cipher_list)
 if do_handshake_on_connect:
 timeout = self.gettimeout()
 try:
Index: Python-2.7/Modules/_ssl.c
===
--- Python-2.7/Modules/_ssl.c(revision 74703)
+++ Python-2.7/Modules/_ssl.c(working copy)
@@ -261,7 +261,8 @@
enum py_ssl_server_or_client socket_type,
enum py_ssl_cert_requirements certreq,
enum py_ssl_version proto_version,
-   char *cacerts_file)
+   char *cacerts_file,
+   char *cipher_list)
 {
 PySSLObject *self;
 char *errstr = NULL;
@@ -366,6 +367,9 @@
 SSL_CTX_set_verify(self->ctx, verification_mode,
NULL); /* set verify lvl */

+if (cipher_list)
+SSL_CTX_set_cipher_list(self->ctx, cipher_list);
+
 PySSL_BEGIN_ALLOW_THREADS
 self->ssl = SSL_new(self->ctx); /* New ssl struct */
 PySSL_END_ALLOW_THREADS
@@ -407,14 +411,17 @@
 char *key_file = NULL;
 char *cert_file = NULL;
 char *cacerts_file = NULL;
+char *cipher_list = NULL;

-if (!PyArg_ParseTuple(args, "O!i|zziiz:sslwrap",
+
+if (!PyArg_ParseTuple(args, "O!i|zziizz:sslwrap",
   PySocketModule.Sock_Type,
   &Sock,
   &server_side,
   &key_file, &cert_file,
   &verification_mode, &protocol,
-  &cacerts_file))
+  &cacerts_file,
+  &cipher_list))
 return NULL;

 /*
@@ -427,12 +434,12 @@

 return (PyObject *) newPySSLObject(Sock, key_file, cert_file,
server_side, verification_mode,
-   protocol, cacerts_file);
+   protocol, cacerts_file, cipher_list);
 }

 PyDoc_STRVAR(ssl_doc,
 "sslwrap(socket, server_side, [keyfile, certfile, certs_mode, protocol,\n"
-"  cacertsfile]) -> sslobject");
+"  cacertsfile, cipherlist]) -> sslobject");

 /* SSL object methods */
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
  



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Controlling the cipher list for SSL connections

2009-09-07 Thread Chris Frantz
Done.

Attached to Issue 3597, which is a similar request to mine.

Best Regards,
--Chris
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] PEP 3145

2009-09-07 Thread Eric Pruitt
Hello all,

I have been working on adding asynchronous I/O to the Python
subprocess module as part of my Google Summer of Code project. Now
that I have finished documenting and pruning the code, I present PEP
3145 for its inclusion into the Python core code. Any and all feedback
on the PEP (http://www.python.org/dev/peps/pep-3145/) is appreciated.

Eric
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] Numeric alignment issue with PEP 3101

2009-09-07 Thread Eric Smith
The default string formatting alignment for all types, according to PEP 
3101, is left aligned. Issue 6857 (http://bugs.python.org/issue6857) 
points out that for numeric types (int, float, and decimal, at least), 
the actual implemented default alignment is right aligned.


Mark Dickinson and I agree that for numeric types, right alignment makes 
much more sense as a default. And that's what %-formatting and 
str.format() both do.


I think the PEP should be modified to say that right alignment is the 
default for numeric types. Also the documentation at 
http://docs.python.org/library/string.html#formatstrings should have the 
same modification.


Does anyone disagree?

Eric.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Numeric alignment issue with PEP 3101

2009-09-07 Thread Greg Ewing

Eric Smith wrote:

Mark Dickinson and I agree that for numeric types, right alignment makes 
much more sense as a default. And that's what %-formatting and 
str.format() both do.


Is the new formatting supposed to behave the same way
as %-formatting for the same format codes? Because the
default for %-formatting is actually right alignment
for *all* types, including strings.

--
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Numeric alignment issue with PEP 3101

2009-09-07 Thread Eric Smith

Greg Ewing wrote:

Is the new formatting supposed to behave the same way
as %-formatting for the same format codes? Because the
default for %-formatting is actually right alignment
for *all* types, including strings.


Hmm, I never noticed that. At this point, I think changing the 
formatting for any types would break code, so we should just change the 
documentation to reflect how currently works.


Eric.

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Numeric alignment issue with PEP 3101

2009-09-07 Thread Raymond Hettinger

I concur.  Numbers are naturally right aligned.


On Sep 7, 2009, at 2:46 PM, Eric Smith wrote:

The default string formatting alignment for all types, according to  
PEP 3101, is left aligned. Issue 6857 (http://bugs.python.org/issue6857 
) points out that for numeric types (int, float, and decimal, at  
least), the actual implemented default alignment is right aligned.


Mark Dickinson and I agree that for numeric types, right alignment  
makes much more sense as a default. And that's what %-formatting and  
str.format() both do.


I think the PEP should be modified to say that right alignment is  
the default for numeric types. Also the documentation at http://docs.python.org/library/string.html#formatstrings 
 should have the same modification.


Does anyone disagree?

Eric.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python%40rcn.com


___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com