21.07.17 13:02, Victor Stinner пише:
Recently, two security vulnerabilities were reported in the urllib module:
https://bugs.python.org/issue30500
http://python-security.readthedocs.io/vuln/bpo-30500_urllib_connects_to_a_wrong_host.html#bpo-30500-urllib-connects-to-a-wrong-host
=> already fixed
On Fri, Jul 21, 2017 at 9:52 AM, Brett Cannon wrote:
> On Thu, 20 Jul 2017 at 22:11 Chris Jerdonek
> wrote:
>> On Thu, Jul 20, 2017 at 8:49 PM, Nick Coghlan wrote:
>> > ...
>> > * Lazy loading can have a significant impact on startup time, as it
>> > means you don't have to pay for the cost of f
On 07/21/2017 03:28 PM, Barry Warsaw wrote:
The TPI (Terrible Python Idea) I had at Pycon was some kind of (local)
memcached of imported Python modules, which would theoretically allow avoiding
loading the modules from the file system on start up.
There would be all kinds of problems with this
I would guess that Windows users don't tend to run lots of command line
tools where startup time dominates, as *nix users do.
On Fri, Jul 21, 2017 at 3:21 PM, Barry Warsaw wrote:
> On Jul 21, 2017, at 01:25 PM, Nikolaus Rath wrote:
>
> >That is what Emacs does, and it causes them a lot of troubl
Emacs has been unexec'ing for as long as I can remember (which is longer
than
I can remember Python :). I know that it's been problematic and there have
been many efforts over the years to replace it, but I think it's been a
fairly
successful technique in practice, at least on platforms that suppo
On Jul 20, 2017, at 03:16 PM, Eric Snow wrote:
>Relatedly, at PyCon this year Barry and I were talking about the idea of
>bootstrapping the interpreter from a memory snapshot on disk, rather than
>from scatch (thus drastically reducing the number of IO events).
The TPI (Terrible Python Idea) I ha
On Jul 21, 2017, at 01:25 PM, Nikolaus Rath wrote:
>That is what Emacs does, and it causes them a lot of trouble. They're
>trying to move away from it at the moment, but the direction is not yet
>clear. The keyword is "unexec", and it wrecks havoc with malloc.
Emacs has been unexec'ing for as lon
Thanks to Kushal Das we now have one of the most requested features since
the transition: a link in PRs back to bugs.python.org (in a more
discoverable way since we have had them since Bedevere launched :) . When a
pull request comes in with an issue number in the title (or one gets
added), a link
Nick Coghlan schrieb am 21.07.2017 um 08:23:
> I'll also note that in these cases where the import overhead is
> proportionally significant for always-imported modules, we may want to look
> at the benefits of freezing them (if they otherwise remain as pure Python
> modules), or compiling them as b
> On Jul 21, 2017, at 3:45 AM, Victor Stinner wrote:
>
> Ok, I more concrete problem. To fix the "urllib FTP" bug, we have to
> find a balance between security (reject any URL looking like an
> attempt to counter the security protections) and backward
> compatibility (accept filenames containing
On Thu, 20 Jul 2017 at 22:11 Chris Jerdonek
wrote:
> On Thu, Jul 20, 2017 at 8:49 PM, Nick Coghlan wrote:
> > ...
> > * Lazy loading can have a significant impact on startup time, as it
> > means you don't have to pay for the cost of finding and loading
> > modules that you don't actually end up
ACTIVITY SUMMARY (2017-07-14 - 2017-07-21)
Python tracker at http://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:
open6058 (+16)
closed 36679 (+38)
total 42737 (+54)
Open issues wit
On Fri, Jul 21, 2017, at 08:43, Giampaolo Rodola' wrote:
> It took me a while to understand the security implications of this
> FTP-related bug, but I believe I got the gist of it here (I can
> elaborate further if it's not clear):
> https://github.com/python/cpython/pull/1214#issuecomment-29839316
On Fri, Jul 21, 2017 at 12:45 PM, Victor Stinner
wrote:
> 2017-07-21 12:02 GMT+02:00 Victor Stinner :
> > https://bugs.python.org/issue29606
> > http://python-security.readthedocs.io/vuln/urllib_
> ftp_protocol_stream_injection.html#urllib-ftp-protocol-stream-injection
> > => not fixed yet
>
> Ok
On Jul 21 2017, David Mertz wrote:
> How implausible is it to write out the actual memory image of a loaded
> Python process?
That is what Emacs does, and it causes them a lot of trouble. They're
trying to move away from it at the moment, but the direction is not yet
clear. The keyword is "unexec
2017-07-21 12:02 GMT+02:00 Victor Stinner :
> https://bugs.python.org/issue29606
> http://python-security.readthedocs.io/vuln/urllib_ftp_protocol_stream_injection.html#urllib-ftp-protocol-stream-injection
> => not fixed yet
Ok, I more concrete problem. To fix the "urllib FTP" bug, we have to
find
Hi,
Recently, two security vulnerabilities were reported in the urllib module:
https://bugs.python.org/issue30500
http://python-security.readthedocs.io/vuln/bpo-30500_urllib_connects_to_a_wrong_host.html#bpo-30500-urllib-connects-to-a-wrong-host
=> already fixed in Python 3.6.2
https://bugs.pyth
On Fri, Jul 21, 2017 at 4:12 PM, David Mertz wrote:
> How implausible is it to write out the actual memory image of a loaded
> Python process? I.e. on a specific machine, OS, Python version, etc? This
> can only be overhead initially, of course, but on subsequent runs it's just
> one memory map, w
On Fri, 21 Jul 2017 00:12:20 -0700
David Mertz wrote:
> How implausible is it to write out the actual memory image of a loaded
> Python process? I.e. on a specific machine, OS, Python version, etc? This
> can only be overhead initially, of course, but on subsequent runs it's just
> one memory map,
How implausible is it to write out the actual memory image of a loaded
Python process? I.e. on a specific machine, OS, Python version, etc? This
can only be overhead initially, of course, but on subsequent runs it's just
one memory map, which the cheapest possible operation.
E.g.
$ python3.7 --wr
20 matches
Mail list logo
