[issue43901] Lazy-create an empty annotations dict in all unannotated user classes and modules

Change by Larry Hastings : -- title: Add an empty annotations dict to all unannotated classes and modules -> Lazy-create an empty annotations dict in all unannotated user classes and modules ___ Python tracker <https://bugs.python.org/issu

[issue43901] Add an empty annotations dict to all unannotated classes and modules

Larry Hastings added the comment: And I just had a realization. Lazy creation of an empty annotations dict, for both classes and modules, will work fine. As stated in my previous comment in this issue, my goal here is to improve best practices in 3.10+, while preserving the unfortunate

[issue43901] Add an empty annotations dict to all unannotated classes and modules

Larry Hastings added the comment: I'm please you folks are as supportive as you are of what I'm doing here, given that you seem a little unsure of the details. I concede that there's a lot going on and it can be hard to keep it all in your head. The point of this issue / PR is to improve

[issue43901] Add an empty annotations dict to all unannotated classes and modules

Larry Hastings added the comment: I'm not breaking backwards compatibility--that's the point of all this. But I'm improving the experience. And if you don't care about 3.9 and before, you can stick to the new improved experience. Looking in the class dict for annotations is terrible

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: Perhaps eval_str=ONLY_IF_STRINGIZED should also add the semantics "if evaluating any string fails, behave as if eval_str=false". I would *not* propose adding that for eval_str=true. But people keep asking for this. Hmm. The heuristic is a tr

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: The difference between eval_str=True and eval_str=ONLY_IF_STRINGIZED: def foo(a:int, b:"howdy howdy"): ... inspect.get_annotations(foo, eval_str=True) throws an exception. inspect.get_annotations(foo, eval_str=ONLY_IF_STRINGIZED) returns {'

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: For what it's worth: I changed the name to ONLY_IF_STRINGIZED in the PR. Since I propose that it be the default, everyone who called inspect.get_annotations(), and inspect.signature(), would use it. I think Pydantic would prefer it, because Pydantic wants

[issue43901] Add an empty annotations dict to all unannotated classes and modules

Larry Hastings added the comment: > I’d say that best practices for 3.9+ are more useful. My point in writing this up was that the best practices change as of 3.10. So, I could add a section to the Python 3.10 documentation giving best practices for 3.10+ and 3.9-. But 3.9 and 3.10 h

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: Time runs short for Python 3.10b1. Can I get a review from anybody here, say over the weekend? -- ___ Python tracker <https://bugs.python.org/issue43

[issue42725] PEP 563: Should the behavior change for yield/yield from's

Larry Hastings added the comment: Wouldn't it be easier to just throw an exception in the stringizing code? I note that there are dedicated functions to generate walrus, yield, yield from, and await in Python/ast_unparse.c. In theory this is a general-purpose facility, but in practice

[issue42725] PEP 563: Should the behavior change for yield/yield from's

Larry Hastings added the comment: I think stringized annotations should prohibit the same things PEP 649 prohibits: walrus, yield / yield from, and await. This was easy in my 649 branch; walrus adds locals, and yield / yield from make it a generator. So the code raises an error

[issue43817] Add inspect.get_annotations()

Change by Larry Hastings : -- assignee: -> larry ___ Python tracker <https://bugs.python.org/issue43817> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: PR is up, passes all checks. I think it's ready for the first round of reviews! -- ___ Python tracker <https://bugs.python.org/issue43

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: I think it gets a little murkier when we talk about *annotations* vs *type hints*. Type hints have a defined meaning for a string: a string is a sort of forward declaration, and you eval() the string to get the real value. (Or, not, if you're comfortable

[issue43817] Add inspect.get_annotations()

Change by Larry Hastings : -- keywords: +patch pull_requests: +24242 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/25522 ___ Python tracker <https://bugs.python.org/issu

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: When I proposed this new function, stringized annotations were the default behavior in Python 3.10, and there were two calls to typing.get_type_hints() in the standard library: * inspect.signature() * functools.singledispatch() Now that stringized

[issue43901] Add an empty annotations dict to all unannotated classes and modules

Larry Hastings added the comment: > * Never modify o.__annotations__. Let me revise that to: * If o.__annotations__ is a dict, never modify the contents of that dict. -- ___ Python tracker <https://bugs.python.org/issu

[issue43901] Add an empty annotations dict to all unannotated classes and modules

Larry Hastings added the comment: It occurs to me that part of this work should also be a new "best practices for __annotations__" entry in the Python docs. Best practices for working with annotations, for code that requires a minimum Python version of 3.10+: Best practice

[issue43901] Add an empty annotations dict to all unannotated classes and modules

Larry Hastings added the comment: By the way, here's a tidbit I never got around to posting in c.l.p-d. I noted in the conversation in January that attrs is an outlier here: it *doesn't* look in the class dict for __annotations__. Instead, it has some complicated code where it asks

[issue43901] Add an empty annotations dict to all unannotated classes and modules

Larry Hastings added the comment: > - Is it possible to create __annotations__ lazily? (IIRC in January we came > to a conclusion about this, something like yes for modules but for classes, > or the other way around?) Maybe for modules, definitely not for classes. The problem is

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: Just to round the bases: get_annotations() won't return an unmodified __annotations__ dict, but it *could* return a *consistent* dict. It could keep a cache (lru or otherwise) of all responses so far. I don't think that's what we want, I just thought I

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: > Are you saying the user would expect to be able to change __annotations__ my > modifying the dict they get back? As the docs are currently written, it's ambiguous. > Is it ever the case that the user can modify __annotations__ through the dict

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: Hmm. If o.__annotations__ is None, should this function set the empty dict on the object? That seems slightly too opinionated to me. On the other hand, the user would probably expect that they could change the dict they got back. (If Python shipped

[issue43817] Add inspect.get_annotations()

Larry Hastings added the comment: Just over twelve hours ago, the Python Steering Committee announced that stringized annotations would no longer be default behavior in Python 3.10. They will go back to being gated with "from __future__ import annotations". I think we

[issue43901] Add an empty annotations dict to all unannotated classes and modules

Larry Hastings added the comment: Preliminary patch is 17 lines. Ah well. I must be terrible at this! -- ___ Python tracker <https://bugs.python.org/issue43

[issue43901] Add an empty annotations dict to all unannotated classes and modules

Larry Hastings added the comment: Huh. The sample code in my thread got goofed up somewhere along the way--maybe it's my fault, maybe it was done to me by some automated process. Anyway, the example demonstrating classes inheriting annotations was meant to be formatted like

[issue43901] Add an empty annotations dict to all unannotated classes and modules

Change by Larry Hastings : -- title: Add an empty annotations dict to all classes and modules -> Add an empty annotations dict to all unannotated classes and modules ___ Python tracker <https://bugs.python.org/issu

[issue43901] Add an empty annotations dict to all classes and modules

New submission from Larry Hastings : The behavior of the __annotations__ member is wildly different between the three objects (function, class, module) that support it. Many of these differences are minor, but one in particular has been an awful wart for years: classes can inherit

[issue43817] Add inspect.get_annotations()

Change by Larry Hastings : -- title: Add typing.get_annotations() -> Add inspect.get_annotations() ___ Python tracker <https://bugs.python.org/issu

[issue43891] co_annotations branch caused a crash in stackeffect() in compile.c

Larry Hastings added the comment: (Sorry, the name of the function is stackdepth(), not stackeffect().) -- ___ Python tracker <https://bugs.python.org/issue43

[issue43891] co_annotations branch caused a crash in stackeffect() in compile.c

New submission from Larry Hastings : I'm working on a branch to implement PEP 649: https://github.com/larryhastings/co_annotations/ Inada Naoki discovered a crash in that branch, discussed here, including steps to reproduce: https://github.com/larryhastings/co_annotations/issues/10

[issue39298] add BLAKE3 to hashlib

Larry Hastings added the comment: I note that Python already ships with some #ifdefs around SSE and the like. So, yes, we already do this sort of thing, although I think this usually uses compiler intrinsics rather than actual assembly. A quick grep shows zero .s files and only one .asm

[issue43463] typing.get_type_hints with TYPE_CHECKING imports / getting hints for single argument

Larry Hastings added the comment: I admit I hadn't looked that closely at Jelle's PR. You're right, its effects on code size should be minimal. If I'm reading it correctly, Jelle's PR would suppress NameError by replacing the failed value with a new "AnnotationName" object. I

[issue43463] typing.get_type_hints with TYPE_CHECKING imports / getting hints for single argument

Larry Hastings added the comment: It would also cause the code generated for the annotations function to balloon--the calculation of every value would have to be wrapped in a try/except, and for what I assume is an obscure use case. I'm already getting some pushback on the code generated

[issue43463] typing.get_type_hints with TYPE_CHECKING imports / getting hints for single argument

Larry Hastings added the comment: > Hey Larry, it would seem that PEP 649 as currently specified would make it > impossible to access annotations via the inspect module in cases where > x.__annotations__ raises (because one of the annotations references an > undefined variab

[issue43817] Add typing.get_annotations()

Larry Hastings added the comment: Assuming this function is added for Python 3.10, I propose that uses of typing.get_type_hints() in the standard library that aren't specifically dealing with type hints should change to calling this function instead. I currently know of two sites

[issue43817] Add typing.get_annotations()

Larry Hastings added the comment: > Should this feature implemented in typing module? How about inspect module? That's a reasonable idea. Part of the reasoning behind putting it in the typing module was to share its implementation with typing.get_type_hints(). However, I was read

[issue43817] Add typing.get_annotations()

Larry Hastings added the comment: > I'd say just submit the PR. Shouldn't be problematic. Okey-doke, I can do it. Though I have plenty to do at the moment, though, so it wouldn't be this week. Is there anybody who would *enjoy* taking this on, who we could farm it out to? If not, tha

[issue43817] Add typing.get_annotations()

Larry Hastings added the comment: To be honest, I'm not 100% sure. But I observe that typing.get_type_hints() is about fifty lines of code, and very few of them are the opinionated lines I want to avoid. Some things typing.get_type_hints() seems to do for you: * Work around the "cl

[issue43817] Add typing.get_annotations()

Larry Hastings added the comment: (realized mid-issue-creation that it should have a different name) -- title: Add typing.eval_annotations() -> Add typing.get_annotations() ___ Python tracker <https://bugs.python.org/issu

[issue43817] Add typing.eval_annotations()

New submission from Larry Hastings : Currently, with PEP 563 looming over us, people who use annotations for something besides type hints are kind of stuck. Converting stringized annotations back into useful values is a complicated problem, and there's only function in the standard library

[issue43746] Weird typing annotation closure behavior

Larry Hastings added the comment: By "use case", I mean, what problem are you solving in a useful program by doing this? So far it seems like a pointless exercise in seeing what funny behavior you can try with annotations. -- ___ Pyth

[issue43772] Minor repr error in typing.TypeVar.__ror__()

New submission from Larry Hastings : The implementation of the | operator for TypeVar objects is as follows: def __or__(self, right): return Union[self, right] def __ror__(self, right): return Union[self, right] I think the implementation of __ror__ is ever-so

[issue43746] Weird typing annotation closure behavior

Larry Hastings added the comment: Do you have an actual use case for self-referential annotations? -- nosy: +larry ___ Python tracker <https://bugs.python.org/issue43

[issue27929] asyncio.AbstractEventLoop.sock_connect broken for AF_BLUETOOTH

Change by Larry Hastings : -- nosy: -larry ___ Python tracker <https://bugs.python.org/issue27929> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue20408] memoryview() constructor documentation error

Change by Larry Hastings : -- nosy: -larry ___ Python tracker <https://bugs.python.org/issue20408> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue28712] Non-Windows mappings for a couple of Windows code pages

Change by Larry Hastings : -- nosy: -larry ___ Python tracker <https://bugs.python.org/issue28712> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue20503] super behaviour and abstract base classes (either implementation or documentation/error message is wrong)

Change by Larry Hastings : -- components: +Interpreter Core -Argument Clinic, Documentation nosy: -larry ___ Python tracker <https://bugs.python.org/issue20

[issue21309] Confusing "see also" for generic C-level __init__ methods in help output

Change by Larry Hastings : -- nosy: -larry ___ Python tracker <https://bugs.python.org/issue21309> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43158] uuid won't build when libuuid is installed in a non-standard place

New submission from Larry Hastings : I'm building Python for a mildly-embedded ARM system. The system is running Linux, but doesn't have a native toolchain installed. So I'm building in a Docker container using a native toolchain (virtualizing the CPU). The toolchain I'm given has a bunch

[issue42964] Draft PEP blob etc

Larry Hastings added the comment: (Oops, meant to send that as a private email. Sorry for the noise, I'll try to be more careful in the future.) -- ___ Python tracker <https://bugs.python.org/issue42

[issue42964] Draft PEP blob etc

New submission from Larry Hastings : You interested in me doing an editing pass / critique of your PEP?  I just poked around on Github, and I don't think I can do one of those inline code review things until it's a PR. Also, I'm a PEP editor, I can get it assigned a PEP number when you're

[issue42881] Should typing.get_type_hints change None annotations?

New submission from Larry Hastings : PEP 484 says: (Note that the return type of __init__ ought to be annotated with -> None. The reason for this is subtle. [...] https://www.python.org/dev/peps/pep-0484/#the-meaning-of-annotations If you follow this advice, then c

[issue42616] C Extensions on Darwin that link against libpython are likely to crash

Larry Hastings added the comment: Sorry, somehow bpo decided I added two people to this issue? Weird. Anyway I have removed them (Ned and "froody"). -- nosy: +larry -froody, ned.deily ___ Python tracker <https://bugs.python.o

[issue42616] C Extensions on Darwin that link against libpython are likely to crash

Change by Larry Hastings : -- nosy: -larry ___ Python tracker <https://bugs.python.org/issue42616> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42616] C Extensions on Darwin that link against libpython are likely to crash

Change by Larry Hastings : -- nosy: -larry ___ Python tracker <https://bugs.python.org/issue42616> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42616] C Extensions on Darwin that link against libpython are likely to crash

Larry Hastings added the comment: Stop adding me to this issue. -- ___ Python tracker <https://bugs.python.org/issue42616> ___ ___ Python-bugs-list mailin

[issue42616] C Extensions on Darwin that link against libpython are likely to crash

Change by Larry Hastings : -- nosy: -larry ___ Python tracker <https://bugs.python.org/issue42616> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42310] for loop creates element in defaultdict

Change by Larry Hastings : -- nosy: -larry ___ Python tracker <https://bugs.python.org/issue42310> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue42310] for loop creates element in defaultdict

Larry Hastings added the comment: Yes. Read the documentation for "defaultdict". In the future, please read the documentation before filing bugs. -- components: -Argument Clinic resolution: -> not a bug stage: -> resolved status: open -> cl

[issue7946] Convoy effect with I/O bound threads and New GIL

Larry Hastings added the comment: FWIW: I think David's cited behavior proves that the GIL is de facto a scheduler. And, in case you missed it, scheduling is a hard problem, and not a solved problem. There are increasingly complicated schedulers with new approaches and heuristics

[issue41183] [3.5] Workaround or fix for SSL ".._KEY_TOO_SMALL" test failures

Larry Hastings added the comment: A day and a half to go! Again, assuming that this won't be fixed and 3.5 will go EOL without supporting this year's Linux distro updates. -- ___ Python tracker <https://bugs.python.org/issue41

[issue39603] [security] http.client: HTTP Header Injection in the HTTP method

Larry Hastings added the comment: > Also note that httplib (python-2.7.18) seems to be affected too. Any > particular reason for it not to be listed in the same vulnerability page? Yes: 2.7 has been end-of-lifed and is no longer sup

[issue41183] [3.5] Workaround or fix for SSL ".._KEY_TOO_SMALL" test failures

Larry Hastings added the comment: It depends on whether or not I get any more fixes for the rest of the month. (Theoretically 3.5 support ends on Sep 13, but I decided to extend it to the end of the month.) I filed this on July 1, so it's already been two months, and the developer who

[issue41183] Workaround or fix for SSL ".._KEY_TOO_SMALL" test failures

Larry Hastings added the comment: Nope, it's not fixed. -- resolution: fixed -> stage: resolved -> needs patch status: closed -> open ___ Python tracker <https://bugs.python.or

[issue41716] SyntaxError: EOL while scanning string literal

Change by Larry Hastings : -- components: +Interpreter Core -Argument Clinic nosy: -larry ___ Python tracker <https://bugs.python.org/issue41716> ___ ___ Pytho

[issue39603] [security] http.client: HTTP Header Injection in the HTTP method

Larry Hastings added the comment: New changeset 524b8de630036a29ca340bc2ae6fd6dc7dda8f40 by Victor Stinner in branch '3.5': bpo-39603: Prevent header injection in http methods (GH-18485) (#21946) https://github.com/python/cpython/commit/524b8de630036a29ca340bc2ae6fd6dc7dda8f40

[issue41183] Workaround or fix for SSL ".._KEY_TOO_SMALL" test failures

Larry Hastings added the comment: > Does testing with the environment variable OPENSSL_CONF=/non-existing-file > workaround the remaining issues? Sadly, no. I get the same failures whether or not that environment variable is set. And I confirmed that the environment variable su

[issue41004] [CVE-2020-14422] Hash collisions in IPv4Interface and IPv6Interface

Change by Larry Hastings : -- assignee: eric.smith -> status: open -> closed ___ Python tracker <https://bugs.python.org/issue41004> ___ ___ Python-bugs-

[issue41004] [CVE-2020-14422] Hash collisions in IPv4Interface and IPv6Interface

Larry Hastings added the comment: New changeset 11d258ceafdf60ab3840f9a5700f2d0ad3e2e2d1 by Tapas Kundu in branch '3.5': [3.5] bpo-41004: Resolve hash collisions for IPv4Interface and IPv6Interface (GH-21033) (#21233) https://github.com/python/cpython/commit

[issue29778] [CVE-2020-15523] _Py_CheckPython3 uses uninitialized dllpath when embedder sets module path with Py_SetPath

Larry Hastings added the comment: New changeset f205f1000a2d7f8b044caf281041b3705f293480 by Steve Dower in branch '3.5': [3.5] bpo-29778: Ensure python3.dll is loaded from correct locations when Python is embedded (GH-21297) (#21377) https://github.com/python/cpython/commit

[issue41459] pickle.load raises SystemError on malformed input

Change by Larry Hastings : -- nosy: -larry ___ Python tracker <https://bugs.python.org/issue41459> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue29778] [CVE-2020-15523] _Py_CheckPython3 uses uninitialized dllpath when embedder sets module path with Py_SetPath

Larry Hastings added the comment: I still don't understand why this is considered a Python security problem. If the user can put a malicious "python3.dll" at some arbitrary spot in the filesystem (e.g. a USB flash drive), and fool Python.exe into loading it, then surely they

[issue29778] [CVE-2020-15523] _Py_CheckPython3 uses uninitialized dllpath when embedder sets module path with Py_SetPath

Larry Hastings added the comment: I must have taken my stupid pills today. Why is this considered a "security" "release blocker"? If you can put files in the root of the hard drive where Windows was installed, surely you have other, e

[issue39017] Infinite loop in the tarfile module

Change by Larry Hastings : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue39017] Infinite loop in the tarfile module

Larry Hastings added the comment: New changeset cac9ca8ed99bd98f4c0dcd1913a146192bf5ee84 by Petr Viktorin in branch '3.5': [3.5] bpo-39017: Avoid infinite loop in the tarfile module (GH-21454) (#21489) https://github.com/python/cpython/commit/cac9ca8ed99bd98f4c0dcd1913a146192bf5ee84

[issue41183] Workaround or fix for SSL ".._KEY_TOO_SMALL" test failures

Larry Hastings added the comment: Ping? -- ___ Python tracker <https://bugs.python.org/issue41183> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39017] Infinite loop in the tarfile module

Larry Hastings added the comment: Yes, please. It's a simple low-risk fix. And 3.5.10rc1 is stuck waiting for a fix anyway. Thanks! -- ___ Python tracker <https://bugs.python.org/issue39

[issue41183] Workaround or fix for SSL ".._KEY_TOO_SMALL" test failures

Larry Hastings added the comment: Any news? -- ___ Python tracker <https://bugs.python.org/issue41183> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue41183] Workaround or fix for SSL ".._KEY_TOO_SMALL" test failures

Larry Hastings added the comment: New changeset f52bf62fe12d46267e958f80dbe1f4425b55cd0f by Christian Heimes in branch '3.5': bpo-41183: Update finite DH params to 3072 bits (#21278) https://github.com/python/cpython/commit/f52bf62fe12d46267e958f80dbe1f4425b55cd0f

[issue41183] Workaround or fix for SSL ".._KEY_TOO_SMALL" test failures

Larry Hastings added the comment: Gotcha. Thanks for looking into it for me. I don't think the world is super anxious about getting 3.5.10rc1 so it's not a big huge deal. But I will wait to hear back from you. Thanks! -- ___ Python tracker

[issue41183] Workaround or fix for SSL ".._KEY_TOO_SMALL" test failures

Larry Hastings added the comment: Do you need a temporary login on one of my Pop!_OS computers, in order to test? -- ___ Python tracker <https://bugs.python.org/issue41

[issue41183] Workaround or fix for SSL ".._KEY_TOO_SMALL" test failures

Larry Hastings added the comment: ./python -m test -v test_ssl >& test_ssl_verbose_36_master -- Added file: https://bugs.python.org/file49290/test_ssl_verbose_36_master ___ Python tracker <https://bugs.python.org/

[issue41183] Workaround or fix for SSL ".._KEY_TOO_SMALL" test failures

Larry Hastings added the comment: I assume this is building against the system OpenSSL. On this machine, the "openssl", "libssl1.1", and "libssl-dev" packages are all version "1.1.1f-1ubuntu2". The OS is "Pop!_OS" version 20.04, w

[issue41183] Workaround or fix for SSL ".._KEY_TOO_SMALL" test failures

Larry Hastings added the comment: The 3.6 branch of python/cpython fails as well on this machine. Output attached. -- Added file: https://bugs.python.org/file49288/test_ssl_36_branch ___ Python tracker <https://bugs.python.org/issue41

[issue41183] Workaround or fix for SSL ".._KEY_TOO_SMALL" test failures

Larry Hastings added the comment: test_ssl was one of the seven modules that failed. But attached here is just the output of % ./python -m test -v test_ssl >& test_ssl_failure -- Added file: https://bugs.python.org/file49287/test_ssl_

[issue41183] Workaround or fix for SSL ".._KEY_TOO_SMALL" test failures

Larry Hastings added the comment: Upgrading to release blocker. -- priority: high -> release blocker resolution: fixed -> stage: resolved -> needs patch status: closed -> open ___ Python tracker <https://bugs.python

[issue41183] Workaround or fix for SSL ".._KEY_TOO_SMALL" test failures

Larry Hastings added the comment: Christian: Help! Again! I merged your PR, pulled a fresh copy, built it, and ran the test suite. I get seven failures in I think the same modules. Most of the failures are either "ssl.SSLError: [SSL] internal error (_ssl.c:728)", or s

[issue34542] [TLS] Update test certs to future proof settings

Larry Hastings added the comment: I also needed a backport of this to 3.5. See #41183. Also, it looks like this issue should have been closed long ago, so I'll go ahead and do that. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions

[issue41183] Workaround or fix for SSL "EE_KEY_TOO_SMALL" test failures

Larry Hastings added the comment: Thanks for the backport! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue41183] Workaround or fix for SSL "EE_KEY_TOO_SMALL" test failures

Larry Hastings added the comment: New changeset d565be84993a3d618add139cf21038e12c60a13e by Christian Heimes in branch '3.5': bpo-41183: Update test certs and keys (#21258) https://github.com/python/cpython/commit/d565be84993a3d618add139cf21038e12c60a13e

[issue34542] [TLS] Update test certs to future proof settings

Larry Hastings added the comment: New changeset d565be84993a3d618add139cf21038e12c60a13e by Christian Heimes in branch '3.5': bpo-41183: Update test certs and keys (#21258) https://github.com/python/cpython/commit/d565be84993a3d618add139cf21038e12c60a13e -- nosy: +larry

[issue41183] Workaround or fix for SSL "EE_KEY_TOO_SMALL" test failures

New submission from Larry Hastings : I'm testing 3.5.10rc1 on a freshly installed Linux (Pop!_OS 20.04), and I'm getting a lot of these test failures: ssl.SSLError: [SSL: EE_KEY_TOO_SMALL] ee key too small (_ssl.c:2951) Apparently the 2048 keys used in the tests are considered "too

[issue41170] Use strnlen instead of strlen when the size i known.

Larry Hastings added the comment: strnlen() isn't standard C, but an exciting new function strnlen_s() is, as of C11. https://en.cppreference.com/w/c/string/byte/strlen (At this rate, we should be able to code CPython using that standard in about 2030.) But! I found a 2005 thread

[issue39503] [security][CVE-2020-8492] Denial of service in urllib.request.AbstractBasicAuthHandler

Change by Larry Hastings : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue38576] CVE-2019-18348: CRLF injection via the host part of the url passed to urlopen()

Larry Hastings added the comment: New changeset 09d8172837b6985c4ad90ee025f6b5a554a9f0ac by Tapas Kundu in branch '3.5': [3.5] closes bpo-38576: Disallow control characters in hostnames in http.client. (#19300) https://github.com/python/cpython/commit

[issue39503] [security][CVE-2020-8492] Denial of service in urllib.request.AbstractBasicAuthHandler

Larry Hastings added the comment: New changeset 37fe316479e0b6906a74b0c0a5e495c55037fdfd by Victor Stinner in branch '3.5': bpo-39503: CVE-2020-8492: Fix AbstractBasicAuthHandler (GH-18284) (#19305) https://github.com/python/cpython/commit/37fe316479e0b6906a74b0c0a5e495c55037fdfd

[issue39073] [security] email module incorrect handling of CR and LF newline characters in Address objects.

Larry Hastings added the comment: New changeset f91a0b6df14d6c5133fe3d5889fad7d84fc0c046 by Victor Stinner in branch '3.5': bpo-39073: validate Address parts to disallow CRLF (#19007) (#20450) https://github.com/python/cpython/commit/f91a0b6df14d6c5133fe3d5889fad7d84fc0c046 -- nosy

[issue39035] Travis CI fail on backports: pyvenv not installed

Larry Hastings added the comment: New changeset f88b578949a034f511dd1b4c1c161351b3ee0db8 by Inada Naoki in branch '3.5': bpo-39035: travis: Update image to xenial (#17623) https://github.com/python/cpython/commit/f88b578949a034f511dd1b4c1c161351b3ee0db8 -- nosy: +larry

[issue40179] Argument Clinic incorretly translates #elif

Larry Hastings added the comment: Good catch, and thanks for submitting a patch too! I want to play with your patch a little before I just say "yes of course". -- ___ Python tracker <https://bugs.python.o

<    1   2   3   4   5   6   7   8   9   10   >