Forest Wilkinson <[EMAIL PROTECTED]> added the comment: Simon: I wish I could offer guidance here, but I'm afraid that I too am reading some of these openssl man pages for the first time.
I agree that writing to a temporary file would be bad. Accepting file-like objects from python code would be nice, but isn't really necessary. Simple strings would suffice. It's easy enough for application code to read the strings from the appropriate files. Of course, the ssl module (or an underlying library) would need a way to determine the data format within the strings. Unfortunately, I didn't notice an equivalent of SSL_CTX_use_PrivateKey_file() that accepts a file's contents instead of its path. SSL_CTX_use_RSAPrivateKey() looks like the next best thing. >much of the mechanism of a Certificate object is already there; >perhaps adding an opaque Key object wouldn't be too bad." That's encouraging. >From the openssl docs I've read so far, it looks like certificates and keys have several formats and use patterns. That seems to me like another argument in favor of supporting separate Certificate and Key objects, even if they're only minimally implemented to begin with. In other words, I don't imagine the presence of Certificate and Key objects would muck up the ssl module's api. In order to keep compatibility with socket.ssl, perhaps any new certificate and key objects should be accepted as alternatives to the existing certfile and keyfile args, but the latter should still be allowed? _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3823> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
