Re: [Python-Dev] Summer of Code: Developing complete SSL support for Python
On Sat, 2005-06-04 at 12:26 -0600, Shane Hathaway wrote:
> Florencio Cano Gabarda wrote:
> > I would like to do the new SSL module as good as possible. A piece of
> > art and efficiency if possible and obviusly having in mind all
> > programming standards.
>
> Guido and much of the community would certainly be appreciative of a new
> SSL module, especially if you can overcome the problems that plague
> M2Crypto.
>
> http://www.artima.com/weblogs/viewpost.jsp?thread=95863
>
> I would say that the criteria for success would be:
>
> 1) A module, expected to be included in the standard library, that makes
> it easy to create both client and server SSL sockets.
>
> 2) No leaks or segfaults.
>
> 3) An API that any programmer can use without knowing much about
> cryptography.
>
> I want to be able to write code that's as simple as this:
>
> import socket
> import ssl
>
> def open_ssl_socket(address):
> base = socket.socket()
> base.connect(address)
> sock = ssl.client(base)
> return sock
>
> def run_server(port, handler, pki_files):
> keys = ssl.load_keys(pki_files)
> s = socket.socket()
> s.bind(('', port))
> s.listen(5)
> while True:
> base, address = s.accept()
> sock = ssl.server(base, keys)
> handler(sock)
> sock.close()
>
> "pki_filenames" in the example is a list of key files, certificate
> files, certificiate signing requests, and perhaps other PKI files. I
> want the ssl module to figure out for itself what each file means, so
> that I as a mere human can forget about those details. :-) However, if
> there's any ambiguity in the set of files provided, the SSL module
> should throw an exception rather than try to guess the intent.
>
> If you're ambitious, you could also figure out how to make this work
> with non-blocking sockets. I believe Twisted has made progress there.
4. In the socket module documentation:
ssl(
sock[, keyfile, certfile])
Initiate a SSL connection over the socket sock. keyfile is the
name of a PEM formatted file that contains your private key.
certfile is a PEM formatted certificate chain file. On success,
a new SSLObject is returned.
Warning: This does not do any certificate verification!
I would make it a top priority to enable certificate verification in
ssl sockets. I don't see the point in doing SSL without certificate
verification. It's just false security. Maybe adding a callback asking
the application what to do if certificate validation fails, so that
application writers can show a GUI dialogue or something like that...
Best regards.
--
Gustavo J. A. M. Carneiro
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
The universe is always one step beyond logic
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 rewrite complete
On 6/1/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > I hope that I've got the rewrite of PEP 343 to include generator > extensions right now. I've chosen the 'with' keyword. Please review > here; I think this is ready for review by the unwashed masses. :-) > > http://www.python.org/peps/pep-0343.html A fairly minor point - with_template read wrongly to me for quite a while: I read it as something along the lines of "with a template" (which then doesn't make much sense...) rather than "template for the with statement". Unfortunately, I don't have a better naming suggestion (other than simply "template", which is probably too general to work), so I just raise this as something you should expect to need to clarify a few times... Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 rewrite complete
Guido van Rossum wrote:
>> @with_template
>> def closing(obj):
>> try:
>> yield obj
>> finally:
>> obj.close()
>>
> I just realized this has a race condition. The bytecode for the
> expression closing(open("...")) must necessarily contain a bytecode
> that calls open() followed by another bytecode that calls closing().
This is not a convincing point. That race condition always existed,
e.g. in the traditional
f = open(filename)
try:
process(f)
finally:
f.close()
as you could always get an async exception between open returns and
f is assigned. This isn't much of an issue, since CPython would always
release the file immediately as the stack frame is cleared due to
the exception.
I think would should explicitly weaken our guarantees for
"asynchronous" exceptions (of which we currently only have
KeyboardInterrupt). The PEP should point out that an async
exception between the beginning of the with statement and
the assignment to the variable may or may not cause __exit__
to be called (depending on how far you are into __enter__)
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 rewrite complete
On 6/5/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> >> @with_template
> >> def closing(obj):
> >> try:
> >> yield obj
> >> finally:
> >> obj.close()
> >>
> > I just realized this has a race condition. The bytecode for the
> > expression closing(open("...")) must necessarily contain a bytecode
> > that calls open() followed by another bytecode that calls closing().
>
> This is not a convincing point. That race condition always existed,
> e.g. in the traditional
>
> f = open(filename)
> try:
> process(f)
> finally:
> f.close()
>
> as you could always get an async exception between open returns and
> f is assigned. This isn't much of an issue, since CPython would always
> release the file immediately as the stack frame is cleared due to
> the exception.
>
> I think would should explicitly weaken our guarantees for
> "asynchronous" exceptions (of which we currently only have
> KeyboardInterrupt). The PEP should point out that an async
> exception between the beginning of the with statement and
> the assignment to the variable may or may not cause __exit__
> to be called (depending on how far you are into __enter__)
That is pretty clear from the translation given in the PEP.
What is not so clear is that the cace can be completely avoided *if*
the call to __enter__ and the try-finally setup are combined in one
opcode, *and* __enter__ is implemented in C, *and* the reversible
actions are all done by __enter__.
This is also why I don't like giving file objects __enter__ and
__exit__ methods.
I know all this doesn't matter in most situations, but sometimes it
does, and it would be good if there was a solution -- today, there
really isn't one except to rely on CPython's reference counting.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Split MIME headers into multiple lines near a space
On 5/30/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Noam's suggestion seems reasonable to me, but I'm not > sure what the performance implications are. I think that they are not critical. The number of lines can grow by at most twice, because shorter words would not have a line of their own. The added rfind call seems not very significant to me, since it is preceded by about log2n string encodings, to test if an encoded prefix fits the required line length. Have a good day, Noam ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
