Hi,
I wrote a PR to fix the following urllib security vulnerability:
"urlparse of urllib returns wrong hostname"
https://bugs.python.org/issue36338https://github.com/python/cpython/pull/16780
While writing my fix, I found another issue about "[" and "]"
characters in the user:password section of an URL:
"urllib IPv6 parsing fails with special characters in passwords"
https://bugs.python.org/issue33342
My PR tries to validate the "scope" part of
"http://[IPv6%scope]/...": reject "%", "[" and "]" in scope. But I'm
not sure that Python should really support the scope in an URL. Should
we just reject URL with "%scope"? Or if we allow it, which characters
should be allowed and/or rejected?
It seems like Firefox and Chromium don't support an IPv6 with as a
scope: when I type http://[::1%1]/ : they open a Google search on this
URL.
I tested Python urllib.request.urlopen() with my PR:
http://[::1%1]:8080/ works as expected: it opens a connection to the
IPv6 localhost in the loopback interface (TCP port 8080).
Currently, my PR allows "%scope" but it rejects "%", "[" and "]"
characters in the scope.
I let you go through these 2 RFC about IPv6 scope / "zone identifier":
https://tools.ietf.org/html/rfc4007https://tools.ietf.org/html/rfc6874
Victor
--
Night gathers, and now my watch begins. It shall not end until my death.
Hi folks,
Since we have two competing proposals for the Steering Council to
consider when it comes to the target release date for Python 3.9.0,
Steve, Łukasz and I put together a short-ish overview of the common
set of problems that the two PEPs are both attempting to address, as
well as the common risks that they're attempting to mitigate.
If folks have questions or suggestions regarding the specific
proposals, those discussion threads can be found on Discourse here:
PEP 602 (12 month release cadence):
https://discuss.python.org/t/pep-602-annual-release-cycle-for-python/2296
PEP 605 (24 month traditional release cadence with a rolling
pre-release stream):
https://discuss.python.org/t/pep-605-a-rolling-feature-release-stream-for-c…
There's also a thread for the new overview PEP:
https://discuss.python.org/t/pep-607-shared-background-for-the-release-cade…
I expect most comments will be best targeted at the threads for the
specific proposals, but the PEP 607 thread should still be useful if
folks have questions or comments about the overview PEP itself.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
Greetings,
I'm wealful to announce the immediate availability of Python 2.7.17, another bugfix release in the Python 2.7 series. Downloads are on python.org:
https://www.python.org/downloads/release/python-2717/
No code changes occurred between the 2.7.17 release candidate and the final release, but there were some documentation changes. See the 2.7.17rc1 changelog for changes between 2.7.16 and 2.7.17:
https://raw.githubusercontent.com/python/cpython/c2f86d86e6c8f5fd1ef602128b…
PEP 373, the Python 2.7 releases schedule, designates 2.7.17 as the penultimate Python 2.7 release. So, be aware that the upstream demise of Python 2 is not far away.
For the time being, bugs may be reported to https://bugs.python.org.
See you soon for The End,
Benjamin
I have been comiling Python 3.8 from source and have had a really difficult time
with getting _ctypes to compile. I see that libffi is no longer distributed with the
Python source code, in preference for what is on the system. I searched for a
PEP that describes the rationale behind this, but my Google fu must be weak.
I have also seen requests that a patch be committed that makes configuring the
use of libffi easier, but as far as I can tell, these have not been committed. It is
something I would like to see as I am in a situation where I cannot depend on the
system libffi - we support older Linux distributions that don't have libffi - an so I
am making a static libffi to be linked in.
Any guidance on this issue would be helpful.
Thanks,
TOm
Hi All,
I'm trying to upgrade the pydevd debugger to the latest version of CPython
(3.8), however I'm having some issues being able to access
`PyInterpreterState.eval_frame` when compiling, so, I'd like to ask if
someone can point me in the right direction.
What I'm trying to do is compile something like:
#include "pystate.h"
...
PyThreadState *ts = PyThreadState_Get();
PyInterpreterState *interp = ts->interp;
interp->eval_frame = my_frame_eval_func;
and the error I'm having is:
_pydevd_frame_eval/pydevd_frame_evaluator.c(7534): error C2037: left of
'eval_frame' specifies undefined struct/union '_is'
So, it seems that now "pystate.h" only has a forward reference to "_is" and
a typedef from " PyInterpreterState" to "_is" and "_is" is defined in
"include/internal/pycore_pystate.h", which doesn't seem like I should be
including (in fact, if I try to include it I get an error saying that I
would need to define Py_BUILD_CORE)... so, can someone point me to the
proper way to set the frame evaluation function on CPython 3.8?
Thanks,
Fabio
Hi, all.
I want Homebrew uses `--enable-optimizations` and `--with-lto` option
for building Python. But maintainer said:
> Given this is not a default option, probably not, unless it is done in upstream (“official”) binaries.
https://github.com/Homebrew/homebrew-core/pull/45337
Are these options used for official macOS binaries?
Is there official information about the build step of official binaries?
Regards,
--
Inada Naoki <songofacandy(a)gmail.com>
I cannot get Python 3.8.0 installed on Linux ( RHEL 8 / CentOS 8).
It's not available in any package repo. When I try to build from source, there are dependencies missing (3), that I cannot find anywhere.
More info here: (I did not want to write this up twice)
https://www.reddit.com/r/Python/comments/digewe/python_38_not_possible_to_i…
The latest version of Python 3 available to me on Linux was released over three years ago ( Python 3.6.0 ), I don't understand why.
On behalf of the Python development community and the Python 3.8 release team, I’m pleased to announce the availability of Python 3.8.0.
Python 3.8.0 is the newest feature release of the Python language, and it contains many new features and optimizations. You can find Python 3.8.0 here:
https://www.python.org/downloads/release/python-380/ <https://www.python.org/downloads/release/python-380/>
Most third-party distributors of Python should be making 3.8.0 packages available soon.
See the “What’s New in Python 3.8 <https://docs.python.org/3.8/whatsnew/3.8.html>” document for more information about features included in the 3.8 series. Detailed information about all changes made in 3.8.0 can be found in its change log.
Maintenance releases for the 3.8 series will follow at regular bi-monthly intervals starting in December of 2019.
We hope you enjoy Python 3.8!
Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation.
https://www.python.org/psf/ <https://www.python.org/psf/>
- Ł
Python 3.7.5 is now available, the next maintenance release of Python 3.7. You can find the release files, a link to the changelog, and more information here:
https://www.python.org/downloads/release/python-375/
Note that the next feature release of Python 3, Python 3.8.0, is also now available. Python 3.8 contains many new features and optimizations. You should consider upgrading to it. We plan to continue regular bugfix releases of Python 3.7.x through mid-year 2020 and provide security fixes for it until mid-year 2023. More details are available in PEP 537, the Python 3.7 Release Schedule (https://www.python.org/dev/peps/pep-0537/).
Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation.
--
Ned Deily
nad(a)python.org -- []