[issue22959] http.client.HTTPSConnection checks hostname when SSL context has check_hostname==False
zodalahtathi added the comment: I think it does, when passing a context with ssl_context.verify_mode != ss.CERT_NONE, and when not setting the check_hostname parameter: 1. will_verify will be True (https://hg.python.org/cpython/file/3.4/Lib/http/client.py#l1207) 2. check_hostname will be True too (https://hg.python.org/cpython/file/3.4/Lib/http/client.py#l1209) 3. ssl.match_hostname will be called after the handshake in wrap_socket (https://hg.python.org/cpython/file/3.4/Lib/http/client.py#l1230) The following code shows the problem: import http.client import ssl ssl_context = ssl.SSLContext(ssl.PROTOCOL_TLSv1_2) ssl_context.verify_mode = ssl.CERT_REQUIRED ssl_context.check_hostname = False https = http.client.HTTPSConnection(localhost, context=ssl_context) print(https._check_hostname) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22959 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22960] xmlrpc.client.ServerProxy() should accept a custom SSL context parameter
zodalahtathi added the comment: Thank you -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22960 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9179] Lookback with group references incorrect (two issues?)
Serhiy Storchaka added the comment: The more I think about it, the more doubt. This patch added a behavior that is incompatible with the regex module. The regex module proceeds lookbehind assertions in the opposite direction, from right to left. This allows it to work with lookbehind assertions of non-fixed length. But the side effect is that in regex group reference in lookbehind assertion can refer only to a group defined right in the same lookbehind assertion (or defined left outside). In re now group reference in lookbehind assertion can refer only to a group defined left. This is likely to change in the future, which brings us to the problem of incompatibility. There are several quick ways to resolve the problem: 1) Rollback the patch and return to the previous non-working behavior. Because of the obvious non-working the problem with changing the implementation of lookbehind assertion in the future will be weaker. 2) Rollback the patch and emit a warning or error when using any group references in lookbehind assertion. Something like patch proposed by Greg Chapman in issue814253 (but slightly more advanced). 3) Leave the patch and emit a warning or an error when using group references to the group defined in this same lookbehind assertion. Group references will work in lookbehind assertions in most cases except rare cases when current re behavior differs from regex behavior. What is your decision Benjamin? Here is a patch against 2.7 which implements variant 3. -- nosy: +benjamin.peterson, larry priority: normal - release blocker resolution: fixed - stage: resolved - status: closed - open Added file: http://bugs.python.org/file37324/re_forbid_some_groupref_in_lookbehind-2.7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9179 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22959] http.client.HTTPSConnection checks hostname when SSL context has check_hostname==False
Benjamin Peterson added the comment: As the documentation says If context is specified and has a verify_mode of either CERT_OPTIONAL or CERT_REQUIRED, then by default host is matched against the host name(s) allowed by the server’s certificate. If you want to change that behaviour, you can explicitly set check_hostname to False. It is rather weird that HTTPSConnection has its own check_hostname parameter independent of the one on the SSL context. Alex, what do you think of this patch? -- Added file: http://bugs.python.org/file37325/ch-weirdness.aptch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22959 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22902] Use 'ip' for uuid.getnode()
Serhiy Storchaka added the comment: Bruno, could you please sign a Contributor Licensing Agreement? http://www.python.org/psf/contrib/contrib-form/ http://www.python.org/psf/contrib/ -- assignee: - serhiy.storchaka stage: - commit review type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22902 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22959] http.client.HTTPSConnection checks hostname when SSL context has check_hostname==False
Alex Gaynor added the comment: This will cause it to not validate in some cases where it currently is validating? That seems like a regression to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22959 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22959] http.client.HTTPSConnection checks hostname when SSL context has check_hostname==False
Benjamin Peterson added the comment: On Sun, Nov 30, 2014, at 11:20, Alex Gaynor wrote: Alex Gaynor added the comment: This will cause it to not validate in some cases where it currently is validating? That seems like a regression to me. I suppose. Certainly, none of the default cases are affected. The problem is it's impossible to have cert validation w/o hostname checking by passing a context to some higher level API than HTTPSConnection (like xmlrpclib) because HTTPSConnection tries to be clever. Ideally, the check_hostname argument wouldn't exist, and everything would come from the context. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22959 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9179] Lookback with group references incorrect (two issues?)
Roundup Robot added the comment: New changeset d1f7c3f45ffe by Benjamin Peterson in branch '3.4': backout 9fcf4008b626 (#9179) for further consideration https://hg.python.org/cpython/rev/d1f7c3f45ffe New changeset f385bc6e6e09 by Benjamin Peterson in branch 'default': merge 3.4 (#9179) https://hg.python.org/cpython/rev/f385bc6e6e09 New changeset 8a3807e15a1f by Benjamin Peterson in branch '2.7': backout fac649bf2d10 (#9179) for further consideration https://hg.python.org/cpython/rev/8a3807e15a1f -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9179 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9179] Lookback with group references incorrect (two issues?)
Benjamin Peterson added the comment: I just backed out the change. Thanks for brining up the issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9179 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22095] Use of set_tunnel with default port results in incorrect post value in host header
Changes by Serhiy Storchaka storch...@gmail.com: -- assignee: - serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22095 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22959] http.client.HTTPSConnection checks hostname when SSL context has check_hostname==False
zodalahtathi added the comment: I agree that changing a default to something less secure is not something to do lightly, however I think forcing a check that is explicitly disabled is a bug and can be counter productive security wise. People who don't have time to look at the stdlib code, and file bug like this are likely to react with fuck it, I'll use plain HTTP. By the way, my use case is precisely xmlrpc. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22959 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9179] Lookback with group references incorrect (two issues?)
Serhiy Storchaka added the comment: What would be the best solution for 2.7? Here is a patch which forbids any group references in lookbehind assertions (they are not work currently and users shouldn't use them). -- stage: - patch review Added file: http://bugs.python.org/file37326/re_forbid_groupref_in_lookbehind-2.7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9179 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22902] Use 'ip' for uuid.getnode()
Roundup Robot added the comment: New changeset 64bb01bce12c by Serhiy Storchaka in branch 'default': Issue #22902: The ip command is now used on Linux to determine MAC address https://hg.python.org/cpython/rev/64bb01bce12c -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22902 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22902] Use 'ip' for uuid.getnode()
Serhiy Storchaka added the comment: Thank you for your contribution Bruno. -- resolution: - fixed stage: commit review - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22902 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9179] Lookback with group references incorrect (two issues?)
Benjamin Peterson added the comment: On Sun, Nov 30, 2014, at 12:55, Serhiy Storchaka wrote: Serhiy Storchaka added the comment: What would be the best solution for 2.7? You can pick. I just always favor not changing things for release candidates. Here is a patch which forbids any group references in lookbehind assertions (they are not work currently and users shouldn't use them). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9179 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9179] Lookback with group references incorrect (two issues?)
Serhiy Storchaka added the comment: Updated documentation. If there are no objections I'll commit re_forbid_groupref_in_lookbehind-2.7_2.patch to 2.7 and 3.4. For 3.5 I prefer to add support of group references. -- Added file: http://bugs.python.org/file37327/re_forbid_groupref_in_lookbehind-2.7_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9179 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22619] Possible implementation of negative limit for traceback functions
Dmitry Kazakov added the comment: Revisiting this issue, I realize that I made quite a few mistakes (because this was the first issue I submitted). The patch is definitely minor, and I'm no longer interested in it. This issue may now be closed. Cheers. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22619 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22619] Possible implementation of negative limit for traceback functions
Changes by Dmitry Kazakov jsb...@gmail.com: -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22619 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20467] Confusing wording about __init__
Simeon Visser added the comment: Is it worth clarifying that __init__ can return a value but only the value None? The following won't raise a TypeError: class O(object): def __init__(self): return None Admittedly the return None is the default behaviour but people may attempt this in order to block creation of the instance (as __new__ is less well-known, I have seen the above attempted on Stack Overflow: http://stackoverflow.com/questions/26896941/proper-way-to-terminate-object-creation-inside-of-init/) -- nosy: +simeon.visser ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20467 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22619] Possible implementation of negative limit for traceback functions
Changes by Dmitry Kazakov jsb...@gmail.com: -- status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22619 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22965] smtplib.py: senderrs[each] - TypeError: unhashable instance
R. David Murray added the comment: I'm not familiar with app-engine, so I don't understand the code snippet in the stackoverflow issue. But what is happening here is that whatever it is you've supplied as the 'to' address is not a string, but sendmail expects it to be. Now, since rcpt converts its argument to a string, you might think it would be reasonable for senderrs to do the same. But that would not be correct, since then you would not be able to use whatever you passed in to to_addrs as the key to retrieve values from senderrs. Even if for some reason one did not consider this important, it still couldn't be changed for backward compatibility reasons. Basically, the fact that rcpt does the equivalent of str(addr) is an implementation detail. I'm closing this as not a bug; that is, the values in to_addrs are required to be strings, which is how that attribute is documented. -- resolution: - not a bug stage: - resolved status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22965 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22966] py_compile: foo.bar.py → __pycache__/foo.cpython-34.pyc
R. David Murray added the comment: And, therefore, a missing test :(. This probably snuck in when we refactored the CLI. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22966 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22953] Windows installer configures system PATH also when installing only for current user
Pekka Klärck added the comment: For me this isn't too high priority. I typically install Python for all users on Windows anyway, and recommend that also for my clients. I just tested this RC to see how (ensure)pip works in practice, decided to install only for the current user, was very happy to notice that there's an option to set PATH, and then decided to submit an issue when I noticed the system PATH was updated. Because setting PATH is opt-in, and because 2.7 installer apparently requires admin rights and thus always can updated system PATH, I doubt this problem is going to actually matter to anyone. Great to hear 3.5 will have real only for me option. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22953 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19361] Specialize exceptions thrown by JSON parser
Serhiy Storchaka added the comment: Updated patch provides JSONDecodeError without end* attributes and with changed message for Extra data. -- Added file: http://bugs.python.org/file37328/json_JSONDecodeError_2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19361 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22943] bsddb: test_queue fails on Windows
Serhiy Storchaka added the comment: Does it look good to you Benjamin? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22943 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22943] bsddb: test_queue fails on Windows
Benjamin Peterson added the comment: Yes, please apply. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22943 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22969] Compile fails with --without-signal-module
New submission from KHH: When compiling with the ./configure --without-signal-module the configure file adds Parser/intrcheck.o to SIGNAL_OBJS, but the corresponding Parser/intercheck.c has been removed from the build tree. Removing the Parser/intrcheck.o causes the build to fail due to undefined references. The error logs are attached. -- components: Build files: python-compile-errors.txt messages: 231910 nosy: KHH priority: normal severity: normal status: open title: Compile fails with --without-signal-module type: compile error versions: Python 3.4 Added file: http://bugs.python.org/file37329/python-compile-errors.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22969 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22935] Disabling SSLv3 support
Ned Deily added the comment: Clearly we need to support openssl's without SSLv3 so I think some version of this needs to be applied to all branches (preferably in time for 2.7.9, Benjamin?). Kurt, if you haven't already, could you sign the contributor agreement so we can use the patch (https://www.python.org/psf/contrib/contrib-form/)? And I guess it would be nice to generalize the SSLv2 checks as doko suggests. -- components: +Build nosy: +benjamin.peterson, ned.deily priority: normal - high ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22935 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22970] Cancelling wait() after notification leaves Condition in an inconsistent state
New submission from David Coles:
If a task that is waiting on an asyncio.Condition is cancelled after
notification but before having successfully reacquired the associated lock, the
acquire() will be cancelled causing wait() to return without the lock held
(violating wait()'s contract and leaving the program in an inconsistent state).
This can be reproduced in cases where there's some contention on the
Condition's lock. For example:
import asyncio
loop = asyncio.get_event_loop()
cond = asyncio.Condition()
@asyncio.coroutine
def cond_wait_timeout(condition, timeout):
wait_task = asyncio.async(condition.wait())
loop.call_later(timeout, wait_task.cancel)
try:
yield from wait_task
return True
except asyncio.CancelledError:
print(Timeout (locked: {0}).format(condition.locked()))
return False
@asyncio.coroutine
def waiter():
yield from cond.acquire()
try:
print(Wait)
if (yield from cond_wait_timeout(cond, 1)):
# Cause some lock contention
print(Do work)
yield from asyncio.sleep(1)
finally:
cond.release()
@asyncio.coroutine
def notifier():
# Yield to the waiters
yield from asyncio.sleep(0.1)
yield from cond.acquire()
try:
print(Notify)
cond.notify_all()
finally:
cond.release()
loop.run_until_complete(asyncio.wait([waiter(), waiter(), notifier()]))
The most straightforward fix appears to be just to have wait() retry to acquire
the lock, effectively ignoring cancellation at this point (since the condition
has already finished waiting and just trying to reacquire the lock before
returning).
--
components: asyncio
files: asyncio-fix-wait-cancellation-race.patch
keywords: patch
messages: 231912
nosy: dcoles, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Cancelling wait() after notification leaves Condition in an inconsistent
state
type: behavior
versions: Python 3.4
Added file:
http://bugs.python.org/file37330/asyncio-fix-wait-cancellation-race.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22970
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
