Martin v. Löwis mar...@v.loewis.de added the comment:
On 14.06.2012 14:26, Antoine Pitrou wrote:
Antoine Pitrou pit...@free.fr added the comment:
It's either secure or it's not.
I don't think that's true. By that reasoning, Python is not secure so
there's no point in fixing crashes
Martin v. Löwis mar...@v.loewis.de added the comment:
Being able to tell people using hmac.total_compare will make you
less vulnerable to timing attacks than using ordinary short
circuiting comparisons is a *good thing*.
No, it's not. It's a *bad thing*. The two issues that have been
opened
Martin v. Löwis mar...@v.loewis.de added the comment:
Why not write a C function which can be more secure than Python code?
For Unicode strings, it's impossible to write a time-independent
comparison function even in C
I would argue that would be an general asset for the stdlib
I would
Martin v. Löwis mar...@v.loewis.de added the comment:
Well, one example:
https://github.com/mitsuhiko/python-pbkdf2/blob/master/pbkdf2.py
It says that it needs that, but I fail to understand why.
pbkdf2 is used to generate encryption keys from passwords, where
you don't need to compare
Martin v. Löwis mar...@v.loewis.de added the comment:
The timing variations with standard comparison are relatively massive
and relatively easy to analyse (if the time taken goes up, you got
the previous digit correct).
If you have an application that is vulnerable to such an attack, you
Martin v. Löwis mar...@v.loewis.de added the comment:
To repeat, the specific feature being proposed for retention is:
To repeat, no use case has been demonstrated for that function. It
has been added because it was fun to write, not because it is useful
Martin v. Löwis mar...@v.loewis.de added the comment:
Is comparing passwords against a secure one not useful?
I claim that this use case doesn't occur in practice. Everybody uses
hashed passwords. If they do compare against a plain-text password,
and they want to change something about
Martin v. Löwis mar...@v.loewis.de added the comment:
I see your point that adding such a function would leverage bad
security behavior and thus may be a bad thing. The usefulness of such
a function to some(?) people is IMHO not disputable though.
I think this entire issue is out of scale
Martin v. Löwis mar...@v.loewis.de added the comment:
Note that this does not relief you from using a time-independent comparison
function. If you call some hash function (which time is known to the
attacker), then you compare it against a stored hashed version. If you use
a normal compare
Martin v. Löwis mar...@v.loewis.de added the comment:
For password hashing, the attacker is unlikely to be able to provide
the digest directly, but for signature checking it's far more likely
to be the case.
Can you elaborate? What is the application, where is the digest
checking, and what
Martin v. Löwis mar...@v.loewis.de added the comment:
Martin, you fail to understand how this works. You don't do 2**32 tries to
leak the 4 charaters, you need 4 * 256, that's why this attack is so bad,
because the time needed for the next character is brute force, but then you
can move
Martin v. Löwis mar...@v.loewis.de added the comment:
That's why the vulnerable cases are far more likely to be related to
*signature* checking. In those you can generally provide both the
hash input (the message) and the hash target (the purported
signature).
I see. I wonder how feasible
Martin v. Löwis mar...@v.loewis.de added the comment:
I recommend to revert the addition of this function. It's not possible to
implement a time-independent comparison function, as demonstrated in issues
14955 and 15061
--
nosy: +loewis
___
Python
Martin v. Löwis mar...@v.loewis.de added the comment:
I recommend to revert the addition of the function, given that it can't be made
secure.
--
nosy: +loewis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15061
Martin v. Löwis mar...@v.loewis.de added the comment:
Thanks for the patches!
--
nosy: +loewis
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14936
Martin v. Löwis mar...@v.loewis.de added the comment:
These functions need to be documented.
--
nosy: +loewis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15042
Martin v. Löwis mar...@v.loewis.de added the comment:
Thanks, fixed
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14937
Martin v. Löwis mar...@v.loewis.de added the comment:
The question really remains whether the VS 9 project files should be generated
from the VS 2010 ones; this would have resolved this error as well (even though
Richard Oudkerk probably wouldn't have run those generators - consequentially
Martin v. Löwis mar...@v.loewis.de added the comment:
Daniel: Antoine is absolutely right. About the only way this can happen is if
*you* contribute the code. Even if you would make clear what you want (what is
a master key and the hello randoms?), it is likely that still nobody else
needs
Martin v. Löwis mar...@v.loewis.de added the comment:
This is a misconfiguration of your system. Take a look at line 29538 of
config.log. It says
configure:13701: ./conftest
ld.so.1: ./conftest: ÖÂÃüµÄ: libintl.so.8: ´ò¿ªÊ§°Ü: ÎÞ´ËÎļþ»òĿ¼
./configure: line -1756: 8400 Killed
Martin v. Löwis mar...@v.loewis.de added the comment:
The comment is correct. The sources are not.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15052
Martin v. Löwis mar...@v.loewis.de added the comment:
Can you please attach the config.log file also?
Also, can you please report what the value of PRId64 in /usr/include/inttypes.h
is?
--
nosy: +loewis
___
Python tracker rep...@bugs.python.org
Martin v. Löwis mar...@v.loewis.de added the comment:
Without looking at the code, it seems that
http://docs.python.org/release/3.1.5/library/io.html?highlight=io#io.TextIOWrapper
gives the answer
If line_buffering is True, flush() is implied when a call to write contains a
newline character
Martin v. Löwis mar...@v.loewis.de added the comment:
U+FFFE is documented as representing an undefined mapping, see
http://docs.python.org/dev/c-api/unicode.html?highlight=charmap#PyUnicode_DecodeCharmap
So the base string case is correct; the derived string implementation also
needs
Martin v. Löwis mar...@v.loewis.de added the comment:
U+FFFE is documented as representing an undefined mapping,
Yes, using U+FFFE for representing an undefined mapping in strings is
normal, the question was about string subclasses.
What is the question? U+FFFE also represents an undefined
Martin v. Löwis mar...@v.loewis.de added the comment:
integers or 1-character strings? What about general mapping? Should
any of them have 0xFFFE or '\uFFFE' represent an undefined mapping?
The documentation says that the parameter can be a dictionary mapping
byte or a unicode string, which
Martin v. Löwis mar...@v.loewis.de added the comment:
Here is a patch with just the shutil changes. Compared to
rmtree-with-fwalk-v3.diff, this changes 90 lines of rmtree, whereas the fwalk
version changes only 70 lines. On the plus side, it's much more obvious in this
version
Martin v. Löwis mar...@v.loewis.de added the comment:
Martin, are you still committed to this?
Yes, I'll provide a patch RSN. I doubt that there will be that much code
duplication.
--
___
Python tracker rep...@bugs.python.org
http
Martin v. Löwis mar...@v.loewis.de added the comment:
I think there were strong objections to changing the path of python.exe, but
this is not proposed in this patch.
As for the patch itself, I think it lacks bdist_msi changes.
--
___
Python
Martin v. Löwis mar...@v.loewis.de added the comment:
If it really fixes the bug, I can update the Tcl version. However, for that, I
would need precise instructions on how to reproduce the bug.
--
___
Python tracker rep...@bugs.python.org
http
Martin v. Löwis mar...@v.loewis.de added the comment:
Compilation with gcc -std=c89 is not supported. Just drop this option. While
Python strives to use C89, we will not distort to meet some abstract language
compliance goal.
OTOH, I fail to see why they need to be bitfields: a plain
Martin v. Löwis mar...@v.loewis.de added the comment:
I think Richard fixed it already, thanks.
--
assignee: loewis -
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14673
Martin v. Löwis mar...@v.loewis.de added the comment:
I'm closing it as won't fix. I don't think it needs to be documented, but I
won't mind if it is.
--
nosy: +loewis
resolution: - wont fix
status: open - closed
___
Python tracker rep
Martin v. Löwis mar...@v.loewis.de added the comment:
I don't think the change had any effect on memory consumption: because of
alignment, padding is inserted either way to fill the flags to four (32-bit) or
eight bytes. So with the bit field, there were 7 bytes of padding on 64-bit
systems
Martin v. Löwis mar...@v.loewis.de added the comment:
I think it's absolutely necessary that text files, by default, are opened in
the encoding of the user's locale, whether the script has called setlocale or
not.
There are reasons for C to not automatically call setlocale at startup (mostly
Martin v. Löwis mar...@v.loewis.de added the comment:
I have now fixed it by looking for the beginning of the string, and not
checking for file name characters at all. There was a related issue that the
auto-complete window would disappear if you type a non-ascii character; I have
fixed
Martin v. Löwis mar...@v.loewis.de added the comment:
See http://hg.python.org/cpython/file/default/Lib/importlib/_bootstrap.py
for the source of SourceFileLoader.
--
nosy: +loewis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Martin v. Löwis mar...@v.loewis.de added the comment:
I do not believe that this is a problem in Python. Instead, it appears that
your Python installation got corrupted somehow.
I recommend to run a virus scanner.
--
nosy: +loewis
___
Python
Martin v. Löwis mar...@v.loewis.de added the comment:
Would you like to contribute a patch?
--
nosy: +loewis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14937
Martin v. Löwis mar...@v.loewis.de added the comment:
Phil: it seems you have hijacked the bug report. Don't do that. If you want to
report a bug, please create a new bug report. Structure it as follows:
1. this is what I did
2. this is what happened
3. this is what should have happened
Martin v. Löwis mar...@v.loewis.de added the comment:
Panos: you are right. The original issue still exists.
However, it is not a bug in Python, but a in the expat library. So I am now
closing this report as out-of-scope for Python.
There is a bug report open on expat requesting support
Changes by Martin v. Löwis mar...@v.loewis.de:
--
resolution: - wont fix
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11804
Martin v. Löwis mar...@v.loewis.de added the comment:
The C standard says, in 6.3.1.3/3
Otherwise [*], the new type is signed and the value cannot be represented in
it; either the result is implementation-defined or an implementation-defined
signal is raised.
[*]: the value cannot be exactly
Martin v. Löwis mar...@v.loewis.de added the comment:
This has nothing to do with XML 1.1 (so closing this report as won't fix).
The UTF-8 text that you present works very well:
p=xml.parsers.expat.ParserCreate(encoding=utf-8)
p.Parse(x\xc3\x87/x, 1)
1
The character LATIN CAPITAL LETTER C
Martin v. Löwis mar...@v.loewis.de added the comment:
2. Yes, only the installation directory, because that's the only
directory we create. Scripts is created by distutils/packaging, but
perhaps we could add it since it is widely used. Anyone have an
opinion?
Fine with me. To create
Martin v. Löwis mar...@v.loewis.de added the comment:
I don't think that doing direct flistdir/fstatat calls would be more complex.
We already have directory walking implemented (in default_rmtree), and I think
the fd-based calls could nicely integrate with that. I'll provide a patch
Martin v. Löwis mar...@v.loewis.de added the comment:
Perhaps a little less contrived
from libc_wrapper import fdopen
from os import *
where libc_wrapper might be a module built on top of ctypes.
--
___
Python tracker rep...@bugs.python.org
http
Martin v. Löwis mar...@v.loewis.de added the comment:
Of course, I would love to see clear documentation of how the kernel
is defined to behave in this situation. It would certainly be
intuitive for mkdir(/net/prodigy/tmp) to force a mount of
/net/prodigy, but defined behavior isn't
Martin v. Löwis mar...@v.loewis.de added the comment:
I believe too many issues are getting confused here. Even though the symptom
appears to be the same (a complaint about _struct not being importable), the
causes might be completely different, as all kinds of different configure
options
Martin v. Löwis mar...@v.loewis.de added the comment:
This is a new feature, not a bug fix, so it can't be added to 2.7.
Newcomers to CPython don't need to bother with 2.7 in general, which can reduce
the combination in half. If they want to use something that works in all
versions, they can
Martin v. Löwis mar...@v.loewis.de added the comment:
Follow-up: I still use 'python Lib/test/regrtest.py'. This works in all
versions since Python 2.0 (with the right Python binary), and supports tab
completion in the shell.
--
___
Python tracker
Martin v. Löwis mar...@v.loewis.de added the comment:
Thanks for the patch. I did the library patch without monkey-patching.
If there are further issues with this feature, please submit new bug reports. I
won't consider the many test failures due to usage of Unicode literals in the
test cases
Changes by Martin v. Löwis mar...@v.loewis.de:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8767
Martin v. Löwis mar...@v.loewis.de added the comment:
While this is technically probably a bug, I'm -0 on fixing it in bugfix
releases, as it has the risk of breaking working code.
--
nosy: +loewis
___
Python tracker rep...@bugs.python.org
http
Martin v. Löwis mar...@v.loewis.de added the comment:
Apparently, connecting the socket is better because some systems (BSDs in
particular) only report ICMP errors to connected UDP sockets. The Linux man
page claims that this reporting is necessary regardless of whether the socket
Martin v. Löwis mar...@v.loewis.de added the comment:
I think it is best, and probably in the spirit of visual studio, to
use the reference part of a project to facilitate linking between
dependency projects. it is designed to take the hassle out of
libraries and search paths. I
Martin v. Löwis mar...@v.loewis.de added the comment:
stat(/net/prodigy, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
mkdir(/net/prodigy/tmp, 0777) = -1 EACCES (Permission denied)
As you can see, a stat() is already done on /net/prodigy.
To be fair, that shouldn’t trigger
Martin v. Löwis mar...@v.loewis.de added the comment:
On my computer, connect() on a UDP socket always finishes
successfully. What's wrong?
Nothing is wrong. UDP is connection-less, so connect() is a no-op,
except that it remembers the address so you can use send() instead
of sendto(). Any
Martin v. Löwis mar...@v.loewis.de added the comment:
I propose that we declare this issue closed, and defer any new issues arising
from the switch to VS 2010 in separate issues.
There will surely be many issues over the next weeks and months, and there is
little point in tracking this all
Martin v. Löwis mar...@v.loewis.de added the comment:
So closing this issue. Kristjan, if you want your patch reviewed further and/or
approved by Brian, please copy it into a new issue.
--
status: open - closed
___
Python tracker rep
Changes by Martin v. Löwis mar...@v.loewis.de:
Removed file: http://bugs.python.org/file25644/smime.p7s
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13210
Martin v. Löwis mar...@v.loewis.de added the comment:
No broad issues, please. One tracker item, one issue. If something other than
_ctypes_test fails to build, it may or may not have the same reason, so caution
requires that we assume they are unrelated defects
Changes by Martin v. Löwis mar...@v.loewis.de:
--
title: Ctypes extension module builds as _ctypes_test.pyd - _ctypes_test fails
to build from the command line with VS 2010
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14821
Martin v. Löwis mar...@v.loewis.de added the comment:
Can you please attach your idle.py, and/or figure out why it has a syntax error
on line 1?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14838
Martin v. Löwis mar...@v.loewis.de added the comment:
Ah, I think I know what happened. When I said command line, I didn't mean
Python (command line), but CMD shell, as found in the start menu (i.e.
cmd.exe). The line I gave you is, of course, invalid Python syntax.
If you have never used
Martin v. Löwis mar...@v.loewis.de added the comment:
I have now upgraded OpenSSL to 0.9.8x for 2.7, to 1.0.0j for 3.2, and to 1.0.1c
for 3.3.
--
nosy: +loewis
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14543
Changes by Martin v. Löwis mar...@v.loewis.de:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14543
Martin v. Löwis mar...@v.loewis.de added the comment:
Closing as a duplicate. Roger, thanks for the analysis.
--
resolution: - duplicate
status: open - closed
superseder: - IDLE and pythonw.exe stderr problem
___
Python tracker rep
Martin v. Löwis mar...@v.loewis.de added the comment:
Perhaps you know what revision that patch was against?
I wish people would stop using git-style diffs, then the patch would actually
say. However, it applied cleanly to tip at the time it was submitted, so you
should be able to go
Martin v. Löwis mar...@v.loewis.de added the comment:
Is this wrong? (I'm still a relative Hg newbie)
It's an ongoing discussion. Some people favor git diffs because
it supports renaming and binaries, I prefer Mercurial diffs, because
it includes the base revision number against the patch
Martin v. Löwis mar...@v.loewis.de added the comment:
That sounds reasonable. So, can't we come up with a diff that does
both? The base revision sounds like a completely necessary piece of
info.
I believe there is a bug report against Mercurial to include the base
revision even in git
Martin v. Löwis mar...@v.loewis.de added the comment:
Please run, from the command line, in the Python installation
python.exe Lib\idlelib\idle.py
and report any output you get.
--
nosy: +loewis
___
Python tracker rep...@bugs.python.org
http
Martin v. Löwis mar...@v.loewis.de added the comment:
I agree that the proposed solutions are hacks, and still propose to close this
as won't fix.
I think this is a bug in Linux. mkdir(/net/prodigy/tmp) ought to trigger the
mount, then fail with EEXIST.
--
nosy: +loewis
Martin v. Löwis mar...@v.loewis.de added the comment:
Zitat von Stefan Krah rep...@bugs.python.org:
Stefan Krah stefan-use...@bytereef.org added the comment:
Preferably, the project files would be generated from the VS2010
project files, but for the moment, manually editing to make them
Martin v. Löwis mar...@v.loewis.de added the comment:
The tar file format does nt support timestamps before 1970. From
http://sunsite.ualberta.ca/Documentation/Gnu/tar-1.13/html_chapter/tar_8.html
POSIX tar format can represent time stamps in the range 1970-01-01 00:00:00
through 2242-03-16
Martin v. Löwis mar...@v.loewis.de added the comment:
In any case, there is a branch supporting Python as a metro app at
http://hg.python.org/sandbox/loewis#win8app
This may get folded back into Python at some point, but certainly not before
Windows 8 is released.
--
nosy: +loewis
Martin v. Löwis mar...@v.loewis.de added the comment:
Building with VS 2008 isn't officially supported anymore. If users want to
continue to use VS 2008, they need to contribute patches. Preferably, the
project files would be generated from the VS2010 project files, but for the
moment
New submission from Martin v. Löwis mar...@v.loewis.de:
random_seed has this code:
long hash = PyObject_Hash(arg);
On Win64, Py_hash_t is a 64-bit type, yet long is a 32-bit type, so this
truncates. I think the computation should be done in Py_ssize_t.
--
messages: 160720
nosy
Martin v. Löwis mar...@v.loewis.de added the comment:
Well, VS 2010 is probably a multi-GB download and install. Besides,
having to juggle between two different VS versions will quickly become
confusing.
Sure. However, it is not feasible to keep the build systems for many
VS versions up
Martin v. Löwis mar...@v.loewis.de added the comment:
Are there any features which make VS 2010 easier to use for us?
Not for us, but for our users. Users request to build Python with VS 2010,
because that's all they have. It's already a major pain for Python Windows
developers to discover
Martin v. Löwis mar...@v.loewis.de added the comment:
I also would appreciate if the VS 2008 build still worked.
Then provide patches.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14813
Martin v. Löwis mar...@v.loewis.de added the comment:
This is bizarre. The same command line that fails during build works
when I paste it manually:
I'm having problems with F-Secure, VS 2010, and make_buildinfo. F-Secure
thinks that make_buildinfo.exe has a virus in it, and quarantines it.
I
Martin v. Löwis mar...@v.loewis.de added the comment:
Returning the compressed data from read() is clearly a bug (IMO), so detecting
that and reporting an exception would be a bug fix.
I still like NotImplementedError more than RuntimeError, though
Martin v. Löwis mar...@v.loewis.de added the comment:
LGTM. Brian?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13210
___
___
Python-bugs-list
Martin v. Löwis mar...@v.loewis.de added the comment:
This is definitely a padding issue. All uncompressed files are located
so that the data starts with a 4-byte boundary (1190+30+15+1=1236, 27486
+30+17+3=27536, etc). This is, probably, allows the use of mmap for the
resources.
That can't
Martin v. Löwis mar...@v.loewis.de added the comment:
Like I said before, I am all for dropping extra fields we can not
interpret. However,
let us be clear that with respect to the standard we are implementing
that zip files constructed like this are ill-formed.
I would still like to see
Changes by Martin v. Löwis mar...@v.loewis.de:
--
versions: +Python 3.3 -Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14812
Martin v. Löwis mar...@v.loewis.de added the comment:
Ok, so I'm closing it.
--
nosy: +loewis
resolution: - wont fix
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9120
Martin v. Löwis mar...@v.loewis.de added the comment:
Thanks for the patch!
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14366
Martin v. Löwis mar...@v.loewis.de added the comment:
Yuval, can you please submit a contributor agreement? See
http://www.python.org/psf/contrib/
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6818
Martin v. Löwis mar...@v.loewis.de added the comment:
As for adding yourself to the CC list: notice the string ubershmekel
appearing in the CC field of http://bugs.python.org/review/6818/show. It
means that you are already on the CC list
Martin v. Löwis mar...@v.loewis.de added the comment:
Serhiy: can you please provide a unit test? The OP's test case is unsuitable
because of both size and copyright.
As for the actual issue: the extra data (type 0xcafe) is apparently added by
jar tools to make the jar file executable:
http
Changes by Martin v. Löwis mar...@v.loewis.de:
Added file: http://bugs.python.org/file25565/zipfile_optimize_read.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10376
Martin v. Löwis mar...@v.loewis.de added the comment:
So as a way out, I propose that the ZipFile class gains a strict
attribute, indicating whether acceptable violations of the spec
are ignored or reported as exceptions.
It is a not easy task (and unnecessary, I suppose). Now zipfile
Martin v. Löwis mar...@v.loewis.de added the comment:
I'm skeptical about the patch. In both 2.7 and 3.x, clipboard_get returns a
Unicode string, yet it fails to decode it properly. So I think this is the bug
that ought to be fixed (using the proper encoding).
Defaulting to UTF8_STRING
Martin v. Löwis mar...@v.loewis.de added the comment:
Martin, is that a way for _tkinter to know whether the result
returned from Tcl/Tk is an encoded string or not in this case?
Off-hand, I don't know. I suppose there is a way to do this correctly,
but one might have to dig through many
Martin v. Löwis mar...@v.loewis.de added the comment:
But the encoding used seemingly depends on the source application -
Geany (GTK 2, I think) seemingly sends UTF8 text anyway, whereas
Firefox escapes the unicode character. So I don't think we can
correctly decode the STRING value in all
Martin v. Löwis mar...@v.loewis.de added the comment:
I'd rather not wait. If packaging is not able to reliably build Python itself,
we shouldn't release Python 3.3 until it is (or withdraw packaging from the
standard library altogether).
--
nosy: +loewis
Changes by Martin v. Löwis mar...@v.loewis.de:
--
versions: +Python 3.3 -Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14790
Changes by Martin v. Löwis mar...@v.loewis.de:
--
priority: normal - release blocker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14790
901 - 1000 of 4659 matches
Mail list logo
