[issue29413] ssl.SSLSocket.unwrap() is not flexible enough
New submission from Greg Stark: This is not a bug, but rather a request for API improvements. Correct SSL shutdown processing is frequent source of confusion. Python’s ssl module unfortunately lacks the flexibility to accommodate some common paradigms. The problem is that the unwrap() method of SSLObject and SSLSocket always blocks until it receives the peer’s close_notify alert. This is the sensible default since it is the most secure. However, it is also common (and secure) to send the close_notify and then shutdown the socket immediately after without waiting for the peer’s close_notify alert. More details can be found in section 7.2.1 of RFC 2246 and its successors. Another good source is the discussion at http://security.stackexchange.com/questions/82028/ssl-tls-is-a-server-always-required-to-respond-to-a-close-notify To accommodate the range of SSL shutdown behaviors in the real world I propose two small API changes. One is to add a keyword argument to the unwrap() method of SSLSocket and SSLObject. The new keyword argument is wait_for_peer, and it’s default value should be True. unwrap(wait_for_peer=True) would be the default behavior, and would match the current behavior: always wait for the peer to send the close_notify. unwrap(wait_for_peer=False) however, would return successfully after sending the close_notify whether or not the peer has sent their close_notify. In addition, a new method ‘get_shutdown_state()’ is needed to retrieve the current shutdown state of the SSL connection or object. Or perhaps the method could be a simple boolean ‘has_peer_sent_shutdown()’. This is just one proposal for adding some necessary flexibility with minimal API changes. Other approaches are possible. -- assignee: christian.heimes components: SSL messages: 286674 nosy: Greg Stark, christian.heimes priority: normal severity: normal status: open title: ssl.SSLSocket.unwrap() is not flexible enough type: behavior versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29334] ssl.SSLObject method getpeercert() is buggy, do_handshake() is strange
Greg Stark added the comment: adding script the illustrates the bug. -- Added file: http://bugs.python.org/file46364/sslbugs.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29334] ssl.SSLObject method getpeercert() is buggy, do_handshake() is strange
Greg Stark added the comment: Christian, I will gladly do so a little later today. Thanks for your quick response. --greg On Fri, Jan 20, 2017 at 7:29 AM, Christian Heimes <rep...@bugs.python.org> wrote: > > Christian Heimes added the comment: > > Hi Grek, > > can you provide a script to reproduce the problem, please? > > -- > > ___ > Python tracker <rep...@bugs.python.org> > <http://bugs.python.org/issue29334> > ___ > -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29334] ssl.SSLObject method getpeercert() is buggy, do_handshake() is strange
New submission from Greg Stark: In my experiments with the relatively new class SSLObject from the ssl module I've noticed the following behavior(s) which I think can be described as bugs. The getpeercert() method raises a ValueError exception "handshake not done" even after the handshake has successfully completed. If, however, I call the do_handshake() method *after* the handshake completes, then getpeercert() correctly runs and returns the peer's certificate. So now let's focus on do_handshake(). This method is basically undocumented, which I thought was ok because what it does should be obvious. It does seem to initiate a handshake if it's the first method call after the SSLObject is created. If called afterward, it doesn't outwardly appear to do anything, but as mentioned previously it does magically make the getpeercert() method start working. -- assignee: christian.heimes components: SSL messages: 285903 nosy: Greg Stark, christian.heimes priority: normal severity: normal status: open title: ssl.SSLObject method getpeercert() is buggy, do_handshake() is strange type: behavior versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29334> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27444] Python doesn't build due to test_float.py broken on non-IEEE machines
Greg Stark added the comment: Well I was able to minimize the actual cause: $ /usr/pkg/bin/python -c 1e300*1e300 [1] Floating point exception /usr/pkg/bin/python -c 1e300*1e300 I noticed that the constant folding arithmetic is protected by "PyFPE_START_PROTECT" macros so I wonder... should I be configuring with --with-fpectl? (Or should it be on unconditionally if it's required to function properly on a given architecture?) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27444> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27444] Python doesn't build due to test_float.py broken on non-IEEE machines
Greg Stark added the comment: I certainly understand the limitations of volunteer projects. I know you have limited resources and can't test on every platform. That's actually exactly why I'm testing on this platform and why I reported the bug. If there's any additional information I can provide to help you I can try to get it. I found this while trying to build a Postgres build-farm member to help us identify portability issues quickly on platforms that aren't widely used by developers. If Python has similar infrastructure I could deploy it to the same hardware to help you spot these problems sooner. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27444> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27444] Python doesn't build due to test_float.py broken on non-IEEE machines
Greg Stark added the comment: I can easily grant you access to mine. It's a bit slow but you can quickly poke around with the state in the backtrace which honestly looks to me like it should be enough to spot the problem. There are other options. There's a good emulator at http://simh.trailing-edge.com/ and there are other non-ieee platforms out there. But installing an OS is a bit of a hassle. If you're interested send me your email address and preferably a public key or something and I'll send you a login. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27444> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27444] Python doesn't build due to test_float.py broken on non-IEEE machines
New submission from Greg Stark: The file Test/test_float.py has a decorator for tests that must be skipped on non-IEEE machines. However just eyeballing it it seems there are a few tests that test behaviour around Inf and NaN that are lacking this decorator. Alternately it's possible this is actually a core interpreter bug where even code which is never called is now triggering floating point exceptions due to some constant propagation optimization or something like that. To reproduce, try to install on a non-IEE machine such as a VAX and your install will crash with: Compiling /usr/pkgsrc/lang/python27/work/.destdir/usr/pkg/lib/python2.7/test/test_filecmp.py ... Compiling /usr/pkgsrc/lang/python27/work/.destdir/usr/pkg/lib/python2.7/test/test_fileinput.py ... Compiling /usr/pkgsrc/lang/python27/work/.destdir/usr/pkg/lib/python2.7/test/test_fileio.py ... Compiling /usr/pkgsrc/lang/python27/work/.destdir/usr/pkg/lib/python2.7/test/test_float.py ... [1] Floating point exception (core dumped) PYTHONPATH=/usr/... *** Error code 136 Stop. make: stopped in /usr/pkgsrc/lang/python27/work/Python-2.7.10 *** Error code 1 I do happen to have been compiling with -O0 -g so I have a core file and a binary with symbols (if you have a VAX gdb...) but here's the backtrace: #0 0x7f687748 in float_mul (v=0x7ee82f54, w=0x7ee82f54, 2129145684, 2129145684) at Objects/floatobject.c:658 #1 0x7f65eb56 in binary_op1 (v=0x7ee82f54, w=0x7ee82f54, op_slot=8, 2129145684, 2129145684, 8) at Objects/abstract.c:945 #2 0x7f65f572 in PyNumber_Multiply (v=0x7ee82f54, w=0x7ee82f54, 2129145684, 2129145684) at Objects/abstract.c:1216 #3 0x7f72e573 in fold_binops_on_constants (codestr=0x7f28b169 "d\001", consts=0x7f0b5dcc, 2133373289, 2131451340) at Python/peephole.c:108 #4 0x7f72f56c in PyCode_Optimize (code=0x7f3316a8, consts=0x7f0b5dcc, names=0x7f0948ec, lineno_obj=0x7f0b5840, 2134054568, 2131451340, 2131314924, 2131449920) at Python/peephole.c:482 #5 0x7f71d3ad in makecode (c=0x7fffc810, a=0x7fffc5b0, 2147469328, 2147468720) at Python/compile.c:3883 #6 0x7f71d77d in assemble (c=0x7fffc810, addNone=1, 2147469328, 1) at Python/compile.c:3999 #7 0x7f717527 in compiler_function (c=0x7fffc810, s=0x7eb82bf0, 2147469328, 2125999088) at Python/compile.c:1422 #8 0x7f719552 in compiler_visit_stmt (c=0x7fffc810, s=0x7eb82bf0, 2147469328, 2125999088) at Python/compile.c:2122 #9 0x7f716d00 in compiler_body (c=0x7fffc810, stmts=0x7ebc88f8, 2147469328, 2126285048) at Python/compile.c:1209 #10 0x7f717882 in compiler_class (c=0x7fffc810, s=0x7ebd2608, 2147469328, 2126325256) at Python/compile.c:1477 #11 0x7f719564 in compiler_visit_stmt (c=0x7fffc810, s=0x7ebd2608, 2147469328, 2126325256) at Python/compile.c:2124 #12 0x7f716d00 in compiler_body (c=0x7fffc810, stmts=0x7eb53010, 2147469328, 2125803536) at Python/compile.c:1209 #13 0x7f716db6 in compiler_mod (c=0x7fffc810, mod=0x7ebe1438, 2147469328, 2126386232) at Python/compile.c:1229 #14 0x7f7151f3 in PyAST_Compile (mod=0x7ebe1438, filename=0x7f2c15b4 "/usr/pkg/lib/python2.7/test/test_float.py", flags=0x7fffc8c0, arena=0x7f3482f0, 2126386232, 2133595572, 2147469504, 2134147824) at Python/compile.c:292 #15 0x7f733849 in Py_CompileStringFlags ( str=0x7eb43014 "\nimport unittest, struct\nimport os\nfrom test import test_support\nimport math\nfrom math import isinf, isnan, copysign, ldexp\nimport operator\nimport random\nimport fractions\nimport sys\nimport time\n\nINF ="..., filename=0x7f2c15b4 "/usr/pkg/lib/python2.7/test/test_float.py", start=257, flags=0x7fffc8c0, 2125738004, 2133595572, 257, 2147469504) at Python/pythonrun.c:1428 #16 0x7f705dc6 in builtin_compile (self=0x0, args=0x7f08f914, kwds=0x0, 0, 2131294484, 0) at Python/bltinmodule.c:559 #17 0x7f6a5b8a in PyCFunction_Call (func=0x7f32a96c, arg=0x7f08f914, kw=0x0, 2134026604, 2131294484, 0) at Objects/methodobject.c:85 #18 0x7f713023 in call_function (pp_stack=0x7fffca44, oparg=3, 2147469892, 3) at Python/ceval.c:4035 #19 0x7f70fe32 in PyEval_EvalFrameEx (f=0x7f29568c, throwflag=0, 2133415564, 0) at Python/ceval.c:2681 #20 0x7f711523 in PyEval_EvalCodeEx (co=0x7f25cad0, globals=0x7f29a3e4, locals=0x0, args=0x7f3b7874, argcount=4, kws=0x7f3b7884, kwcount=0, defs=0x7f29d3a8, defcount=3, closure=0x0, 2133183184, 2133435364, 0, 2134603892, 4, 2134603908, 0, 2133447592, 3, 0) at Python/ceval.c:3267 #21 0x7f71337c in fast_function (func=0x7f29b924, pp_stack=0x7fffcd30, n=4, na=4, nk=0, 2133440804, 2147470640, 4, 4, 0) at Python/ceval.c:4131 #22 0x7f713106 in call_function (pp_stack=0x7fffcd30, oparg=4, 2147470640, 4) at Python/ceval.c:4056 #23 0x7f70fe32 in PyEval_EvalFrameEx (f=0x7f3b76ec, throwflag=0, 2134603500, 0) at Python/ceval.c:2681 #24 0x7f711523 in PyEval_EvalCodeEx (co=0x7f23ecc8, globals=0x7f33e714, locals=0x0, args=0x7f2d1198, argcount=5, kws=0x7f2d11ac, kwcount=0, defs=0x7f24bfd8,
