[issue12803] SSLContext.load_cert_chain() should accept a password argument
New submission from Adam Simpkins : The SSLContext.load_cert_chain() method should accept a password argument to use if the private key is encrypted. Currently it always uses OpenSSL's default password callback, which prompts the user interactively for a password. I've attached a patch that adds an extra password argument, which can be either a string, bytes, bytearray, or a function to call to get the password. -- components: Library (Lib) files: ssl-password.patch keywords: patch messages: 142595 nosy: simpkins priority: normal severity: normal status: open title: SSLContext.load_cert_chain() should accept a password argument type: feature request versions: Python 3.1, Python 3.2 Added file: http://bugs.python.org/file22971/ssl-password.patch ___ Python tracker <http://bugs.python.org/issue12803> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12803] SSLContext.load_cert_chain() should accept a password argument
Adam Simpkins added the comment: > It seems a bit strange to me to accept string types or callable in the > same argument. If it just supported strings, people could still write > password=somefunction(), right? The function is only called if the private key is encrypted and a password is necessary. This allows the code to only prompt for a password if it is actually needed. This also parallels the OpenSSL C API, which only accepts a function to get the password. I added support for plain strings as a convenience. The string argument will be ignored if the file is not encrypted. -- ___ Python tracker <http://bugs.python.org/issue12803> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12803] SSLContext.load_cert_chain() should accept a password argument
Adam Simpkins added the comment: Here's a new patch that accepts any callable. The old patch only accepted actual function objects. -- Added file: http://bugs.python.org/file22975/ssl-password.2.patch ___ Python tracker <http://bugs.python.org/issue12803> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12803] SSLContext.load_cert_chain() should accept a password argument
Adam Simpkins added the comment: Good catch. Here's an updated patch to fix the missing decref in _pwinfo_set() The length check in _password_callback() applies to both callback functions and predefined strings. The C API always uses a callback, so _password_callback() is used even when the python caller has passed in a string. We can't check the length in _pwinfo_set() since it depends on the buffer length argument that openssl will pass to _password_callback(). -- Added file: http://bugs.python.org/file23029/ssl-password.3.patch ___ Python tracker <http://bugs.python.org/issue12803> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12803] SSLContext.load_cert_chain() should accept a password argument
Adam Simpkins added the comment: OpenSSL doesn't appear to do any special handling for i18n, and just treats the strings as binary data. It uses fgets() to read the password from the terminal, so it will receive it however the terminal encodes it. It's not clear to me that PyUnicode_EncodeFSDefault() is quite the right thing to do. The initfsencoding() routine seems different from how initstdio() works (which checks the PYTHONIOENCODING environment variable, and then appears to fall back to os.device_encoding()). I'm leaning towards just updating the docs to specify that if a string is supplied it will be encoded using UTF-8. I'm happy to do either way you recommend, though. -- ___ Python tracker <http://bugs.python.org/issue12803> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12803] SSLContext.load_cert_chain() should accept a password argument
Adam Simpkins added the comment: Here's a patch with updates to the documentation to more fully specify the behavior of the password field, including specifying that strings will be encoded using UTF-8. -- Added file: http://bugs.python.org/file23043/ssl-password.4.patch ___ Python tracker <http://bugs.python.org/issue12803> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15785] curses.get_wch() returns keypad codes incorrectly
New submission from Adam Simpkins: The curses.get_wch() function does not check if wget_wch() returned OK or KEY_CODE_YES. In either case, it simply returns the character code. This makes get_wch() unusable when keypad is enabled, because the caller cannot distinguish function key or arrow key presses from real unicode code points. For example, get_wch() returns 259 both for an up arrow press and for the input character 'ă'. It seems like this API needs to be redesigned somehow to allow terminal keypad codes to be distinguished from unicode input. -- components: Library (Lib) messages: 169165 nosy: simpkins priority: normal severity: normal status: open title: curses.get_wch() returns keypad codes incorrectly type: behavior versions: Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue15785> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15785] curses.get_wch() returns keypad codes incorrectly
Adam Simpkins added the comment: > + Get a wide character as (is_key_code, key). *is_key_code* is True for > + function keys, keypad keys and so, in this case, *key* is a multibyte > string > + containing the key name. Otherwise, *key* is a single character > + corresponding to the key. The curses module already exposes the integer KEY_* constants. I think the API would be easier to use if it simply returned the integer keycode constant rather than returning the human-readable name returned by keyname(). I suspect most callers will want to compare the keycode against one of these KEY_* constants to see what type of key was pressed so they can take action on specific keys. Comparing the return value against one of the curses.KEY_* constants seems easier than having to compare it to the result of curses.keyname(curses.KEY_*) The curses module also already exposes the keyname() function if callers do want to get the human-readable string for an integer keycode. If the function returned either a single-character unicode string or an integer keycode, this would also make it possible to completely drop the is_key_code part of the return value. (Callers could simply check the type of the return value to see if it is a keycode.) -- ___ Python tracker <http://bugs.python.org/issue15785> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
