[ python-Bugs-1583946 ] SSL "issuer" and "server" functions problems - security
Bugs item #1583946, was opened at 2006-10-24 20:32
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: John Nagle (nagle)
Assigned to: Nobody/Anonymous (nobody)
Summary: SSL "issuer" and "server" functions problems - security
Initial Comment:
(Python 2.5 library)
The Python SSL object offers two methods from
obtaining the info from an SSL certificate, "server()"
and "issuer()". These return strings.
The actual values in the certificate are a series
of key /value pairs in ASN.1 binary format. But what
"server()" and "issuer()" return are single strings,
with the key/value pairs separated by "/".
However, "/" is a valid character in certificate
data. So parsing such strings is ambiguous, and
potentially exploitable.
This is more than a theoretical problem. The
issuer field of Verisign certificates has a "/" in the
middle of a text field:
"/O=VeriSign Trust Network/OU=VeriSign,
Inc./OU=VeriSign International Server CA - Class
3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY
LTD.(c)97 VeriSign".
Note the
"OU=Terms of use at www.verisign.com/rpa (c)00"
with a "/" in the middle of the value field. Oops.
Worse, this is potentially exploitable. By
ordering a low-level certificate with a "/" in the
right place, you can create the illusion (at least for
flawed implementations like this one) that the
certificate belongs to someone else. Just order a
certificate from GoDaddy, enter something like this in
the "Name" field
"Myphonyname/C=US/ST=California/L=San Jose/O=eBay
Inc./OU=Site Operations/CN=signin.ebay.com"
and Python code will be spoofed into thinking you're eBay.
Fortunately, browsers don't use Python code.
The actual bug is in
python/trunk/Modules/_ssl.c
at
if ((self->server_cert =
SSL_get_peer_certificate(self->ssl))) {
X509_NAME_oneline(X509_get_subject_name(self->server_cert),
self->server, X509_NAME_MAXLEN);
X509_NAME_oneline(X509_get_issuer_name(self->server_cert),
self->issuer, X509_NAME_MAXLEN);
The "X509_name_oneline" function takes an X509_NAME
structure, which is the certificate system's
representation of a list, and flattens it into a
printable string. This is a debug function, not one
for use in production code. The SSL documentation for
"X509_name_oneline" says:
"The functions X509_NAME_oneline() and
X509_NAME_print() are legacy functions which produce a
non standard output form, they don't handle multi
character fields and have various quirks and
inconsistencies. Their use is strongly discouraged in
new applications."
What OpenSSL callers are supposed to do is call
X509_NAME_entry_count() to get the number of entries in
an X509_NAME structure, then get each entry with
X509_NAME_get_entry(). A few more calls will obtain
the name/value pair from the entry, as UTF8 strings,
which should be converted to Python UNICODE strings.
OpenSSL has all the proper support, but Python's shim
doesn't interface to it correctly.
X509_NAME_oneline() doesn't handle Unicode; it converts
non-ASCII values to "\xnn" format. Again, it's for
debug output only.
So what's needed are two new functions for Python's SSL
sockets to replace "issuer" and "server". The new
functions should return lists of Unicode strings
representing the key/value pairs. (A list is needed,
not a dictionary; two strings with the same key
are both possible and common.)
The reason this now matters is that new "high
assurance" certs, the ones that tell you how much a
site can be trusted, are now being deployed, and to use
them effectively, you need that info. Support for them
is in Internet Explorer 7, so they're going to be
widespread soon. Python needs to catch up.
And, of course, this needs to be fixed as part of
Unicode support.
John Nagle
Animats
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-10-25 10:38
Message:
Logged In: YES
user_id=21627
The bug is not in the the server() and issuer() methods
(which do exactly what they are meant to do); the bug is in
applications which assume that the result of these methods
can be parsed. As you point out, it cannot. The functions,
as is, don't present a security problem. If their result is
presented as-is to the user, the user can determine herself
whether she recognizes the entity referred-to in the
distinguished name.
Notice that it is certainly possible to produce an
unambigous string representation of a distinguished name;
RFC 4514 specifies an algorithm to do so (fo
[ python-Bugs-1583946 ] SSL "issuer" and "server" names cannot be parsed
Bugs item #1583946, was opened at 2006-10-24 20:32
Message generated for change (Settings changed) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Nagle (nagle)
Assigned to: Nobody/Anonymous (nobody)
>Summary: SSL "issuer" and "server" names cannot be parsed
Initial Comment:
(Python 2.5 library)
The Python SSL object offers two methods from
obtaining the info from an SSL certificate, "server()"
and "issuer()". These return strings.
The actual values in the certificate are a series
of key /value pairs in ASN.1 binary format. But what
"server()" and "issuer()" return are single strings,
with the key/value pairs separated by "/".
However, "/" is a valid character in certificate
data. So parsing such strings is ambiguous, and
potentially exploitable.
This is more than a theoretical problem. The
issuer field of Verisign certificates has a "/" in the
middle of a text field:
"/O=VeriSign Trust Network/OU=VeriSign,
Inc./OU=VeriSign International Server CA - Class
3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY
LTD.(c)97 VeriSign".
Note the
"OU=Terms of use at www.verisign.com/rpa (c)00"
with a "/" in the middle of the value field. Oops.
Worse, this is potentially exploitable. By
ordering a low-level certificate with a "/" in the
right place, you can create the illusion (at least for
flawed implementations like this one) that the
certificate belongs to someone else. Just order a
certificate from GoDaddy, enter something like this in
the "Name" field
"Myphonyname/C=US/ST=California/L=San Jose/O=eBay
Inc./OU=Site Operations/CN=signin.ebay.com"
and Python code will be spoofed into thinking you're eBay.
Fortunately, browsers don't use Python code.
The actual bug is in
python/trunk/Modules/_ssl.c
at
if ((self->server_cert =
SSL_get_peer_certificate(self->ssl))) {
X509_NAME_oneline(X509_get_subject_name(self->server_cert),
self->server, X509_NAME_MAXLEN);
X509_NAME_oneline(X509_get_issuer_name(self->server_cert),
self->issuer, X509_NAME_MAXLEN);
The "X509_name_oneline" function takes an X509_NAME
structure, which is the certificate system's
representation of a list, and flattens it into a
printable string. This is a debug function, not one
for use in production code. The SSL documentation for
"X509_name_oneline" says:
"The functions X509_NAME_oneline() and
X509_NAME_print() are legacy functions which produce a
non standard output form, they don't handle multi
character fields and have various quirks and
inconsistencies. Their use is strongly discouraged in
new applications."
What OpenSSL callers are supposed to do is call
X509_NAME_entry_count() to get the number of entries in
an X509_NAME structure, then get each entry with
X509_NAME_get_entry(). A few more calls will obtain
the name/value pair from the entry, as UTF8 strings,
which should be converted to Python UNICODE strings.
OpenSSL has all the proper support, but Python's shim
doesn't interface to it correctly.
X509_NAME_oneline() doesn't handle Unicode; it converts
non-ASCII values to "\xnn" format. Again, it's for
debug output only.
So what's needed are two new functions for Python's SSL
sockets to replace "issuer" and "server". The new
functions should return lists of Unicode strings
representing the key/value pairs. (A list is needed,
not a dictionary; two strings with the same key
are both possible and common.)
The reason this now matters is that new "high
assurance" certs, the ones that tell you how much a
site can be trusted, are now being deployed, and to use
them effectively, you need that info. Support for them
is in Internet Explorer 7, so they're going to be
widespread soon. Python needs to catch up.
And, of course, this needs to be fixed as part of
Unicode support.
John Nagle
Animats
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-10-25 10:38
Message:
Logged In: YES
user_id=21627
The bug is not in the the server() and issuer() methods
(which do exactly what they are meant to do); the bug is in
applications which assume that the result of these methods
can be parsed. As you point out, it cannot. The functions,
as is, don't present a security problem. If their result is
presented as-is to the user, the user can determine herself
whether she recognizes the entity referred-to in the
distinguished name.
Notice that it is certainly possible to produce an
unambigous string representation of a distinguished name;
RFC 4514 specifies an algorithm to do so (for use
[ python-Bugs-1583946 ] SSL "issuer" and "server" functions problems - security
Bugs item #1583946, was opened at 2006-10-24 20:32
Message generated for change (Settings changed) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
>Priority: 5
Private: No
Submitted By: John Nagle (nagle)
Assigned to: Nobody/Anonymous (nobody)
Summary: SSL "issuer" and "server" functions problems - security
Initial Comment:
(Python 2.5 library)
The Python SSL object offers two methods from
obtaining the info from an SSL certificate, "server()"
and "issuer()". These return strings.
The actual values in the certificate are a series
of key /value pairs in ASN.1 binary format. But what
"server()" and "issuer()" return are single strings,
with the key/value pairs separated by "/".
However, "/" is a valid character in certificate
data. So parsing such strings is ambiguous, and
potentially exploitable.
This is more than a theoretical problem. The
issuer field of Verisign certificates has a "/" in the
middle of a text field:
"/O=VeriSign Trust Network/OU=VeriSign,
Inc./OU=VeriSign International Server CA - Class
3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY
LTD.(c)97 VeriSign".
Note the
"OU=Terms of use at www.verisign.com/rpa (c)00"
with a "/" in the middle of the value field. Oops.
Worse, this is potentially exploitable. By
ordering a low-level certificate with a "/" in the
right place, you can create the illusion (at least for
flawed implementations like this one) that the
certificate belongs to someone else. Just order a
certificate from GoDaddy, enter something like this in
the "Name" field
"Myphonyname/C=US/ST=California/L=San Jose/O=eBay
Inc./OU=Site Operations/CN=signin.ebay.com"
and Python code will be spoofed into thinking you're eBay.
Fortunately, browsers don't use Python code.
The actual bug is in
python/trunk/Modules/_ssl.c
at
if ((self->server_cert =
SSL_get_peer_certificate(self->ssl))) {
X509_NAME_oneline(X509_get_subject_name(self->server_cert),
self->server, X509_NAME_MAXLEN);
X509_NAME_oneline(X509_get_issuer_name(self->server_cert),
self->issuer, X509_NAME_MAXLEN);
The "X509_name_oneline" function takes an X509_NAME
structure, which is the certificate system's
representation of a list, and flattens it into a
printable string. This is a debug function, not one
for use in production code. The SSL documentation for
"X509_name_oneline" says:
"The functions X509_NAME_oneline() and
X509_NAME_print() are legacy functions which produce a
non standard output form, they don't handle multi
character fields and have various quirks and
inconsistencies. Their use is strongly discouraged in
new applications."
What OpenSSL callers are supposed to do is call
X509_NAME_entry_count() to get the number of entries in
an X509_NAME structure, then get each entry with
X509_NAME_get_entry(). A few more calls will obtain
the name/value pair from the entry, as UTF8 strings,
which should be converted to Python UNICODE strings.
OpenSSL has all the proper support, but Python's shim
doesn't interface to it correctly.
X509_NAME_oneline() doesn't handle Unicode; it converts
non-ASCII values to "\xnn" format. Again, it's for
debug output only.
So what's needed are two new functions for Python's SSL
sockets to replace "issuer" and "server". The new
functions should return lists of Unicode strings
representing the key/value pairs. (A list is needed,
not a dictionary; two strings with the same key
are both possible and common.)
The reason this now matters is that new "high
assurance" certs, the ones that tell you how much a
site can be trusted, are now being deployed, and to use
them effectively, you need that info. Support for them
is in Internet Explorer 7, so they're going to be
widespread soon. Python needs to catch up.
And, of course, this needs to be fixed as part of
Unicode support.
John Nagle
Animats
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-10-25 10:38
Message:
Logged In: YES
user_id=21627
The bug is not in the the server() and issuer() methods
(which do exactly what they are meant to do); the bug is in
applications which assume that the result of these methods
can be parsed. As you point out, it cannot. The functions,
as is, don't present a security problem. If their result is
presented as-is to the user, the user can determine herself
whether she recognizes the entity referred-to in the
distinguished name.
Notice that it is certainly possible to produce an
unambigous string representation of a distinguished name;
RFC 4514 specifies an algorithm to do so
[ python-Bugs-1582742 ] Python is dumping core after the test test_ctypes
Bugs item #1582742, was opened at 2006-10-23 11:42 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582742&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: shashi (shashikala) Assigned to: Nobody/Anonymous (nobody) Summary: Python is dumping core after the test test_ctypes Initial Comment: Hi , Iam building Python-2.5 on HPUX Itanium. The compilation is done without any error, but while testing the same using gmake test it is dumping core telling "Segementation Fault" after the test test_ctypes. Please help me in resolving the above issue.Iam attaching the output of gmake test. Thanks in advance, -- >Comment By: Martin v. Löwis (loewis) Date: 2006-10-25 10:41 Message: Logged In: YES user_id=21627 You will need to run Python in a debugger and find out where it crashes. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582742&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1583946 ] SSL "issuer" and "server" names cannot be parsed
Bugs item #1583946, was opened at 2006-10-24 18:32
Message generated for change (Comment added) made by nagle
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Nagle (nagle)
Assigned to: Nobody/Anonymous (nobody)
Summary: SSL "issuer" and "server" names cannot be parsed
Initial Comment:
(Python 2.5 library)
The Python SSL object offers two methods from
obtaining the info from an SSL certificate, "server()"
and "issuer()". These return strings.
The actual values in the certificate are a series
of key /value pairs in ASN.1 binary format. But what
"server()" and "issuer()" return are single strings,
with the key/value pairs separated by "/".
However, "/" is a valid character in certificate
data. So parsing such strings is ambiguous, and
potentially exploitable.
This is more than a theoretical problem. The
issuer field of Verisign certificates has a "/" in the
middle of a text field:
"/O=VeriSign Trust Network/OU=VeriSign,
Inc./OU=VeriSign International Server CA - Class
3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY
LTD.(c)97 VeriSign".
Note the
"OU=Terms of use at www.verisign.com/rpa (c)00"
with a "/" in the middle of the value field. Oops.
Worse, this is potentially exploitable. By
ordering a low-level certificate with a "/" in the
right place, you can create the illusion (at least for
flawed implementations like this one) that the
certificate belongs to someone else. Just order a
certificate from GoDaddy, enter something like this in
the "Name" field
"Myphonyname/C=US/ST=California/L=San Jose/O=eBay
Inc./OU=Site Operations/CN=signin.ebay.com"
and Python code will be spoofed into thinking you're eBay.
Fortunately, browsers don't use Python code.
The actual bug is in
python/trunk/Modules/_ssl.c
at
if ((self->server_cert =
SSL_get_peer_certificate(self->ssl))) {
X509_NAME_oneline(X509_get_subject_name(self->server_cert),
self->server, X509_NAME_MAXLEN);
X509_NAME_oneline(X509_get_issuer_name(self->server_cert),
self->issuer, X509_NAME_MAXLEN);
The "X509_name_oneline" function takes an X509_NAME
structure, which is the certificate system's
representation of a list, and flattens it into a
printable string. This is a debug function, not one
for use in production code. The SSL documentation for
"X509_name_oneline" says:
"The functions X509_NAME_oneline() and
X509_NAME_print() are legacy functions which produce a
non standard output form, they don't handle multi
character fields and have various quirks and
inconsistencies. Their use is strongly discouraged in
new applications."
What OpenSSL callers are supposed to do is call
X509_NAME_entry_count() to get the number of entries in
an X509_NAME structure, then get each entry with
X509_NAME_get_entry(). A few more calls will obtain
the name/value pair from the entry, as UTF8 strings,
which should be converted to Python UNICODE strings.
OpenSSL has all the proper support, but Python's shim
doesn't interface to it correctly.
X509_NAME_oneline() doesn't handle Unicode; it converts
non-ASCII values to "\xnn" format. Again, it's for
debug output only.
So what's needed are two new functions for Python's SSL
sockets to replace "issuer" and "server". The new
functions should return lists of Unicode strings
representing the key/value pairs. (A list is needed,
not a dictionary; two strings with the same key
are both possible and common.)
The reason this now matters is that new "high
assurance" certs, the ones that tell you how much a
site can be trusted, are now being deployed, and to use
them effectively, you need that info. Support for them
is in Internet Explorer 7, so they're going to be
widespread soon. Python needs to catch up.
And, of course, this needs to be fixed as part of
Unicode support.
John Nagle
Animats
--
>Comment By: John Nagle (nagle)
Date: 2006-10-25 17:26
Message:
Logged In: YES
user_id=5571
Actually, they don't do what they're "designed to do".
According to the Python library documentation for SSL
objects, the server method "Returns a string containing the
ASN.1 distinguished name identifying the server's
certificate. (See below for an example showing what
distinguished names look like.)" The example "below" is
missing from the documentation, so the documentation gives
us no clue of what to expect.
There are several standardized representations for ASN.1
information. See
"http://www.oss.com/asn1/tutorial/Explain.html"; Most are
binary. The only standard textual form is "
[ python-Bugs-1583946 ] SSL "issuer" and "server" names cannot be parsed
Bugs item #1583946, was opened at 2006-10-24 20:32
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Nagle (nagle)
Assigned to: Nobody/Anonymous (nobody)
Summary: SSL "issuer" and "server" names cannot be parsed
Initial Comment:
(Python 2.5 library)
The Python SSL object offers two methods from
obtaining the info from an SSL certificate, "server()"
and "issuer()". These return strings.
The actual values in the certificate are a series
of key /value pairs in ASN.1 binary format. But what
"server()" and "issuer()" return are single strings,
with the key/value pairs separated by "/".
However, "/" is a valid character in certificate
data. So parsing such strings is ambiguous, and
potentially exploitable.
This is more than a theoretical problem. The
issuer field of Verisign certificates has a "/" in the
middle of a text field:
"/O=VeriSign Trust Network/OU=VeriSign,
Inc./OU=VeriSign International Server CA - Class
3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY
LTD.(c)97 VeriSign".
Note the
"OU=Terms of use at www.verisign.com/rpa (c)00"
with a "/" in the middle of the value field. Oops.
Worse, this is potentially exploitable. By
ordering a low-level certificate with a "/" in the
right place, you can create the illusion (at least for
flawed implementations like this one) that the
certificate belongs to someone else. Just order a
certificate from GoDaddy, enter something like this in
the "Name" field
"Myphonyname/C=US/ST=California/L=San Jose/O=eBay
Inc./OU=Site Operations/CN=signin.ebay.com"
and Python code will be spoofed into thinking you're eBay.
Fortunately, browsers don't use Python code.
The actual bug is in
python/trunk/Modules/_ssl.c
at
if ((self->server_cert =
SSL_get_peer_certificate(self->ssl))) {
X509_NAME_oneline(X509_get_subject_name(self->server_cert),
self->server, X509_NAME_MAXLEN);
X509_NAME_oneline(X509_get_issuer_name(self->server_cert),
self->issuer, X509_NAME_MAXLEN);
The "X509_name_oneline" function takes an X509_NAME
structure, which is the certificate system's
representation of a list, and flattens it into a
printable string. This is a debug function, not one
for use in production code. The SSL documentation for
"X509_name_oneline" says:
"The functions X509_NAME_oneline() and
X509_NAME_print() are legacy functions which produce a
non standard output form, they don't handle multi
character fields and have various quirks and
inconsistencies. Their use is strongly discouraged in
new applications."
What OpenSSL callers are supposed to do is call
X509_NAME_entry_count() to get the number of entries in
an X509_NAME structure, then get each entry with
X509_NAME_get_entry(). A few more calls will obtain
the name/value pair from the entry, as UTF8 strings,
which should be converted to Python UNICODE strings.
OpenSSL has all the proper support, but Python's shim
doesn't interface to it correctly.
X509_NAME_oneline() doesn't handle Unicode; it converts
non-ASCII values to "\xnn" format. Again, it's for
debug output only.
So what's needed are two new functions for Python's SSL
sockets to replace "issuer" and "server". The new
functions should return lists of Unicode strings
representing the key/value pairs. (A list is needed,
not a dictionary; two strings with the same key
are both possible and common.)
The reason this now matters is that new "high
assurance" certs, the ones that tell you how much a
site can be trusted, are now being deployed, and to use
them effectively, you need that info. Support for them
is in Internet Explorer 7, so they're going to be
widespread soon. Python needs to catch up.
And, of course, this needs to be fixed as part of
Unicode support.
John Nagle
Animats
--
>Comment By: Martin v. Löwis (loewis)
Date: 2006-10-25 20:05
Message:
Logged In: YES
user_id=21627
Notice that RFC 2253 has been superceded by RFC 4514 (see my
earlier message). However, I really see no reason to fix this:
even if the ambiguity problems were fixed, you *still*
should not
use the issuer and subject names in a security-relevant context.
--
Comment By: John Nagle (nagle)
Date: 2006-10-25 19:26
Message:
Logged In: YES
user_id=5571
Actually, they don't do what they're "designed to do".
According to the Python library documentation for SSL
objects, the server method "Returns a string containing
[ python-Bugs-1472877 ] Tix: Subwidget names
Bugs item #1472877, was opened at 2006-04-19 10:26
Message generated for change (Comment added) made by mkiever
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472877&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Matthias Kievernagel (mkiever)
Assigned to: Martin v. Löwis (loewis)
Summary: Tix: Subwidget names
Initial Comment:
My system information:
--
uname -a:
Linux linux 2.6.4-52-default #1 Wed Apr 7 02:08:30 UTC
2004 i686 athlon i386 GNU/Linux
Python:
Python 2.4.1 (#4, Jan 10 2006, 10:53:14)
[GCC 3.3.3 (SuSE Linux)] on linux2
and
Python 2.3.5 (#1, Sep 12 2005, 14:56:24)
[GCC 3.3.3 (SuSE Linux)] on linux2
--
Using Tix you can produce the following exception:
---
>>> from Tix import *
>>> tk = Tk ()
>>> b = Balloon ()
>>> b.subwidget ( 'label' )
Traceback (most recent call last):
File "", line 1, in ?
File "/home/mkiever/pro/Python-2.4.1/Lib/lib-tk/Tix.
py", line 340, in subwidget
return self._nametowidget(n)
File "/home/mkiever/pro/Python-2.4.1/Lib/lib-tk/
Tkinter.py", line 1015, in nametowidget
w = w.children[name]
KeyError: 'lab'
>>>
---
I found a commentary in Tix.py:TixWidget:__init__
stating that 'subwidget_list' should contain
Tix names. But in Tix.py:TixSubWidget:__init__
the python names are used, not the names returned
by Tix.
I was successful with the following two
small additions (+++) near lines 400-450:
-
class TixSubWidget(TixWidget):
...
def __init__(self, master, name,
destroy_physically=1,
check_intermediate=1):
...
if (not check_intermediate) or len(plist) < 2:
# immediate descendant
if check_intermediate:+++
name = plist [0] +++
TixWidget.__init__(self, master, None, None,
{'name' : name})
else:
...
name = plist [-1] +++
TixWidget.__init__(self, parent, None, None,
{'name' : name})
self.destroy_physically = destroy_physically
...
-
This replaces the python name by the name
returned from Tix.
I have not extensively tested this (sorry).
Hope this helps.
Matthias Kievernagel ([EMAIL PROTECTED])
--
>Comment By: Matthias Kievernagel (mkiever)
Date: 2006-10-25 20:36
Message:
Logged In: YES
user_id=1477880
Solution was not complete.
Submitted a complete patch #1472877 for this
which is tested against the tix demo code
in Demo/tix/tixwidgets.py
Matthias Kievernagel
mkiever at web dot de
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472877&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1584723 ] os.tempnam fails on SUSE Linux to accept directory argument
Bugs item #1584723, was opened at 2006-10-25 22:52
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1584723&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Andreas (andyfloe)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.tempnam fails on SUSE Linux to accept directory argument
Initial Comment:
On SUSE Linux 10.1 the function os.tempnam does not use
the "dir" argument properly. It always takes the
tmpdir, in this case "/tmp". In the example below it is
expected to get a filename of '/tmp/tmp/pref2iGGS5'
instead of '/tmp/pref2iGGS5'.
[EMAIL PROTECTED]:~> python
Python 2.5 (r25:51908, Oct 18 2006, 22:50:32)
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os
>>> os.mkdir("/tmp/tmp")
>>> os.tempnam("/tmp/tmp", "pref")
__main__:1: RuntimeWarning: tempnam is a potential
security risk to your program
'/tmp/pref2iGGS5'
>>>
[EMAIL PROTECTED]:~> ls -l /tmp/tmp
total 0
[EMAIL PROTECTED]:~> ls -ld /tmp/tmp
drwxr-xr-x 2 auser users 48 2006-10-17 20:13 /tmp/tmp
This behavior is also the same on the Python version
which comes with SUSE Linux 10.1. On Solaris 10 the
behavior is as expected, e.g.
-bash-3.00$ python
Python 2.4.3 (#1, Sep 16 2006, 10:31:38) [C] on sunos5
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os
>>> os.mkdir("/tmp/tmp")
>>> os.tempnam("/tmp/tmp", "pref")
__main__:1: RuntimeWarning: tempnam is a potential
security risk to your program
'/tmp/tmp/prefAAAIeaafH'
A patch for the test 'test_os.py' is attached to this
report. It has been tested on SUSE Linux 10.1.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1584723&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1584723 ] os.tempnam fails on SUSE Linux to accept directory argument
Bugs item #1584723, was opened at 2006-10-25 20:52
Message generated for change (Comment added) made by mkiever
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1584723&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Andreas (andyfloe)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.tempnam fails on SUSE Linux to accept directory argument
Initial Comment:
On SUSE Linux 10.1 the function os.tempnam does not use
the "dir" argument properly. It always takes the
tmpdir, in this case "/tmp". In the example below it is
expected to get a filename of '/tmp/tmp/pref2iGGS5'
instead of '/tmp/pref2iGGS5'.
[EMAIL PROTECTED]:~> python
Python 2.5 (r25:51908, Oct 18 2006, 22:50:32)
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os
>>> os.mkdir("/tmp/tmp")
>>> os.tempnam("/tmp/tmp", "pref")
__main__:1: RuntimeWarning: tempnam is a potential
security risk to your program
'/tmp/pref2iGGS5'
>>>
[EMAIL PROTECTED]:~> ls -l /tmp/tmp
total 0
[EMAIL PROTECTED]:~> ls -ld /tmp/tmp
drwxr-xr-x 2 auser users 48 2006-10-17 20:13 /tmp/tmp
This behavior is also the same on the Python version
which comes with SUSE Linux 10.1. On Solaris 10 the
behavior is as expected, e.g.
-bash-3.00$ python
Python 2.4.3 (#1, Sep 16 2006, 10:31:38) [C] on sunos5
Type "help", "copyright", "credits" or "license" for
more information.
>>> import os
>>> os.mkdir("/tmp/tmp")
>>> os.tempnam("/tmp/tmp", "pref")
__main__:1: RuntimeWarning: tempnam is a potential
security risk to your program
'/tmp/tmp/prefAAAIeaafH'
A patch for the test 'test_os.py' is attached to this
report. It has been tested on SUSE Linux 10.1.
--
Comment By: Matthias Kievernagel (mkiever)
Date: 2006-10-26 00:12
Message:
Logged In: YES
user_id=1477880
This one once irritated me also.
In my case the cause was
the environment variable 'TMPDIR'.
This is the first location chosen
by os.tempnam (see 'man tempnam').
Please check again.
Matthias Kievernagel
mkiever at web dot de
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1584723&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
