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 rep...@bugs.python.org
http://bugs.python.org/issue12226
Giovanni Bajo added the comment:
Il giorno 02/gen/2013, alle ore 00:20, Domen Kožar rep...@bugs.python.org 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 vulnerability
Giovanni Bajo added the comment:
Il giorno 02/gen/2013, alle ore 06:52, Christian Heimes
rep...@bugs.python.org 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 like
Giovanni Bajo added the comment:
Il giorno 02/gen/2013, alle ore 19:51, Christian Heimes
rep...@bugs.python.org 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 only unicode
Giovanni Bajo added the comment:
Il giorno 11/nov/2012, alle ore 05:56, Chris Rebert rep...@bugs.python.org 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 good enough
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:
Il giorno 07/nov/2012, alle ore 08:40, Serhiy Storchaka
rep...@bugs.python.org 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)
$ ./python -m timeit -n 1 -s t
Giovanni Bajo added the comment:
Il giorno 07/nov/2012, alle ore 12:59, Marc-Andre Lemburg
rep...@bugs.python.org ha scritto:
Marc-Andre Lemburg added the comment:
On 07.11.2012 12:55, Mark Dickinson wrote:
Mark Dickinson added the comment:
[MAL]
I don't understand why we are only
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/
(notice
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
Giovanni Bajo giovannib...@gmail.com 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
Giovanni Bajo giovannib...@gmail.com 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
Giovanni Bajo giovannib...@gmail.com 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
Giovanni Bajo giovannib...@gmail.com 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
Giovanni Bajo giovannib...@gmail.com added the comment:
Would you mind elaborating on where is the race condition?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7213
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 definite idea
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 python à from
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 system
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
Changes by Giovanni Bajo:
--
nosy: +rasky
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1342
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org
20 matches
Mail list logo
