Giovanni Bajo added the comment:
Please notice that a redesign of PyPI and package security is ongoing in
catalog-sig.
--
nosy: +Giovanni.Bajo
___
Python tracker
<http://bugs.python.org/issue12
Giovanni Bajo added the comment:
Il giorno 02/gen/2013, alle ore 19:51, Christian Heimes
ha scritto:
>
> Christian Heimes added the comment:
>
> Giovanni, why do you think that hashing of unicode strings is slower than
> byte strings?
>
> First of all ASCII onl
Giovanni Bajo added the comment:
Il giorno 02/gen/2013, alle ore 06:52, Christian Heimes
ha scritto:
>
> Christian Heimes added the comment:
>
> Thanks for the information! I'm working on a PEP for the issue at hand.
Since you're collecting ideas on this, I would l
Giovanni Bajo added the comment:
Il giorno 02/gen/2013, alle ore 00:20, Domen Kožar ha
scritto:
>
> Domen Kožar added the comment:
>
> According to talk at 29c3:
> http://events.ccc.de/congress/2012/Fahrplan/events/5152.en.html
>
> Quote: We also describe a vulnerab
Giovanni Bajo added the comment:
Il giorno 11/nov/2012, alle ore 05:56, Chris Rebert ha
scritto:
>
> Chris Rebert added the comment:
>
> What about CityHash? (http://code.google.com/p/cityhash/ ; unofficial C port:
> http://code.google.com/p/cityhash-c/ )
> It's
Giovanni Bajo added the comment:
Il giorno 07/nov/2012, alle ore 12:59, Marc-Andre Lemburg
ha scritto:
>
> Marc-Andre Lemburg added the comment:
>
> On 07.11.2012 12:55, Mark Dickinson wrote:
>>
>> Mark Dickinson added the comment:
>>
>> [MAL]
>>&
Giovanni Bajo added the comment:
Il giorno 07/nov/2012, alle ore 08:40, Serhiy Storchaka
ha scritto:
> Serhiy Storchaka added the comment:
>
> I tested different kind of strings.
>
> $ ./python -m timeit -n 1 -s "t = b'a' * 10**8" "hash(t)"
&g
Giovanni Bajo added the comment:
Until it's broken with a yet-unknown attack, SipHash is a pseudo-random
function and as such it does uniformly distribute values across the output
space, and never leak any information on the key (the randomized seed). Being
designed by cryptographers,
Giovanni Bajo added the comment:
For short strings, you might want to have a look at the way you fetch the final
partial word from memory.
If the string is >= 8 bytes, you can fetch the last partial word as an
unaligned memory fetch followed by a shift, instead of using a switch like in
Giovanni Bajo added the comment:
Christian, there are good semi-crypto hash functions that don't leak as bad as
Python's own modified FNV hash, without going all the way to HMAC.
SipHash has very good collision resistance and doesn't leak anything:
https://www.131002.net/siphash
Giovanni Bajo added the comment:
If there's agreement that the general problem is unsolvable (so fork and
threads just don't get along with each other), what we could attempt is trying
to limit the side effects in the standard library, so that fewest users as
possible are affect
Giovanni Bajo added the comment:
Hi Gregory,
will you backport Mirko's patches to subprocess32?
The last thing left in this bug is my proposal to change the default of
close_fds to True to Windows too, but at the same time detect whether this is
possible or not (depending on the
Giovanni Bajo added the comment:
Would you mind elaborating on where is the race condition?
--
___
Python tracker
<http://bugs.python.org/issue7213>
___
___
Pytho
Giovanni Bajo added the comment:
Setting CLOEXEC on the pipes seems like a very good fix for this bug. I'm +1 on
it, but I think it should be the default; instead, your proposed patch adds a
new argument to the public API. Why do you think it's necessary to do so?
At the same time,
Giovanni Bajo added the comment:
Hi Gregory, I saw your commit here:
http://code.activestate.com/lists/python-checkins/91914/
This basically means that in 3.2 it is mandatory to specify close_fds to avoid
a DeprecationWarning. *BUT* there is no good value that works both on Windows
and Linux
Giovanni Bajo added the comment:
mbstowcs uses LC_CTYPE. Is that correct and consistent with the way
default encoding under UNIX is handled by Py3k?
Would a Py_MainW or similar wrapper be easier on the UNIX guys? I'm just
asking, I don't have a def
Giovanni Bajo added the comment:
I'm attaching a simple patch that seems to work under Py3k. The trick is
that Py3k already attempts (not sure how or why) to decode argv using
utf-8. So it's sufficient to setup argv as UTF8-encoded strings.
Notice that brings the output of "pyt
Giovanni Bajo added the comment:
Making the standard Windows Python DLL larger is not only a problem of
disk size: it will make all packages produced by PyInstaller or py2exe
larger, and that means lots of wasted bandwidth.
I see that MvL is still -1 on simply splitting CJK codecs out, and
New submission from Giovanni Bajo:
Under Windows, sys.argv is created through the Windows ANSI API.
When you have a file/directory which can't be represented in the
system encoding (eg: a japanese-named file or directory on a Western
Windows), Windows will encode the filename to the s
Changes by Giovanni Bajo:
--
nosy: +rasky
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1342>
__
___
Python-bugs-list mailing list
Unsubs
20 matches
Mail list logo
