[ python-Bugs-1583537 ] tarfile incorrectly handles long filenames
Bugs item #1583537, was opened at 2006-10-24 14:05
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=1583537&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.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mike Looijmans (cdwave)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile incorrectly handles long filenames
Initial Comment:
tarfile seems to incorrectly handle filenames longer
than 100 characters. This is tarfile as provided with
2.4.3 and 2.4.4. The 0.8.0 version of tarfile is even
worse - it will cut off the last character of any
filename that is exactly 100 in size.
Below the unit test that I use to reproduce the problem:
class Test00tarfile(unittest.TestCase):
def runtest(self, longName):
import tarfile
dst=StringIO()
src=StringIO("Hello world!")
srclen = len("Hello world!")
tar = tarfile.open(mode='w|', fileobj=dst)
tar.add('test.py')
info = tar.gettarinfo('test.py', longName)
info.size = srclen
tar.addfile(info, src)
src.seek(0)
tar.addfile(info, src)
tar.close()
dst.seek(0)
tar = tarfile.open(mode='r|', fileobj=dst)
info = tar.next()
self.assertEqual(info.name, 'test.py')
info = tar.next()
self.assertEqual(info.size, srclen)
self.assertEqual(info.name, longName)
info = tar.next()
self.assertEqual(info.name, longName)
info = tar.next()
self.assertEqual(None, info)
def testLongFileName200(self):
"tarfile with 200+ length filename"
self.runtest("LongName/" + 200 * "x" + "/LongTail")
def testLongFileName100(self):
"tarfile with 100 length filename"
self.runtest('MyWiki/underlay/pages/(e7ae80e4bd93e4b8ade69687)MoinMoin(2fe5ae89e8a385e6898be5868c)/cache/text_html')
The "200" test fails on the standard version, on
tarfile 0.8.0 the 100 test fails too.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583537&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1583537 ] tarfile incorrectly handles long filenames
Bugs item #1583537, was opened at 2006-10-24 14:05
Message generated for change (Comment added) made by cdwave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583537&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.4
>Status: Deleted
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Mike Looijmans (cdwave)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile incorrectly handles long filenames
Initial Comment:
tarfile seems to incorrectly handle filenames longer
than 100 characters. This is tarfile as provided with
2.4.3 and 2.4.4. The 0.8.0 version of tarfile is even
worse - it will cut off the last character of any
filename that is exactly 100 in size.
Below the unit test that I use to reproduce the problem:
class Test00tarfile(unittest.TestCase):
def runtest(self, longName):
import tarfile
dst=StringIO()
src=StringIO("Hello world!")
srclen = len("Hello world!")
tar = tarfile.open(mode='w|', fileobj=dst)
tar.add('test.py')
info = tar.gettarinfo('test.py', longName)
info.size = srclen
tar.addfile(info, src)
src.seek(0)
tar.addfile(info, src)
tar.close()
dst.seek(0)
tar = tarfile.open(mode='r|', fileobj=dst)
info = tar.next()
self.assertEqual(info.name, 'test.py')
info = tar.next()
self.assertEqual(info.size, srclen)
self.assertEqual(info.name, longName)
info = tar.next()
self.assertEqual(info.name, longName)
info = tar.next()
self.assertEqual(None, info)
def testLongFileName200(self):
"tarfile with 200+ length filename"
self.runtest("LongName/" + 200 * "x" + "/LongTail")
def testLongFileName100(self):
"tarfile with 100 length filename"
self.runtest('MyWiki/underlay/pages/(e7ae80e4bd93e4b8ade69687)MoinMoin(2fe5ae89e8a385e6898be5868c)/cache/text_html')
The "200" test fails on the standard version, on
tarfile 0.8.0 the 100 test fails too.
--
>Comment By: Mike Looijmans (cdwave)
Date: 2006-10-24 15:33
Message:
Logged In: YES
user_id=1372511
Test was wrong, and there were distinct bugs in various
versions.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583537&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1583862 ] yield+break stops tracing
Bugs item #1583862, was opened at 2006-10-24 17:55
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=1583862&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: Lukas Lalinsky (luks)
Assigned to: Nobody/Anonymous (nobody)
Summary: yield+break stops tracing
Initial Comment:
Here is an example script:
def myiter():
for i in range(10):
yield i
for i in myiter():
break
print "foo"
Now, if I try to trace it:
$ python -m trace --trace --count test.py
--- modulename: threading, funcname: settrace
threading.py(70): _trace_hook = func
--- modulename: test, funcname:
test.py(1): def myiter():
test.py(5): for i in myiter():
--- modulename: test, funcname: myiter
test.py(2): for i in range(10):
test.py(3): yield i
test.py(6): break
c:\python25\lib\ntpath.py:190: RuntimeWarning:
tp_compare didn't return -1 or -2 for exception
if i<=max(p.rfind('/'), p.rfind('\\')):
foo
It stops tracing after the `break` statement. The line
after, `print "foo"`, is not traced nor included in the
coverage output.
I'm not sure RuntimeWarning from ntpath.py is relevant
here, because if I use the trace module in some other
situation it doesn't print it. IMO, it's just a side
effect of some different problem.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583862&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1583863 ] __str__ cannot be overridden on unicode-derived classes
Bugs item #1583863, was opened at 2006-10-24 15:57 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=1583863&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: Mike K (laughingboy0) Assigned to: Nobody/Anonymous (nobody) Summary: __str__ cannot be overridden on unicode-derived classes Initial Comment: class S(str): def __str__(self): return '__str__ overridden' class U(unicode): def __str__(self): return '__str__ overridden' def __unicode__(self): return u'__unicode__ overridden' s = S() u = U() print 's:', s print "str(s):", str(s) print 's substitued is "%s"\n' % s print 'u:', u print "str(u):", str(u) print 'u substitued is "%s"' % u - s: __str__ overridden str(s): __str__ overridden s substitued is "__str__ overridden" u: str(u): __str__ overridden u substitued is "" Results are identical for 2.4.2 and 2.5c2 (running under windows). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583863&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1583862 ] yield+break stops tracing
Bugs item #1583862, was opened at 2006-10-24 17:55
Message generated for change (Settings changed) made by luks
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583862&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: Lukas Lalinsky (luks)
Assigned to: Nobody/Anonymous (nobody)
Summary: yield+break stops tracing
Initial Comment:
Here is an example script:
def myiter():
for i in range(10):
yield i
for i in myiter():
break
print "foo"
Now, if I try to trace it:
$ python -m trace --trace --count test.py
--- modulename: threading, funcname: settrace
threading.py(70): _trace_hook = func
--- modulename: test, funcname:
test.py(1): def myiter():
test.py(5): for i in myiter():
--- modulename: test, funcname: myiter
test.py(2): for i in range(10):
test.py(3): yield i
test.py(6): break
c:\python25\lib\ntpath.py:190: RuntimeWarning:
tp_compare didn't return -1 or -2 for exception
if i<=max(p.rfind('/'), p.rfind('\\')):
foo
It stops tracing after the `break` statement. The line
after, `print "foo"`, is not traced nor included in the
coverage output.
I'm not sure RuntimeWarning from ntpath.py is relevant
here, because if I use the trace module in some other
situation it doesn't print it. IMO, it's just a side
effect of some different problem.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583862&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1583862 ] yield+break stops tracing
Bugs item #1583862, was opened at 2006-10-24 17:55
Message generated for change (Comment added) made by luks
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583862&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: Lukas Lalinsky (luks)
Assigned to: Nobody/Anonymous (nobody)
Summary: yield+break stops tracing
Initial Comment:
Here is an example script:
def myiter():
for i in range(10):
yield i
for i in myiter():
break
print "foo"
Now, if I try to trace it:
$ python -m trace --trace --count test.py
--- modulename: threading, funcname: settrace
threading.py(70): _trace_hook = func
--- modulename: test, funcname:
test.py(1): def myiter():
test.py(5): for i in myiter():
--- modulename: test, funcname: myiter
test.py(2): for i in range(10):
test.py(3): yield i
test.py(6): break
c:\python25\lib\ntpath.py:190: RuntimeWarning:
tp_compare didn't return -1 or -2 for exception
if i<=max(p.rfind('/'), p.rfind('\\')):
foo
It stops tracing after the `break` statement. The line
after, `print "foo"`, is not traced nor included in the
coverage output.
I'm not sure RuntimeWarning from ntpath.py is relevant
here, because if I use the trace module in some other
situation it doesn't print it. IMO, it's just a side
effect of some different problem.
--
>Comment By: Lukas Lalinsky (luks)
Date: 2006-10-24 18:05
Message:
Logged In: YES
user_id=587716
Oh, I forgot. This bug is specific to Python 2.5. It works
fine in 2.4.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583862&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" functions problems - security
Bugs item #1583946, was opened at 2006-10-24 18:32
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=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
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1584028 ] remove() during iteration causes items to be skipped
Bugs item #1584028, was opened at 2006-10-24 14:44 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=1584028&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.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Kevin Rabsatt (krabsa) Assigned to: Nobody/Anonymous (nobody) Summary: remove() during iteration causes items to be skipped Initial Comment: If, when iterating over the contents of a list, the current item is removed, the next item is skipped. #Code: if __name__ == '__main__': items = [0,1,2,3,4,5] for i in items: print i items.remove(i) #End Code Outputs: 0 2 4 I believe the behavior is undesirable. An argument can be made to not fix, but the issue is worth noting. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1584028&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" functions problems - security
Bugs item #1583946, was opened at 2006-10-24 11:32
Message generated for change (Comment added) made by greg
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: Gregory P. Smith (greg)
Date: 2006-10-24 15:05
Message:
Logged In: YES
user_id=413
Yes OpenSSL 0.9.8d or later should be used for a new binary
release.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4343
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3738
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2940
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2937
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470
___
Python-bugs-list mailing list
Unsubs
[ python-Bugs-1583946 ] SSL "issuer" and "server" functions problems - security
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: 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: John Nagle (nagle)
Date: 2006-10-24 22:40
Message:
Logged In: YES
user_id=5571
The problem isn't in the version of OpenSSL used in Python,
which is at 0.9.8a. OpenSSL has had the necessary functions
for years. But Python isn't using them.
It's in "python/trunk/Modules/_ssl.c", as described above.
--
Comment By: Gregory P. Smith (greg)
Date: 2006-10-24 22:05
Message:
Logged In: YES
user_id=413
Yes OpenSSL 0.9.8d or later should be used for a new binary
release.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4343
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3738
h
[ python-Bugs-1584028 ] remove() during iteration causes items to be skipped
Bugs item #1584028, was opened at 2006-10-24 16:44 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1584028&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.4 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Kevin Rabsatt (krabsa) Assigned to: Nobody/Anonymous (nobody) Summary: remove() during iteration causes items to be skipped Initial Comment: If, when iterating over the contents of a list, the current item is removed, the next item is skipped. #Code: if __name__ == '__main__': items = [0,1,2,3,4,5] for i in items: print i items.remove(i) #End Code Outputs: 0 2 4 I believe the behavior is undesirable. An argument can be made to not fix, but the issue is worth noting. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-10-24 20:06 Message: Logged In: YES user_id=80475 Sorry, this isn't a bug -- it is a natural side-effect of mutating a object while iterating over it. The various approaches to dealing with this include: * don't allow mutation while iterating -- dict.iterkeys() uses this approach * iterate over a copy of the object -- dict.keys() uses this approach * iterate over consecutive indices and ignore mutation -- lists use this approach Programmers can avoid dealing with this issue by: * precopying the list: for i in items[:]: print i remove(i) * building a new list during iteration: items[:] = [x for x in items if f(x)] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1584028&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
