[ python-Bugs-1504676 ] Make sgmllib char and entity references pluggable

[SourceForge.net]

Bugs item #1504676, was opened at 2006-06-12 06:41
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=1504676&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
Submitted By: Sam Ruby (rubys)
Assigned to: Nobody/Anonymous (nobody)
Summary: Make sgmllib char and entity references pluggable

Initial Comment:
The changes being made to sgmllib in Python 2.5 may
break existing applications.  This patch makes it easy
for subclasses to revert to the old behavior. 
Additionally, it makes it easier to provide new
behaviors, like supporting unicode, hexadecimal
character references, and additional entities.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504676&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1284316 ] Win32: Security problem with default installation directory

[SourceForge.net]

Bugs item #1284316, was opened at 2005-09-07 23:34
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284316&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: Installation
Group: Platform-specific
Status: Open
Resolution: None
>Priority: 5
Submitted By: Mika Eloranta (mel)
Assigned to: Martin v. Löwis (loewis)
Summary: Win32: Security problem with default installation directory

Initial Comment:
(Sorry, this is a bit long since the issue is not
entirely trivial.)

This problem only exists on Windows operating systems
installed on an NTFS file system. Confirmed on several
Windows 2000, XP and Windows 2003 Server systems. All
Python versions (at least 2.x) are affected.

The default installation target directory where Python
is installation on Windows is directly under the system
drive's root directory (e.g. "C:\python24"). The file
and directory permissions inherited by the
python24-directory from the root directory are not
secure enough for keeping application binaries.

Microsoft has, in their infinite wisdom, decided that
the root directory of the system drive should allow
regular (non-admin) users to create directories and
files there. This set of permissions is inherited by
the python directory when it is created in the default
location (i.e. "C:\python24" or whatever).

This "feature" allows a regular (non-admin) user to
perform a priviledge escalation attack for example in
the following manner:

1. Figure out the name of some DLL python (or some
extension .PYD) loads using LoadLibrary() without an
absolute path.

2. Copy a DLL with the same name into the
python-directory (this should not be allowed, but it
is!) containing some code the attacker wants to run
with escalated priviledges.

3. Wait until python is run by an admin in the same
machine or by the LocalSystem account.

How to view the problematic part of the ACL:
1. Right-click the "C:\python24" directory in Windows
Explorer
2. select Properties... -> Security -> Advanced
3. In the "Permissions" tab you will see an entry for
the "Users" group, it says "Special" in the
"Permissions" column
4. Select the above entry and click "Edit..."
5. Well hidden? I think so, too.

The fix:
The proper (default) location where application
binaries should be installed is under the "c:\program
files\" directory. This directory has properly set
permissions by default.

PS. The same problem exists in ActivePerl, Ruby and
many other tools.


--

>Comment By: Martin v. Löwis (loewis)
Date: 2006-06-12 14:26

Message:
Logged In: YES 
user_id=21627

Lowering the priority; this is now a documented bug.

--

Comment By: D. Scott Miller (dsmiller)
Date: 2006-05-06 03:04

Message:
Logged In: YES 
user_id=1517734

Here's a few possible solutions to the permissions problem
that retain the idea of defaulting to an install path with
no spaces without making too many assumptions about what
permissions the installing admin actually wants:
-
Idea #1

Install by default to %systemroot%\PythonXX. Hey, Java
sticks some stuff in there, right? If the idea is "this is
kind of a part-of-the-OS thing, and MS does it this way for
cscript.exe" then this seems to make sense. (We hope any
admins who're using a %systemroot% with spaces in it know
what they're doing.)

Is the default name for %systemroot% different on any
particular localized versions of Windows? I know it's
"WINDOWS" in Japanese versions, anyway.
-
Idea #2

Have two folder select boxes in the installer, one for where
to install Python and one for a folder from which to copy
ACLs. These would default to %systemdrive%\PythonXX and
%programfiles%, respectively. Have a check box to disable
the ACL copying, but have it checked by default.

This is still bad, as it doesn't solve the problem of being
a special separate directory with its own individual ACL to
maintain, but it's somewhat less bad than it is now for
people who click through the installer trusting it to not
open up their system to new flavors of privilege escalation.
-
Idea #3

Do something goofy with NTFS junctions.
-

Regardless of what's done, given that people expect not to
have to worry about spaces these days, it may be a good idea
to include an explanation/warning about the situation in the
installer text.
-

In regards to Martin Löwis' concern about non-admin users
not being able to cause the generation of .pyc files in the
main Python directory tree: It's already like that on most
OS's, correct? So it would just apply in cases where someone
a) writes an add-on specifically targeting the Python
directory tree,

[ python-Bugs-1501330 ] failure of test_ossaudiodev; elapsed time .1 sec faster

[SourceForge.net]

Bugs item #1501330, was opened at 2006-06-05 17:23
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501330&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
Submitted By: Brett Cannon (bcannon)
Assigned to: Greg Ward (gward)
Summary: failure of test_ossaudiodev; elapsed time .1 sec faster

Initial Comment:
I am getting a consistent failure of test_ossaudiodev
on Ubuntu Hoary on an HP xw4300 Workstation.  The
failure is that the test is printing out "elapsed time:
3.0 sec" while the test expects 3.1 sec.

I don't know anything about sound recordings so I don't
know if there is any way to calculate the expected
length of the test sound file and thus know that this
is a true error or the test is just working faster than
normally expected.

--

>Comment By: Brett Cannon (bcannon)
Date: 2006-06-12 11:09

Message:
Logged In: YES 
user_id=357491

Output with the patch:

playing test sound file (expected running time: 2.93 sec)
actual running time was 3.09 sec (5.5% difference)

--

Comment By: Greg Ward (gward)
Date: 2006-06-11 09:54

Message:
Logged In: YES 
user_id=14422

Brett -- I'm not sure why I put 3.1 sec in there.  It's
probably just what popped out the first time I ran this test
on my machine.  Anyways, simple math reveals that the
theoretical running time of the test file is ~2.93 sec:

  (23493 bytes) / (1 byte/sample) / (8000 samples/sec) =
2.93 sec

which of course ignores the overhead of the file header, but
that seems to pretty small.  "sox" agrees:

$ time /usr/bin/play Lib/test/audiotest.au

Input Filename : Lib/test/audiotest.au
Sample Size: 8-bits
Sample Encoding: u-law
Channels   : 1
Sample Rate: 8000

Time: 00:02.93 [00:00.00] of 00:02.93 ( 100.0%) Output
Buffer:  23.46K

Done.
/usr/bin/play Lib/test/audiotest.au  0.03s user 0.02s system
1% cpu 3.127 total

Can you try that on your machine and put the output here?

Anyways, the likely culprits are 1) faster hardware (less
overhead opening audio device, reading file, etc) and 2)
variations in sound chip frequency (8000 Hz is not always
exactly 8000 Hz).  I'll try to fix the test so it's a little
fuzzier.


--

Comment By: A.M. Kuchling (akuchling)
Date: 2006-06-07 06:04

Message:
Logged In: YES 
user_id=11375

Yes, the length is calculable -- you have N bytes in the
file, with so many bits per sample and so many samples per
second.  Perhaps the driver now buffers more and the write()
returns earlier?  Or you could try printing the exact
duration without rounding; maybe it's 3.099 or something
and the print is just truncating.


Assigning to Greg Ward, in case he gets around to looking at it.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501330&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1504947 ] There should be a Python build using Visual Studio 2005

[SourceForge.net]

Bugs item #1504947, was opened at 2006-06-12 12:08
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=1504947&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: Build
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Vincent Manis (vmanis)
Assigned to: Nobody/Anonymous (nobody)
Summary: There should be a Python build using Visual Studio 2005

Initial Comment:
This report is a follow-on from Bug# 1498051, which 
complained that Distutils doesn't recognize Visual 
Studio 2005. That bug was closed with a statement 
that extensions should be built with the same version 
of the MS compiler that built the Python system. 

Given that Visual Studio 2003 is no longer available 
as a commercial product from Microsoft, many people 
(myself included) must use Visual Studio 2005. 
Therefore, I am requesting that a separate `batteries 
included' Windows installer be provided where 
everything has been built with VS2005.  

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504947&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1504998 ] under Windows XP, os.walk problem with path >256? chars

[SourceForge.net]

Bugs item #1504998, was opened at 2006-06-12 15:34
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=1504998&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
Submitted By: Mike Coleman (mkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: under Windows XP, os.walk problem with path >256? chars

Initial Comment:
Under Windows XP, when using os.walk to walk a tree, I
get an error message for a path of 256+ characters.

The error looks like 

error listing directory [[Errno 206] The filename or
extension is too long: 

The path in question is 12 directories deep, if that
matters.  The Windows 'dir' command also doesn't like
this path because of its length, but it seems like
there ought to be a way to walk it.



--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1504998&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1505081 ] Wrong grammar

[SourceForge.net]

Bugs item #1505081, was opened at 2006-06-12 23:19
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=1505081&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: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Milind (t-milich)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong grammar

Initial Comment:
The Python and test is written as:

and_test ::= not_test | and_test "and" not_test 

It should be changed to :

and_test ::= not_test |  not_test "and" and_test


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1505081&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1505095 ] Incorrect comment in socket.py

[SourceForge.net]

Bugs item #1505095, was opened at 2006-06-12 17:12
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=1505095&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
Submitted By: Bruce Christensen (bruckie)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect comment in socket.py

Initial Comment:
socket.py includes this comment around line 125:

# These classes are used by the socket() defined on 
Windows and BeOS
# platforms to provide a best-effort implementation of 
the cleanup
# semantics needed when sockets can't be dup()ed.
#
# These are not actually used on other platforms.

This appears to be incorrect. It appears that behavior 
is the same on different OSes (other than the riscos 
sleeptaskw function and Windows WSA error codes).

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1505095&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1505081 ] Wrong grammar

[SourceForge.net]

Bugs item #1505081, was opened at 2006-06-12 23:19
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1505081&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: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Milind (t-milich)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong grammar

Initial Comment:
The Python and test is written as:

and_test ::= not_test | and_test "and" not_test 

It should be changed to :

and_test ::= not_test |  not_test "and" and_test


--

>Comment By: Georg Brandl (gbrandl)
Date: 2006-06-13 06:00

Message:
Logged In: YES 
user_id=849994

What problem does this cause for you?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1505081&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1505081 ] Wrong grammar

[SourceForge.net]

Bugs item #1505081, was opened at 2006-06-12 19:19
Message generated for change (Settings changed) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1505081&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: Documentation
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Milind (t-milich)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong grammar

Initial Comment:
The Python and test is written as:

and_test ::= not_test | and_test "and" not_test 

It should be changed to :

and_test ::= not_test |  not_test "and" and_test


--

>Comment By: Tim Peters (tim_one)
Date: 2006-06-13 02:50

Message:
Logged In: YES 
user_id=31435

The grammar is correct as-is anyway, so closing this as
invalid ("and" is left-associative, that's critical to
correct understanding of its short-circuit semantics, and
the production for and_test is left-recursive to make that
clear:  "a and b and c" must be parsed as "(a and b) and c",
not as "a and (b and c)" as the suggested change would force).

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-06-13 02:00

Message:
Logged In: YES 
user_id=849994

What problem does this cause for you?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1505081&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1451717 ] OS/X on i386 framework build

[SourceForge.net]

Bugs item #1451717, was opened at 2006-03-16 23:22
Message generated for change (Settings changed) made by ronaldoussoren
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451717&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: Build
Group: Python 2.4
>Status: Pending
>Resolution: Fixed
Priority: 5
Submitted By: Ian Holsman (webperf)
Assigned to: Nobody/Anonymous (nobody)
Summary: OS/X on i386 framework build

Initial Comment:
in Makefile.pre (374) it hard codes the architecture to
'ppc' which isn't correct for the new x86 boxes.

this needs to be i386 for the framework install to
actually build on the new macs.

regards
Ian

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-23 14:51

Message:
Logged In: YES 
user_id=580910

This has been fixed on the trunk. I'll backport this to 2.4.x in the near 
future.

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-17 16:07

Message:
Logged In: YES 
user_id=580910

BTW. The 'also' bit has been fixed in the trunk.

--

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-04-02 21:21

Message:
Logged In: YES 
user_id=580910

This is a duplicate of bug 1447587  

--

Comment By: Ian Holsman (webperf)
Date: 2006-03-16 23:34

Message:
Logged In: YES 
user_id=5209

also..
in plat-mac/applesingle.py the fields
AS_HEADER_FORMAT
and 
AS_ENTRY_FORMAT
need a '>' infront of the definitions
AS_HEADER_FORMAT=">LL16sh"
AS_ENTRY_FORMAT=">lll"
(this is what the system-packaged python has.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451717&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com