[ python-Bugs-1720959 ] Please make sqlite3.Row iterable
Bugs item #1720959, was opened at 2007-05-17 22:23 Message generated for change (Comment added) made by ghaering You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720959&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: Extension Modules Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: phil (philipdumont) Assigned to: Gerhard Häring (ghaering) Summary: Please make sqlite3.Row iterable Initial Comment: Sometimes I'd like to get row values with columnname indexes, sometimes by iterating over the row. The default (not setting the connection's row_factory) is to return a tuple, which gives the latter, but not the former. Setting row_factory to sqlite3.Row gives the former, but (surprisingly) not the latter. It's a surprise because back when pysqlite was not part of the Python distrib (I don't recall what version), its Row type was iterable. Any chance that bit of functionality could be put back? -- >Comment By: Gerhard Häring (ghaering) Date: 2007-05-20 18:26 Message: Logged In: YES user_id=163326 Originator: NO This functionality is already in the Python 2.6 branch. I was told not to backport it to 2.5.x. So, I'll close this issue. -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-05-17 23:14 Message: Logged In: YES user_id=33168 Originator: NO Gerhard, could you take a look? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720959&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1722239 ] NamedTuple security issue
Bugs item #1722239, was opened at 2007-05-20 20:00
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=1722239&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.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: NamedTuple security issue
Initial Comment:
collections.NamedTuple is using an assert to prevent exec attacks:
assert ''.join(field_names).replace('_', '').isalpha()
# protect against exec attack
s
asserts are ignored when Python code is run with the -O or -OO flag. I suggest
to replace them.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722239&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1722239 ] NamedTuple security issue
Bugs item #1722239, was opened at 2007-05-20 11:00
Message generated for change (Comment added) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722239&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.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: NamedTuple security issue
Initial Comment:
collections.NamedTuple is using an assert to prevent exec attacks:
assert ''.join(field_names).replace('_', '').isalpha()
# protect against exec attack
s
asserts are ignored when Python code is run with the -O or -OO flag. I suggest
to replace them.
--
>Comment By: Brett Cannon (bcannon)
Date: 2007-05-20 12:23
Message:
Logged In: YES
user_id=357491
Originator: NO
Or you could just not have the security protection in there. I am sure
there are a ton of other places that are not protected against malicious
use of exec.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722239&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1722239 ] NamedTuple security issue
Bugs item #1722239, was opened at 2007-05-20 20:00
Message generated for change (Comment added) made by tiran
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722239&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.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
Assigned to: Nobody/Anonymous (nobody)
Summary: NamedTuple security issue
Initial Comment:
collections.NamedTuple is using an assert to prevent exec attacks:
assert ''.join(field_names).replace('_', '').isalpha()
# protect against exec attack
s
asserts are ignored when Python code is run with the -O or -OO flag. I suggest
to replace them.
--
>Comment By: Christian Heimes (tiran)
Date: 2007-05-20 22:40
Message:
Logged In: YES
user_id=560817
Originator: YES
It's less than a ton (how do I weight source code? *g*) but it's used in
some modules. Personally I don't like the usage of exec/execfile and I'm
always worried when I see code that utilizes it. I've created a patch that
checks typename and field_names for non alphanumeric characters.
Bastion.py:exec testcode
bdb.py:exec cmd in globals, locals
cgi.py:exec "testing print_exception() -- italics?"
code.py:exec code in self.locals
collections.py:exec template in m
cProfile.py:exec cmd in globals, locals
doctest.py:exec compile(example.source, filename,
"single",
hashlib.py:exec funcName + ' = f'
hashlib.py:exec funcName + ' =
__get_builtin_constructor(funcName)'
ihooks.py:exec code in m.__dict__
imputil.py:exec code in module.__dict__
pdb.py:exec code in globals, locals
profile.py:exec cmd in globals, locals
rexec.py:exec TEMPLATE % (m, m)
rexec.py:exec code in m.__dict__
runpy.py:exec code in run_globals
site.py:exec line
socket.py:exec _s % (_m, _m, _m, _m)
timeit.py:exec code in globals(), ns
timeit.py:exec _setup in globals(), ns
trace.py:exec cmd in dict, dict
trace.py:exec cmd in globals, locals
File Added: NamedTuple_55472.diff
--
Comment By: Brett Cannon (bcannon)
Date: 2007-05-20 21:23
Message:
Logged In: YES
user_id=357491
Originator: NO
Or you could just not have the security protection in there. I am sure
there are a ton of other places that are not protected against malicious
use of exec.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722239&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1722344 ] Thread shutdown exception in Thread.notify()
Bugs item #1722344, was opened at 2007-05-20 15:24
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=1722344&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: Yang Zhang (yangzhang)
Assigned to: Nobody/Anonymous (nobody)
Summary: Thread shutdown exception in Thread.notify()
Initial Comment:
Hi, I sometimes see the following exceptions when shutting down my app (using
Python 2.5.1):
Unhandled exception in thread started by
Error in sys.excepthook:
Original exception was:
Exception in thread Thread-3 (most likely raised during interpreter shutdown):
Traceback (most recent call last):
File "/usr/local/lib/python2.5/threading.py", line 460, in __bootstrap
File "/usr/local/lib/python2.5/threading.py", line 440, in run
File "/home/yang/local/armed/lib/python2.5/site-packages/afx/threads.py",
line 71, in worker
File "/usr/local/lib/python2.5/Queue.py", line 176, in get
File "/usr/local/lib/python2.5/threading.py", line 248, in notify
: exceptions must be classes, instances, or
strings (deprecated), not NoneType
Unhandled exception in thread started by
Error in sys.excepthook:
Original exception was:
Exception in thread Thread-6 (most likely raised during interpreter shutdown):
Traceback (most recent call last):
File "/usr/local/lib/python2.5/threading.py", line 460, in __bootstrap
File "/usr/local/lib/python2.5/threading.py", line 440, in run
File "/home/yang/local/armed/lib/python2.5/site-packages/afx/threads.py",
line 71, in worker
File "/usr/local/lib/python2.5/Queue.py", line 176, in get
File "/usr/local/lib/python2.5/threading.py", line 248, in notify
: exceptions must be classes, instances, or
strings (deprecated), not NoneType
Unhandled exception in thread started by
Error in sys.excepthook:
Original exception was:
Here is the code from my application:
def worker():
debug( 'starting worker' )
while True:
msg = i.get() # <-- THIS IS LINE 71
if msg is stop_msg: break
resultbuf, func, args, kwargs = msg
result, exc = None, None
try:
result = func( *args, **kwargs )
except:
t, v, tb = exc_info()
exc = t, v, tb.tb_next
o.put( ( resultbuf, result, exc ) )
s.send( 'x' ) # assuming socket.send is thread-safe
debug( 'stopping worker' )
Here is the origin of the exception (in threading.py):
def notify(self, n=1):
assert self._is_owned(), "notify() of un-acquire()d lock" # <-- THIS IS
LINE 248
__waiters = self.__waiters
waiters = __waiters[:n]
if not waiters:
if __debug__:
self._note("%s.notify(): no waiters", self)
return
self._note("%s.notify(): notifying %d waiter%s", self, n,
n!=1 and "s" or "")
for waiter in waiters:
waiter.release()
try:
__waiters.remove(waiter)
except ValueError:
pass
I'm not sure why this is happening. The threads are not daemon threads; I
terminate them cleanly. When I get a SIGINT (I usu. shut down my app with
ctrl-C), I enqueue n stop_msg's to the 'i' Queue so that the n workers can all
exit.
Note I usually launch 5 workers, so I'm not consistently getting an exception
per worker. Also, I've been unable to reproduce this at will.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722344&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1722348 ] urlparse.urlunparse forms file urls incorrectly
Bugs item #1722348, was opened at 2007-05-20 18:35
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=1722348&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: Thomas Folz-Donahue (eigenlambda)
Assigned to: Nobody/Anonymous (nobody)
Summary: urlparse.urlunparse forms file urls incorrectly
Initial Comment:
This is a conversation with the current Python interpreter.
>>> import urlparse
>>> urlparse.urlparse(urlparse.urlunparse(urlparse.urlparse("file:usr/bin/python")))
('file', 'usr', '/bin/python', '', '', '')
As you can see, the results are incorrect. The problem is in the urlunsplit
function:
def urlunsplit((scheme, netloc, url, query, fragment)):
if netloc or (scheme and scheme in uses_netloc and url[:2] != '//'):
if url and url[:1] != '/': url = '/' + url
url = '//' + (netloc or '') + url
if scheme:
url = scheme + ':' + url
if query:
url = url + '?' + query
if fragment:
url = url + '#' + fragment
return url
RFC 1808 (see http://www.ietf.org/rfc/rfc1808.txt ) specifies that a URL shall
have the following syntax:
:///;?#
The problem with the current version of urlunsplit is that it tests if there
are already two slashes before the 'url' section before outputting a URL. This
is incorrect because (1) RFC 1808 clearly specifies at least three slashes
between the end of the scheme portion and the beginning of the path portion and
(2) this method will strip the first few slashes from an arbitrary path
portion, which may require those slashes. Removing that url[:2] != '//' causes
urlunsplit to behave correctly when dealing with urls like
file:usr/bin/python .
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722348&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1722348 ] urlparse.urlunparse forms file urls incorrectly
Bugs item #1722348, was opened at 2007-05-20 18:35
Message generated for change (Comment added) made by eigenlambda
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722348&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: Thomas Folz-Donahue (eigenlambda)
Assigned to: Nobody/Anonymous (nobody)
Summary: urlparse.urlunparse forms file urls incorrectly
Initial Comment:
This is a conversation with the current Python interpreter.
>>> import urlparse
>>> urlparse.urlparse(urlparse.urlunparse(urlparse.urlparse("file:usr/bin/python")))
('file', 'usr', '/bin/python', '', '', '')
As you can see, the results are incorrect. The problem is in the urlunsplit
function:
def urlunsplit((scheme, netloc, url, query, fragment)):
if netloc or (scheme and scheme in uses_netloc and url[:2] != '//'):
if url and url[:1] != '/': url = '/' + url
url = '//' + (netloc or '') + url
if scheme:
url = scheme + ':' + url
if query:
url = url + '?' + query
if fragment:
url = url + '#' + fragment
return url
RFC 1808 (see http://www.ietf.org/rfc/rfc1808.txt ) specifies that a URL shall
have the following syntax:
:///;?#
The problem with the current version of urlunsplit is that it tests if there
are already two slashes before the 'url' section before outputting a URL. This
is incorrect because (1) RFC 1808 clearly specifies at least three slashes
between the end of the scheme portion and the beginning of the path portion and
(2) this method will strip the first few slashes from an arbitrary path
portion, which may require those slashes. Removing that url[:2] != '//' causes
urlunsplit to behave correctly when dealing with urls like
file:usr/bin/python .
--
>Comment By: Thomas Folz-Donahue (eigenlambda)
Date: 2007-05-20 19:12
Message:
Logged In: YES
user_id=1797315
Originator: YES
Some other issues with the urlparse module. Several constant lists
defined at the beginning of the module should be sets because they are only
used for testing if certain strings are in them. Also, urlunsplit() uses
the + operator way too much, creating strings that are immediately thrown
away. IMO, the alternative is actually more readable. Attaching a patch
(diff -u urlparse.py urlparse.py.new > urlparse.diff).
File Added: urlparse.diff
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722348&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1722239 ] NamedTuple security issue
Bugs item #1722239, was opened at 2007-05-20 13:00
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722239&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.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Heimes (tiran)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: NamedTuple security issue
Initial Comment:
collections.NamedTuple is using an assert to prevent exec attacks:
assert ''.join(field_names).replace('_', '').isalpha()
# protect against exec attack
s
asserts are ignored when Python code is run with the -O or -OO flag. I suggest
to replace them.
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-05-21 00:39
Message:
Logged In: YES
user_id=80475
Originator: NO
Will replace the assertion with something that always executes.
--
Comment By: Christian Heimes (tiran)
Date: 2007-05-20 15:40
Message:
Logged In: YES
user_id=560817
Originator: YES
It's less than a ton (how do I weight source code? *g*) but it's used in
some modules. Personally I don't like the usage of exec/execfile and I'm
always worried when I see code that utilizes it. I've created a patch that
checks typename and field_names for non alphanumeric characters.
Bastion.py:exec testcode
bdb.py:exec cmd in globals, locals
cgi.py:exec "testing print_exception() -- italics?"
code.py:exec code in self.locals
collections.py:exec template in m
cProfile.py:exec cmd in globals, locals
doctest.py:exec compile(example.source, filename,
"single",
hashlib.py:exec funcName + ' = f'
hashlib.py:exec funcName + ' =
__get_builtin_constructor(funcName)'
ihooks.py:exec code in m.__dict__
imputil.py:exec code in module.__dict__
pdb.py:exec code in globals, locals
profile.py:exec cmd in globals, locals
rexec.py:exec TEMPLATE % (m, m)
rexec.py:exec code in m.__dict__
runpy.py:exec code in run_globals
site.py:exec line
socket.py:exec _s % (_m, _m, _m, _m)
timeit.py:exec code in globals(), ns
timeit.py:exec _setup in globals(), ns
trace.py:exec cmd in dict, dict
trace.py:exec cmd in globals, locals
File Added: NamedTuple_55472.diff
--
Comment By: Brett Cannon (bcannon)
Date: 2007-05-20 14:23
Message:
Logged In: YES
user_id=357491
Originator: NO
Or you could just not have the security protection in there. I am sure
there are a ton of other places that are not protected against malicious
use of exec.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1722239&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
