[Python-Dev] Upcoming 3.7.9 and 3.6.12 Security Releases

2020-08-12 Thread Ned Deily 
We are planning to produce security-fix rollup releases for Python 3.7.x and 
3.6.x on 2020-08-14. The most recent releases for these versions were on 
2020-06-27 and 3.7.8 was the final bugfix release for 3.7.  Shortly after those 
releases, several security issues affecting them were fixed.  Because one of 
those fixes addresses a potential security vulnerability when using Python on 
Windows (https://bugs.python.org/issue29778), we are making an exception and 
providing updated binary installers for 3.7.9 since this first 3.7.x security 
release follows so soon after the final 3.7.x bugfix release.

Also, starting with these releases, we plan to no longer produce release 
candidates for 3.7.x and 3.6.x security releases, and instead simply provide 
final releases, as we receive little to no feedback from security release 
candidates and the number of changes in each security releases is small.

Core developers: if you know of any additional security issues that should be 
addressed in these releases, please mark the relevant bpo issues as "release 
blocker" and, if possible, submit PRs for review prior to the end of 2020-08-13 
AOE.  Thanks!

--
  Ned Deily
  [email protected] -- []
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/AS45YBRKOJQC7WB5GLHZB65HYJCNTK6A/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: async generator bug fixed in 3.8+ and backported to 3.6 but not to 3.7

2020-08-12 Thread Ned Deily 
On Aug 11, 2020, at 16:59, Guido van Rossum  wrote:
> If the release manager agrees, this should be a simple call to cherry-picker.
> 
> On Tue, Aug 11, 2020 at 13:18 Matthew Einhorn  wrote:
>> The fix for https://bugs.python.org/issue33786 ("@asynccontextmanager 
>> doesn't work well with async generators") was merged in 3.8 and then 
>> backported to 3.6. However, it was overlooked to be backported for 3.7 
>> (https://github.com/python/cpython/pull/7506).
>> 
>> I'm aware that 3.7 is in security fix mode only so I'm not sure there's more 
>> to be done, however, given that this is fixed for 3.6, 3.7 is in a weird 
>> position still having the bug.
>> 
>> So I just wanted to bring this up in case the fix can still be backported to 
>> 3.7.

Thanks for bringing this up.  I have re-opened bpo-33786 to include the missing 
3.7 backport in the next 3.7.x release.

--
  Ned Deily
  [email protected] -- []
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/WHEWJ642AIZDROKPCIQKBYXMQFNQKUFL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [python-committers] Upcoming 3.7.9 and 3.6.12 Security Releases

2020-08-12 Thread Victor Stinner 
Le mer. 12 août 2020 à 12:03, Ned Deily  a écrit :
> Core developers: if you know of any additional security issues that should be 
> addressed in these releases, please mark the relevant bpo issues as "release 
> blocker" and, if possible, submit PRs for review prior to the end of 
> 2020-08-13 AOE.  Thanks!

The vulnerabilities that I'm tracking are all fixed in the 3.7 branch: good!

--

I'm maintaining
https://python-security.readthedocs.io/vulnerabilities.html list
manually. It's a list of known Python vulnerabilities. I'm using it to
ensure that known vulnerabilities are fixed in all branches which
still accept security fixes (3.5, 3.6, 3.7, 3.8, 3.9, master). It's
common that the oldest branches are forgotten.

Right now, Python 3.7 is considered as vulnerable to these 4 vulnerabilities:

- https://python-security.readthedocs.io/vuln/ipaddress-hash-collisions.html
- https://python-security.readthedocs.io/vuln/http-header-injection-method.html
- https://python-security.readthedocs.io/vuln/tarfile-pax-dos.html
- https://python-security.readthedocs.io/vuln/pysetpath-python-dll-path.html

All of them have "Python 3.7 (need release)" status: a fix is already
merged in the 3.7 branch, but there is no release including it yet.

Again, I'm maintaining the list manually, so there are maybe a few
other security fixes that I failed to track in this list.

--

By the way, I'm also maintaining
https://pypi.org/project/check-python-vuln/ project: it checks Python
for known vulnerabilities. The list of tested vulnerabilities is even
shorter :-(

If you would like to help, visit:

* https://github.com/vstinner/python-security/
* https://github.com/vstinner/check_python_vuln

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/FBA4GV4PNSSHXNT4XFZ4MV6EYWQ72ZUL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [python-committers] Upcoming 3.7.9 and 3.6.12 Security Releases

2020-08-12 Thread Vinay Sharma via Python-Dev 
Hi,
I am sorry to intrude in this thread. But I think there is a vulnerability in 
macos caused by ftruncate. For instance running the following code abruptly 
crashed macos (mojave and catalina).

```
from multiprocessing.shared_memory import SharedMemory
shm = SharedMemory(name='test-crash', create=True, size=100)
```
This is being tracked at https://bugs.python.org/issue39584 
.
Could please comment whether this should be fixed by python, or we should wait 
for a macos fix.

> On 12-Aug-2020, at 4:38 PM, Victor Stinner  wrote:
> 
> https://pypi.org/project/check-python-vuln/ 
> 
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/K23LLSPSJ3RCJZUNXKSXURJLVTPFS3KB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [python-committers] Upcoming 3.7.9 and 3.6.12 Security Releases

2020-08-12 Thread Victor Stinner 
Le mer. 12 août 2020 à 14:09, Vinay Sharma  a écrit :
> This is being tracked at https://bugs.python.org/issue39584.
> Could please comment whether this should be fixed by python, or we should 
> wait for a macos fix.

This issue looks like a regular bug. I suggest not holding a security
release for it. It's more important than fixes for security
vulnerabilities are released as soon as possible.

Also, it seems easy to work around the issue: don't attempt to
allocate 1 PB if you only have 8 GB of memory :-)

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/WMBTHQZVTSCCUAFMWJ5FTWG3OFZ423CJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 and variadic positional-only args

2020-08-12 Thread Jim J. Jewett 
Oscar Benjamin's study of sympy is part of what prompted this, and does provide 
a concrete example of why constructors should be echoed.

I think in general, the matching has fallen into two categories:

(1)  Simple literal-like matching, that mostly works OK.  There is still some 
concern over what is a bind variable vs a match constraint, but it mostly 
works.  And everyone agrees that it isn't the important or interesting part of 
the proposal.

(2)  Object destructuring matches, that ... are not as close to resolution.  It 
occurs to me that object creation is also a function call (albeit with an 
implicit self), so this may be a good place to build on Bound Signatures. 
(Think inspect.Parameter, but also containing the value.)

I hope (and think) that the result for sympy would be about what Oscar asked 
for (below), so I'll fill in with the more generic Point-based example.

class Point:
def __init__ Point(self, x, y, z=0, *, color=Color.BLACK): ...

case Point(23, y=y, oldcolor=color):   # z doesn't matter

I have weak opinions on whether to require y=y to (or y= or :=y or ...) to 
capture one of the variables when it isn't being renamed.

Oscar Benjamin wrote:
> I've taken a look through PEP 622 and I've been thinking about how
> it could be used with sympy.

> ... The key feature of Basic instances is that they have an .args
> attribute which can be used to rebuild the object ...

> All Basic classes are strictly constructed using positional only
> arguments and not keyword arguments. In the PEP it seems that
> we can handle positional arguments when their number is fixed 
> by the type. ... The main problem though is with variadic positional
> arguments. ...

> From a first glimpse of the proposal I thought I could do matches like this:
> match obj:
> case Add(Mul(x, y), Mul(z, t)) if y == t:
> case Add(terms):
> case Mul(coeff, factors):
> case And(Or(A, B), Or(C, D)) if B == D:
> case Union(Interval(x1, y1), Interval(x2, y2)) if y1 == x2:
> case Union(Interval(x, y), FiniteSet(p)) | Union(FiniteSet(p),
> Interval(x, y)):
> case Union(*sets):
> Knowing the sympy codebase each of those patterns would look quite
> natural because they resemble the constructors for the corresponding
> objects (as intended in the PEP). It seems instead that many of these
> constructors would need to have args= so it becomes:
> match obj:
> case Add(args=(Mul(args=(x, y)), Mul(args=(z, t if y == t:
> case Add(args=terms):
> case Mul(args=(coeff, *factors)):
> case And(args=(Or(args=(A, B)), Or(args=(C, D if C == D:
> case Union(args=(Interval(x1, y1), Interval(x2, y2))) if y1 == x2:
> case Union(args=(Interval(x, y), FiniteSet(args=p))) |
> Union(args=(FiniteSet(args=p), Interval(x, y))):
> case Union(args=sets):
> Each of these looks less natural as they don't match the constructors
> and the syntax gets messier with nesting.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/T2C2KI5DSXJ63MC2XMTXXC6E65VZ5FZK/
Code of Conduct: http://python.org/psf/codeofconduct/