[issue13631] readline fails to parse some forms of .editrc under editline (libedit) emulation on Mac OS X

[Ned Deily]

Changes by Ned Deily :


--
nosy: +ned.deily

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13550] Rewrite logging hack of the threading module

[Charles-François Natali]

Charles-François Natali  added the comment:

I'm personally +1 on removing the verbose thing altogether:
- it's ugly
- I doubt it's really useful (I mean, printing to stderr - which is often line 
buffered or unbuffered - upon every action will probably change the timing)
- it also brings some problems on its own, e.g. #4188

So unless there's a good reason behind it, I think we could let it go.

--
nosy: +neologix

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13565] test_multiprocessing.test_notify_all() hangs on "AMD64 Snow Leopard 02 03.x"

[Charles-François Natali]

Charles-François Natali  added the comment:

I think this could be due to the multiprocessing manager's server socket 
backlog value, which is a little too low: by default, it's set to 5, and the 
tests launch up to 3 threads and 3 processes in parallel, so if we're unlucky 
with the scheduling, we could get some ECONNREFUSED.
Unless otherwise specified, the server uses Unix domain sockets: on Linux, when 
the server's socket backlog is full, connect() blocks, which could explain why 
it doesn't happen on Linux. It would be nice to check the behavior in case of 
socket backlog full on affected OSes (for example OS X or FreeBSD).

Here's a run on Linux:
"""
$ ./python ~/test_backlog.py 
0
1
2
3
4
[blocks]
"""

If we get ECONNREFUSED on OS X or FreeBSD, then there's a chance it's the 
culprit. If not, well, no idea what's going on :-)

--
nosy: +neologix
Added file: http://bugs.python.org/file24048/test_backlog.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11867] Make test_mailbox deterministic

[Charles-François Natali]

Charles-François Natali  added the comment:

> Probably because I'm a threading/multiprocessing neophyte :)

That's a very good reason :-)

Here's a version using two multiprocessing events. Note that I use
timeouts for wait() just to avoid being stuck if something goes wrong:
the test now runs in a dozen ms.

By the way, next time you need a duplex communication between two
processes, you can use socketpair(), which returns a pair of connected
sockets.

--
Added file: http://bugs.python.org/file24049/test_mailbox_evt.diff

___
Python tracker 

___diff --git a/Lib/test/test_mailbox.py b/Lib/test/test_mailbox.py
--- a/Lib/test/test_mailbox.py
+++ b/Lib/test/test_mailbox.py
@@ -17,6 +17,10 @@
 import fcntl
 except ImportError:
 pass
+try:
+import multiprocessing
+except ImportError:
+multiprocessing = None
 
 
 class TestBase(unittest.TestCase):
@@ -993,28 +997,36 @@
 self.assertEqual(contents, f.read())
 self._box = self._factory(self._path)
 
+@unittest.skipUnless(hasattr(os, 'fork'), "Test needs fork().")
+@unittest.skipUnless(multiprocessing, "Test needs multiprocessing.")
 def test_lock_conflict(self):
-# Fork off a subprocess that will lock the file for 2 seconds,
-# unlock it, and then exit.
-if not hasattr(os, 'fork'):
-return
+# Fork off a child process that will lock the mailbox temporarily,
+# unlock it and exit.
+ready = multiprocessing.Event()
+done = multiprocessing.Event()
+
 pid = os.fork()
 if pid == 0:
-# In the child, lock the mailbox.
+# child
 try:
+# lock the mailbox, and signal the parent it can proceed
 self._box.lock()
-time.sleep(2)
+ready.set()
+
+# wait until the parent is done, and unlock the mailbox
+done.wait(5)
 self._box.unlock()
 finally:
 os._exit(0)
 
-# In the parent, sleep a bit to give the child time to acquire
-# the lock.
-time.sleep(0.5)
+# In the parent, wait until the child signals it locked the mailbox.
+ready.wait(5)
 try:
 self.assertRaises(mailbox.ExternalClashError,
   self._box.lock)
 finally:
+# Signal the child it can now release the lock and exit.
+done.set()
 # Wait for child to exit.  Locking should now succeed.
 exited_pid, status = os.waitpid(pid, 0)
 
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13627] Python SSL stack doesn't support Elliptic Curve ciphers

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Here is a patch adding a set_ecdh_curve() method on SSL contexts, and a 
ssl.OP_SINGLE_ECDH_USE option flag. This is enough to enable ECDH with 
compatible clients (I've tested with Firefox and openssl s_client).

--
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file24050/ecdh.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11867] Make test_mailbox deterministic

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Charles-François's patch looks good to me.

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13627] Python SSL stack doesn't support Elliptic Curve ciphers

[naif]

naif  added the comment:

So, with this patch it should be possible to strictly enable ciphers such as:
ECDHE-RSA-AES256-SHA   SSLv3 Kx=ECDH Au=RSA  Enc=AES(256) Mac=SHA1
ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1
ECDH-RSA-AES256-SHASSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA1
ECDH-ECDSA-AES256-SHA  SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA1

Which ciphers did you negotiated succesfully?


While with the implementation of http://bugs.python.org/issue13627 (DH/DHE 
ciphers) we should be able to negotiate:
 SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA   EDH-RSA-DES-CBC3-SHA (SSLv3)
 TLS_DHE_DSS_WITH_DES_CBC_SHAEDH-DSS-CBC-SHA (TLSv1)
 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA   EDH-DSS-DES-CBC3-SHA (TLSv1)
 TLS_DHE_RSA_WITH_DES_CBC_SHAEDH-RSA-DES-CBC-SHA (TLSv1)
 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA   EDH-RSA-DES-CBC3-SHA (TLSv1)
 TLS_DHE_DSS_WITH_AES_128_CBC_SHADHE-DSS-AES128-SHA
 TLS_DHE_DSS_WITH_AES_256_CBC_SHADHE-DSS-AES256-SHA
 TLS_DHE_RSA_WITH_AES_128_CBC_SHADHE-RSA-AES128-SHA
 TLS_DHE_RSA_WITH_AES_256_CBC_SHADHE-RSA-AES256-SHA

Do you expect it would be a difficult step to handle also the DH/DHE (non ECC) 
negotiation?

Additionally it would be imho very important if the Python language would 
provide a "default ciphers setup" that look at maximum compatibility, 
performance and security.

If it sounds fine for you, i would open another ticket to create a default 
cipherlist.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13626] Python SSL stack doesn't support DH ciphers

[naif]

naif  added the comment:

Wow, i saw your patch for ECC SSL ciphers on http://bugs.python.org/issue13627 .

Do you think we can use the same method/concept as ssl.OP_SINGLE_ECDH_USE but 
ssl.OP_SINGLE_DH_USE for DH?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13634] Python SSL stack doesn't support Compression configuration

[naif]

New submission from naif :

TLSv1 support compression with gzip/deflate that can provide for a lot of 
protocols a great improvement (just think about SIP/TLS or IMAP) in terms of 
bandwidth.

Currenly Python SSL stack based on OpenSSL doesn't allow the configuration 
(enabling/disabling/forcing) of TLS compression.

This ticket is about suggesting to implement TLS compression configuration of 
OpenSSL as described on:
http://blog.dave.cridland.net/?p=73

--
components: Library (Lib)
messages: 149830
nosy: naif
priority: normal
severity: normal
status: open
title: Python SSL stack doesn't support Compression configuration
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13635] Python SSL stack doesn't support ordering of Ciphers

[naif]

New submission from naif :

The list of Ciphers for Python SSL binding for OpenSSL cannot be ordered in a 
specific list of preference.

This is a requirement for strict security environment where the ordered cipher 
list it's very important.

Apache support the ordering of ciphers trough the configuration of 
SSLHonorCipherOrder:
http://www.carbonwind.net/blog/post/Setting-the-preferred-cipher-suite-on-Apache-22x.aspx

Also Internet Explorer 7 support Ciphers order configuration:
https://blogs.technet.com/b/steriley/archive/2007/11/06/changing-the-ssl-cipher-order-in-internet-explorer-7-on-windows-vista.aspx?Redirected=true

Not having the ordered cipher list doesn't allow Python SSL stack configuration 
to be compliant with high security environment, de-facto representing a 
security vulnerability.

We suggest to fix the issue of lacking that feature.

--
components: Library (Lib)
messages: 149831
nosy: naif
priority: normal
severity: normal
status: open
title: Python SSL stack doesn't support ordering of Ciphers
type: security
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13627] Python SSL stack doesn't support Elliptic Curve ciphers

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> So, with this patch it should be possible to strictly enable ciphers such as:
> ECDHE-RSA-AES256-SHA   SSLv3 Kx=ECDH Au=RSA  Enc=AES(256) Mac=SHA1
> ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1
> ECDH-RSA-AES256-SHASSLv3 Kx=ECDH/RSA Au=ECDH Enc=AES(256) Mac=SHA1
> ECDH-ECDSA-AES256-SHA  SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=AES(256) Mac=SHA1
> 
> Which ciphers did you negotiated succesfully?

I didn't try to negotiate a specific cipher, I just saw that the
selected cipher was ECDHE-RSA-AES256-SHA (using a standard self-signed
certificate). I suppose other ciphers are accessible as well.

> While with the implementation of http://bugs.python.org/issue13627
> (DH/DHE ciphers) we should be able to negotiate:

You mean issue13626.

> Do you expect it would be a difficult step to handle also the DH/DHE
> (non ECC) negotiation?

No, but that's issue13626 :)

> Additionally it would be imho very important if the Python language
> would provide a "default ciphers setup" that look at maximum
> compatibility, performance and security.

You have the set_ciphers() method which allows you to set a "cipher
string":
http://docs.python.org/dev/library/ssl.html#ssl.SSLContext.set_ciphers
OpenSSL itself has several generic cipher settings available:
http://www.openssl.org/docs/apps/ciphers.html#CIPHER_LIST_FORMAT

For example the following setting gives you only ECDH ciphers with
strong encryption and authentication:

$ openssl ciphers -v 'kEECDH:!NULL:!aNULL'
ECDHE-RSA-AES256-SHASSLv3 Kx=ECDH Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256)  Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA  SSLv3 Kx=ECDH Au=RSA  Enc=3DES(168) Mac=SHA1
ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1
ECDHE-RSA-AES128-SHASSLv3 Kx=ECDH Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128)  Mac=SHA1
ECDHE-RSA-RC4-SHA   SSLv3 Kx=ECDH Au=RSA  Enc=RC4(128)  Mac=SHA1
ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128)  Mac=SHA1

We are not cryptography experts and I don't think it would be a good
idea to maintain our own list of ciphers.

(furthermore, I don't think "maximum compatibility, performance and
security" are generally compatible with each other)

--
title: Python  SSL stack doesn't support Elliptic Curve ciphers -> Python SSL 
stack doesn't support Elliptic Curve ciphers

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13626] Python SSL stack doesn't support DH ciphers

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Wow, i saw your patch for ECC SSL ciphers on 
> http://bugs.python.org/issue13627 .
> 
> Do you think we can use the same method/concept as
> ssl.OP_SINGLE_ECDH_USE but ssl.OP_SINGLE_DH_USE for DH?

Of course.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13626] Python SSL stack doesn't support DH ciphers

[naif]

naif  added the comment:

In the meantime i added two other tickets on security and performance 
improvements of Python SSL support, to make it really complete and comparable 
to Apache/Dovecot/PHP in terms of configuration and capability: 

Python SSL stack doesn't support ordering of Ciphers
http://bugs.python.org/issue13635

Python SSL stack doesn't support Compression configuration
http://bugs.python.org/issue13634

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13635] Python SSL stack doesn't support ordering of Ciphers

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Apparently it's just a matter of exposing SSL_OP_CIPHER_SERVER_PREFERENCE?

--
nosy: +pitrou
type: security -> enhancement
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13627] Python SSL stack doesn't support Elliptic Curve ciphers

[naif]

naif  added the comment:

The Tor Project is composed of Cryptography experts, thus i am opening that 
ticket cause with our group we're implementing Tor2web based on Python that 
require *strict* security requirements for crypto.

The Tor Project heavily use Python for most of tools.

If you want we can open a discussion within Tor Project to have a "rationale 
method" to define a set of "default ciphers" considering the ration of 
security/performance/compatibility.

That way anyone using Python SSL/TLS will be sure in using a "Secure system" 
without the risk of legacy protocol such as SSLv2 or insecure ciphers like 
Export 40bit DES that are nowdays enabled by default.

Today a Python coder approaching SSL/TLS will have an insecurely configured TLS 
connection that can be hijacked via SSLv2 protocol or cracked via 40bit DES. 

Even Firefox, Chrome, IE, Opera disable by default certain protocols and 
certain ciphers, so imho it would be valuable to have a "Secure default", 
obviously considering and maintaining compatibility.

What do you think?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13635] Python SSL stack doesn't support ordering of Ciphers

[naif]

naif  added the comment:

Looking at the code from mod_ssl i would say that this is the preference 
required https://issues.apache.org/bugzilla/show_bug.cgi?id=28665

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13634] Python SSL stack doesn't support Compression configuration

[Antoine Pitrou]

Antoine Pitrou  added the comment:

So, there are two things here:
- allow to disable compression (it's enabled by default AFAICT) using the 
SSL_OP_NO_COMPRESSION flag
- allow to query compression status on SSL sockets using the 
SSL_get_current_compression() API

--
nosy: +pitrou
stage:  -> needs patch
type:  -> enhancement
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers

[naif]

New submission from naif :

By default the Python SSL/TLS Stack (client/server) expose unsecure protocols 
(SSLv2) and unsecure ciphers (EXPORT 40bit DES).

This ticket is about defining a set of secure ciphers that should also provide 
maximum performance and compatibility, in order to allow any Python coder to 
use a Secure SSL/TLS stack without the need to became a Crypto Experts.

The discussion come from ticket http://bugs.python.org/issue13627 .

The proposal is to involve a discussion from the Tor Project (mailing list 
Tor-Talk & Tor-Dev) to define rationally a default set of ciphers/protocol for 
Python SSL/TLS from the Cryptography point of view .

--
components: Library (Lib)
messages: 149839
nosy: naif
priority: normal
severity: normal
status: open
title: Python SSL Stack doesn't have a Secure Default set of ciphers
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13627] Python SSL stack doesn't support Elliptic Curve ciphers

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> If you want we can open a discussion within Tor Project to have a
> "rationale method" to define a set of "default ciphers" considering
> the ration of security/performance/compatibility.

Why don't you simple define your own default ciphers and call the
set_ciphers() method?

That said, we could perhaps call set_ciphers("HIGH") by default. This
excludes legacy ciphers (such as RC4, DES) without having us maintain an
explicit list.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13627] Python SSL stack doesn't support Elliptic Curve ciphers

[naif]

naif  added the comment:

Created a ticket there for a default-setting:

Python SSL Stack doesn't have a Secure Default set of ciphers
http://bugs.python.org/issue13636

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers

[Antoine Pitrou]

Antoine Pitrou  added the comment:

As I said, I don't think maintaining an explicit list of ciphers ourselves is 
reasonable, since there are no crypto experts (AFAICT) amongst the Python core 
developers.

Also, maintaining an explicit list of ciphers means people wouldn't benefit 
automatically from new ciphers unless Python itself is modified.

However, as I've proposed on issue13627, we could call set_ciphers("HIGH") by 
default. This excludes legacy ciphers (such as RC4, DES) without having us 
maintain an explicit list.

--
nosy: +gregory.p.smith, pitrou
stage:  -> needs patch
type:  -> security
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11867] Make test_mailbox deterministic

[Roundup Robot]

Roundup Robot  added the comment:

New changeset c6d41dd60d2d by Charles-François Natali in branch '2.7':
Issue #11867: Make test_mailbox.test_lock_conflict deterministic (and fix a
http://hg.python.org/cpython/rev/c6d41dd60d2d

New changeset 0053b7c68a02 by Charles-François Natali in branch '3.2':
Issue #11867: Make test_mailbox.test_lock_conflict deterministic (and fix a
http://hg.python.org/cpython/rev/0053b7c68a02

New changeset 020260ec44f2 by Charles-François Natali in branch 'default':
Issue #11867: Make test_mailbox.test_lock_conflict deterministic (and fix a
http://hg.python.org/cpython/rev/020260ec44f2

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers

[naif]

naif  added the comment:

>From Antoine Pitrou (pitrou):
> Why don't you simple define your own default ciphers and call the
> set_ciphers() method?
> That said, we could perhaps call set_ciphers("HIGH") by default. This
> excludes legacy ciphers (such as RC4, DES) without having us maintain an
> explicit list.

I would suggest to follow a future proof approach that would consider:
* Disable SSLv2 (no one support it anymore)
* Enable Elliptic Curve Crypto and provide it as a priority (maximum security 
with strong performance gain)
* Enable Perfect Forward Secrecy ciphers first (DH ephemeral DHE)

* Provide an ordered cipher list for TLSv1
 - First ECC/DHE ciphers (Future Proof, PFS, with maximum performance)
 - Second DHE ciphers (Non-future proof, PFS, less performance)
 - Third TLSv1 AES ciphers (AES-128/AES-256, max compatibility, max performance)

* Then provide an ordered cipher list for SSLv3 (No AES support)
 - First 3DES DHE ciphers (PFS security)
 SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA   EDH-RSA-DES-CBC3-SHA

 - Second 3DES non-DHE cipher 
 SSL_RSA_WITH_3DES_EDE_CBC_SHA   DES-CBC3-SHA

 - Third RC4 based encryption
 SSL_RSA_WITH_RC4_128_SHA


That way (but this is an approach to be discussed) we will pick-up a set of 
widely secure ciphers, high performance ciphers, highly compatible ciphers, but 
with a selection logic that's optimized for existing set of application and 
servers.

Or eventually hide that complexity for the Python developers by providing a set 
of "pre-configured" profiles to be used?

I always find ppl having difficulties in dealing with SSL/TLS, as a result 
SSL/TLS configuration it's often "by default" .

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Actually, it seems we want 'HIGH:!aNULL:!eNULL' to avoid non-encrypted and 
non-authenticated ciphers.

> That way (but this is an approach to be discussed) we will pick-up
> a set of widely secure ciphers

Please read my message above and understand this faces us with a number of 
maintenance problems which can actually *decrease* security.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Here is a possible patch for 3.2.
Probably needs a doc addition as well.

--
keywords: +patch
stage: needs patch -> patch review
versions: +Python 2.7
Added file: http://bugs.python.org/file24051/default_ciphers.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers

[naif]

naif  added the comment:

Ok for:
'HIGH:!aNULL:!eNULL'

but also:
- Disable SSLv2
- Enable ECC/ECDHE by default
- Enable DH/DHE by default

With this in place, i would then suggest to see which is the "Default ordered 
list of ciphers" with an SSL cipher scanner/wireshark.

Then we would be able to know if the "default order" for the ciphers is 
reasonable or if we would need to manually organize it to have a preferred 
selection that consider security and performance, while keeping always 
compatibility.

What do you think of an approach like this?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13635] Python SSL stack doesn't support ordering of Ciphers

[Roundup Robot]

Roundup Robot  added the comment:

New changeset c706f76c9ea8 by Antoine Pitrou in branch 'default':
Issue #13635: Add ssl.OP_CIPHER_SERVER_PREFERENCE, so that SSL servers
http://hg.python.org/cpython/rev/c706f76c9ea8

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> - Disable SSLv2

It should be disabled automatically since the SSLv2 cipher suites are not part 
of "HIGH": see 
http://www.openssl.org/docs/apps/ciphers.html#SSL_v2_0_cipher_suites_

> - Enable ECC/ECDHE by default
> - Enable DH/DHE by default

These both require parameters. I think adding simple instructions in the 
documentation would go a long way towards helping users. It would also probably 
be more instructive than silently choosing default values.

(after all, for ECDHE it's a one-line addition; DHE needs a separate file so 
it's less immediate)

> With this in place, i would then suggest to see which is the "Default
> ordered list of ciphers" with an SSL cipher scanner/wireshark.

I'm not really able to do that. Perhaps you can help?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13635] Python SSL stack doesn't support ordering of Ciphers

[Antoine Pitrou]

Antoine Pitrou  added the comment:

The new option is now committed in 3.3. Thanks for the report!

--
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11867] Make test_mailbox deterministic

[Charles-François Natali]

Charles-François Natali  added the comment:

Should be fixed now, thanks!

--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13628] python-gdb.py: patch to improve support of optimized Python

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 0b03cb97dac0 by Victor Stinner in branch '3.2':
Issue #13628: python-gdb.py is now able to retrieve more frames in the Python
http://hg.python.org/cpython/rev/0b03cb97dac0

New changeset 5e3a172bba89 by Victor Stinner in branch 'default':
(Merge 3.2) Issue #13628: python-gdb.py is now able to retrieve more frames in
http://hg.python.org/cpython/rev/5e3a172bba89

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers

[naif]

naif  added the comment:

To disable SSLv2 you must specifically disable it.

Look, i tried a server we're working on http://github.com/hellais/tor2web 
that's running on:

privacyresearch.infosecurity.ch port 

With 'HIGH:!aNULL:!eNULL' SSLv2 can connect:

openssl s_client -connect  privacyresearch.infosecurity.ch: -ssl2

SSLv2, Cipher is DES-CBC3-MD5

So it negotiated SSLv2 with 3DES that's not a good choice, SSLv2 must be 
disabled.

We must disable SSLv1 with !SSLv2, for example i am using just now 
'HIGH:!aNULL:!eNULL:!SSLv2:@STRENGTH' .

Trying to connect with SSLv2 fail:
openssl s_client -connect  privacyresearch.infosecurity.ch: -ssl2
140735092141340:error:1406D0B8:SSL routines:GET_SERVER_HELLO:no cipher 
list:s2_clnt.c:450:

Trying to connect by default, it select a strong cipher (i still didn't setup 
the dh/stuff):

openssl s_client -connect  privacyresearch.infosecurity.ch:

Connect with: TLSv1/SSLv3, Cipher is AES256-SHA

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13628] python-gdb.py: patch to improve support of optimized Python

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 1cc8e9565339 by Victor Stinner in branch '2.7':
Issue #13628: python-gdb.py is now able to retrieve more frames in the Python
http://hg.python.org/cpython/rev/1cc8e9565339

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13628] python-gdb.py: patch to improve support of optimized Python

[STINNER Victor]

STINNER Victor  added the comment:

> It is possible to retrieve "f" from the caller, PyEval_EvalCodeEx()

It does not always work, but it works sometimes, so it's better to try :-)

I applied my fix to Python 2.7, 3.2 and 3.3. lipython.py of Python 2.7 is 
outdated, it should be resynchronized with the one of Python 3.3. I will do 
that later and in another issue.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> We must disable SSLv1 with !SSLv2, for example i am using just now
> 'HIGH:!aNULL:!eNULL:!SSLv2:@STRENGTH' .

Ok, thanks for the investigation. I think "HIGH:!aNULL:!eNULL:!SSLv2" is
sufficient.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers

[naif]

naif  added the comment:

Yes, i can do the test for the ordered set of ciphers with all the patches 
in-place, can build a custom python 3.2 with the patch applied.

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.

For DH, you say that it require some file, but looking at mod_ssl Changelog it 
say:
  The reason was that mod_ssl's temporary RSA keys and DH parameters
  were stored in the persistent memory pool directly as OpenSSL's
  RSA and DH structures.

I mean, when i install Apache with SSL, from the system administrator point of 
view, i never have to create a file somewhere in order to have that ciphers.

Maybe also DH/EDH stuff can be done "in memory"?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers

[naif]

naif  added the comment:

About ECDHE use as a default, prioritized key exchange method, google is using 
it along with RC4:
http://www.julianevansblog.com/2011/11/https-encryption-increased-for-gmail-and-google.html

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers

[naif]

naif  added the comment:

We could also disable all the ciphers that use MD5 for authentication:

MD5 has been disabled for SSL use due to it's weakness by:

- Firefox (All mozilla products now refuse any MD5 ciphers)
https://www.thesslstore.com/blog/index.php/firefox-to-stop-supporting-md5-based-ssl/
- Duracon by Jacob Appelbaum (Tor Project)
https://github.com/ioerror/duraconf

"HIGH:!aNULL:!eNULL:!SSLv2:!MD5" would do the magic, so we update the default 
to a modern, yet compatible set of SSL ciphers supported.

I don't want in any case to break compatibilities, but by default a software, 
should not support vulnerable, weak ciphers and this seems a good compromise.

Then the last fine tuning would be have the right preferred orders of ciphers 
to always prefer ECDHE (if available).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers

[naif]

naif  added the comment:

It would be also useful to "Sort" the order of ciphers by it's strength.

This is done by the parameter @STRENGTH" :

>From http://www.openssl.org/docs/apps/ciphers.html

"Additionally the cipher string @STRENGTH can be used at any point to sort the 
current cipher list in order of encryption algorithm key length."

In that case the default cipher string would become:
"HIGH:!aNULL:!eNULL:!SSLv2:!MD5:@STRENGTH"

The logic for third party developers could be explained as:

Only =>128bit ciphers
Disable unauthenticated ciphers
Disable SSLv2 protocol
Disable weak MD5 hash as authentication
Sort the cipher preferences by it's strength

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> MD5 has been disabled for SSL use due to it's weakness by:

Apparently MD5 is already disabled by "HIGH:!SSLv2".

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers

[Antoine Pitrou]

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 (from 2x to
4x apparently).

> Maybe also DH/EDH stuff can be done "in memory"?

Yes, there are also APIs for that, but you still have to provide magic
numbers (or have Python provide them).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers

[naif]

naif  added the comment:

I confirm, tested "HIGH:!SSLv2" and MD5 cannot be negotiated.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13634] Python SSL stack doesn't support Compression configuration

[Antoine Pitrou]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13634] Python SSL stack doesn't support Compression configuration

[Antoine Pitrou]

Antoine Pitrou  added the comment:

(note that some OpenSSLs are built without compression, such as Mageia's)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers

[Antoine Pitrou]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13620] Support Chrome in webbrowser.py

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
keywords: +easy, needs review -patch
nosy: +georg.brandl
stage:  -> patch review
versions: +Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13453] Tests and network timeouts

[Charles-François Natali]

Charles-François Natali  added the comment:

Another failure on an OpenIndiana buildbot:
"""
==
ERROR: testTimeoutConnect (test.test_ftplib.TestTimeouts)
--
Traceback (most recent call last):
  File 
"/export/home/buildbot/32bits/3.2.cea-indiana-x86/build/Lib/test/test_ftplib.py",
 line 837, in testTimeoutConnect
ftp.connect(HOST, timeout=30)
  File "/export/home/buildbot/32bits/3.2.cea-indiana-x86/build/Lib/ftplib.py", 
line 142, in connect
self.sock = socket.create_connection((self.host, self.port), self.timeout)
  File "/export/home/buildbot/32bits/3.2.cea-indiana-x86/build/Lib/socket.py", 
line 404, in create_connection
raise err
  File "/export/home/buildbot/32bits/3.2.cea-indiana-x86/build/Lib/socket.py", 
line 395, in create_connection
sock.connect(sa)
socket.error: [Errno 146] Connection refused
"""

I guess it's always the same problem, a broken name resolution service which 
takes a long time to resolve "localhost".
I'll try to bump the timeouts.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13453] Tests and network timeouts

[Antoine Pitrou]

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 use a single connection, and when a timeout
occurs in a test, subsequent tests will all fail with this error...

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13453] Tests and network timeouts

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Jesus is the OpenIndiana buildbots' administrator.

--
nosy: +jcea

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13453] Tests and network timeouts

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 2228d985fdcc by Charles-François Natali in branch '2.7':
Issue #13453: Try to increase some socket timeouts to make some buildbots stop
http://hg.python.org/cpython/rev/2228d985fdcc

New changeset d7daf98c068e by Charles-François Natali in branch '3.2':
Issue #13453: Try to increase some socket timeouts to make some buildbots stop
http://hg.python.org/cpython/rev/d7daf98c068e

New changeset 307d698c3ece by Charles-François Natali in branch 'default':
Issue #13453: Try to increase some socket timeouts to make some buildbots stop
http://hg.python.org/cpython/rev/307d698c3ece

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13612] xml.etree.ElementTree says unknown encoding of a regular encoding

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +flox, haypo
versions: +Python 3.2, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13583] sqlite3.Row doesn't support slice indexes

[Antoine Pitrou]

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 1 of ‘PySlice_GetIndicesEx’ from incompatible pointer type

- you can use assertEqual to avoid defining the error message yourself

--
nosy: +pitrou
stage:  -> patch review
versions:  -Python 2.7, Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5424] Packed IPaddr conversion tests should be extended

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 71e5a083f9b1 by Antoine Pitrou in branch '3.2':
Issue #5424: add tests for inet_ntoa, inet_ntop, inet_aton and inet_pton.
http://hg.python.org/cpython/rev/71e5a083f9b1

New changeset a3d5f522065f by Antoine Pitrou in branch 'default':
Issue #5424: add tests for inet_ntoa, inet_ntop, inet_aton and inet_pton.
http://hg.python.org/cpython/rev/a3d5f522065f

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5424] Packed IPaddr conversion tests should be extended

[Antoine Pitrou]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6743] Add function compatible with print to pprint module

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13627] Python SSL stack doesn't support Elliptic Curve ciphers

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 8b729d65cfd2 by Antoine Pitrou in branch 'default':
Issue #13627: Add support for SSL Elliptic Curve-based Diffie-Hellman
http://hg.python.org/cpython/rev/8b729d65cfd2

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13627] Python SSL stack doesn't support Elliptic Curve ciphers

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Patch now committed in 3.3.

--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13637] binascii.a2b_* functions could accept unicode strings

[Antoine Pitrou]

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 not support the buffer interface

But they could just as well accept ASCII-only unicode strings. Also, with PEP 
393, accessing the 8-bit ASCII data doesn't even need a conversion.

--
components: Library (Lib)
messages: 149876
nosy: haypo, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: binascii.a2b_* functions could accept unicode strings
type: enhancement
versions: Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13638] PyErr_SetFromErrnoWithFilenameObject is undocumented

[Antoine Pitrou]

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
stage: needs patch
status: open
title: PyErr_SetFromErrnoWithFilenameObject is undocumented
versions: Python 3.2, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11638] python setup.py sdist --formats tar* crashes if version is unicode

[Jason R. Coombs]

Jason R. Coombs  added the comment:

I meant to paste the repro with distutils.core:

python -c "from distutils.core import setup; setup(name=u'foo')" sdist 
--formats gztar

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11638] python setup.py sdist --formats tar* crashes if version is unicode

[Jason R. Coombs]

Jason R. Coombs  added the comment:

This error is also encountered if the package name is unicode. The error can be 
simply reproduced with this command:

python -c "from setuptools import setup; setup(name=u'foo')" sdist --formats 
gztar

The error also occurs with the bdist command, and probably others.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13626] Python SSL stack doesn't support DH ciphers

[Antoine Pitrou]

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.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13630] IDLE: Find(ed) text is not highlighted while dialog box is open

[Roger Serwy]

Roger Serwy  added the comment:

IDLE does have a color scheme configuration for "found" as listed in the 
highlighting config dialog and internally as the Tkinter Text tag "hit". This 
looks like the stubs for functionality that never got implemented.

Take a look at the SearchBar IDLE extension. It provides incremental searching 
which highlights all matches.

--
nosy: +serwy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13616] Never ending loop in in update_refs Modules/gcmodule.c

[David Butler]

David Butler  added the comment:

sorry for the delay, I had to wait until the problem occurred again...

I gdb'ed into the process again, the backtrace is a little different this 
time...

(gdb) bt
#0  0xb76adfc6 in update_refs (containers=) at 
Modules/gcmodule.c:292
#1  collect (generation=2) at Modules/gcmodule.c:873
#2  0xb76ae5e3 in collect_generations () at Modules/gcmodule.c:996
#3  _PyObject_GC_Malloc (basicsize=16) at Modules/gcmodule.c:1457
#4  0xb76ae684 in _PyObject_GC_New (tp=0xb76f6aa0) at Modules/gcmodule.c:1467
#5  0xb761a8bd in list_iter (seq=
[((None, u'to'), u'aves.rule'), ((None, u'rel'), u'ManyToOneRel'), ((None, 
u'name'), u'rule')]) at Objects/listobject.c:2873
#6  0xb75eef45 in PyObject_GetIter (o=
[((None, u'to'), u'aves.rule'), ((None, u'rel'), u'ManyToOneRel'), ((None, 
u'name'), u'rule')]) at Objects/abstract.c:3083
#7  0xb7680f35 in PyEval_EvalFrameEx (f=
Frame 0x9bcc0c4, for file /usr/lib/python2.7/xml/dom/pulldom.py, line 88, 
in startElementNS (self=, _ns_contexts=[{'http://www.w3.org/XML/1998/namespace': 'xml'}], 
pending_events=None, _current_context={...}, 
elementStack=[, _elem_info={}, doctype=None, 
_id_search_stack=None, childNodes=, _id_cache={}) 
at remote 0xa2fac4c>, , nodeName=u'django-objects', 
nextSibling=None, parentNode=<...>, namespaceURI=None, prefix=None, 
_attrsNS={(None, u'version'): , nodeName=u'version', 
ownerElement=<...>, value=u'1.0', namespaceURI=None, prefix=None, 
nodeValue=u'1.0', childNodes=, name=u'version') 
at remote 0xa2facac>}, tagName=u'django-objects', childNodes=, _attrs={u'version': <...>}) at remote 0xa2faa8c>, 
, nodeName=u'object', n
 amespaceURI=None, prefix=None,...(truncated), throwflag=0) at 
Python/ceval.c:2483
#8  0xb768189a in fast_function (nk=, na=, 
n=, 
pp_stack=, func=) at Python/ceval.c:4099
#9  call_function (oparg=, pp_stack=) at 
Python/ceval.c:4034
#10 PyEval_EvalFrameEx (f=
Frame 0x9ed8f74, for file /usr/lib/python2.7/xml/sax/expatreader.py, line 
338, in start_element_ns (self=, _external_ges=1, 
_source=, _decl_handler_prop=None, 
_bufsize=65516, _cont_handler=, _ns_contexts=[{'http://www.w3.org/XML/1998/namespace': 
'xml'}], pending_events=None, _current_context={...}, 
elementStack=[, _elem_info={}, doctype=None, 
_id_search_stack=None, childNodes=, _id_cache={}) 
at remote 0xa2fac4c>, , nodeName=u'django-objects', 
nextSibling=None, parentNode=<...>, namespaceURI=None, prefix=None, 
_attrsNS={(None, u'version'): , nodeName=u've
 rsion', ownerElement=<...>, va...(truncated), throwflag=0) at 
Python/ceval.c:2666
#11 0xb7683508 in PyEval_EvalCodeEx (co=0x9dd6c80, globals=
{'SAXNotRecognizedException': , 'expat': , '__name__': 'xml.sax.expatreader', 
'feature_namespace_prefixes': 'http://xml.org/sax/features/namespace-prefixes', 
'AttributesNSImpl': , 'feature_string_interning': 
'http://xml.org/sax/features/string-interning', '__package__': 'xml.sax', 
'versi---Type  to continue, or q  to quit---step
on': '0.20', 'AttributesImpl': , 
'feature_namespaces': 'http://xml.org/sax/features/namespaces', '__doc__': 
"\nSAX driver for the pyexpat C module.  This driver works 
with\npyexpat.__version__ == '2.22'.\n", 'feature_validation': 
'http://xml.org/sax/features/validation', 'create_parser': , '__builtins__': {'bytearray': , 
'IndexError': , 'all': , 
'help': <_Helper at remote 0xb73643ac>, 'vars': , 
'SyntaxError': , 'unicode': , 'UnicodeD...(truncated), locals=0x0, args=0x9d94510, argcount=3, 
kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0) at Python/ceval.c:3253
#12 0xb7614f2a in function_call (func=, arg=
(, _external_ges=1, _source=, _decl_handler_prop=None, _bufsize=65516, 
_cont_handler=, _ns_contexts=[{'http://www.w3.org/XML/1998/namespace': 'xml'}], 
pending_events=None, _current_context={...}, 
elementStack=[, _elem_info={}, doctype=None, 
_id_search_stack=None, childNodes=, _id_cache={}) 
at remote 0xa2fac4c>, , nodeName=u'django-objects', 
nextSibling=None, parentNode=<...>, namespaceURI=None, prefix=None, 
_attrsNS={(None, u'version'): , nodeName=u'version', 
ownerElement=<...>, value=u'1.0', namespaceURI=None, prefix=None, 
nodeValue=u'1.0', childNodes=<
 NodeList at remote 0xa2faccc>,...(truncated), kw=0x0) at 
Objects/funcobject.c:526

--- truncated ---

(gdb) b collect
Breakpoint 1 at 0xb76ade3c: file Modules/gcmodule.c, line 822.
(gdb) cont
Continuing.

( here i let it run for a about a minute )

^C
Program received signal SIGINT, Interrupt.
0xb76adfcb in update_refs (containers=) at Modules/gcmodule.c:290
290 in Modules/gcmodule.c
(gdb) print gc
$1 = (PyGC_Head *) 0xb770df00
(gdb) step
292 in Modules/gcmodule.c
(gdb) info locals
gc = 0xb770df00
(gdb) step
290 in Modules/gcmodule.c
(gdb) info locals
gc = 0xb770df00

I was going to leave the process running, and the debugger up, but I forgot 
that a reboot script was still enabled, and it caused the machine to reboot... 
so i am recompiling python with CFLAGS="-O0 ..." to try to fix some "value 

[issue8684] improvements to sched.py

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 50267d2bb320 by Giampaolo Rodola' in branch 'default':
(bug #8684) fix 'fedora without thread buildbot' as per 
http://bugs.python.org/issue8684
http://hg.python.org/cpython/rev/50267d2bb320

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8684] improvements to sched.py

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

This should now be fixed. Thanks for signaling.

--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13620] Support Chrome in webbrowser.py

[Arnaud Calmettes]

Arnaud Calmettes  added the comment:

Hi.
The patch works fine on my box with Chromium 16 under Archlinux.

However, I think it might not work under Ubuntu or Debian, since the program is 
named "chromium-browser" on these distros, and it is missing from the list of 
tested browser. I am setting up an Ubuntu box to test and confirm this.

--
nosy: +arnaudc

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13051] Infinite recursion in curses.textpad.Textbox

[Ned Deily]

Changes by Ned Deily :


--
nosy: +haypo
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13620] Support Chrome in webbrowser.py

[Oleg Broytman]

Changes by Oleg Broytman :


Removed file: http://bugs.python.org/file23986/webbrowser.py.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13620] Support Chrome in webbrowser.py

[Oleg Broytman]

Oleg Broytman  added the comment:

I updated the patch. Thank you for reviewing!

--
keywords: +patch
Added file: http://bugs.python.org/file24055/webbrowser.py.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13601] sys.stderr should be unbuffered (or always line-buffered)

[Geoffrey Bache]

Geoffrey Bache  added the comment:

> I'm hesitant to make it line-buffered by default when directed to a 
> file, since this could significantly slow down a program that for some
> reason produces super-voluminous output (e.g. when running a program
> with heavy debug logging turned on).

Is that really the purpose of standard error though? Heavy debug output, in my 
experience, is usually sent to standard output or to another file.

Also, did anyone ever complain about this as a problem, given it is the default 
behaviour of Python 2?

In my view the requirements of seeing errors when they happen, and guaranteeing 
that they will always be seen no matter what happens afterwards, should weigh 
more heavily than this.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13597] Improve documentation of stdout/stderr buffering in Python 3.x

[Geoffrey Bache]

Geoffrey Bache  added the comment:

The changes are good as far as they go, but they only affect the documentation 
of sys.stderr and sys.stdout. 

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?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13601] sys.stderr should always be line-buffered

[Geoffrey Bache]

Geoffrey Bache  added the comment:

I think we all agree line-buffering is sufficient, so I change the title.

--
title: sys.stderr should be unbuffered (or always line-buffered) -> sys.stderr 
should always be line-buffered

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13620] Support Chrome in webbrowser.py

[Arnaud Calmettes]

Arnaud Calmettes  added the comment:

The new patch works under Ubuntu but not not under Archlinux anymore (where the 
program is named "chromium").
 
Here is a patch that works with python 3.3 under both distributions.

--
Added file: http://bugs.python.org/file24056/webbrowser.py-2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13620] Support Chrome in webbrowser.py

[Oleg Broytman]

Changes by Oleg Broytman :


Removed file: http://bugs.python.org/file24055/webbrowser.py.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13620] Support Chrome in webbrowser.py

[Oleg Broytman]

Oleg Broytman  added the comment:

I'm fine with that version.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13051] Infinite recursion in curses.textpad.Textbox

[Brian Curtin]

Brian Curtin  added the comment:

Would you be able to produce a unit test which fails before your patch is 
applied, but succeeds after applying your changes? That'll make your changes 
more likely to get accepted.

--
nosy: +brian.curtin

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13620] Support Chrome in webbrowser.py

[Arnaud Calmettes]

Arnaud Calmettes  added the comment:

Here is a patch against the 3.3 documentation, mentionning the new supported 
browser types.

--
Added file: http://bugs.python.org/file24057/webbrowser_doc.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13405] Add DTrace probes

[Stan Cox]

Stan Cox  added the comment:

systemtap doesn't have have a ustack helper, but if the frame pointer were 
provided to PYTHON_FUNCTION_ENTRY, then it could be cached to provide python 
stack frame access.

--- Python/ceval.c.12011-12-07 11:18:03.733659382 -0500
+++ Python/ceval.c  2011-12-19 18:45:54.601309213 -0500
@@ -796,3 +796,3 @@
lineno = PyCode_Addr2Line(f->f_code, f->f_lasti);
-   PYTHON_FUNCTION_ENTRY(filename, name, lineno);
+   PYTHON_FUNCTION_ENTRY(filename, name, lineno, f);

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13616] Never ending loop in in update_refs Modules/gcmodule.c

[Jesús Cea Avión]

Jesús Cea Avión  added the comment:

It seems to be a real infinite loop. Bad thing. Could be a bug in an extension, 
difficult to say.

This is going to be VERY difficult to debug without a reproductible case we can 
try.

Could you possibly check the object type of the "infinite loop" object?. If the 
loop is from an object to itself, maybe you can instrumentalize python to 
detect this loop when created.

Add to your code "gc.collect()" is a frequent loop. It is going to suck CPU, 
but could reproduce the issue faster and make it easier to diagnose.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13639] UnicodeDecodeError when creating tar.gz with unicode name

[Jason R. Coombs]

New submission from Jason R. Coombs :

python -c "import tarfile; tarfile.open(u'hello.tar.gz', 'w|gz')"

produces

Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Users\jaraco\projects\public\cpython\Lib\tarfile.py", line 1687, in 
open
_Stream(name, filemode, comptype, fileobj, bufsize),
  File "C:\Users\jaraco\projects\public\cpython\Lib\tarfile.py", line 431, in 
__init__
self._init_write_gz()
  File "C:\Users\jaraco\projects\public\cpython\Lib\tarfile.py", line 459, in 
_init_write_gz
self.__write(self.name + NUL)
  File "C:\Users\jaraco\projects\public\cpython\Lib\tarfile.py", line 475, in 
__write
self.buf += s
UnicodeDecodeError: 'ascii' codec can't decode byte 0x8b in position 1: ordinal 
not in range(128)


Remove the compression ('|gz') or remove the unicode name or run under Python 3 
and the command completes without error.

The error does not occur under Python 3 (even with non-ascii characters), so it 
should be possible to create a tarfile with a unicode filename on Python 2.7.

This failure is the underlying cause of #11638.

--
messages: 149896
nosy: jason.coombs
priority: normal
severity: normal
status: open
title: UnicodeDecodeError when creating tar.gz with unicode name
versions: Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11638] python setup.py sdist --formats tar* crashes if version is unicode

[Jason R. Coombs]

Jason R. Coombs  added the comment:

I believe the underlying cause of this issue is #13639.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13634] Python SSL stack doesn't support Compression configuration

[Jesús Cea Avión]

Changes by Jesús Cea Avión :


--
nosy: +jcea

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13635] Python SSL stack doesn't support ordering of Ciphers

[Jesús Cea Avión]

Changes by Jesús Cea Avión :


--
nosy: +jcea

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13636] Python SSL Stack doesn't have a Secure Default set of ciphers

[Jesús Cea Avión]

Changes by Jesús Cea Avión :


--
nosy: +jcea

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13640] add mimetype for application/vnd.apple.mpegurl

[Hiroaki Kawai]

New submission from Hiroaki Kawai :

Add application/vnd.apple.mpegurl, which is used by smartphones recently.
It is registered in IANA : 
http://www.iana.org/assignments/media-types/application/vnd.apple.mpegurl

An application is described in 
http://tools.ietf.org/html/draft-pantos-http-live-streaming-07

--
components: Library (Lib)
files: mimetypes.patch
keywords: patch
messages: 149898
nosy: Hiroaki.Kawai
priority: normal
severity: normal
status: open
title: add mimetype for application/vnd.apple.mpegurl
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file24058/mimetypes.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11638] python setup.py sdist --formats tar* crashes if version is unicode

[Jason R. Coombs]

Jason R. Coombs  added the comment:

I've created a repo to continue this work. I've integrated David's patch 
(thanks).

It's not obvious to me what the encoding should be. Python and the tarfile 
module can accept unicode filenames. It seems that only the gzip part of 
tarfile fails if a unicode name is passed. Encoding to 'utf-8' or the default 
file system encoding doesn't seem right (as the characters end up getting 
stored in the gzip archive itself). Additionally, encoding as 'utf-8' would 
cause the file to be created with a utf-8 filename, which would be undesirable.

So in the current repo, I've created a check to convert the filename to ASCII. 
If it can be converted to ASCII, it is converted and passed through to tarfile. 
This should address the majority of users who have thus encountered this issue. 
For those who wish to use non-ascii characters in project names or versions, 
one will have to use Python 3 or wait until #13639 is fixed.

Please review the enclosed patch.

Since one test fails (and is known to fail), should it omitted? Can it remain 
but be marked as "expected to fail"?

--
hgrepos: +96

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11638] python setup.py sdist --formats tar* crashes if version is unicode

[Jason R. Coombs]

Changes by Jason R. Coombs :


Added file: http://bugs.python.org/file24059/9e9ea96eb0dd.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13616] Never ending loop in in update_refs Modules/gcmodule.c

[David Butler]

David Butler  added the comment:

2011/12/19 Jesús Cea Avión 

I am willing to work toward a simplified test case, but its going to be
difficult, I am hoping that I can narrow down the source of the problem...

Forgive me, I'm gdb is actually a new thing to me... how could I check the
object type?
Also what do you mean exactly when you say "instrumentalize"

I started some valgrind testing today, (to try to figure out whats causing
some segfaults in a possibly unrelated bug, will this interfere with
testing for this bug?)

> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13616] Never ending loop in in update_refs Modules/gcmodule.c

[Jesús Cea Avión]

Jesús Cea Avión  added the comment:

Instrumentalize: check for this pathological case (an object with a GC pointer 
back to itself) in the code that modify the GC pointers. Lets say, everytime 
code change the pointers, you test for this. Luckily you can learn the codepath 
creating this situation. Change and recompile python code for checking this.

Read Include/object.h. You will see that ANY python object has, at least, two 
components: a reference counter and a pointer to its type. Follow that pointer 
to type and get its name.

Let me try an example...

"""
gdb python
GNU gdb (GDB) 7.3.1
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-pc-solaris2.10".
For bug reporting instructions, please see:
...
Reading symbols from /usr/local/bin/python...done.
(gdb) br PyTuple_New
Function "PyTuple_New" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (PyTuple_New) pending.
(gdb) r
Starting program: /usr/local/bin/python 
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]
[Switching to Thread 1 (LWP 1)]

Breakpoint 1, PyTuple_New (size=0) at Objects/tupleobject.c:50
50  Objects/tupleobject.c: No such file or directory.
in Objects/tupleobject.c
(gdb) fin
Run till exit from #0  PyTuple_New (size=0) at Objects/tupleobject.c:50
0xfee650e4 in PyType_Ready (type=0xfef5cd00) at Objects/typeobject.c:4077
4077Objects/typeobject.c: No such file or directory.
in Objects/typeobject.c
Value returned is $1 = (PyObject *) 0x806202c
(gdb) print $1->ob_type
$2 = (struct _typeobject *) 0xfef5cb40
(gdb) print *($1->ob_type)
$3 = {ob_refcnt = 1, ob_type = 0xfef5cde0, ob_size = 0, tp_name = 0xfef07542 
"tuple", tp_basicsize = 12, tp_itemsize = 4, 
  tp_dealloc = 0xfee568f0 , tp_print = 0xfee56c80 , 
tp_getattr = 0, tp_setattr = 0, tp_compare = 0, 
  tp_repr = 0xfee57380 , tp_as_number = 0x0, tp_as_sequence = 
0xfef52500, tp_as_mapping = 0xfef52528, 
  tp_hash = 0xfee56850 , tp_call = 0, tp_str = 0, tp_getattro = 
0xfee416d0 , tp_setattro = 0, 
  tp_as_buffer = 0x0, tp_flags = 67519979, 
  tp_doc = 0xfef3b580 "tuple() -> empty tuple\ntuple(iterable) -> tuple 
initialized from iterable's items\n\nIf the argument is a tuple, the return 
value is the same object.", tp_traverse = 0xfee56440 , tp_clear 
= 0, 
  tp_richcompare = 0xfee56b10 , tp_weaklistoffset = 0, 
tp_iter = 0xfee56a60 , tp_iternext = 0, 
  tp_methods = 0xfef52540, tp_members = 0x0, tp_getset = 0x0, tp_base = 0x0, 
tp_dict = 0x0, tp_descr_get = 0, tp_descr_set = 0, 
  tp_dictoffset = 0, tp_init = 0, tp_alloc = 0, tp_new = 0xfee57680 
, tp_free = 0xfeede6a0 , 
  tp_is_gc = 0, tp_bases = 0x0, tp_mro = 0x0, tp_cache = 0x0, tp_subclasses = 
0x0, tp_weaklist = 0x0, tp_del = 0, 
  tp_version_tag = 0}
"""

I break in the tuple creation routine. Then I let it finish. It is going to 
return a PyObject, a generic python object. I follow the type pointer and get 
the name of the type: 'tp_name = 0xfef07542 "tuple"'. I already knew the result 
was going to be a tuple, but it is nice to cross-check :)

Sometimes it is more complicated, and you have to cast pointers. Use the source 
code as your map.

Sorry, it is difficult to teach how to do such a low level debug remotely :).

PS: Remember to add "gc.collect()" in your mainloop. In this way you will hit 
the problem faster, because you don't have to wait for Python to invoke the 
collector implicitly. If you have tons of objects this can be actually slower. 
Try.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13616] Never ending loop in in update_refs Modules/gcmodule.c

[Jesús Cea Avión]

Jesús Cea Avión  added the comment:

David, if you get desperate, let us know. If you can deal with Mercurial and 
compiling Python code, I could post a mercurial repository/branch with code 
modifications to help you to debug this.

But it is almost Christmas and I am VERY busy and have to do a few long 
distance trips yet, so that better be the last option. First try to advance a 
bit yourself. At least you will learn a lot.

But don't let this bug to languish...

If you can manage to reproduce the issue more easily, that would be VERY 
useful. Tell us too what external modules are you using.

Good luck.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

[Duncan Findlay]

Duncan Findlay  added the comment:

I've been digging into this quite a bit, and I've been able to dig up a little 
more info.

* In Python 2.1, the behavior was very similar to what we have now -- signals 
were not blocked. http://bugs.python.org/issue465673 was filed reporting issues 
with readline on Solaris. The issue was basically that readline used 
setjmp/longjmp to handle the SIGINT, and the exception handler was being 
executed by the wrong thread. The fix that was implemented (for Python 2.2b1) 
was to block threads except to the main thread. There was some discussion at 
the time about this being the "proper" way according to POSIX. 
(http://groups.google.com/group/comp.lang.python/browse_frm/thread/61da54186fbeebf9)

* Python 2.2 and 2.3 had the opposite of the current behavior (i.e. all signals 
were blocked in threads). Several bugs were reported. Most of the problems 
seemed to be about blocked synchronous signals (e.g. SIGSEGV) leading to bad 
things, and the unkillable subprocesses caused when you fork/exec with signals 
block.
  - http://bugs.python.org/issue756924
  - http://bugs.python.org/issue949332
  - http://mail.python.org/pipermail/python-dev/2003-December/041138.html

  * The patch to fix these bugs was submitted as 
http://bugs.python.org/issue960406. Unfortunately, it was not well described 
and so the links to the above issues were not clear. The discussion in the 
tracker for 960406 revolves mostly around readline, and for good reason -- 
reverting to the 2.1 behavior required a fix to readline so as to not regress. 
Unfortunately,  I believe the main impetus behind the patch was to fix the 
handling of synchronous signals and unkillable subprocesses. It was implemented 
in Python 2.4.

* Since Python 2.4, everything's been working fine on Linux, because Linux will 
send signals to the main thread, only. Unfortunately, the problem remains that 
the signals in FreeBSD are generally handled by the user thread instead. This 
causes two problems.

  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. This means that indefinite selects are not possible if we want 
to handle signals, and, perhaps more perversely, signal.pause() cannot be 
reliably used in the main thread.

  * Current attempts to fix this in the FreeBSD ports revert to the pre-2.4 
behavior of blocking all signals. This leads to the same unkillable 
subprocesses and (presumably) issues with synchronous signals.

  * Attempts to fix this properly in Python are stalled because we've rightly 
detected that we're just oscillating between two behaviors, both having issues, 
and nobody has proposed a suitable middle ground.


I think I've found a suitable solution, that should resolve all of the issues:

* Block all *asynchronous* signals in user threads. The synchronous threads, 
such as SIGSEGV should not be blocked. (This was actually the original fix 
proposed for http://bugs.python.org/issue949332)

* Unblock all signals after a fork() in a thread, since the thread is now the 
main thread. This will solve the unkillable subprocesses.

* Readline should not be impacted by this change. The readline functionality 
was replaced as part of the 2.4 patch to not install readline's signal 
handlers, unless you're using a really old version of readline, *and* the 
original readline problems were only present when signals were unblocked, but 
we're going to start blocking them.

* As bamby points out in his first post here, this is unlikely to change the 
behavior of much code. Anything portable should work, it will now just be more 
predictable. I suppose if you were developing for FreeBSD (specifically for a 
stock unmodified Python compiled from source, not the version distributed 
through ports), this change could subtly change the behavior of an application. 
For most FreeBSD developers (i.e. the ones using ports), this change should 
simply result in killable subprocesses.


I will put together a patch, though I would like to see some consensus around 
this approach before I spend too much (more) time on this.

Thanks.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

[Antoine Pitrou]

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. This means that indefinite selects are not possible if we 
> want to handle signals, and, perhaps more perversely, signal.pause() cannot 
> be reliably used in the main thread.

Well, I agree it makes matters more complicated, but if FreeBSD decides this 
behaviour is desireable, why would Python try to work around it?
To solve the select() problem you can have the signal handler write on a pipe 
(using signal.set_wakeup_fd (*)) and the select() call wait on that pipe. This 
also should allow to emulate signal.pause() (basically a select() with only the 
signal pipe).

IMHO, the general idea of Unix signals is a low-level kludge and any attempt to 
make it sane at the Python level is probably doomed to failure. Other 
synchronization methods should always be preferred, if possible.

(*) Linux has signalfd, but we don't expose it yet

--
nosy: +haypo, neologix
versions: +Python 3.3 -Python 2.6, Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com