Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 2

2014-02-25 Thread Nick Coghlan 
On 25 February 2014 17:43, Stuart Bishop  wrote:
> On 23 February 2014 08:56, Ethan Furman  wrote:
>
>> ``%a`` will call :func:``ascii()`` on the interpolated value's
>> :func:``repr()``.
>> This is intended as a debugging aid, rather than something that should be
>> used
>> in production.  Non-ascii values will be encoded to either ``\xnn`` or
>> ``\u``
>> representation.
>
> So we use %a for exactly the same purposes that we used to use %r.
>
>> Unsupported codes
>> -
>>
>> ``%r`` (which calls ``__repr__`` and returns a :class:`str`) is not
>> supported.
>
> But you propose changing the code.
>
> I think there would have been a lot less discussion if you just
> defined %r to do what you propose for %a, as everything would work as
> people expected.

No, it wouldn't.

[Python 3]
>>> "%r" % "\xe9"
"'é'"
>>> "%a" % "\xe9"
"'\\xe9'"

%r is being disallowed in PEP 461 because it doesn't guarantee ASCII
compatibility in Python 3 the way it did in Python 2. That's not up
for discussion, as having %r behave like %a in binary interpolation
but not in text interpolation would be far too confusing.

However, %a *already* guarantees ASCII compatible output for text
interpolation (by escaping everything below 0x20 or above 0x7F, the
same way %r did in Python 2), so some of us think %a *should* be
allowed for consistency with text interpolation, both because there's
no compelling reason to disallow it and because it's the obvious way
to interpolate representations of arbitrary objects into binary
formats that contain ASCII compatible segments.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

2014-02-25 Thread Victor Stinner 
Hi,

2014-02-25 8:53 GMT+01:00 Nick Coghlan :
> I've checked these, and noted the relevant hg.python.org links on the
> tracker issue at http://bugs.python.org/issue20246

Would it be possible to have a table with all known Python security
vulnerabilities and the Python versions which are fixed? Bonus point
if we provide a link to the changeset fixing it for each branch. Maybe
put this table on http://www.python.org/security/ ?

Last issues:
- hash DoS
- sock.recvfrom_into()
- DoS with very long lines in HTTP, FTP, etc. protocols
- etc.

Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

2014-02-25 Thread Victor Stinner 
Hi,

2014-02-25 8:39 GMT+01:00 Christian Heimes :
> this looks pretty serious -- and it caught me off guard, too. :(
> https://www.trustedsec.com/february-2014/python-remote-code-execution-socket-recvfrom_into/

I don't think that the issue is critical.

Extract of the article "Diving into SocketServer() luckily
socket.recvfrom_into() isn’t even used". In fact, I didn't find any
usage of the method except of unit test. Do you know which
applications are vulnerable?

Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Running 2.7 tests on OS X

2014-02-25 Thread Rik 
I want to try to submit a patch for 2.7, but I don't know how to run the
tests for the 2.7 branch. `./configure` doesn't seem to create a
`python.exe` file on the 2.7 branch on OS X Mavericks, and I do need this
file according to this guide:
http://docs.python.org/devguide/

Anybody know how I should do this?
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

2014-02-25 Thread Antoine Pitrou 
On Tue, 25 Feb 2014 08:39:40 +0100
Christian Heimes  wrote:
> 
> this looks pretty serious -- and it caught me off guard, too. :(
> 
> https://www.trustedsec.com/february-2014/python-remote-code-execution-socket-recvfrom_into/
> 
> Next time please inform the Python Security Response Team about any
> and all issues that are related to buffer overflows or similar bugs.
> In fact please drop a note about anything that even remotely look like
> an exploitable issue. Even public bug reports should be forwarded to PSRT.

If that's the case, then can't we have an email hook on bugs.python.org
every time an issue is classified as security? (either when created or
later when modified)

"Bug reports should be forwarded to PSRT" just adds a tedious and
unnecessary manual step.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Running 2.7 tests on OS X

2014-02-25 Thread Antoine Pitrou 

Hi Rik,

On Tue, 25 Feb 2014 12:25:27 +0100
Rik  wrote:
> I want to try to submit a patch for 2.7, but I don't know how to run the
> tests for the 2.7 branch. `./configure` doesn't seem to create a
> `python.exe` file on the 2.7 branch on OS X Mavericks, and I do need this
> file according to this guide:
> http://docs.python.org/devguide/

To quote the devguide, the complete command is:

  ./configure --with-pydebug && make -j2

which you can decompose into:

  ./configure --with-pydebug
  make -j2

(note: "--with-pydebug" is kind of optional, but enables many debugging
guards and assertions that help catch low-level issues; it also makes
the resulting executable slower, somewhere between 2x and 10x slower)

python.exe will be created by the "make" step, not the "./configure"
step.

(as a side note, "-j2" means two processes will be used concurrently
for compiling; you can adjust according to the number of CPU cores in
your system)

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

2014-02-25 Thread Maciej Fijalkowski 
On Tue, Feb 25, 2014 at 11:13 AM, Victor Stinner
 wrote:
> Hi,
>
> 2014-02-25 8:53 GMT+01:00 Nick Coghlan :
>> I've checked these, and noted the relevant hg.python.org links on the
>> tracker issue at http://bugs.python.org/issue20246
>
> Would it be possible to have a table with all known Python security
> vulnerabilities and the Python versions which are fixed? Bonus point
> if we provide a link to the changeset fixing it for each branch. Maybe
> put this table on http://www.python.org/security/ ?
>
> Last issues:
> - hash DoS

is this fixed?
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

2014-02-25 Thread Donald Stufft 

On Feb 25, 2014, at 7:59 AM, Maciej Fijalkowski  wrote:

> On Tue, Feb 25, 2014 at 11:13 AM, Victor Stinner
>  wrote:
>> Hi,
>> 
>> 2014-02-25 8:53 GMT+01:00 Nick Coghlan :
>>> I've checked these, and noted the relevant hg.python.org links on the
>>> tracker issue at http://bugs.python.org/issue20246
>> 
>> Would it be possible to have a table with all known Python security
>> vulnerabilities and the Python versions which are fixed? Bonus point
>> if we provide a link to the changeset fixing it for each branch. Maybe
>> put this table on http://www.python.org/security/ ?
>> 
>> Last issues:
>> - hash DoS
> 
> is this fixed?
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/donald%40stufft.io

It is in 3.4.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

2014-02-25 Thread Maciej Fijalkowski 
On Tue, Feb 25, 2014 at 3:01 PM, Donald Stufft  wrote:
>
> On Feb 25, 2014, at 7:59 AM, Maciej Fijalkowski  wrote:
>
>> On Tue, Feb 25, 2014 at 11:13 AM, Victor Stinner
>>  wrote:
>>> Hi,
>>>
>>> 2014-02-25 8:53 GMT+01:00 Nick Coghlan :
 I've checked these, and noted the relevant hg.python.org links on the
 tracker issue at http://bugs.python.org/issue20246
>>>
>>> Would it be possible to have a table with all known Python security
>>> vulnerabilities and the Python versions which are fixed? Bonus point
>>> if we provide a link to the changeset fixing it for each branch. Maybe
>>> put this table on http://www.python.org/security/ ?
>>>
>>> Last issues:
>>> - hash DoS
>>
>> is this fixed?
>> ___
>> Python-Dev mailing list
>> [email protected]
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: 
>> https://mail.python.org/mailman/options/python-dev/donald%40stufft.io
>
> It is in 3.4.

Oh, I thought security fixes go to all python releases.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

2014-02-25 Thread Chris Angelico 
On Tue, Feb 25, 2014 at 11:59 PM, Maciej Fijalkowski  wrote:
>> Last issues:
>> - hash DoS
>
> is this fixed?

Yes, hash randomization was added as an option in 2.7.3 or 2.7.4 or
thereabouts, and is on by default in 3.3+. You do have to set an
environment variable for 2.7 (and I think 2.6 got that too (??)), as
it can break code.

ChrisA
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

2014-02-25 Thread Maciej Fijalkowski 
On Tue, Feb 25, 2014 at 3:06 PM, Chris Angelico  wrote:
> On Tue, Feb 25, 2014 at 11:59 PM, Maciej Fijalkowski  wrote:
>>> Last issues:
>>> - hash DoS
>>
>> is this fixed?
>
> Yes, hash randomization was added as an option in 2.7.3 or 2.7.4 or
> thereabouts, and is on by default in 3.3+. You do have to set an
> environment variable for 2.7 (and I think 2.6 got that too (??)), as
> it can break code.

No, the hash randomization is broken, it does not provide enough
randomness (without changing the hash function which only happened in
3.4+)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

2014-02-25 Thread Donald Stufft 

On Feb 25, 2014, at 8:06 AM, Chris Angelico  wrote:

> On Tue, Feb 25, 2014 at 11:59 PM, Maciej Fijalkowski  wrote:
>>> Last issues:
>>> - hash DoS
>> 
>> is this fixed?
> 
> Yes, hash randomization was added as an option in 2.7.3 or 2.7.4 or
> thereabouts, and is on by default in 3.3+. You do have to set an
> environment variable for 2.7 (and I think 2.6 got that too (??)), as
> it can break code.
> 
> ChrisA
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/donald%40stufft.io

Hash randomization is broken and doesn’t fix anything. It’s only SipHash in 
3.4+ that actually fixes it.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

2014-02-25 Thread Donald Stufft 

On Feb 25, 2014, at 8:07 AM, Maciej Fijalkowski  wrote:

> On Tue, Feb 25, 2014 at 3:06 PM, Chris Angelico  wrote:
>> On Tue, Feb 25, 2014 at 11:59 PM, Maciej Fijalkowski  
>> wrote:
 Last issues:
 - hash DoS
>>> 
>>> is this fixed?
>> 
>> Yes, hash randomization was added as an option in 2.7.3 or 2.7.4 or
>> thereabouts, and is on by default in 3.3+. You do have to set an
>> environment variable for 2.7 (and I think 2.6 got that too (??)), as
>> it can break code.
> 
> No, the hash randomization is broken, it does not provide enough
> randomness (without changing the hash function which only happened in
> 3.4+)
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/donald%40stufft.io

More information available here: http://legacy.python.org/dev/peps/pep-0456/

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

2014-02-25 Thread Chris Angelico 
On Wed, Feb 26, 2014 at 12:07 AM, Maciej Fijalkowski  wrote:
> No, the hash randomization is broken, it does not provide enough
> randomness (without changing the hash function which only happened in
> 3.4+)

Hmm, I don't remember reading about that - got a link to more info? Or
was that report kept quieter?

ChrisA
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

2014-02-25 Thread Antoine Pitrou 
On Tue, 25 Feb 2014 08:08:09 -0500
Donald Stufft  wrote:
> 
> Hash randomization is broken and doesn’t fix anything.

Not sure what you mean with "doesn't fix anything". Hash collisions were
easy to exploit pre-hash randomization, they doesn't seem as easy to
exploit with it.

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

2014-02-25 Thread Donald Stufft 

On Feb 25, 2014, at 8:17 AM, Antoine Pitrou  wrote:

> On Tue, 25 Feb 2014 08:08:09 -0500
> Donald Stufft  wrote:
>> 
>> Hash randomization is broken and doesn’t fix anything.
> 
> Not sure what you mean with "doesn't fix anything". Hash collisions were
> easy to exploit pre-hash randomization, they doesn't seem as easy to
> exploit with it.

Instead of pre-generating one set of values that can be be used to DoS things
you have to pre-generate 256 sets of values and try them until you get the
right one. It’s like putting on armor made of paper and saying it’s harder to
stab you now.


-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

2014-02-25 Thread Chris Angelico 
On Wed, Feb 26, 2014 at 12:21 AM, Donald Stufft  wrote:
> Instead of pre-generating one set of values that can be be used to DoS things
> you have to pre-generate 256 sets of values and try them until you get the
> right one. It’s like putting on armor made of paper and saying it’s harder to
> stab you now.

Paper armor? You mean the stuff they tested here?
http://www.imdb.com/title/tt1980597/

Cutting the problem by a factor of 256 isn't nothing, but yes, it's
still a problem. But why is it only 256? I tried Googling for 'python
hash randomization problem' and other keywords but all I can find is
the original. I'm sure someone's done the analysis somewhere as to why
it's still a problem in 2.7, and why (presumably) it can't be fixed in
2.7 - after all, that's the version that's not going anywhere any time
soon.

ChrisA
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

2014-02-25 Thread Nick Coghlan 
On 25 Feb 2014 23:09, "Maciej Fijalkowski"  wrote:
>
> On Tue, Feb 25, 2014 at 3:06 PM, Chris Angelico  wrote:
> > On Tue, Feb 25, 2014 at 11:59 PM, Maciej Fijalkowski 
wrote:
> >>> Last issues:
> >>> - hash DoS
> >>
> >> is this fixed?
> >
> > Yes, hash randomization was added as an option in 2.7.3 or 2.7.4 or
> > thereabouts, and is on by default in 3.3+. You do have to set an
> > environment variable for 2.7 (and I think 2.6 got that too (??)), as
> > it can break code.
>
> No, the hash randomization is broken, it does not provide enough
> randomness (without changing the hash function which only happened in
> 3.4+)

The blind hash collision DOS attack was fixed in all applicable branches.
There was then a second vulnerability in the randomisation that still
allowed a relatively straightforward invocation specific secret recovery
attack against earlier versions that is only fixed with the SipHash change
in 3.4.

You and the other PyPy devs apparently feel that the existence of the
second vulnerability means it isn't worth your while to fix the original
one either. While this mirrors the core team's original position that it
was up to applications and frameworks to deal with the problem, conflating
the two vulnerabilities like that is still just your perspective, not ours
(in addition to all the same measures that limited the impact of the
original issue, there are many measures that specifically mitigate the
latter one, with process recycling being one of the simplest).

Regards,
Nick.

> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

2014-02-25 Thread Nick Coghlan 
On 25 Feb 2014 23:23, "Donald Stufft"  wrote:
>
>
> On Feb 25, 2014, at 8:17 AM, Antoine Pitrou  wrote:
>
> > On Tue, 25 Feb 2014 08:08:09 -0500
> > Donald Stufft  wrote:
> >>
> >> Hash randomization is broken and doesn't fix anything.
> >
> > Not sure what you mean with "doesn't fix anything". Hash collisions were
> > easy to exploit pre-hash randomization, they doesn't seem as easy to
> > exploit with it.
>
> Instead of pre-generating one set of values that can be be used to DoS
things
> you have to pre-generate 256 sets of values and try them until you get the
> right one. It's like putting on armor made of paper and saying it's
harder to
> stab you now.

This isn't quite correct - the hash randomisation can at least be combined
with aggressive process recycling to present a moving target that is harder
to attack. Without any hash randomisation at all, process recycling can't
help in the slightest.

SIPHash is still the real fix, although the reality remains that an
attacker that really wants to bring a site down is likely to achieve their
aims, regardless of whether or not there's a specific DoS vulnerability in
the application server.

Cheers,
Nick.

>
>
> -
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
DCFA
>
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

2014-02-25 Thread Donald Stufft 

On Feb 25, 2014, at 8:33 AM, Nick Coghlan  wrote:

> 
> On 25 Feb 2014 23:09, "Maciej Fijalkowski"  wrote:
> >
> > On Tue, Feb 25, 2014 at 3:06 PM, Chris Angelico  wrote:
> > > On Tue, Feb 25, 2014 at 11:59 PM, Maciej Fijalkowski  
> > > wrote:
> > >>> Last issues:
> > >>> - hash DoS
> > >>
> > >> is this fixed?
> > >
> > > Yes, hash randomization was added as an option in 2.7.3 or 2.7.4 or
> > > thereabouts, and is on by default in 3.3+. You do have to set an
> > > environment variable for 2.7 (and I think 2.6 got that too (??)), as
> > > it can break code.
> >
> > No, the hash randomization is broken, it does not provide enough
> > randomness (without changing the hash function which only happened in
> > 3.4+)
> 
> The blind hash collision DOS attack was fixed in all applicable branches. 
> There was then a second vulnerability in the randomisation that still allowed 
> a relatively straightforward invocation specific secret recovery attack 
> against earlier versions that is only fixed with the SipHash change in 3.4.
> 
> You and the other PyPy devs apparently feel that the existence of the second 
> vulnerability means it isn't worth your while to fix the original one either. 
> While this mirrors the core team's original position that it was up to 
> applications and frameworks to deal with the problem, conflating the two 
> vulnerabilities like that is still just your perspective, not ours (in 
> addition to all the same measures that limited the impact of the original 
> issue, there are many measures that specifically mitigate the latter one, 
> with process recycling being one of the simplest).
> 
> 

I don’t have a PoC but my gut is that process cycling is not nearly enough to 
mitigate the second class of attack. You’d only need 256 * N requests to 
recover the secret where N is the number of samples you need to factor out 
network noise. However if you decide you don’t care about recovering the secret 
and you just care about DoSing a server you can just hit it with colliding 
values for all 256 possible values. 255 of them will complete quickly and one 
of them will take a long time, repeat this a few times and you’ll have the 
server DoS’d in a short amount of time.

I’m not sure what you mean by I don’t think it’s worth my while. I don’t run 
any project where I would fix this in. I do agree with the sentiment of the 
PyPy developers that implementing this fix is more or less pointless for PyPy 
because it’s so trivially worked around. Saying that the original fix fixed the 
original issue is taking a very narrow view of what the original issue even is. 
It’s not *wrong* to take that view, but I don’t think it’s very useful outside 
the context of not wanting to admit that the original fix wasn’t good enough. I 
*do* believe that calling it fixed is misleading to people who will assume it 
means they no longer have to worry about a trivial DoS via hash collisions when 
they still do need to, just slightly different than before.

In the end, it’s good that it was fixed in 3.4, I wish it had been back ported 
and applied to 2.7 and the relevant 3.x branches. 

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

2014-02-25 Thread Benjamin Peterson 


On Mon, Feb 24, 2014, at 11:39 PM, Christian Heimes wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hi,
> 
> this looks pretty serious -- and it caught me off guard, too. :(
> 
> https://www.trustedsec.com/february-2014/python-remote-code-execution-socket-recvfrom_into/
> 
> Next time please inform the Python Security Response Team about any
> and all issues that are related to buffer overflows or similar bugs.
> In fact please drop a note about anything that even remotely look like
> an exploitable issue. Even public bug reports should be forwarded to
> PSRT.

I'm not sure why you think it wasn't sent to security@
https://mail.python.org/mailman/private/psrt/2014-January/001297.html
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

2014-02-25 Thread Barry Warsaw 
On Feb 25, 2014, at 03:03 PM, Maciej Fijalkowski wrote:

>Oh, I thought security fixes go to all python releases.

Well, not the EOL'd ones of course.

Where's the analysis on backporting SIPHash to older Python versions?  Would
such a backport break backward compatibility?  What other impacts would
backporting have?  Would it break pickles, marshals, or other serialization
protocols?  Are there performance penalties?

While security should be a top priority, it isn't the only consideration in
such cases.  A *lot* of discussion went into how to effect the hash
randomization in Python 2.7, because of questions like these.  The same
analysis would have to be done for backporting this change to active older
Python versions.

-Barry
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] GSOC 2014 - IDLE Project

2014-02-25 Thread Saimadhav Heblikar 
Hi,

Saimadhav Heblikar here.I would like to express my interest in working on
IDLE improvement project as a part of Google Summer of Code 2014 for Python
Core projects under the Python Software Foundation.I am currently a
freshman Computer Science undergraduate student at  PESIT , Bangalore.

Similar to most Python programmers, i started my python journey on IDLE,and
once i came to know that IDLE was one of the prospective projects,i knew
this was great opportunity to give back to IDLE and the community as whole.

I have created an account on the bug tracker and submitted the PSF
contributor agreement.My username on the tracker is sahutd(saimadhav
heblikar) http://bugs.python.org/user18939. I use the same nickname on the
IRC channel.

To enhance my understanding of the codebase, i have submitted few patches,

some which have been committed

http://bugs.python.org/issue20634

http://bugs.python.org/issue20677



and some which are under review

http://bugs.python.org/issue20403 (IDLE related)

http://bugs.python.org/issue20640 (Adds IDLE unittest)

http://bugs.python.org/issue20451

http://bugs.python.org/issue20466


--

Coming to the point,as the theme of the project which i am interested in
and the theme for the IDLE GSOC `13 projects by Jayakrishnan and Phil
Webster are the same,  i have a few questions to ask the python
mentors/devs.

1.What will be the scope of the idle gsoc 2014?By scope,i want to
 know,whether i will be expected to continue the work done in 2013, or
start afresh.

2. If i were to start afresh,i have explored the following two
possibilities,

  a)Code recommender feature for IDLE - Similar to the feature in
Eclipse but made for Python(would work from the shell or in IDLE).As an
example of how it would work,we could think of it as a web api, which would
return information about most used functions in a module.It would help
beginners and experts alike to make better use of their dev time.It would
also go a long way in making python even more social.If any questions on
this proposal,i am looking forward to answer it. (I would like to know the
community's opinion on this,GSOC or otherwise)If this generates a positive
response, i will immediately come up with a plan to develop it.

  b)Working on a project to integrate a passive checker like pyflakes
with the ability to highlight and possibly correct errors on-the-fly and on
demand.Automatically integrate the above feature to work on
folders/directories, selection of files ,projects etc.


2.If i were to continue the work done in gsoc 2013,would it involve

   a)building on features for PEP8(or other style checker,though after
reading http://bugs.python.org/issue18704  i am inclined to believe it is
not a must have atm. )

  b)extending the unittest framework. Would i be completing(or to an
extent) , the missing tests in idlelib/idle_test?What would be the
priorities?

  c)features which don't seem to have been completed from gsoc 2013 like
line numbering,improving cursor behavior and making right click more
intuitive.(Anything gsoc 13 related which i have missed out?)

--

I believe from the abstracts of  GSOC 13 projects which were selected,that
, i am expected to increase test coverage for idle AND  add a new feature .
Is my understanding correct?

I would like to know whom i can contact(mentors) if have questions about
the proposal writing and/or other technical questions relating to GSOC 14.

I would also like to come up with overall outline based on your feedback so
that it can critiqued before i submit the application on the google page.

Awaiting your replies.

Saimadhav Heblikar(sahutd)

Bug Tracker username: sahutd (http://bugs.python.org/user18939)

Email : [email protected]

Github : https://github.com/sahutd
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Fwd: GSOC 2014 - IDLE Project

2014-02-25 Thread Saimadhav Heblikar 
Hi,

Saimadhav Heblikar here.I would like to express my interest in working on
IDLE improvement project as a part of Google Summer of Code 2014 for Python
Core projects under the Python Software Foundation.I am currently a
freshman Computer Science undergraduate student at  PESIT , Bangalore.

Similar to most Python programmers, i started my python journey on IDLE,and
once i came to know that IDLE was one of the prospective projects,i knew
this was great opportunity to give back to IDLE and the community as whole.

I have created an account on the bug tracker and submitted the PSF
contributor agreement.My username on the tracker is sahutd(saimadhav
heblikar) http://bugs.python.org/user18939. I use the same nickname on the
IRC channel.

To enhance my understanding of the codebase, i have submitted few patches,

some which have been committed

http://bugs.python.org/issue20634

http://bugs.python.org/issue20677



and some which are under review

http://bugs.python.org/issue20403 (IDLE related)

http://bugs.python.org/issue20640 (Adds IDLE unittest)

http://bugs.python.org/issue20451

http://bugs.python.org/issue20466


--

Coming to the point,as the theme of the project which i am interested in
and the theme for the IDLE GSOC `13 projects by Jayakrishnan and Phil
Webster are the same,  i have a few questions to ask the python
mentors/devs.

1.What will be the scope of the idle gsoc 2014?By scope,i want to
 know,whether i will be expected to continue the work done in 2013, or
start afresh.

2. If i were to start afresh,i have explored the following two
possibilities,

  a)Code recommender feature for IDLE - Similar to the feature in
Eclipse but made for Python(would work from the shell or in IDLE).As an
example of how it would work,we could think of it as a web api, which would
return information about most used functions in a module.It would help
beginners and experts alike to make better use of their dev time.It would
also go a long way in making python even more social.If any questions on
this proposal,i am looking forward to answer it. (I would like to know the
community's opinion on this,GSOC or otherwise)If this generates a positive
response, i will immediately come up with a plan to develop it.

  b)Working on a project to integrate a passive checker like pyflakes
with the ability to highlight and possibly correct errors on-the-fly and on
demand.Automatically integrate the above feature to work on
folders/directories, selection of files ,projects etc.


2.If i were to continue the work done in gsoc 2013,would it involve

   a)building on features for PEP8(or other style checker,though after
reading http://bugs.python.org/issue18704  i am inclined to believe it is
not a must have atm. )

  b)extending the unittest framework. Would i be completing(or to an
extent) , the missing tests in idlelib/idle_test?What would be the
priorities?

  c)features which don't seem to have been completed from gsoc 2013 like
line numbering,improving cursor behavior and making right click more
intuitive.(Anything gsoc 13 related which i have missed out?)

--

I believe from the abstracts of  GSOC 13 projects which were selected,that
, i am expected to increase test coverage for idle AND  add a new feature .
Is my understanding correct?

I would like to know whom i can contact(mentors) if have questions about
the proposal writing and/or other technical questions relating to GSOC 14.

I would also like to come up with overall outline based on your feedback so
that it can critiqued before i submit the application on the google page.

Awaiting your replies.

Saimadhav Heblikar(sahutd)

Bug Tracker username: sahutd (http://bugs.python.org/user18939)

Email : [email protected]

Github : https://github.com/sahutd
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: whatsnew: textwrap.shorten.

2014-02-25 Thread Serhiy Storchaka 

23.02.14 18:42, r.david.murray написав(ла):

http://hg.python.org/cpython/rev/4d615ab37804
changeset:   89337:4d615ab37804
user:R David Murray 
date:Sun Feb 23 10:22:07 2014 -0500
summary:
   whatsnew: textwrap.shorten.

Also add the missing TextWrapper.shorten method doc.


There is no the TextWrapper.shorten method. The textwrap.shorten() 
function is implemented via new max_lines parameter.



___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

2014-02-25 Thread Christian Heimes 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 25.02.2014 15:41, Benjamin Peterson wrote:
> I'm not sure why you think it wasn't sent to security@ 
> https://mail.python.org/mailman/private/psrt/2014-January/001297.html

Because
> 
I can't find the mail in my inbox. Perhaps it fell victim to
python.org's spam filter like several other mails to my python.org
address? I really don't know. :(

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJTDN8iAAoJEMeIxMHUVQ1FNAIQANHAiRBvDfLZ15+GQ/QcMCC/
8Vfcvc+DbQ2f36qFiuGsTwMnEAXX3RbKoqdi1oKbHm8yEFhIIYtKge7UATYKVZ66
YtypiWMVFUXQJf7/JnSzMbEbK8AZ8XCN0aKio18DXH4lG5DGSC0z69uj6rgxVyVm
lt84oOSFxRojUVHYUSjc1eOUDdyJ8IHc0uC2v6O8x75c2X09ftkjMik7XcU1H0iL
m303bI2lWVJLNAjFBjYVo4erwTqP4lD+LSr6lpmEn0eNfQc5ZawCL3gMdzmU87gY
0pQkRaJk2axESzDEpVFnvbX5ugzq2y+qeTKuCO8pOzE7nkknQp2RKDPNwhSjj4aX
+JDjVaNpd3/in6YRPGzR4kjNKbMwC56Rgz4bvha9kg4Ldh+QAGbnUJhK8GmM1IVD
7TnEOdVwkaq7n/i/HVuIQZE6G0kKeunz0QJ5vtR4xUMNp24wvid1IJM5GdSR73hQ
tTWJjXP4F85cu0gcy81nTTOLd+7ryPoyF9xOVXUvlwwYWDv4w0hLXXOJ/y/pOIMl
B7sYyEaAcgFTjUhOpHamhLgqL1HuUHDsZdDy5ISOciX1nBxodjelcEmlpeGN+bH6
YUFgXvFu8GO+OsTsZ3UHJzrdzRiUcwk8ECTNgyEYAGg/ztpqsyXU8wNBI4KDSnB7
9ivcsc5aTUBrSiJExkRs
=x7QU
-END PGP SIGNATURE-
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

2014-02-25 Thread Maciej Fijalkowski 
On Tue, Feb 25, 2014 at 5:22 PM, Barry Warsaw  wrote:
> On Feb 25, 2014, at 03:03 PM, Maciej Fijalkowski wrote:
>
>>Oh, I thought security fixes go to all python releases.
>
> Well, not the EOL'd ones of course.

yes of course sorry.

>
> Where's the analysis on backporting SIPHash to older Python versions?  Would
> such a backport break backward compatibility?  What other impacts would
> backporting have?  Would it break pickles, marshals, or other serialization
> protocols?  Are there performance penalties?
>
> While security should be a top priority, it isn't the only consideration in
> such cases.  A *lot* of discussion went into how to effect the hash
> randomization in Python 2.7, because of questions like these.  The same
> analysis would have to be done for backporting this change to active older
> Python versions.

My impression is that a lot of discussion went into hash
randomization, because it was a high profile issue. It got "fixed",
then later someone discovered that the fix is completely broken and
was left at that without much discussion because it's no longer "high
visibility". I would really *like* to perceive this process as a lot
of discussion going into because of ramification of changes.

Cheers,
fijal
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

2014-02-25 Thread Antoine Pitrou 
On Tue, 25 Feb 2014 20:38:46 +0200
Maciej Fijalkowski  wrote:
> 
> My impression is that a lot of discussion went into hash
> randomization, because it was a high profile issue. It got "fixed",
> then later someone discovered that the fix is completely broken and
> was left at that without much discussion because it's no longer "high
> visibility". I would really *like* to perceive this process as a lot
> of discussion going into because of ramification of changes.

Most of the discussion, AFAIR, was about the potential backwards
compatibility issues (which led to the decision of adding hash
randomization in 2.7, but disabled by default).

But you're right that for some reason it suddenly became a "high
profile issue" while the general attack mechanism had apparently been
known for years.
(and AFAIK there's no proof of actual attacks in the wild)

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Add Py_REPLACE and Py_XREPLACE macros

2014-02-25 Thread Serhiy Storchaka 

17.02.14 01:27, Nick Coghlan написав(ла):

This change doesn't fix any of the known crashers in Lib/test/crashers,
though - I applied the patch locally and checked.


It fixes other crasher (http://bugs.python.org/issue20440#msg209713).


The point is that people already know what Py_CLEAR does. This operation
is like Py_CLEAR (the old reference is only removed *after* the pointer
has been updated), except that the value it is being replaced with can
be something other than NULL. If the replacement value *is* NULL, then
the new operation is *exactly* equivalent to Py_CLEAR.

Operations that do related things should ideally have related names. The
point of my deliberately erroneous expansion is that it's an error a
reader can make while still correctly understanding the *logic* of the
code, even though they're missing a subtlety of the mechanics.


Py_CLEAR and Py_DECREF have no related names. I think that the clarity 
and briefness are important. I assume that these macros will be widely 
used (they allow existing code to write shorter), perhaps even more than 
Py_CLEAR. Therefore people will know what they do.



An explicit name like Py_SET_AND_DECREF would also be reasonable. It's
substantially less confusing than Py_REPLACE, as it is less ambiguous
about whether or not the refcount on the new value is adjusted.


I agree if it will satisfy Martin, although this name looks ugly to me.

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Running 2.7 tests on OS X

2014-02-25 Thread Terry Reedy 

On 2/25/2014 6:25 AM, Rik wrote:

I want to try to submit a patch for 2.7, but I don't know how to run the
tests for the 2.7 branch. `./configure` doesn't seem to create a
`python.exe` file on the 2.7 branch on OS X Mavericks, and I do need
this file according to this guide:
http://docs.python.org/devguide/


While testing with a fresh build is definitely best, 2nd best is testing 
against the latest release, as long as it is installed with Lib/test 
included. So don't let build problems indefinitely stop you from 
submitting the patch ;-).


--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

2014-02-25 Thread Terry Reedy 

On 2/25/2014 8:32 AM, Chris Angelico wrote:

On Wed, Feb 26, 2014 at 12:21 AM, Donald Stufft  wrote:

Instead of pre-generating one set of values that can be be used to DoS things
you have to pre-generate 256 sets of values and try them until you get the
right one. It’s like putting on armor made of paper and saying it’s harder to
stab you now.


Paper armor? You mean the stuff they tested here?
http://www.imdb.com/title/tt1980597/


OT, but I just watched that Mythbusters episode and they confirmed that 
on a weight basis, paper armor from multiple folded sheets was 
comparable to steel. They have also shown that phonebooks stop ordinary 
bullets.


--
Terry Jan Reedy


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] [OT] Paper armor [was Python Remote Code Execution in socket.recvfrom_into()]

2014-02-25 Thread Ethan Furman 

On 02/25/2014 12:13 PM, Terry Reedy wrote:

On 2/25/2014 8:32 AM, Chris Angelico wrote:

On Wed, Feb 26, 2014 at 12:21 AM, Donald Stufft wrote:


Instead of pre-generating one set of values that can be be used to DoS things
you have to pre-generate 256 sets of values and try them until you get the
right one. It’s like putting on armor made of paper and saying it’s harder to
stab you now.


Paper armor? You mean the stuff they tested here?
http://www.imdb.com/title/tt1980597/


OT, but I just watched that Mythbusters episode and they confirmed that on a 
weight basis, paper armor from multiple
folded sheets was comparable to steel. They have also shown that phonebooks 
stop ordinary bullets.


Those must be big-city phone books.  About the only thing my phone book would 
stop is a bb. :/

--
~Ethan~
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

2014-02-25 Thread Nick Coghlan 
On 26 Feb 2014 04:51, "Antoine Pitrou"  wrote:
>
> On Tue, 25 Feb 2014 20:38:46 +0200
> Maciej Fijalkowski  wrote:
> >
> > My impression is that a lot of discussion went into hash
> > randomization, because it was a high profile issue. It got "fixed",
> > then later someone discovered that the fix is completely broken and
> > was left at that without much discussion because it's no longer "high
> > visibility". I would really *like* to perceive this process as a lot
> > of discussion going into because of ramification of changes.
>
> Most of the discussion, AFAIR, was about the potential backwards
> compatibility issues (which led to the decision of adding hash
> randomization in 2.7, but disabled by default).
>
> But you're right that for some reason it suddenly became a "high
> profile issue" while the general attack mechanism had apparently been
> known for years.
> (and AFAIK there's no proof of actual attacks in the wild)

Remote DOS attacks are so easy and so prevalent that if all a CVE does is
make them slightly easier when untrusted input isn't properly validated and
resource consumption per request isn't capped, security teams rank it as a
pretty low threat and not very interesting.

However, there was a paper that presented this one like it was a big
revelation, it stirred up a lot of complaints, so doing something about it
ended up being easier than repeatedly explaining why it didn't really
matter that much. Donald's right that the original fix just increased the
required attack payload size from 1 MB (if I recall the number correctly)
to 256 MB total, but at that point attempts to exploit it are starting to
look like a more conventional DoS (one that doesn't rely on any particular
vulnerability to be effective) anyway.

It's still nice to finally have it fixed properly in 3.4, though, and the
original change at least took care of the problem of getting people to
update their code that previously relied on consistent dict ordering.
Without that previous work, the hash change for 3.4 would have been more
challenging.

Cheers,
Nick.

>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython: whatsnew: DynanicClassAttribute (#19030), Py_SetStandardStreamEncoding (#16129)

2014-02-25 Thread Nick Coghlan 
On 26 Feb 2014 07:04, "r.david.murray"  wrote:
>
> http://hg.python.org/cpython/rev/4cd620d8c3f6
> changeset:   89392:4cd620d8c3f6
> user:R David Murray 
> date:Tue Feb 25 16:03:14 2014 -0500
> summary:
>   whatsnew: DynanicClassAttribute (#19030), Py_SetStandardStreamEncoding
(#16129)
>
> Adding missing docs for DynamicClassAttribute by copying the docstring.
 The
> doc entry could stand some expansion, which I will note on the issue.
>
> files:
>   Doc/library/types.rst |  21 +
>   Doc/whatsnew/3.4.rst  |  17 +
>   2 files changed, 38 insertions(+), 0 deletions(-)
>
>
> diff --git a/Doc/library/types.rst b/Doc/library/types.rst
> --- a/Doc/library/types.rst
> +++ b/Doc/library/types.rst
> @@ -15,6 +15,9 @@
>  Python interpreter, but not exposed as builtins like :class:`int` or
>  :class:`str` are.
>
> +Finally, it provides some additional type-related utility classes and
functions
> +that are not fundamental enough to be builtins.
> +
>
>  Dynamic Type Creation
>  -
> @@ -220,6 +223,9 @@
>Return a new view of the underlying mapping's values.
>
>
> +Additional Utility Classes and Functions
> +
> +
>  .. class:: SimpleNamespace
>
> A simple :class:`object` subclass that provides attribute access to
its
> @@ -246,3 +252,18 @@
> instead.
>
> .. versionadded:: 3.3
> +
> +
> +.. function:: DynamicClassAttribute(fget=None, fset=None, fdel=None,
doc=None)
> +
> +   Route attribute access on a class to __getattr__.
> +
> +   This is a descriptor, used to define attributes that act differently
when
> +   accessed through an instance and through a class.  Instance access
remains
> +   normal, but access to an attribute through a class will be routed to
the
> +   class's __getattr__ method; this is done by raising AttributeError.
> +
> +   This allows one to have properties active on an instance, and have
virtual
> +   attributes on the class with the same name (see Enum for an example).
> +
> +   .. versionadded:: 3.4
> diff --git a/Doc/whatsnew/3.4.rst b/Doc/whatsnew/3.4.rst
> --- a/Doc/whatsnew/3.4.rst
> +++ b/Doc/whatsnew/3.4.rst
> @@ -1270,6 +1270,17 @@
>  :issue:`1565525`).
>
>
> +types
> +-
> +
> +A new :func:`~types.DynamicClassAttribute` descriptor provides a way to
define
> +an attribute that acts normally when looked up through an instance
object, but
> +which is routed to the *class* ``__getattr__`` when looked up through the
> +class.  This allows one to have properties active on a class, and have
virtual
> +attributes on the class with the same name (see :mod:`Enum` for an
example).
> +(Contributed by Ethan Furman in :issue:`19030`.)
> +
> +
>  urllib
>  --
>
> @@ -1512,6 +1523,12 @@
>object allocator have been silenced.  (Contributed by Dhiru Kholia in
>:issue:`18596`.)
>
> +* New function :c:func:`Py_SetStandardStreamEncoding` allows an
application
> +  that is embedding Python to do the equivalent of setting
> +  :envvar:`PYTHONIOENCODING`.  Its arguments override the equivalent
> +  values from :envvar:`PYTHONIOENCODING` if it exists.  (Contributed
> +  by Bastien Montagne and Nick Coghlan in :issue:`16129`.)
> +

There was an existing entry for this one: second bullet under
http://docs.python.org/dev/whatsnew/3.4.html#other-build-and-c-api-changes

Cheers,
Nick.

>
>  .. _other-improvements-3.4:
>
>
> --
> Repository URL: http://hg.python.org/cpython
>
> ___
> Python-checkins mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-checkins
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] GSoC 2014 - Email Module

2014-02-25 Thread Surya 
Hey there,

I am Surya, studying final year of Engineering.  I have looked into Core
Python's ideas list and got interested in Email module.

I've been working on Django over the past few years, and now like to work
on slightly a different layer of protocols and this idea happened to be it.

That said, I have been just using the Email module earlier along with other
similar modules and never dwell into the internal protocol standards before.

It would be great if someone initially can let me know what documentation I
should start reading to get up to the speed and probably bugs related to
this idea I can look into.

Also, I am looking forward to talk about the project with the mentor!

Thanks
Surya 
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GSoC 2014 - Email Module

2014-02-25 Thread Terry Reedy 

On 2/25/2014 8:56 PM, Surya wrote:

Hey there,

I am Surya, studying final year of Engineering.  I have looked into Core
Python's ideas list and got interested in Email module.

I've been working on Django over the past few years, and now like to
work on slightly a different layer of protocols and this idea happened
to be it.

That said, I have been just using the Email module earlier along with
other similar modules and never dwell into the internal protocol
standards before.

It would be great if someone initially can let me know what
documentation I should start reading to get up to the speed and probably
bugs related to this idea I can look into.


Please sign up for core-mentorship list and ask questions there.

--
Terry Jan Reedy

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 2

2014-02-25 Thread Stephen J. Turnbull 
Nick Coghlan writes that b'%a' is

 > the obvious way to interpolate representations of arbitrary objects
 > into binary formats that contain ASCII compatible segments.

The only argument that I have sympathy for is

 > %a *should* be allowed for consistency with text interpolation

although introduction of a new format character is a poor man's
consistency, and this is consistency for consistency's sake.  (I don't
have a big problem with that, though.  I *like* consistency!)

But TOOWTDI where I get off the bus.  I don't I agree that this
consistency is terribly useful, given how easy it is to

def ascify(obj):
# You could also do this with UTF-8.
return ascii(obj).encode('ascii', errors='backslashescape')

I think the obvious way to interpolate representations of arbitrary
objects into binary formats that may contain ASCII-compatible
*segments* is a '__bytes__' method.  (Yes, I'm cheating, that's not
the sense of "arbitrary" Nick meant.  But see below for what happens
when I *do* consider Nick's sense of "arbitrary".)  If it makes sense
to represent an object using only ASCII bytes (eg, a BASE64 encoding
for binary blobs), why not a '__bytes__' method?  If non-ASCII-
compatible segments are allowed, why not use __repr__, or a '__bytes__'
method that gives you a full representation of the object (eg, a pickle)?

So we're really talking about formats that are 100% ASCII-compatible.
What are the use cases?  Debugging logs?  I don't see it.  As far as
human-readability goes, I read 100% incompatible-with-anything debug
logs (aka, containing Japanese in several of its 4 commonly-used
wire-format encodings) into XEmacs buffers regularly with no problems.
Decoding them can be a bitch, of course -- life would be simple if
only they *were* Python reprs!  Of course Emacsen provide a huge
amount of help with such things, but most of what I need to do would
work fine as long as the editor doesn't crash, has an ASCII printable
visual representation of non-printing-ASCII bytes, and allows both
truncation and wrap-at-screen-edge printing of long lines.

OTOH, maybe you have an automatic log-analysis tool or the like that
snafus on non-ASCII-compatible stuff.  if you are truly serious about
keeping your debug logs 100% ASCII-compatible (whether pure ASCII or
some ASCII-compatible "universal" encoding like UTF-8 or GB18030), you
really have your work cut out for you, especially if you want it to be
automatically parseable.  Ascification is the least of your worries.
Or you can do something like

def log_debug_msg(msg_or_obj):
write_to_log(ascify(msg_or_obj))

and get rid of the annoying "b" prefix on all your log message
formats, too!  YMMV, but *I* don't see debug logs as a plausible
justification.

The only plausible case I can think of is Glenn's web app where you
actually directly insert debug information into wire protocol destined
to appear in end-user output -- but then, this web app itself is only
usable in Kansas and other places where the nearest place that a
language other than Middle American English is spoken is a megameter
away.  Industrial strength frameworks will do that work using str, and
then .encode() to the user's requested encoding.  So this probably
isn't an app, but rather the web server itself (which speaks bytes to
clients, not text to users).  But then, typical reprs (whether
restricted to ASCII or not) have insufficient information about an
object to reproduce it.  Why is it a good idea to encourage people
writing objects to a debug log to use a broken-for-the-purpose repr?
(I can see it could go either way.  For example, if the alternative is
a "something went wrong" error message.  But I'd like to see a stronger
argument that a feature which is intended to encourage people to take
shortcuts -- and otherwise has no justification -- is Pythonic. :-)

The "inappropriate '__bytes__' method" seems to be a imaginary
bogeyman, in any case.  If people really want to dump arbitrary
objects (in Nick's sense) to a byte-oriented stream *outside* of the
stream's protocol, I think it would be easier to do that with 'ascify'
then by altering *every* class definition by adding 'ascify' as the
'__bytes__' definition.  Note that 'ascify' is fully general in case
you don't know what the type of the object you are dumping is;
'__bytes__' may not be.  Some objects may have existing incompatible
definitions for '__bytes__': eg, in HTTP, there's no problem with
sending an object in binary format, and it might very well be a
complex object with internal structure that gets flattened for
transmission (into a pickle, for example, or a Python list of frames
from a streaming server: "stream % frames[secs_to_frame(28):]").
Surely you're not going to replace that '__bytes__' with

def __bytes__(self):
return ascify(self)"

Steve


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Uns

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

2014-02-25 Thread Stephen J. Turnbull 
Donald Stufft writes:

 > Instead of pre-generating one set of values that can be be used to
 > DoS things you have to pre-generate 256 sets of values and try them
 > until you get the right one. It’s like putting on armor made of
 > paper and saying it’s harder to stab you now.

You obviously don't watch "Burn Notice."  Paper armor worked great for
Michael Weston!

Unpacking, not all crackers are serious.  I'd be willing to bet that
there are a number of script kiddies who are *still* running scripts
that only know about the first hole.  What's to lose by beating them?


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 2

2014-02-25 Thread Nick Coghlan 
On 26 February 2014 13:57, Stephen J. Turnbull  wrote:
> Nick Coghlan writes that b'%a' is
>
>  > the obvious way to interpolate representations of arbitrary objects
>  > into binary formats that contain ASCII compatible segments.
>
> The only argument that I have sympathy for is
>
>  > %a *should* be allowed for consistency with text interpolation
>
> although introduction of a new format character is a poor man's
> consistency, and this is consistency for consistency's sake.  (I don't
> have a big problem with that, though.  I *like* consistency!)

It's *not* a new format character, unless you mean "new in Python 3".
Python 3 text interpolation has included %a for as long as I can
recall, specifically as a way of spelling the old Python 2 %r
interpolation behaviour now that the Python 3 %r allows Unicode text.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python Remote Code Execution in socket.recvfrom_into()

2014-02-25 Thread Wes Turner 
On 2/25/14, Victor Stinner  wrote:
> Hi,
>
> 2014-02-25 8:53 GMT+01:00 Nick Coghlan :
>> I've checked these, and noted the relevant hg.python.org links on the
>> tracker issue at http://bugs.python.org/issue20246
>
> Would it be possible to have a table with all known Python security
> vulnerabilities and the Python versions which are fixed? Bonus point
> if we provide a link to the changeset fixing it for each branch. Maybe
> put this table on http://www.python.org/security/ ?

For http://www.python.org/security/ :

Here's a start at an issue tracker query for open and closed issues
with 'Type: Security':

http://bugs.python.org/issue?%40search_text=&ignore=file%3Acontent&title=&%40columns=title&id=&%40columns=id&stage=&creation=&%40sort=creation&creator=&activity=&%40columns=activity&actor=&nosy=&type=4&components=&versions=&%40columns=versions&dependencies=&assignee=&keywords=&priority=&%40group=priority&status=&%40columns=status&resolution=&nosy_count=&message_count=&%40pagesize=200&%40startwith=0&%40action=search

Here's a list of filed CVEs with Python in the vendor field:

http://www.cvedetails.com/vulnerability-list/vendor_id-10210/product_id-18230/Python-Python.html

When referring to security issues, it may be helpful to reference the
CVE codes and tracker IDs.

>
> Last issues:
> - hash DoS
> - sock.recvfrom_into()
> - DoS with very long lines in HTTP, FTP, etc. protocols
> - etc.
>
> Victor
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com
>


-- 
-- 
Wes Turner
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com