[Python-Dev] Re: About vulnerabilities in Cpython native code
On Fri, Jan 7, 2022 at 6:09 PM Stephen J. Turnbull wrote: > > Chris Angelico writes: > > > Python source code is not user input though. So there has to be a way > > for someone to attack a Python-based service, like attacking a web app > > by sending HTTP requests to it. > > Not sure what your point is. Of course there has to be a vector. But > as a Mailman developer, I can assure you that there are Python > programs facing the web that accept HTTP requests and SMTP messages, > and process the content, which could be anything an attacker wants it > to be. > > I can't recall any CVEs that we could trace to Python (rather than our > code :-/), but Mailman can be and has been attacked. I can imagine > that if there was an RCE vulnerability in Python or a C module we use, > Mailman would be a top candidate for a workable exploit because of the > amount of processing of user-supplied text we must do. (Don't worry > about me, I sleep well anyway. Python is pretty bullet-proof IMO ;-) > > Did I completely misunderstand you, or the previous posters? Not completely, just very minorly. I'm distinguishing between attacks that can be triggered remotely, and those which require the attacker to run specific Python code. For example, using ctypes to change the value of an integer object is not an attack vector, because there's no way for an HTTP or SMTP message to cause you to do that. There are *plenty* of ways to abuse ctypes to crash CPython, and we're not afraid of them, because we don't do that kind of thing in public-facing code. :) (If there is a way for an attacker to run arbitrary Python code (maybe by abusing a templating system), then that is its own attack vector, since anything can be done, without any sort of interpreter crash.) My distinction here is that the source code for Mailman itself is not "user input" any more than the source code for CPython is. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/6MYAL4ZEELKO3RHL4UZYY2DSOGM56B6W/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2021-12-31 - 2022-01-07)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7199 ( +4)
closed 50825 (+78)
total 58024 (+82)
Open issues with patches: 2886
Issues opened (50)
==
#34931: os.path.splitext with more dots
https://bugs.python.org/issue34931 reopened by xnovakj
#46009: sending non-None values makes generator raise StopIteration on
https://bugs.python.org/issue46009 reopened by christian.heimes
#46110: compile("-"*300 + "4", '', mode) causes hard crash
https://bugs.python.org/issue46110 reopened by pablogsal
#46216: spurious link to os.system() from os.times() documentation ent
https://bugs.python.org/issue46216 opened by emery.berger
#46217: 3.11 build failure on Win10: new _freeze_module changes?
https://bugs.python.org/issue46217 opened by terry.reedy
#46220: imaplib.py "select" mailbox names containing spaces.
https://bugs.python.org/issue46220 opened by mckenzm
#46223: asyncio cause infinite loop during debug
https://bugs.python.org/issue46223 opened by zillionare
#46225: f_lasti behaves differently for lambdas returned from loops
https://bugs.python.org/issue46225 opened by nedbat
#46226: User specific paths added to System PATH environment variable
https://bugs.python.org/issue46226 opened by akrymskiy
#46227: add pathlib.Path.walk method
https://bugs.python.org/issue46227 opened by Ovsyanka
#46232: Client certificates with UniqueIdentifier in the subject break
https://bugs.python.org/issue46232 opened by kacper
#46234: 3.11: Tracing of decorators now visits the decorator line befo
https://bugs.python.org/issue46234 opened by nedbat
#46235: Do all ref-counting at once for sequence multiplication
https://bugs.python.org/issue46235 opened by Dennis Sweeney
#46237: Incorrect line reported in syntax error
https://bugs.python.org/issue46237 opened by arian-f
#46242: Improve error message when attempting to extend an enum with `
https://bugs.python.org/issue46242 opened by sobolevn
#46244: typing._TypeVarLike missing __slots__
https://bugs.python.org/issue46244 opened by ariebovenberg
#46245: Add support for dir_fd in shutil.rmtree()
https://bugs.python.org/issue46245 opened by serhiy.storchaka
#46246: importlib.metadata.DeprecatedList appears to be missing __slot
https://bugs.python.org/issue46246 opened by ariebovenberg
#46247: in xml.dom.minidom, Node and DocumentLS appear to be missing _
https://bugs.python.org/issue46247 opened by ariebovenberg
#46249: [sqlite3] move set lastrowid out of the query loop and enable
https://bugs.python.org/issue46249 opened by erlendaasland
#46250: 3.10 docs responsive design removes navigation buttons (next,
https://bugs.python.org/issue46250 opened by vkvanjavk
#46252: SSLWantReadError causes _SelectorSocketTransport to close
https://bugs.python.org/issue46252 opened by matan1008
#46253: C API documentation of Py_UNICODE_* character properties macro
https://bugs.python.org/issue46253 opened by juliangilbey
#46254: Better fitting type for iterating in the trace_init C function
https://bugs.python.org/issue46254 opened by uriya1998
#46255: Remove unnecessary check in _IOBase._check*() methods
https://bugs.python.org/issue46255 opened by malin
#46258: Minor algorithmic improvements for math.isqrt
https://bugs.python.org/issue46258 opened by mark.dickinson
#46261: [doc] fix inaccuracies in sqlite3.Cursor.lastrowid docs
https://bugs.python.org/issue46261 opened by erlendaasland
#46264: 'I'.lower() should give non dotted i for LANG=tr_TR
https://bugs.python.org/issue46264 opened by fbacher
#46265: Error when cross compiling for hardfloat MIPS
https://bugs.python.org/issue46265 opened by jefferyto
#46267: gzip.compress incorrectly ignores level parameter
https://bugs.python.org/issue46267 opened by rhpvorderman
#46269: '__new__' is never shown in `dir(SomeEnum)`
https://bugs.python.org/issue46269 opened by sobolevn
#46270: Comparison operators in Python Tutorial 5.7
https://bugs.python.org/issue46270 opened by realjanpaulus
#46271: frozen modules are not regenerated on bytecode magic change wh
https://bugs.python.org/issue46271 opened by christian.heimes
#46272: Fix bitwise and logical terminology in python.gram
https://bugs.python.org/issue46272 opened by rhettinger
#46273: Document what asyncio.wait() and asyncio.as_completed() do if
https://bugs.python.org/issue46273 opened by termim
#46274: Tokenizer module does not handle backslash characters correctl
https://bugs.python.org/issue46274 opened by ucodery
#46275: caret location for syntax error pointing with f-strings
https://bugs.python.org/issue46275 opened by williamnavaraj
#46276: ImportError: DLL load failed while importing
https://bugs.python.org/issue46276 opened by 89z
#46279: [docs] Minor information-ordering issue in __main__ doc
https://bugs.p
[Python-Dev] Suggestion: a little language for type definitions
I posted this suggestion earlier in the callable type syntax discussion, at
which point it was completely ignored. Possibly because it’s a really stupid
idea, but let me post it again on the off chance that it isn’t a stupid idea
but was overlooked.
> If I can make a wild suggestion: why not create a little language for type
> specifications?
>
> If you look at other programming languages you’ll see that the “type
> definition sub-language” is often completely different from the “execution
> sub-language”, with only some symbols in common and used in vaguely related
> ways. `bool (*myfuncptr)(int, float*)` uses a completely different set of
> syntactic rules than `rv = (*myfunptr)(*myintptr, &myfloat)`. So with some
> grains of salt you could say that C is comprised of a declarative typing
> sublanguage and an imperative execution sublanguage.
And an even better example is Pascal, which uses a set of syntactic constructs
for typing that are completely different from the execution statement syntax:
`var a : array[1..10] of real` looks very different from `a[1]`, where C `float
a[10]` looks pretty similar to `a[10]`.
The next bit of my original email is another wild idea, the previous bit
doesn’t depend on it really. I can imagine completely different ways of doing a
typing sublanguage:
> Python typing uses basically a subset of the execution expression syntax as
> its declarative typing language.
>
> What if we created a little language that is clearly flagged, for example as
> t”….” or t’….’? Then we could simply define the typestring language to be
> readable, so you could indeed say t”(int, str) -> bool”. And we could even
> allow escapes (similar to f-strings) so that the previous expression could
> also be specified, if you really wanted to, as t”{typing.Callable[[int, str],
> bool}”.
--
Jack Jansen, , http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma Goldman
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/26JB6YIPWXUSTQSXTVSZMUS6FM4RZBJA/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Suggestion: a little language for type definitions
On Fri, Jan 7, 2022 at 4:04 PM wrote:
> I posted this suggestion earlier in the callable type syntax discussion,
> at which point it was completely ignored.
>
Maybe not. I made a similar suggestion early in the thread, and Brett
Cannon said that the SC had rejected that approach.
But I’m not sure when that was— is it time to revisit the idea?
Note that if PEP 563 is ultimately accepted, then Annotations would be
strings, and type checkers could use any language they wanted.
In fact, right now annotations can
Optionally be strings anyway.
I don’t think that would be good for the community to have multiple sys to
do it, but it might be a way to experiment.
-CHB
Possibly because it’s a really stupid idea, but let me post it again on the
> off chance that it isn’t a stupid idea but was overlooked.
>
> If I can make a wild suggestion: why not create a little language for type
> specifications?
>
> If you look at other programming languages you’ll see that the “type
> definition sub-language” is often completely different from the “execution
> sub-language”, with only some symbols in common and used in vaguely related
> ways. `bool (*myfuncptr)(int, float*)` uses a completely different set of
> syntactic rules than `rv = (*myfunptr)(*myintptr, &myfloat)`. So with some
> grains of salt you could say that C is comprised of a declarative typing
> sublanguage and an imperative execution sublanguage.
>
>
> And an even better example is Pascal, which uses a set of syntactic
> constructs for typing that are completely different from the execution
> statement syntax: `var a : array[1..10] of real` looks very different from
> `a[1]`, where C `float a[10]` looks pretty similar to `a[10]`.
>
> The next bit of my original email is another wild idea, the previous bit
> doesn’t depend on it really. I can imagine completely different ways of
> doing a typing sublanguage:
>
> Python typing uses basically a subset of the execution expression syntax
> as its declarative typing language.
>
> What if we created a little language that is clearly flagged, for example
> as t”….” or t’….’? Then we could simply define the typestring language to
> be readable, so you could indeed say t”(int, str) -> bool”. And we could
> even allow escapes (similar to f-strings) so that the previous expression
> could also be specified, if you really wanted to, as
> t”{typing.Callable[[int, str], bool}”.
>
>
> --
>
> Jack Jansen, , http://www.cwi.nl/~jack
>
> If I can't dance I don't want to be part of your revolution -- Emma Goldman
>
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/26JB6YIPWXUSTQSXTVSZMUS6FM4RZBJA/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Christopher Barker, PhD (Chris)
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/WW6YHV45OUEAIJCYWZ7TLAEGUO75QEOW/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Suggestion: a little language for type definitions
This is actually a topic the 2021 SC discussed at length and at the time we
decided that the typing language should follow the execution language. It was
buried in the call type syntax thread so it’s was probably easy to miss:
https://mail.python.org/archives/list/python-dev@python.org/message/4TY3MVJQOLKSTMCJRTGAZEOSIIMAWQ45/
Of course, this decision can be revisited by the 2022 SC.
-Barry
> On Jan 7, 2022, at 15:59, jack.jan...@cwi.nl wrote:
>
> I posted this suggestion earlier in the callable type syntax discussion, at
> which point it was completely ignored. Possibly because it’s a really stupid
> idea, but let me post it again on the off chance that it isn’t a stupid idea
> but was overlooked.
>
>> If I can make a wild suggestion: why not create a little language for type
>> specifications?
>>
>> If you look at other programming languages you’ll see that the “type
>> definition sub-language” is often completely different from the “execution
>> sub-language”, with only some symbols in common and used in vaguely related
>> ways. `bool (*myfuncptr)(int, float*)` uses a completely different set of
>> syntactic rules than `rv = (*myfunptr)(*myintptr, &myfloat)`. So with some
>> grains of salt you could say that C is comprised of a declarative typing
>> sublanguage and an imperative execution sublanguage.
>
> And an even better example is Pascal, which uses a set of syntactic
> constructs for typing that are completely different from the execution
> statement syntax: `var a : array[1..10] of real` looks very different from
> `a[1]`, where C `float a[10]` looks pretty similar to `a[10]`.
>
> The next bit of my original email is another wild idea, the previous bit
> doesn’t depend on it really. I can imagine completely different ways of doing
> a typing sublanguage:
>
>> Python typing uses basically a subset of the execution expression syntax as
>> its declarative typing language.
>>
>> What if we created a little language that is clearly flagged, for example as
>> t”….” or t’….’? Then we could simply define the typestring language to be
>> readable, so you could indeed say t”(int, str) -> bool”. And we could even
>> allow escapes (similar to f-strings) so that the previous expression could
>> also be specified, if you really wanted to, as t”{typing.Callable[[int,
>> str], bool}”.
>
> --
> Jack Jansen, , http://www.cwi.nl/~jack
> If I can't dance I don't want to be part of your revolution -- Emma Goldman
>
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/26JB6YIPWXUSTQSXTVSZMUS6FM4RZBJA/
> Code of Conduct: http://python.org/psf/codeofconduct/
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/FRLJ6HS3LMF3LYG5WAF5RBYQIWEQASZX/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Python 3.6 rides into the sunset
While there are many reasons to welcome the end of 2021, I would like to give a shout-out to Python 3.6 which officially reached end-of-life on 2021-12-23, 6.5 years after its development began and exactly five years after its initial release. Building on the success of previous Python 3 releases, 3.6 added many new features and improvements too numerous to list: over 1 commits by some 160 contributors, including one of the most popular features in recent Python releases, f-strings (thanks, EVS!). I think it is fair to say that, with Python 3.6, the long transition from Python 2 was finally settled. As release manager for 3.6, I would like to personally thank all those contributors, and mostly volunteers: you made my job an easy one with your overwhelmingly positive attitude and support. I would also like to thank the authors and maintainers of the many third-party packages that were updated to support 3.6 as well as the downstream distributors of Python whose rapid uptake and release of 3.6 in their distributions was crucial to its success. I would also like to thank those who helped get the 3.6 releases out the door, in particular, Steve Dower for manufacturing the Windows packages, Julien Palard for managing our on-line documentation build process, Elvis Pranskevichus and Yury Selivanov for taking on the thankless task of assembling and editing the 3.6 "What's New" document, my fellow release managers for their encouragement and support from the start to finish of 3.6's life, the Steering Councils, the PSF Infrastructure Team, those individuals and organizations who contribute resources (money, people, time, facilities, services) to the PSF, making Python development possible. And, I suppose I should thank that git who produces the macOS packages. Thanks again to you all for making 3.6 so successful! --Ned P.S. As a reminder, with 3.6 having reached end-of-life, we no longer accept bug reports of any type against 3.6 and the 3.6 source code is now frozen. There is no longer a 3.6 branch in the GitHub cpython repository; the final state of the branch is captured in the repo as tag "3.6" and, as always, the source code for any release can be checked out using its tag; for example, the source for the final release of 3.6 can be obtained with "git checkout v3.6.15". Pro tip: if you haven't already, you may want to update your repo clones with "git fetch --tags upstream" (if you use the recommended naming convention) to get the latest tags and branches. -- Ned Deily n...@python.org -- [] ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/CZRA7AMKWZ5AJIJM3OFYY7P24I5L2LPS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Suggestion: a little language for type definitions
On Fri, Jan 07, 2022 at 04:27:37PM -0800, Christopher Barker wrote: > Note that if PEP 563 is ultimately accepted, then Annotations would be > strings, and type checkers could use any language they wanted. Annotations still have to be syntactically valid Python expressions. >>> from __future__ import annotations >>> def func(arg: array[1...10] of float) -> str: pass File "", line 1 def func(arg: array[1...10] of float) -> str: pass ^^^ SyntaxError: invalid syntax Of course if you explicitly wrap your annotation in quotation marks, you can use any syntax you like (think: regexes, SQL, etc). But without a *standard* annotation syntax: - static checkers will disagree on what annotations mean; - runtime introspection will be difficult; and - IDEs and syntax colourisers are going to just treat them as strings. We can write little DSLs with any syntax we like using explicitly quoted strings. We're not limited to do this in annotations. But while DSLs tend to be specific to your own library or application, annotations exist in a wide ecosystem of both static and runtime tools that expect to interpret annotations. Writing your own little DSL for annotations cuts you off from the rest of the Python ecosystem. -- Steve ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/65UGW2D5ATEVDQVNPYX4B7QZFQJOLXOO/ Code of Conduct: http://python.org/psf/codeofconduct/
