Antoine Pitrou added the comment:
> I would suggest to try to keep ECC/ECDH/ECDHE enabled, conceptually
> we would like to have ECDHE as the first ciphers because it's the most
> modern, performance and secure.
However, this will also divide performance by a large factor
Antoine Pitrou added the comment:
Here is a patch.
--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file24052/compression.patch
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
(note that some OpenSSLs are built without compression, such as Mageia's)
--
___
Python tracker
<http://bugs.python.org/is
Antoine Pitrou added the comment:
> About ECDHE use as a default, prioritized key exchange method, google
> is using it along with RC4:
Hmmm... do note that RC4 is disabled with "HIGH".
--
___
Python tracker
<http://bugs.py
Changes by Antoine Pitrou :
--
keywords: +easy, needs review -patch
nosy: +georg.brandl
stage: -> patch review
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
> File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/socket.py", line 275,
> in readinto
> raise IOError("cannot read from timed out object")
> OSError: cannot read from timed out object
Ah, annoying. The NNTP tests u
Antoine Pitrou added the comment:
Jesus is the OpenIndiana buildbots' administrator.
--
nosy: +jcea
___
Python tracker
<http://bugs.python.org/is
Changes by Antoine Pitrou :
--
nosy: +flox, haypo
versions: +Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue13612>
___
___
Python-bug
Antoine Pitrou added the comment:
Thanks for the patch. Two things:
- there is a compilation warning using gcc:
/home/antoine/cpython/default/Modules/_sqlite/row.c: In function
‘pysqlite_row_subscript’:
/home/antoine/cpython/default/Modules/_sqlite/row.c:128:26: attention : passing
argument
Antoine Pitrou added the comment:
I have finally committed the patch. Thank you!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Changes by Antoine Pitrou :
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue6743>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
Patch now committed in 3.3.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Antoine Pitrou :
a2b_hex and friends accept only byte strings:
>>> binascii.a2b_hex(b'00')
b'\x00'
>>> binascii.a2b_hex('00')
Traceback (most recent call last):
File "", line 1, in
TypeError: 'str' does
New submission from Antoine Pitrou :
Its declaration can be found in Include/pyerrors.h.
Same for PyErr_SetExcFromWindowsErrWithFilenameObject.
--
assignee: docs@python
components: Documentation
messages: 149877
nosy: arnaudc, docs@python, haypo, pitrou
priority: normal
severity: normal
Antoine Pitrou added the comment:
Here is a patch adding the load_dh_params method on SSL contexts, and the
OP_SINGLE_DH_USE option flag.
--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file24053/dh.pa
Antoine Pitrou added the comment:
> 1. On FreeBSD, we must assume that every blocking system call, in *every
> thread*, can be interrupted, and we need to catch EINTR.
>
> 2. On FreeBSD, we cannot block indefinitely in the main thread and expect to
> handle signals.
Antoine Pitrou added the comment:
Here is a patch.
--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file24060/binasciistr.patch
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
Now committed in 3.3.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Antoine Pitrou :
Similarly to #13637 for the binascii module, the decoding functions in the
base64 module could accept ASCII-only unicode strings.
--
components: Library (Lib)
keywords: easy
messages: 149912
nosy: pitrou
priority: normal
severity: normal
status
Antoine Pitrou added the comment:
Committed now.
--
resolution: -> fixed
stage: patch review -> committed/rejected
___
Python tracker
<http://bugs.python.org/i
Changes by Antoine Pitrou :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue13637>
___
___
Python-bugs-list mailing list
Unsubscri
Antoine Pitrou added the comment:
This looks like a reasonable request to me, and the patch looks generally ok as
well.
--
nosy: +neologix, pitrou
stage: -> patch review
versions: -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python
Antoine Pitrou added the comment:
One nit: the patch needs "versionadded" tags for the two new functions.
--
___
Python tracker
<http://bugs.python.o
Changes by Antoine Pitrou :
--
nosy: +lars.gustaebel
___
Python tracker
<http://bugs.python.org/issue13639>
___
___
Python-bugs-list mailing list
Unsubscribe:
Antoine Pitrou added the comment:
So, you're complaining about something which works, kind of:
$ touch héhé
$ LANG=C python3 -c "import os; print(os.listdir())"
['h\udcc3\udca9h\udcc3\udca9']
> This makes robustly working with non-ascii filenames on different
>
Antoine Pitrou added the comment:
> The standard encoding is UTF-8.
How so? I don't know of any Linux or Unix spec which says so. If you get
the Linux heads to standardize this then I'll certainly be very happy
(and countless others will, too). But AFAIK this it not the case an
Antoine Pitrou added the comment:
> Perhaps we should make these algorithms build conditional? Are these
> patent issues of concern to us?
Well, if RedHat used the "standard" OPENSSL_NO_ECDH flag, it's easy
enough to fix compilat
Changes by Antoine Pitrou :
--
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue13627>
___
___
Python-bugs-list mailing list
Unsubscri
Antoine Pitrou added the comment:
Can you post the exact compiler errors you encountered?
--
___
Python tracker
<http://bugs.python.org/issue13627>
___
___
Pytho
Antoine Pitrou added the comment:
Nevermind, I've found them on the Fedora buildbot.
--
___
Python tracker
<http://bugs.python.org/issue13627>
___
___
Pytho
Antoine Pitrou added the comment:
Since we're at it, do you know if Redhat also disables regular Diffie-Hellman?
See issue13626.
--
___
Python tracker
<http://bugs.python.org/is
Antoine Pitrou added the comment:
ec44f2e82707 fixed compilation on Fedora and test_ssl passed fine.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
Now fixed in all 3 branches.
--
nosy: +pitrou
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
superseder: -> "inspect" gets broken by some descriptors
___
Antoine Pitrou added the comment:
Now fixed in all 3 branches.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
Patch committed. Thanks for your contribution!
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
I think we should relax the constraints a bit (RC4 seems ok for TLS/SSL use
(*)) and therefore suggest we settle on
"DEFAULT:!LOW:!EXPORT:!aNULL:!eNULL:!SSLv2".
(OpenSSL's default is "DEFAULT:!aNULL:!eNULL", so we're
Antoine Pitrou added the comment:
> I also suggested changes to the documentation of the "-u" flag, and to
> "What's New in Python 3.0", can someone look at that also?
Sorry for having overlooked that. T
Antoine Pitrou added the comment:
Thanks for the patch. Since you modified PyCFunction_GET_SELF to return NULL
for static methods, why not simply use it instead of manually looking up the
flags in several places?
I'm talking about the following changes:
-PyObject
Changes by Antoine Pitrou :
--
nosy: +brett.cannon, ncoghlan
___
Python tracker
<http://bugs.python.org/issue12453>
___
___
Python-bugs-list mailing list
Unsub
New submission from Antoine Pitrou :
test_import fails when run directly after test_coding:
$ ./python -m test test_coding test_import
[1/2] test_coding
[2/2] test_import
test test_import failed -- Traceback (most recent call last):
File "/home/antoine/cpython/default/Lib/test/test_impo
Antoine Pitrou added the comment:
The cause is that the import machinery checks the timestamp stored in the pyc
file to decide whether it must be refreshed. Depending on the system's
timestamp granularity, there can be false negatives: the py file was modified
twice with the same time
Antoine Pitrou added the comment:
The pyc format currently stores the modification time cast to a 32-bit int. A
3.3 iteration of the pyc format could instead store two 32-bit ints, one for
the integral part and one for the fractional part (e.g. in nanoseconds). When
HAVE_STAT_TV_NSEC is
Antoine Pitrou added the comment:
I've done a review at http://bugs.python.org/review/12715
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/is
Changes by Antoine Pitrou :
--
stage: patch review -> committed/rejected
___
Python tracker
<http://bugs.python.org/issue13620>
___
___
Python-bugs-list mai
Antoine Pitrou added the comment:
In the meantime, I've committed the test patch.
--
___
Python tracker
<http://bugs.python.org/issue13645>
___
___
Pytho
Antoine Pitrou added the comment:
> Indeed. EXT3's timestamps have a 1s granularity, for example.
> Another possibility would be to store both mtime and st_size (it's the
> default heuristic used by rsync does to decide whether to skip a
> file).
Good idea. It would also
Antoine Pitrou added the comment:
> Thanks for the patch sbt.
> I think this is indeed useful, but I'm tempted to go further and say
> we should make this the default - and only - behavior. This will
> probably break existing code that accidentaly relied the fact that the
>
Antoine Pitrou added the comment:
> If we want to start from the "DEFAULT" than we should probably disable:
> - PSK
> - CAMELLIA
> - MD5
> - IDEA
> - SEED
Why do you want to disable all these?
--
___
Python trac
Antoine Pitrou added the comment:
> Why make this decision ourselves at all? Copy what Mozilla and Chromium do
> by default.
If that translates to an explicit list of ciphers it will be a pain to
maintain. Using a generic OpenSSL string such as "DEFAULT:!LOW:[etc.]"
means Ope
Antoine Pitrou added the comment:
> with your latest proposal 'HIGH:!aNULL:!eNULL:!SSLv2' :
> - MD5 was disabled
> - IDEA was disabled
> - SEED was disabled
That was the consequence of it, but that wasn't an explicit goal.
> Generally speaking, as a concep
Antoine Pitrou added the comment:
> The concept i would propose is to choose the ciphers that "known to be
> secure" by disabling everything else.
I hate repeating myself, but who will maintain it?
--
___
Python tracker
<htt
Antoine Pitrou added the comment:
> It is a de facto, not de jure standard: UTF-8 is how things are
> typically stored. Other software (eg gnome file handling utilities)
> makes this assumption. See eg
> <http://www.cl.cam.ac.uk/~mgk25/unicode.html#linux>.
So should we s
Antoine Pitrou added the comment:
> > By default the Python SSL/TLS Stack (client/server) expose
> > unsecure protocols (SSLv2) and unsecure ciphers (EXPORT 40bit DES).
>
> If there is a problem, it should not be fixed in Python, but in the
> underlying library (OpenSS
Antoine Pitrou added the comment:
I would rather document it in TextIOBase:
http://docs.python.org/dev/library/io.html#io.TextIOBase
With text I/O streams, tell() returns an arbitrary "position cookie", meaning
you can't meaningfully do arithmetic on it: this is why cur-relati
Antoine Pitrou added the comment:
> with ContextStack() as stack:
> files = [stack.enter_context(open(fname)) for fname in filenames]
I find this a bit distasteful. Cleaning up resources now needs something called
a "ContextStack" and an "enter_context"
Antoine Pitrou added the comment:
For the record, here are the default ciphers in our Windows OpenSSL build:
Z:\openssl-1.0.0a>out64\openssl.exe ciphers -v
WARNING: can't open config file: /usr/local/ssl/openssl.cnf
ECDHE-RSA-AES256-SHASSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SH
Antoine Pitrou added the comment:
Thank you Meador. I've committed an updated patch.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.pyth
Antoine Pitrou added the comment:
> I'm not sure about the best module to host this, though: os.path ?
os.path is mostly about path manipulation functions, although it also performs
directory I/O (e.g. realpath()).
--
___
Python tracke
Antoine Pitrou added the comment:
Perhaps Paul can try to reproduce and diagnose the issue directly on the
buildbot?
--
nosy: +pmoore
___
Python tracker
<http://bugs.python.org/issue5
Antoine Pitrou added the comment:
Well, getoutput and getstatusoutput are arguably ugly.
However, since they are very high-level functions meant to quickly execute
commands, returning str makes sense. You can't do anything smart with the
output anyway, since stdout and stder
Antoine Pitrou added the comment:
> I'm just adding this to the regex module and I've come up against a
> possible issue. The regex module supports named lists, which could be
> very big. Should the entire contents of those lists also be shown in
> the repr?They would hav
Antoine Pitrou added the comment:
> But it only takes one committer who doesn't care about evalable reprs
> to permanently break the pattern for everyone :-(
So 95% of our datatypes were committed by a single person? :)
--
___
Python tra
Antoine Pitrou added the comment:
> There is a new "match_hostname" that doesn't implement all the
> required, standard SSL/TLS Client security checks that should be done.
Indeed, as the name indicates, it just checks the hostname.
Please detail what the other secur
Antoine Pitrou added the comment:
I'm not sure I like this idea. I think it would be nice to see it discussed on
python-dev.
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/is
Antoine Pitrou added the comment:
> You need to check expiration date of the cert in question, and I
> suppose invocation date as well.
> You need to look at each of the CNs in the subject name, as well as
> each of the DNSname types in the SAN extension.
> You *absolutely must*
Antoine Pitrou added the comment:
> Be sure to support SAN. People forget that, and the API makes it a pain in
> the butt (the validator doesn't even know who you're validating for).
Right, that's why we added the match_hostname() function. It knows about
subjectAltNa
Antoine Pitrou added the comment:
> I wish we had something like:
> io.file
> io.file.tempfile
> io.file.path
> io.file.atomicfile
I adhere to "flat is better than nested". e.g. it always irks me to type
"urllib.request" instead of "urllib"
Antoine Pitrou added the comment:
> Antoine, in case it's useful, do you think that it would be possible
> to have something exactly-like the OpenSSL verify command?
Well, to quote the page you mentioned:
“The verify program uses the same functions as the internal SSL and
S/MIME v
Antoine Pitrou added the comment:
So how about providing a new public `os` module function doing a
rename-with-overwrite on all platforms?
We could name it e.g. os.replace().
os.rename_overwrite() is another possibility, more explicit but also longer.
--
stage: -> needs pa
Antoine Pitrou added the comment:
The patch is committed, thank you!
--
resolution: -> rejected
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
> Anyway, my "thoughts?" wasn't referring to this namespace hierarchy
> "proposal" (which really isn't one), but rather to the best module
> which could host an AtomicFile class.
Does it have to be a class? What w
Antoine Pitrou added the comment:
> > Does it have to be a class? What would be the operations apart from
> > write()?
>
> Well, I thought that making it a file-like object could be useful:
> that way, one could pass it to pickle.dump(), logging.StreamHandler or
> any
Antoine Pitrou added the comment:
> There's no point in calling fsync() after each write, since data is
> written to a temporary file which won't be visible before rename():
> even if you call fsync() after each write, if the file is not properly
> closed, it won'
Changes by Antoine Pitrou :
--
nosy: +orsenthil
versions: +Python 2.7 -Python 3.4
___
Python tracker
<http://bugs.python.org/issue13651>
___
___
Python-bugs-list m
Antoine Pitrou added the comment:
> What is the motivation for providing a new function?
Because changing os.rename would break compatibility.
--
___
Python tracker
<http://bugs.python.org/iss
Antoine Pitrou added the comment:
> An alternative might be a flag on rename: overwrite=['always', 'os_default']
How about overwrite=[None, True] with None meaning "OS default"?
> with a warning and a switch of the default in a subsequent release.
I
Antoine Pitrou added the comment:
> I'm good with None/True, but that would imply that for posix rename
> we'll need to implement the overwrite=False option...which would be a
> nice thing (the shell mv command has -i for that).
My point was rather to forbid False as a
Antoine Pitrou added the comment:
> os.rename(overwrite=False) by default will do less harm than the opposite,
Disagreed.
> Then I believe that having a small chance of overwriting file just created
> at exactly the same moment on a POSIX is a small price to pay for function
&g
Antoine Pitrou added the comment:
> As a Windows programmer I am quite surprised to read this thread with
> information that on Linux os.rename() overwrites files without questions,
> so as I Windows programmer I want os.rename() to stop that.
As a Windows programmer, you are n
Changes by Antoine Pitrou :
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue13660>
___
___
Python-bugs-
Changes by Antoine Pitrou :
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue13661>
___
___
Python-bugs-
Antoine Pitrou added the comment:
> C11 uses 'x' for this, for what it's worth.
>
> This is not a "duplicate issue". The openat solution is no easier than
> the os.open solution.
Ok, let's re-open then. I'm not sold on the feature, but the fact
Changes by Antoine Pitrou :
--
nosy: +georg.brandl, loewis
___
Python tracker
<http://bugs.python.org/issue13663>
___
___
Python-bugs-list mailing list
Unsub
Antoine Pitrou added the comment:
I don't know what the purpose of this feature is nor who the target users are.
Trying to micro-manage the interpreter's resource allocation from Python code
is certainly a losing battle, and does not warrant relying on
implementation-specific APIs
Changes by Antoine Pitrou :
--
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue13609>
___
___
Python-bugs-list mai
Antoine Pitrou added the comment:
> On my linux debian box:
> $ grep -r XATTR_SIZE_MAX -I /usr
> include/linux/limits.h:#define XATTR_SIZE_MAX 65536
> $ dpkg -l libc6
> libc6 2.11.2-10 Embedded GNU C Library: Shared libraries
> $ dpkg -S /usr/include/linux/lim
Antoine Pitrou added the comment:
New prototype with per-module import locks and deadlock avoidance.
When a deadlock due to threaded circular imports is detected, the offending
import returns the partially constructed module object (as would happen in
single-threaded mode).
Probably lacks a
Changes by Antoine Pitrou :
--
nosy: +ezio.melotti
___
Python tracker
<http://bugs.python.org/issue13668>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Antoine Pitrou :
--
nosy: +haypo
stage: needs patch -> patch review
versions: +Python 3.3 -Python 2.6
___
Python tracker
<http://bugs.python.org/issu
Antoine Pitrou added the comment:
> It owns the lock, but hasn't yet updated the lock's owner
> (lock->tstate), so another thread calling detect_circularity() will
> think that this lock is available, and will proceed, which can
> eventually lead to a deadlock.
Antoine Pitrou added the comment:
Patch is now applied to 3.3, thank you for your patience :)
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Antoine Pitrou added the comment:
I've checked the latest patch to work fine under Windows 7 (and Linux, of
course).
--
stage: -> commit review
___
Python tracker
<http://bugs.python.org
Antoine Pitrou added the comment:
I think calling PyErr_WriteUnraisable would be more appropriate than
PyErr_Clear.
I also wonder whether it's ok to ignore the exception. Pressing e.g. Ctrl-C
generally shouldn't fail to stop the program, even if another exception is
being process
Antoine Pitrou added the comment:
Here is a patch adding the source code size to the pyc header.
The number of places where details of the pyc file format are hard coded is
surprisingly high...
Unfortunately, I had to modify importlib's public API (path_mtime ->
path_stats). I
Antoine Pitrou added the comment:
Where are the tests? :)
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.org/issue13676>
___
___
Python-bugs-list mailin
Antoine Pitrou added the comment:
Well, have you read http://docs.python.org/library/multiprocessing.html#windows
?
(especially "Safe importing of main module")
--
nosy: +pitrou
___
Python tracker
<http://bugs.python.o
Antoine Pitrou added the comment:
> If, on the other hand, we really want to reduce the number of cases
> where a deadlock would occur by increasing the locking granularity,
> then it's the way to go.
Yes, that's the point. Today you have to be careful when mixing impor
Antoine Pitrou added the comment:
I believe this new patch should be much more robust than the previous one.
It also adds a test for the improvement (it freezes an unpatched interpreter).
--
Added file: http://bugs.python.org/file24114/implock5.patch
Antoine Pitrou added the comment:
> Anyways, the docs say that python should throw a RuntimeError, but it
> didn't?
I think running it directly would raise a RuntimeError, but importing it
wouldn't.
> And would it be doable to add a warning at the top of the
> multipr
Antoine Pitrou added the comment:
Ok, closing this issue.
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
601 - 700 of 16792 matches
Mail list logo
