Bug#484305: PoC not working for bicyclerepair

[Steffen Joeris]

severity 484305 important
thanks

Hi

I have troubles reproducing your problem and I've tried an etch and a lenny
chroot.

white@security:/tmp/roundup-1.2.1/roundup$ pwd
/tmp/roundup-1.2.1/roundup
white@security:/tmp/roundup-1.2.1/roundup$ vim /tmp/foo
white@security:/tmp/roundup-1.2.1/roundup$ apt-cache policy bicyclerepair
bicyclerepair:
  Installed: 0.9-4.1
  Candidate: 0.9-4.1
  Version table:
 *** 0.9-4.1 0
        500 http://ftp.no.debian.org etch/main Packages
        100 /var/lib/dpkg/status

and

white@security:/tmp/roundup-1.4.4/roundup$ pwd
/tmp/roundup-1.4.4/roundup
white@security:/tmp/roundup-1.4.4/roundup$ vim /tmp/foo
white@security:/tmp/roundup-1.4.4/roundup$ apt-cache policy bicyclerepair
bicyclerepair:
  Installed: 0.9-4.2
  Candidate: 0.9-4.2
  Version table:
 *** 0.9-4.2 0
        500 http://ftp.no.debian.org lenny/main Packages
        100 /var/lib/dpkg/status


Also, I can't find /usr/share/vim/addons/plugin/bike.vim. The package
bicyclerepair only contains /usr/share/vim/addons/ftplugin/python_bike.vim,
however I am not so firm with vim plugins after all.
I am using a standard vim config file.

Cheers
Steffen

[Debian Bug Tracking System]

Processing commands for control@...:

> severity 484305 important
Bug#484305: bicyclerepair: bike.vim imports untrusted python files from cwd
Severity set to `important' from `critical'

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Nico Golde-6]

severity 484305 grave
thanks

Hi Thomas,
* Thomas Arendsen Hein <thomas@...> [2008-07-06 22:53]:
> * Steffen Joeris <steffen.joeris@...> [20080706 11:15]:
> > severity 484305 important
> > thanks
>
> Please do not downgrade severity without providing a reason.

"critical makes unrelated software on the system (or the whole system)
break, or causes serious data loss, or introduces a security
hole on systems where you install the package."

I had a look at the issue now and this is not the case
because you have to a) install vim-python and bicyclerepair
together and b) set vim.python as the vim alternative.
Thus downgrading this bug.

> As I
> wrote in my original report, this should not be less than "grave":
>
> | I set Severity to "critical" instead of "grave", because the user who
> | reported the traceback to me on a multi-user system does not use
> | bicyclerepair, but just vim. Reportbug forced me to set "root security
> | hole", because everyone using vim is affected (including root) and
> | the Justification 5 "unknown / something else" would downgrade the
> | Severity to "normal".

I think that this is more like a user security hole because
the security issue itself doesn't automatically result in
root access. root security hole fit better to issues
included in a daemon running as root for example. But I
doubt discussing this gets us anywhere and I personally
don't care about this tag in this case :)

[...]

> On etch:
>
> $ dpkg -l bicyclerepair|grep ^i
> ii  bicyclerepair       0.9-4.1             A refactoring tool for python
>
> $ dpkg -L bicyclerepair|grep vim
> /usr/share/doc/bicyclerepair/README.vim
> /usr/share/vim
> /usr/share/vim/vim62
> /usr/share/vim/vim62/plugin
> /usr/share/vim/vim62/plugin/bike.vim
> /usr/share/vim/vim63
> /usr/share/vim/vim63/plugin
> /usr/share/vim/vim63/plugin/bike.vim
> /usr/share/vim/addons
> /usr/share/vim/addons/plugin
> /usr/share/vim/addons/plugin/bike.vim
>
> Maybe (I haven't verified) you need:
> /etc/alternatives/vim -> /usr/bin/vim.python

Indeed, this is needed (+ installation of vim-python).
So to sum up you need to install vim-python and set the
alternative to vim.python. I am not sure about the status of
this in unstable, at least I could not reproduce this on
unstable but vim.python is also no longer available there,
a lot in the vim structure changed since then and I don't
really have an idea about the scripting support of vim.

That's why I Cc'ed the vim maintainers. Do you think this
should also work in the same way in unstable/testing?
I am also not really sure what is causing the automatic
import.

To reproduce this on stable:
cd /tmp && apt-get source roundup && roundup-1.2.1/roundup/
apt-get install vim-python bicyclerepair
update-alternatives --set vim /usr/bin/vim.python
and edit some random file (e.g. vim /tmp/foobar).

I found out that the file that causes this is token.py in
the roundup sources. Another way to reproduce this would be
to create a file named fcntl:

cat >> fcntl.py << EOF
print "FOOOOBAR"
EOF

This file is also automatically imported besides the files
bike.py, compiler.py, parser.py, symbol.py, token.py, struct.py
cStringIO.py, dis.py, opcode.py, new.py, re.py, sre.py
sre_compile.py, sre_constants.py, sre_parse.py, __future__.py
string.py, strop.py, tempfile.py, random.py, math.py, binascii.py
_random.py and fcntl.py


Something should prepend '.' to syspath but I don't see
anything doing this :/

Kind regards
Nico
--
Nico Golde - http://www.ngolde.de - nion@... - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.

[Debian Bug Tracking System]

Processing commands for control@...:

> severity 484305 grave
Bug#484305: bicyclerepair: bike.vim imports untrusted python files from cwd
Severity set to `grave' from `critical'

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[James Vega-2]

On Mon, Jul 07, 2008 at 07:11:10PM +0200, Nico Golde wrote:

> Hi Thomas,
> * Thomas Arendsen Hein <thomas@...> [2008-07-06 22:53]:
> > * Steffen Joeris <steffen.joeris@...> [20080706 11:15]:
> > > severity 484305 important
> > > thanks
> >
> > Please do not downgrade severity without providing a reason.
>
> "critical makes unrelated software on the system (or the whole system)
> break, or causes serious data loss, or introduces a security
> hole on systems where you install the package."
>
> I had a look at the issue now and this is not the case
> because you have to a) install vim-python and bicyclerepair
> together and b) set vim.python as the vim alternative.
> Thus downgrading this bug.

In Lenny/Sid, all Vim packages except vim-tiny and vim contain the
python support, so it is more likely that a user will have a vim binary
that can be scripted via Python.

On the other hand, in Lenny/Sid the path that plugins used to be
installed to (/usr/share/vim/addons) is no longer automatically included
in Vim's runtimepath.  This means that manual work is required to enable
the plugin.

> [...]
> > On etch:
> >
> > $ dpkg -l bicyclerepair|grep ^i
> > ii  bicyclerepair       0.9-4.1             A refactoring tool for python
> >
> > $ dpkg -L bicyclerepair|grep vim
> > /usr/share/doc/bicyclerepair/README.vim
> > /usr/share/vim
> > /usr/share/vim/vim62
> > /usr/share/vim/vim62/plugin
> > /usr/share/vim/vim62/plugin/bike.vim
> > /usr/share/vim/vim63
> > /usr/share/vim/vim63/plugin
> > /usr/share/vim/vim63/plugin/bike.vim
> > /usr/share/vim/addons
> > /usr/share/vim/addons/plugin
> > /usr/share/vim/addons/plugin/bike.vim
> >
> > Maybe (I haven't verified) you need:
> > /etc/alternatives/vim -> /usr/bin/vim.python
>
> Indeed, this is needed (+ installation of vim-python).
> So to sum up you need to install vim-python and set the
> alternative to vim.python. I am not sure about the status of
> this in unstable, at least I could not reproduce this on
> unstable but vim.python is also no longer available there,
> a lot in the vim structure changed since then and I don't
> really have an idea about the scripting support of vim.
>
> That's why I Cc'ed the vim maintainers. Do you think this
> should also work in the same way in unstable/testing?

See above explanation.

Also, taking a look at the current bicyclerepair package, the addon is
now installed to /usr/share/addons/vim/ftplugin/python_bike.vim.  This
means that the functionality will only be used when editing python files
(once the user has enabled the plugin) instead of when editing any file,
as was the case when it was installed to plugins/bike.vim.

> I am also not really sure what is causing the automatic
> import.

Python, by default, has '' as the initial item in its sys.path list

  $ python
  Python 2.5.2 (r252:60911, Jun 25 2008, 17:58:32)
  [GCC 4.3.1] on linux2
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import sys
  >>> sys.path
  ['', '/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2', '/usr/lib/python2.5/lib-tk', '/usr/lib/python2.5/lib-dynload', '/usr/local/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages/Numeric', '/usr/lib/python2.5/site-packages/gst-0.10', '/var/lib/python-support/python2.5', '/var/lib/python-support/python2.5/gtk-2.0']

This means that anything in the current directory is first priority when
trying to use/import a module.

/usr/lib/pythonX.Y/compiler/transformer.py has the following lines that
are run when the module is imported

  import token
  ...
  _cmp_types = {
      token.LESS : '<',
      token.GREATER : '>',
      token.EQEQUAL : '==',
      token.EQUAL : '==',
      token.LESSEQUAL : '<=',
      token.GREATEREQUAL : '>=',
      token.NOTEQUAL : '!=',
      }

When the bike Vim plugin is loaded, it imports the bike python module,
which imports compiler (and therefore compiler.transformer).  Since
Vim's current working directory is roundup-X.Y/roundup, the above lines
from transformer.py combined with '' being the first item in sys.path
cause python to load the token module in the current working directory
(from roundup's source) instead of using /usr/lib/pythonX.Y/token.py.

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@...>

[Nico Golde-6]

Hi James,
* James Vega <jamessan@...> [2008-07-07 20:11]:
> On Mon, Jul 07, 2008 at 07:11:10PM +0200, Nico Golde wrote:
> > * Thomas Arendsen Hein <thomas@...> [2008-07-06 22:53]:
> > > * Steffen Joeris <steffen.joeris@...> [20080706 11:15]:
[...]
> In Lenny/Sid, all Vim packages except vim-tiny and vim contain the
> python support, so it is more likely that a user will have a vim binary
> that can be scripted via Python.
>
> On the other hand, in Lenny/Sid the path that plugins used to be
> installed to (/usr/share/vim/addons) is no longer automatically included
> in Vim's runtimepath.  This means that manual work is required to enable
> the plugin.

Ok, thanks for this information!

[...]

> > That's why I Cc'ed the vim maintainers. Do you think this
> > should also work in the same way in unstable/testing?
>
> See above explanation.
>
> Also, taking a look at the current bicyclerepair package, the addon is
> now installed to /usr/share/addons/vim/ftplugin/python_bike.vim.  This
> means that the functionality will only be used when editing python files
> (once the user has enabled the plugin) instead of when editing any file,
> as was the case when it was installed to plugins/bike.vim.

Ok

> > I am also not really sure what is causing the automatic
> > import.
>
> Python, by default, has '' as the initial item in its sys.path list
>
>   $ python
>   Python 2.5.2 (r252:60911, Jun 25 2008, 17:58:32)
>   [GCC 4.3.1] on linux2
>   Type "help", "copyright", "credits" or "license" for more information.
>   >>> import sys
>   >>> sys.path
>   ['', '/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2', '/usr/lib/python2.5/lib-tk', '/usr/lib/python2.5/lib-dynload', '/usr/local/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages/Numeric', '/usr/lib/python2.5/site-packages/gst-0.10', '/var/lib/python-support/python2.5', '/var/lib/python-support/python2.5/gtk-2.0']
>
> This means that anything in the current directory is first priority when
> trying to use/import a module.

This should only happen in an interactive session, not!?
nion@coredump:/tmp$] mkdir somedir
[nion@coredump:/tmp$] cd somedir
[nion@coredump:somedir$] cat > /tmp/test.py << EOF
heredoc> import sys
heredoc> print sys.path
heredoc> EOF
[nion@coredump:somedir$] python /tmp/test.py
['/tmp', '/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2', '/usr/lib/python2.5/lib-tk', '/usr/lib/python2.5/lib-dynload', '/usr/local/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages/Numeric', '/usr/lib/python2.5/site-packages/PIL', '/var/lib/python-support/python2.5', '/var/lib/python-support/python2.5/gtk-2.0', '/usr/lib/python2.5/site-packages/wx-2.6-gtk2-unicode']

The python docs also state "As initialized upon program startup, the first item
of this list, path[0], is the directory containing the script that was used to
invoke the Python interpreter."
So this should be no problem unless I missed your point.

> /usr/lib/pythonX.Y/compiler/transformer.py has the following lines that
> are run when the module is imported
>
>   import token
>   ...
>   _cmp_types = {
>       token.LESS : '<',
>       token.GREATER : '>',
>       token.EQEQUAL : '==',
>       token.EQUAL : '==',
>       token.LESSEQUAL : '<=',
>       token.GREATEREQUAL : '>=',
>       token.NOTEQUAL : '!=',
>       }
>
> When the bike Vim plugin is loaded, it imports the bike python module,
> which imports compiler (and therefore compiler.transformer).  Since
> Vim's current working directory is roundup-X.Y/roundup, the above lines
> from transformer.py combined with '' being the first item in sys.path
> cause python to load the token module in the current working directory
> (from roundup's source) instead of using /usr/lib/pythonX.Y/token.py.

I'd agree if that would be the case in a python script, I had this thought
as well first but this doesn't seem to work. That's why I said that I don't
see something like sys.path = [os.curdir] + sys.path in the code.

Did I misunderstand what you wrote?

Thanks for your help James!
Cheers
Nico
--
Nico Golde - http://www.ngolde.de - nion@... - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.

[James Vega-2]

On Mon, Jul 07, 2008 at 09:16:21PM +0200, Nico Golde wrote:

> Hi James,
> * James Vega <jamessan@...> [2008-07-07 20:11]:
> > On Mon, Jul 07, 2008 at 07:11:10PM +0200, Nico Golde wrote:
> > > I am also not really sure what is causing the automatic
> > > import.
> >
> > Python, by default, has '' as the initial item in its sys.path list
> >
> >   $ python
> >   Python 2.5.2 (r252:60911, Jun 25 2008, 17:58:32)
> >   [GCC 4.3.1] on linux2
> >   Type "help", "copyright", "credits" or "license" for more information.
> >   >>> import sys
> >   >>> sys.path
> >   ['', '/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2', '/usr/lib/python2.5/lib-tk', '/usr/lib/python2.5/lib-dynload', '/usr/local/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages/Numeric', '/usr/lib/python2.5/site-packages/gst-0.10', '/var/lib/python-support/python2.5', '/var/lib/python-support/python2.5/gtk-2.0']
> >
> > This means that anything in the current directory is first priority when
> > trying to use/import a module.
>
> This should only happen in an interactive session, not!?
> nion@coredump:/tmp$] mkdir somedir
> [nion@coredump:/tmp$] cd somedir
> [nion@coredump:somedir$] cat > /tmp/test.py << EOF
> heredoc> import sys
> heredoc> print sys.path
> heredoc> EOF
> [nion@coredump:somedir$] python /tmp/test.py
> ['/tmp', '/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2', '/usr/lib/python2.5/lib-tk', '/usr/lib/python2.5/lib-dynload', '/usr/local/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages/Numeric', '/usr/lib/python2.5/site-packages/PIL', '/var/lib/python-support/python2.5', '/var/lib/python-support/python2.5/gtk-2.0', '/usr/lib/python2.5/site-packages/wx-2.6-gtk2-unicode']
>
> The python docs also state "As initialized upon program startup, the first item
> of this list, path[0], is the directory containing the script that was used to
> invoke the Python interpreter."

In an interactive session, sys.path[0] is '' because the "script" is
simply the python interpreter.  In your example, if you were in /tmp
when you ran test.py you would have seen '' as sys.path[0] as well.

In the case of Vim, sys.path[0] is always Vim's current working
directory.

/tmp $ mkdir somedir
/tmp $ cat test.vim
function! ShowPath()
    python << EOF
import os
import sys
print os.getcwd()
print repr(sys.path[0])
EOF
endfunction
call ShowPath()
cd somedir
call ShowPath()
q
/tmp $ python -S test.vim
/tmp
''
/tmp/somedir
''

From what I can tell, every time the :python command (which is simply a
thin wrapper to the PyRun_SimpleString function from Python's library)
is run from Vim, it's like running a new script.

This would explain why why sys.path[0] and os.getcwd() are updated when
we change the current working directory of the Vim process.

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@...>

[Nico Golde-6]

Hi James,
* James Vega <jamessan@...> [2008-07-07 22:04]:
> On Mon, Jul 07, 2008 at 09:16:21PM +0200, Nico Golde wrote:
> > * James Vega <jamessan@...> [2008-07-07 20:11]:
> > > On Mon, Jul 07, 2008 at 07:11:10PM +0200, Nico Golde wrote:
[...]

> > [nion@coredump:somedir$] python /tmp/test.py
> > ['/tmp', '/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2', '/usr/lib/python2.5/lib-tk', '/usr/lib/python2.5/lib-dynload', '/usr/local/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages', '/usr/lib/python2.5/site-packages/Numeric', '/usr/lib/python2.5/site-packages/PIL', '/var/lib/python-support/python2.5', '/var/lib/python-support/python2.5/gtk-2.0', '/usr/lib/python2.5/site-packages/wx-2.6-gtk2-unicode']
> >
> > The python docs also state "As initialized upon program startup, the first item
> > of this list, path[0], is the directory containing the script that was used to
> > invoke the Python interpreter."
>
> In an interactive session, sys.path[0] is '' because the "script" is
> simply the python interpreter.  In your example, if you were in /tmp
> when you ran test.py you would have seen '' as sys.path[0] as well.

Yes sure that conforms to the quote from the python docs.

> In the case of Vim, sys.path[0] is always Vim's current working
> directory.
[...]
> From what I can tell, every time the :python command (which is simply a
> thin wrapper to the PyRun_SimpleString function from Python's library)
> is run from Vim, it's like running a new script.
>
> This would explain why why sys.path[0] and os.getcwd() are updated when
> we change the current working directory of the Vim process.

Ok, that explains why this happens. This is somehow bad
because everyone who writes a python vim script needs to be
aware of that.

Can you think of a better solution than the following?
--- /usr/share/vim/addons/plugin/bike.vim       2008-07-07 22:14:28.000000000 +0200
+++ bike.vim.new        2008-07-07 22:14:26.000000000 +0200
@@ -100,6 +100,7 @@
 try:
     if sys.version_info < (2, 2):
         raise ImportError, 'Bicycle Repair Man needs Python 2.2 or newer'
+    sys.path.remove('')
     import bike
     bikectx = bike.init()
     bikectx.isLoaded        # make sure bike package is recent enough

Kind regards
Nico
--
Nico Golde - http://www.ngolde.de - nion@... - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.

[James Vega-3]

On Mon, Jul 07, 2008 at 10:15:44PM +0200, Nico Golde wrote:

> Can you think of a better solution than the following?
> --- /usr/share/vim/addons/plugin/bike.vim       2008-07-07 22:14:28.000000000 +0200
> +++ bike.vim.new        2008-07-07 22:14:26.000000000 +0200
> @@ -100,6 +100,7 @@
>  try:
>      if sys.version_info < (2, 2):
>          raise ImportError, 'Bicycle Repair Man needs Python 2.2 or newer'
> +    sys.path.remove('')
>      import bike
>      bikectx = bike.init()
>      bikectx.isLoaded        # make sure bike package is recent enough

I think this is being addressed from the wrong perspective.  This is a
Python problem.  Performing "import compiler", where compiler is a
module in the std-lib and performs its own import of another std-lib
module should not cause the module in the user's working directory to be
imported instead.

As evidenced by PEP 328[0] and PEP 366[1], this is an acknowledged
problem upstream and they're working to address it.  As for what that
means for the current bug, this is something that python users have to
deal with when they have a file whose name conflicts with one in the
std-lib.  This also means that the *only* time users will run into
issues like this are specifically when they have a filename in Vim's
working directory that conflicts with the name of a Python module.

[0] - http://www.python.org/dev/peps/pep-0328/
[1] - http://www.python.org/dev/peps/pep-0366/
--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@...>

[Nico Golde-6]

Hi James,
* James Vega <jamessan@...> [2008-07-07 23:42]:

> On Mon, Jul 07, 2008 at 10:15:44PM +0200, Nico Golde wrote:
> > Can you think of a better solution than the following?
> > --- /usr/share/vim/addons/plugin/bike.vim       2008-07-07 22:14:28.000000000 +0200
> > +++ bike.vim.new        2008-07-07 22:14:26.000000000 +0200
> > @@ -100,6 +100,7 @@
> >  try:
> >      if sys.version_info < (2, 2):
> >          raise ImportError, 'Bicycle Repair Man needs Python 2.2 or newer'
> > +    sys.path.remove('')
> >      import bike
> >      bikectx = bike.init()
> >      bikectx.isLoaded        # make sure bike package is recent enough
>
> I think this is being addressed from the wrong perspective.

Yes I agree, I would also be not really happy about this
solution as all module writes would need to be aware of this
problem.

> This is a Python problem.  Performing "import compiler", where compiler is a
> module in the std-lib and performs its own import of another std-lib
> module should not cause the module in the user's working directory to be
> imported instead.
>
> As evidenced by PEP 328[0] and PEP 366[1], this is an acknowledged
> problem upstream and they're working to address it.  As for what that
> means for the current bug, this is something that python users have to
> deal with when they have a file whose name conflicts with one in the
> std-lib.  This also means that the *only* time users will run into
> issues like this are specifically when they have a filename in Vim's
> working directory that conflicts with the name of a Python module.

Do you think reassigning this to python would be
appropriate?

Thanks for the PEP links, I wasn't aware of them.

Kind regards
Nico
--
Nico Golde - http://www.ngolde.de - nion@... - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.

[James Vega-2]

On Tue, Jul 08, 2008 at 10:18:46PM +0200, Nico Golde wrote:

> Hi James,
> * James Vega <jamessan@...> [2008-07-07 23:42]:
> > On Mon, Jul 07, 2008 at 10:15:44PM +0200, Nico Golde wrote:
> > > Can you think of a better solution than the following?
> > > --- /usr/share/vim/addons/plugin/bike.vim       2008-07-07 22:14:28.000000000 +0200
> > > +++ bike.vim.new        2008-07-07 22:14:26.000000000 +0200
> > > @@ -100,6 +100,7 @@
> > >  try:
> > >      if sys.version_info < (2, 2):
> > >          raise ImportError, 'Bicycle Repair Man needs Python 2.2 or newer'
> > > +    sys.path.remove('')
> > >      import bike
> > >      bikectx = bike.init()
> > >      bikectx.isLoaded        # make sure bike package is recent enough
> >
> > I think this is being addressed from the wrong perspective.
>
> Yes I agree, I would also be not really happy about this
> solution as all module writes would need to be aware of this
> problem.
>
> > This is a Python problem.  Performing "import compiler", where compiler is a
> > module in the std-lib and performs its own import of another std-lib
> > module should not cause the module in the user's working directory to be
> > imported instead.
> >
> > As evidenced by PEP 328[0] and PEP 366[1], this is an acknowledged
> > problem upstream and they're working to address it.  As for what that
> > means for the current bug, this is something that python users have to
> > deal with when they have a file whose name conflicts with one in the
> > std-lib.  This also means that the *only* time users will run into
> > issues like this are specifically when they have a filename in Vim's
> > working directory that conflicts with the name of a Python module.
>
> Do you think reassigning this to python would be
> appropriate?

That would probably be a better place for it, yes.  I definitely don't
think it's a bug in Vim or the specific Vim script and I'm unsure
whether it's truly a bug in Python or just less-than-ideal behavior.
Even with the listed PEPs implemented, it sounds like this behavior is
still possible, just not as likely.

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@...>