Debian Bug report logs - #493937
bicyclerepair: bike.vim imports untrusted python files from cwd

version graph

Package: vim-python; Maintainer for vim-python is (unknown);

Reported by: Thomas Arendsen Hein <thomas@intevation.de>

Date: Tue, 3 Jun 2008 15:42:02 UTC

Severity: important

Tags: security

Fixed in versions vim/1:7.1.314-3+lenny2, vim/2:7.2.025-2

Done: James Vega <jamessan@debian.org>

Bug is archived. No further changes may be made.

Forwarded to Bram Moolenaar <Bram@moolenaar.net>

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian Security Team <team@security.debian.org>, Robert Collins <robertc@robertcollins.net>:
Bug#484305; Package bicyclerepair. Full text and rfc822 format available.

Acknowledgement sent to Thomas Arendsen Hein <thomas@intevation.de>:
New Bug report received and forwarded. Copy sent to Debian Security Team <team@security.debian.org>, Robert Collins <robertc@robertcollins.net>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Thomas Arendsen Hein <thomas@intevation.de>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: bicyclerepair: bike.vim imports untrusted python files from cwd
Date: Tue, 3 Jun 2008 17:40:03 +0200
Package: bicyclerepair
Version: 0.9-4.1
Severity: critical
Tags: security
Justification: root security hole

# pwd
/tmp/roundup-1.3.3/roundup
# vim /tmp/whatever
Error detected while processing /usr/share/vim/addons/plugin/bike.vim:
line  110:
Traceback (most recent call last):
  File "<string>", line 6, in ?
  File "/usr/lib/python2.4/site-packages/bike/__init__.py", line 10, in ?
    from bikefacade import init, NotAPythonModuleOrPackageException, CouldntLoca
teASTNodeFromCoordinatesException, UndoStackEmptyException
  File "/usr/lib/python2.4/site-packages/bike/bikefacade.py", line 3, in ?
    import compiler
  File "__init__.py", line 24, in ?

  File "compiler/transformer.py", line 1348, in ?
AttributeError: 'module' object has no attribute 'LESS'
Press ENTER or type command to continue


bicyclerepair contains /usr/share/vim/addons/plugin/bike.vim which is
automatically executed, at least in etch. I don't know about lenny/sid,
see #464817 (bicyclerepair: Conform with Vim addon policy)

It imports (i.e. runs) python code it finds in the current working
directory, in my example from the extracted roundup tarball.

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". The description for "grave" said, that it only
applies if the security problem affects people actually using the package.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.24.3-id1-k8-2
Locale: LANG=en_US, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15)

Versions of packages bicyclerepair depends on:
ii  python                        2.4.4-2    An interactive high-level object-o
ii  python-central                0.5.12     register and build utility for Pyt

bicyclerepair recommends no packages.

-- no debconf information

-- 
thomas@intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
Intevation GmbH, Osnabrueck - Register: Amtsgericht Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner




Information forwarded to debian-bugs-dist@lists.debian.org, Robert Collins <robertc@robertcollins.net>:
Bug#484305; Package bicyclerepair. Full text and rfc822 format available.

Acknowledgement sent to Steffen Joeris <steffen.joeris@skolelinux.de>:
Extra info received and forwarded to list. Copy sent to Robert Collins <robertc@robertcollins.net>. Full text and rfc822 format available.

Message #10 received at 484305@bugs.debian.org (full text, mbox):

From: Steffen Joeris <steffen.joeris@skolelinux.de>
To: 484305@bugs.debian.org
Cc: control@bugs.debian.org
Subject: PoC not working for bicyclerepair
Date: Sun, 6 Jul 2008 11:04:13 +0200
[Message part 1 (text/plain, inline)]
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
[signature.asc (application/pgp-signature, inline)]

Severity set to `important' from `critical' Request was from Steffen Joeris <steffen.joeris@skolelinux.de> to control@bugs.debian.org. (Sun, 06 Jul 2008 09:06:03 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Robert Collins <robertc@robertcollins.net>:
Bug#484305; Package bicyclerepair. Full text and rfc822 format available.

Acknowledgement sent to Thomas Arendsen Hein <thomas@intevation.de>:
Extra info received and forwarded to list. Copy sent to Robert Collins <robertc@robertcollins.net>. Full text and rfc822 format available.

Message #17 received at 484305@bugs.debian.org (full text, mbox):

From: Thomas Arendsen Hein <thomas@intevation.de>
To: Steffen Joeris <steffen.joeris@skolelinux.de>
Cc: 484305@bugs.debian.org, control@bugs.debian.org
Subject: Re: PoC not working for bicyclerepair
Date: Sun, 6 Jul 2008 22:24:57 +0200
[Message part 1 (text/plain, inline)]
severity 484305 critical
thanks

* Steffen Joeris <steffen.joeris@skolelinux.de> [20080706 11:15]:
> severity 484305 important
> thanks

Please do not downgrade severity without providing a reason. 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". The description for "grave" said, that it only
| applies if the security problem affects people actually using the package.

> 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
> 
> 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.

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

On lenny the plugin is indeed stored in
/usr/share/vim/addons/ftplugin/python_bike.vim

Regards,
Thomas

-- 
thomas@intevation.de - http://intevation.de/~thomas/ - OpenPGP key: 0x5816791A
Intevation GmbH, Osnabrueck - Register: Amtsgericht Osnabrueck, HR B 18998
Geschaeftsfuehrer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
[Message part 2 (application/pgp-signature, inline)]

Severity set to `critical' from `important' Request was from Thomas Arendsen Hein <thomas@intevation.de> to control@bugs.debian.org. (Sun, 06 Jul 2008 20:30:10 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Robert Collins <robertc@robertcollins.net>:
Bug#484305; Package bicyclerepair. Full text and rfc822 format available.

Acknowledgement sent to Nico Golde <nion@debian.org>:
Extra info received and forwarded to list. Copy sent to Robert Collins <robertc@robertcollins.net>. Full text and rfc822 format available.

Message #24 received at 484305@bugs.debian.org (full text, mbox):

From: Nico Golde <nion@debian.org>
To: Thomas Arendsen Hein <thomas@intevation.de>, 484305@bugs.debian.org
Cc: Steffen Joeris <steffen.joeris@skolelinux.de>, control@bugs.debian.org, pkg-vim-maintainers@lists.alioth.debian.org
Subject: Re: Bug#484305: PoC not working for bicyclerepair
Date: Mon, 7 Jul 2008 19:11:10 +0200
[Message part 1 (text/plain, inline)]
severity 484305 grave
thanks

Hi Thomas,
* Thomas Arendsen Hein <thomas@intevation.de> [2008-07-06 22:53]:
> * Steffen Joeris <steffen.joeris@skolelinux.de> [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@jabber.ccc.de - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.
[Message part 2 (application/pgp-signature, inline)]

Severity set to `grave' from `critical' Request was from Nico Golde <nion@debian.org> to control@bugs.debian.org. (Mon, 07 Jul 2008 17:15:06 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Robert Collins <robertc@robertcollins.net>:
Bug#484305; Package bicyclerepair. Full text and rfc822 format available.

Acknowledgement sent to James Vega <jamessan@debian.org>:
Extra info received and forwarded to list. Copy sent to Robert Collins <robertc@robertcollins.net>. Full text and rfc822 format available.

Message #31 received at 484305@bugs.debian.org (full text, mbox):

From: James Vega <jamessan@debian.org>
To: Nico Golde <nion@debian.org>
Cc: Thomas Arendsen Hein <thomas@intevation.de>, 484305@bugs.debian.org, pkg-vim-maintainers@lists.alioth.debian.org, Steffen Joeris <steffen.joeris@skolelinux.de>
Subject: Re: Bug#484305: PoC not working for bicyclerepair
Date: Mon, 7 Jul 2008 14:10:37 -0400
[Message part 1 (text/plain, inline)]
On Mon, Jul 07, 2008 at 07:11:10PM +0200, Nico Golde wrote:
> Hi Thomas,
> * Thomas Arendsen Hein <thomas@intevation.de> [2008-07-06 22:53]:
> > * Steffen Joeris <steffen.joeris@skolelinux.de> [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@debian.org>
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Robert Collins <robertc@robertcollins.net>:
Bug#484305; Package bicyclerepair. Full text and rfc822 format available.

Acknowledgement sent to Nico Golde <nion@debian.org>:
Extra info received and forwarded to list. Copy sent to Robert Collins <robertc@robertcollins.net>. Full text and rfc822 format available.

Message #36 received at 484305@bugs.debian.org (full text, mbox):

From: Nico Golde <nion@debian.org>
To: Thomas Arendsen Hein <thomas@intevation.de>, 484305@bugs.debian.org, pkg-vim-maintainers@lists.alioth.debian.org, Steffen Joeris <steffen.joeris@skolelinux.de>
Subject: Re: Bug#484305: PoC not working for bicyclerepair
Date: Mon, 7 Jul 2008 21:16:21 +0200
[Message part 1 (text/plain, inline)]
Hi James,
* James Vega <jamessan@debian.org> [2008-07-07 20:11]:
> On Mon, Jul 07, 2008 at 07:11:10PM +0200, Nico Golde wrote:
> > * Thomas Arendsen Hein <thomas@intevation.de> [2008-07-06 22:53]:
> > > * Steffen Joeris <steffen.joeris@skolelinux.de> [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@jabber.ccc.de - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Robert Collins <robertc@robertcollins.net>:
Bug#484305; Package bicyclerepair. Full text and rfc822 format available.

Acknowledgement sent to James Vega <jamessan@debian.org>:
Extra info received and forwarded to list. Copy sent to Robert Collins <robertc@robertcollins.net>. Full text and rfc822 format available.

Message #41 received at 484305@bugs.debian.org (full text, mbox):

From: James Vega <jamessan@debian.org>
To: Nico Golde <nion@debian.org>
Cc: Thomas Arendsen Hein <thomas@intevation.de>, 484305@bugs.debian.org, pkg-vim-maintainers@lists.alioth.debian.org, Steffen Joeris <steffen.joeris@skolelinux.de>
Subject: Re: Bug#484305: PoC not working for bicyclerepair
Date: Mon, 7 Jul 2008 16:03:53 -0400
[Message part 1 (text/plain, inline)]
On Mon, Jul 07, 2008 at 09:16:21PM +0200, Nico Golde wrote:
> Hi James,
> * James Vega <jamessan@debian.org> [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@debian.org>
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Robert Collins <robertc@robertcollins.net>:
Bug#484305; Package bicyclerepair. Full text and rfc822 format available.

Acknowledgement sent to Nico Golde <nion@debian.org>:
Extra info received and forwarded to list. Copy sent to Robert Collins <robertc@robertcollins.net>. Full text and rfc822 format available.

Message #46 received at 484305@bugs.debian.org (full text, mbox):

From: Nico Golde <nion@debian.org>
To: Thomas Arendsen Hein <thomas@intevation.de>, 484305@bugs.debian.org, pkg-vim-maintainers@lists.alioth.debian.org, Steffen Joeris <steffen.joeris@skolelinux.de>
Subject: Re: Bug#484305: PoC not working for bicyclerepair
Date: Mon, 7 Jul 2008 22:15:44 +0200
[Message part 1 (text/plain, inline)]
Hi James,
* James Vega <jamessan@debian.org> [2008-07-07 22:04]:
> On Mon, Jul 07, 2008 at 09:16:21PM +0200, Nico Golde wrote:
> > * James Vega <jamessan@debian.org> [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@jabber.ccc.de - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Robert Collins <robertc@robertcollins.net>:
Bug#484305; Package bicyclerepair. Full text and rfc822 format available.

Acknowledgement sent to James Vega <jamessan@jamessan.com>:
Extra info received and forwarded to list. Copy sent to Robert Collins <robertc@robertcollins.net>. Full text and rfc822 format available.

Message #51 received at 484305@bugs.debian.org (full text, mbox):

From: James Vega <jamessan@jamessan.com>
To: Nico Golde <nion@debian.org>
Cc: Thomas Arendsen Hein <thomas@intevation.de>, 484305@bugs.debian.org, pkg-vim-maintainers@lists.alioth.debian.org, Steffen Joeris <steffen.joeris@skolelinux.de>
Subject: Re: Bug#484305: PoC not working for bicyclerepair
Date: Mon, 7 Jul 2008 17:40:22 -0400
[Message part 1 (text/plain, inline)]
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@debian.org>
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Robert Collins <robertc@robertcollins.net>:
Bug#484305; Package bicyclerepair. Full text and rfc822 format available.

Acknowledgement sent to Nico Golde <nion@debian.org>:
Extra info received and forwarded to list. Copy sent to Robert Collins <robertc@robertcollins.net>. Full text and rfc822 format available.

Message #56 received at 484305@bugs.debian.org (full text, mbox):

From: Nico Golde <nion@debian.org>
To: Thomas Arendsen Hein <thomas@intevation.de>, 484305@bugs.debian.org, pkg-vim-maintainers@lists.alioth.debian.org, Steffen Joeris <steffen.joeris@skolelinux.de>
Subject: Re: Bug#484305: PoC not working for bicyclerepair
Date: Tue, 8 Jul 2008 22:18:46 +0200
[Message part 1 (text/plain, inline)]
Hi James,
* James Vega <jamessan@jamessan.com> [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@jabber.ccc.de - GPG: 0x73647CFF
For security reasons, all text in this mail is double-rot13 encrypted.
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Robert Collins <robertc@robertcollins.net>:
Bug#484305; Package bicyclerepair. Full text and rfc822 format available.

Acknowledgement sent to James Vega <jamessan@debian.org>:
Extra info received and forwarded to list. Copy sent to Robert Collins <robertc@robertcollins.net>. Full text and rfc822 format available.

Message #61 received at 484305@bugs.debian.org (full text, mbox):

From: James Vega <jamessan@debian.org>
To: Nico Golde <nion@debian.org>
Cc: Thomas Arendsen Hein <thomas@intevation.de>, 484305@bugs.debian.org, pkg-vim-maintainers@lists.alioth.debian.org, Steffen Joeris <steffen.joeris@skolelinux.de>
Subject: Re: Bug#484305: PoC not working for bicyclerepair
Date: Tue, 8 Jul 2008 16:51:25 -0400
[Message part 1 (text/plain, inline)]
On Tue, Jul 08, 2008 at 10:18:46PM +0200, Nico Golde wrote:
> Hi James,
> * James Vega <jamessan@jamessan.com> [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@debian.org>
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Robert Collins <robertc@robertcollins.net>:
Bug#484305; Package bicyclerepair. Full text and rfc822 format available.

Acknowledgement sent to Simon McVittie <smcv@debian.org>:
Extra info received and forwarded to list. Copy sent to Robert Collins <robertc@robertcollins.net>. Full text and rfc822 format available.

Message #66 received at 484305@bugs.debian.org (full text, mbox):

From: Simon McVittie <smcv@debian.org>
To: 484305@bugs.debian.org
Cc: control@bugs.debian.org
Subject: Re: Bug#484305: bicyclerepair: bike.vim imports untrusted python files from cwd
Date: Wed, 6 Aug 2008 01:39:15 +0100
[Message part 1 (text/plain, inline)]
clone 484305 -1
reassign -1 vim-python
thanks

Shouldn't Python builds of vim avoid this bug by stopping '' from being
prepended to sys.path in the first place?

After looking through Python initialization and vim's if_python.c it
seems that the way forward is to set Python's argv, via PySys_SetArgv(),
to have a non-empty and absolute first argument.

vim sets Python's argv to  { "", NULL }, which according to a comment is to
avoid a crash when warn() is called. Changing that to { "/usr/bin/vim", NULL }
would seem to solve this problem - but for that matter, any safe value is fine.

A safe value for argv[0] is any value where there won't be files dir/*.py or
dir/*/__init__.py, where dir == dirname(argv[0]). So setting argv[0] to
"/", "/usr/lib/something" or "/usr/share/vim" would be safe too, for instance.

I'm afraid I haven't tested this in vim itself (the multiple builds take a
while...) but the attached program demonstrates it:

smcv@carbon% gcc -o484305 `python-config --cflags` `python-config --ldflags` 484305.c
smcv@carbon% ./484305
(I have no argv!)
['/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2',
... more output ...
'/var/lib/python-support/python2.5/pyinotify']
smcv@carbon% ./484305 ""
['']
['', '/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2',
... more output ...
'/var/lib/python-support/python2.5/pyinotify']
smcv@carbon% ./484305 "/usr/bin/vim"
['/usr/bin/vim']
['/usr/bin', '/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2',
... more output ...
'/var/lib/python-support/python2.5/pyinotify']

Hope this helps,
    Simon
[484305.c (text/x-csrc, attachment)]

Bug 484305 cloned as bug 493937. Request was from Simon McVittie <smcv@debian.org> to control@bugs.debian.org. (Wed, 06 Aug 2008 00:42:02 GMT) Full text and rfc822 format available.

Bug reassigned from package `bicyclerepair' to `vim-python'. Request was from Simon McVittie <smcv@debian.org> to control@bugs.debian.org. (Wed, 06 Aug 2008 00:42:04 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Vim Maintainers <pkg-vim-maintainers@lists.alioth.debian.org>:
Bug#493937; Package vim-python. Full text and rfc822 format available.

Acknowledgement sent to James Vega <jamessan@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Vim Maintainers <pkg-vim-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #75 received at 493937@bugs.debian.org (full text, mbox):

From: James Vega <jamessan@debian.org>
To: Simon McVittie <smcv@debian.org>, 484305@bugs.debian.org
Cc: 493937@bugs.debian.org, Nico Golde <nion@debian.org>, Steffen Joeris <steffen.joeris@skolelinux.de>
Subject: Re: Bug#484305: bicyclerepair: bike.vim imports untrusted python files from cwd
Date: Tue, 5 Aug 2008 23:07:48 -0400
[Message part 1 (text/plain, inline)]
On Wed, Aug 06, 2008 at 01:39:15AM +0100, Simon McVittie wrote:
> Shouldn't Python builds of vim avoid this bug by stopping '' from being
> prepended to sys.path in the first place?

As I mentioned earlier[0][1] in the bug log, I don't think removing ''
from sys.argv is the correct change to make in Vim.

> After looking through Python initialization and vim's if_python.c it
> seems that the way forward is to set Python's argv, via PySys_SetArgv(),
> to have a non-empty and absolute first argument.
> 
> vim sets Python's argv to  { "", NULL }, which according to a comment is to
> avoid a crash when warn() is called. Changing that to { "/usr/bin/vim", NULL }
> would seem to solve this problem - but for that matter, any safe value is fine.

The way Vim is using PySys_SetArgv (and therefore the resulting
behavior) is exactly following the recommended use of PySys_SetArgv
according to upstream's documentation[2].

> A safe value for argv[0] is any value where there won't be files dir/*.py or
> dir/*/__init__.py, where dir == dirname(argv[0]). So setting argv[0] to
> "/", "/usr/lib/something" or "/usr/share/vim" would be safe too, for instance.
> 
> I'm afraid I haven't tested this in vim itself (the multiple builds take a
> while...) but the attached program demonstrates it:
> 
> smcv@carbon% gcc -o484305 `python-config --cflags` `python-config --ldflags` 484305.c
> smcv@carbon% ./484305
> (I have no argv!)
> ['/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2',
> ... more output ...
> '/var/lib/python-support/python2.5/pyinotify']
> smcv@carbon% ./484305 ""
> ['']
> ['', '/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2',
> ... more output ...
> '/var/lib/python-support/python2.5/pyinotify']
> smcv@carbon% ./484305 "/usr/bin/vim"
> ['/usr/bin/vim']
> ['/usr/bin', '/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2',
> ... more output ...
> '/var/lib/python-support/python2.5/pyinotify']

While this does provide a workaround for the issue, this is behavior
inherent in the way Python is designed and should be fixed in Python.
If we choose to instead address every application that embeds Python,
we're just creating an endless stream of work for ourselves.

From a quick check via Google's codesearch, at least X-Chat[3],
Gnumeric[4], python-nautilus[5], and gedit[6] are likely to have this
same problem.

N.B., most of the above projects use a single-element argv of the
project name.  This is no different than using a single-element argv of
"" since PySys_SetArgv attempts to resolve argv[0] to an absolute path
and uses "" when it is unable to do so.

[0] - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=484305#51
[1] - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=484305#61
[2] - "If there isn't a script that will be run, the first entry in argv
      can be an empty string."
      http://docs.python.org/api/initialization.html#l2h-881
[3] - http://ln-s.net/27az
[4] - http://ln-s.net/27ay
[5] - http://ln-s.net/27b1
[6] - http://ln-s.net/27b9
-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@debian.org>
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Vim Maintainers <pkg-vim-maintainers@lists.alioth.debian.org>:
Bug#493937; Package vim-python. Full text and rfc822 format available.

Acknowledgement sent to Robert Collins <robertc@robertcollins.net>:
Extra info received and forwarded to list. Copy sent to Debian Vim Maintainers <pkg-vim-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #80 received at 493937@bugs.debian.org (full text, mbox):

From: Robert Collins <robertc@robertcollins.net>
To: James Vega <jamessan@debian.org>, 484305@bugs.debian.org
Cc: Simon McVittie <smcv@debian.org>, 493937@bugs.debian.org, Nico Golde <nion@debian.org>, Steffen Joeris <steffen.joeris@skolelinux.de>
Subject: Re: Bug#484305: bicyclerepair: bike.vim imports untrusted python files from cwd
Date: Wed, 06 Aug 2008 13:21:23 +1000
[Message part 1 (text/plain, inline)]
On Tue, 2008-08-05 at 23:07 -0400, James Vega wrote:


> While this does provide a workaround for the issue, this is behavior
> inherent in the way Python is designed and should be fixed in Python.
> If we choose to instead address every application that embeds Python,
> we're just creating an endless stream of work for ourselves.

Possibly. I did file a bug [rejected] on reportbug itself just a few
days ago, because it also will load from . if '' is in the pythonpath.

OTOH perhaps having '' in sys.path is always wrong and we should start a
mass set of bugs to prevent it?

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
[signature.asc (application/pgp-signature, inline)]

Severity set to `important' from `grave' Request was from James Vega <jamessan@debian.org> to control@bugs.debian.org. (Tue, 23 Sep 2008 19:03:03 GMT) Full text and rfc822 format available.

Reply sent to James Vega <jamessan@debian.org>:
You have taken responsibility. (Fri, 17 Oct 2008 21:33:05 GMT) Full text and rfc822 format available.

Notification sent to Thomas Arendsen Hein <thomas@intevation.de>:
Bug acknowledged by developer. (Fri, 17 Oct 2008 21:33:47 GMT) Full text and rfc822 format available.

Message #87 received at 493937-close@bugs.debian.org (full text, mbox):

From: James Vega <jamessan@debian.org>
To: 493937-close@bugs.debian.org
Subject: Bug#493937: fixed in vim 1:7.1.314-3+lenny2
Date: Fri, 17 Oct 2008 21:02:41 +0000
Source: vim
Source-Version: 1:7.1.314-3+lenny2

We believe that the bug you reported is fixed in the latest version of
vim, which is due to be installed in the Debian FTP archive:

vim-common_7.1.314-3+lenny2_i386.deb
  to pool/main/v/vim/vim-common_7.1.314-3+lenny2_i386.deb
vim-dbg_7.1.314-3+lenny2_i386.deb
  to pool/main/v/vim/vim-dbg_7.1.314-3+lenny2_i386.deb
vim-doc_7.1.314-3+lenny2_all.deb
  to pool/main/v/vim/vim-doc_7.1.314-3+lenny2_all.deb
vim-full_7.1.314-3+lenny2_all.deb
  to pool/main/v/vim/vim-full_7.1.314-3+lenny2_all.deb
vim-gnome_7.1.314-3+lenny2_i386.deb
  to pool/main/v/vim/vim-gnome_7.1.314-3+lenny2_i386.deb
vim-gtk_7.1.314-3+lenny2_i386.deb
  to pool/main/v/vim/vim-gtk_7.1.314-3+lenny2_i386.deb
vim-gui-common_7.1.314-3+lenny2_all.deb
  to pool/main/v/vim/vim-gui-common_7.1.314-3+lenny2_all.deb
vim-lesstif_7.1.314-3+lenny2_i386.deb
  to pool/main/v/vim/vim-lesstif_7.1.314-3+lenny2_i386.deb
vim-nox_7.1.314-3+lenny2_i386.deb
  to pool/main/v/vim/vim-nox_7.1.314-3+lenny2_i386.deb
vim-perl_7.1.314-3+lenny2_all.deb
  to pool/main/v/vim/vim-perl_7.1.314-3+lenny2_all.deb
vim-python_7.1.314-3+lenny2_all.deb
  to pool/main/v/vim/vim-python_7.1.314-3+lenny2_all.deb
vim-ruby_7.1.314-3+lenny2_all.deb
  to pool/main/v/vim/vim-ruby_7.1.314-3+lenny2_all.deb
vim-runtime_7.1.314-3+lenny2_all.deb
  to pool/main/v/vim/vim-runtime_7.1.314-3+lenny2_all.deb
vim-tcl_7.1.314-3+lenny2_all.deb
  to pool/main/v/vim/vim-tcl_7.1.314-3+lenny2_all.deb
vim-tiny_7.1.314-3+lenny2_i386.deb
  to pool/main/v/vim/vim-tiny_7.1.314-3+lenny2_i386.deb
vim_7.1.314-3+lenny2.diff.gz
  to pool/main/v/vim/vim_7.1.314-3+lenny2.diff.gz
vim_7.1.314-3+lenny2.dsc
  to pool/main/v/vim/vim_7.1.314-3+lenny2.dsc
vim_7.1.314-3+lenny2_i386.deb
  to pool/main/v/vim/vim_7.1.314-3+lenny2_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 493937@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
James Vega <jamessan@debian.org> (supplier of updated vim package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Fri, 17 Oct 2008 10:58:00 -0400
Source: vim
Binary: vim-common vim-gui-common vim-runtime vim-doc vim-tiny vim vim-dbg vim-perl vim-python vim-ruby vim-tcl vim-gtk vim-nox vim-lesstif vim-gnome vim-full
Architecture: source all i386
Version: 1:7.1.314-3+lenny2
Distribution: testing-proposed-updates
Urgency: low
Maintainer: Debian Vim Maintainers <pkg-vim-maintainers@lists.alioth.debian.org>
Changed-By: James Vega <jamessan@debian.org>
Description: 
 vim        - Vi IMproved - enhanced vi editor
 vim-common - Vi IMproved - Common files
 vim-dbg    - Vi IMproved - enhanced vi editor (debugging symbols)
 vim-doc    - Vi IMproved - HTML documentation
 vim-full   - Vi IMproved - enhanced vi editor (transitional package)
 vim-gnome  - Vi IMproved - enhanced vi editor - with GNOME2 GUI
 vim-gtk    - Vi IMproved - enhanced vi editor - with GTK2 GUI
 vim-gui-common - Vi IMproved - Common GUI files
 vim-lesstif - Vi IMproved - enhanced vi editor - with LessTif GUI
 vim-nox    - Vi IMproved - enhanced vi editor
 vim-perl   - Vi IMproved - enhanced vi editor (transitional package)
 vim-python - Vi IMproved - enhanced vi editor (transitional package)
 vim-ruby   - Vi IMproved - enhanced vi editor (transitional package)
 vim-runtime - Vi IMproved - Runtime files
 vim-tcl    - Vi IMproved - enhanced vi editor (transitional package)
 vim-tiny   - Vi IMproved - enhanced vi editor - compact version
Closes: 493937
Changes: 
 vim (1:7.1.314-3+lenny2) testing-proposed-updates; urgency=low
 .
   * src/if_python.c: Strip empty directories from Python's sys.path to prevent
     Vim from using its current working directory as a module import path.
     (Closes: #493937)
Checksums-Sha1: 
 e1eb91d7c003dbca7a80d486dc66d3ca817990f4 1726 vim_7.1.314-3+lenny2.dsc
 3dd0b8aebbac4e4a1cc70c4a673d1b088965ccde 378498 vim_7.1.314-3+lenny2.diff.gz
 3cf7c4f2c8358c61563586e1cb5031bc3aeb873c 159836 vim-gui-common_7.1.314-3+lenny2_all.deb
 304c785e2c34a21bb38d0f29165700ed4e06bbcb 5594756 vim-runtime_7.1.314-3+lenny2_all.deb
 307bf72162291a4afc1b2276cda0f055069f4069 2151992 vim-doc_7.1.314-3+lenny2_all.deb
 c70e748a649ecf3a423ff19a999900fc4ee1b91b 75312 vim-perl_7.1.314-3+lenny2_all.deb
 9705fa3fe512aab99e6c1098fd0d7ba831c981d8 75318 vim-python_7.1.314-3+lenny2_all.deb
 be476f34e1e7cde3c79523bb4c4d9cc346a433dc 75314 vim-ruby_7.1.314-3+lenny2_all.deb
 44b237673263a5c8f3d1b405434f93fe62d16da3 75310 vim-tcl_7.1.314-3+lenny2_all.deb
 29e2cfd11b7ed0dd946958f47db041e909fd3395 75344 vim-full_7.1.314-3+lenny2_all.deb
 80da23bb7394e5543201690af3c8845e58576d3e 334966 vim-tiny_7.1.314-3+lenny2_i386.deb
 17c1cf84016536d49098409094777a9ac27588dd 994194 vim-gtk_7.1.314-3+lenny2_i386.deb
 6d90a9dfb631d8f4a21b9c59eecb0c5c7e881bce 996140 vim-gnome_7.1.314-3+lenny2_i386.deb
 4ec7e36283b596d2764a322ce7758114b7030a15 986582 vim-lesstif_7.1.314-3+lenny2_i386.deb
 099124132d1a4ad6530471d1d152d074722c8d6d 863142 vim-nox_7.1.314-3+lenny2_i386.deb
 85f33faf19141a2c90b8ffed4e8d9f5a5001a6d2 208160 vim-common_7.1.314-3+lenny2_i386.deb
 8ebebf40b542cf909c62c2b88785d22c07f289c1 776664 vim_7.1.314-3+lenny2_i386.deb
 ee3ab387145da9a367f7947cca1d1be2095191c8 8381078 vim-dbg_7.1.314-3+lenny2_i386.deb
Checksums-Sha256: 
 64e1caa7078c871fe47300bdda79407a8be04812dccd527144593054b644578f 1726 vim_7.1.314-3+lenny2.dsc
 dcf59e4e9f306115794a6fbf18fccc04a999abb8300c418db816c3a30df16864 378498 vim_7.1.314-3+lenny2.diff.gz
 a247beec34fbf6f276c5e9142944dd0a085c67df3d73f07dc0cb54fba04cf7cf 159836 vim-gui-common_7.1.314-3+lenny2_all.deb
 4f34be554c01848ed2b00f60efe2d8cc213ad619c78f25689c3702048b838e09 5594756 vim-runtime_7.1.314-3+lenny2_all.deb
 d7d3dd532648f7c32bc1c50e0e1a4270753b933e7b02d1f282b2c3550a2361a5 2151992 vim-doc_7.1.314-3+lenny2_all.deb
 50b47d8f8020ba4d6904c9716174c4f31e11d40a0dfa9066a8b502d5c864e4a5 75312 vim-perl_7.1.314-3+lenny2_all.deb
 089c633e396fe48b0e4832f9b4dc7a9d63ad22cc32741b7fbd5bb4805c8a9d4e 75318 vim-python_7.1.314-3+lenny2_all.deb
 6b89f454a0781120ecdb0a201fae09af025541037ebe5cb9568418f148627c6d 75314 vim-ruby_7.1.314-3+lenny2_all.deb
 4f0249094451003079cfc8e176751d72746e5bf6da29dfb87e838852123c8c0d 75310 vim-tcl_7.1.314-3+lenny2_all.deb
 199666191bd5400ab14d7d3da69f8392da4733ac83c70ed517291506493361eb 75344 vim-full_7.1.314-3+lenny2_all.deb
 da77cea0152fe86f784413dad1449f2b8912a10fac9e1265d8b3caa087d0b5f9 334966 vim-tiny_7.1.314-3+lenny2_i386.deb
 54cb69e0323d4729b1bdb6fc964b60a4d9503a18521b652ef20a3f11b0a78917 994194 vim-gtk_7.1.314-3+lenny2_i386.deb
 e4803c1118edb108529018c308abcb7c15e836670484cc3f3a92e2f46bcd3fc5 996140 vim-gnome_7.1.314-3+lenny2_i386.deb
 333416512585a9da0c05e0da76b80fd3cc99de872f3bc6880d842354aea0941c 986582 vim-lesstif_7.1.314-3+lenny2_i386.deb
 d84a1d9441d2bade2553c4e2d7389d49e17df7eb34fbc75ba635edafdc16197f 863142 vim-nox_7.1.314-3+lenny2_i386.deb
 4589f84fbd84ba01746c828ef8375e27c0963de13a6e88ac28f3556e9bb3ef68 208160 vim-common_7.1.314-3+lenny2_i386.deb
 6c896ce4a6ecf8814b339029847f94cf8ab32f53db7787c7d742a929480e228b 776664 vim_7.1.314-3+lenny2_i386.deb
 fa3b723c69331f539204595418a62e5caff2c5ebb6899f94a785ec775d1d3e8c 8381078 vim-dbg_7.1.314-3+lenny2_i386.deb
Files: 
 710afba1b97650cf657e6965c9c0f7cc 1726 editors optional vim_7.1.314-3+lenny2.dsc
 ed6a94bf841c30bc4d7b39477df133cf 378498 editors optional vim_7.1.314-3+lenny2.diff.gz
 b4a0105bbdcc9de7749b2600ce9abf11 159836 editors optional vim-gui-common_7.1.314-3+lenny2_all.deb
 76b98e261d7034b47ed6a3fcb77718d6 5594756 editors optional vim-runtime_7.1.314-3+lenny2_all.deb
 af2015c9671b4a7e89eefb96302d02d6 2151992 doc optional vim-doc_7.1.314-3+lenny2_all.deb
 c502b71fdbdb9ace25f476dc259c1d4d 75312 editors extra vim-perl_7.1.314-3+lenny2_all.deb
 82c36481cafc07118e1ec09feb13798e 75318 editors extra vim-python_7.1.314-3+lenny2_all.deb
 037290fb800b7c6a05d4b69ed43f4ac8 75314 editors extra vim-ruby_7.1.314-3+lenny2_all.deb
 737a051974a3d1b3c23645dc660da48e 75310 editors extra vim-tcl_7.1.314-3+lenny2_all.deb
 3fb1ce09f8b97c7f706594358ae7513f 75344 editors extra vim-full_7.1.314-3+lenny2_all.deb
 f8a80e3e89bb4e1d9f6c5ed1bcda119a 334966 editors important vim-tiny_7.1.314-3+lenny2_i386.deb
 4f8291738a7ce8cf445b3afac264904d 994194 editors extra vim-gtk_7.1.314-3+lenny2_i386.deb
 b1b9fdd93026c9c2f2e610807167020a 996140 editors extra vim-gnome_7.1.314-3+lenny2_i386.deb
 6d32ae98d91f5ec679e3f824d6859b8d 986582 editors extra vim-lesstif_7.1.314-3+lenny2_i386.deb
 977419a826de800ce79a38cc91ce57a5 863142 editors extra vim-nox_7.1.314-3+lenny2_i386.deb
 2673594ec9851f4a18c6c7894afb1abe 208160 editors important vim-common_7.1.314-3+lenny2_i386.deb
 dd63be51e8deddf6425341aaa5f88ef5 776664 editors optional vim_7.1.314-3+lenny2_i386.deb
 720ca4bac095e296a0ccaa4660d24202 8381078 editors extra vim-dbg_7.1.314-3+lenny2_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkj43zgACgkQDb3UpmEybUD5vACbBgsXprqPXS3KviBfAD/7CsBI
obgAnRac282VshUbDcl4PgrmAAEXPDXi
=QMsa
-----END PGP SIGNATURE-----





Reply sent to James Vega <jamessan@debian.org>:
You have taken responsibility. (Mon, 20 Oct 2008 19:21:09 GMT) Full text and rfc822 format available.

Notification sent to Thomas Arendsen Hein <thomas@intevation.de>:
Bug acknowledged by developer. (Mon, 20 Oct 2008 19:21:09 GMT) Full text and rfc822 format available.

Message #92 received at 493937-close@bugs.debian.org (full text, mbox):

From: James Vega <jamessan@debian.org>
To: 493937-close@bugs.debian.org
Subject: Bug#493937: fixed in vim 2:7.2.025-2
Date: Mon, 20 Oct 2008 19:02:17 +0000
Source: vim
Source-Version: 2:7.2.025-2

We believe that the bug you reported is fixed in the latest version of
vim, which is due to be installed in the Debian FTP archive:

vim-common_7.2.025-2_i386.deb
  to pool/main/v/vim/vim-common_7.2.025-2_i386.deb
vim-dbg_7.2.025-2_i386.deb
  to pool/main/v/vim/vim-dbg_7.2.025-2_i386.deb
vim-doc_7.2.025-2_all.deb
  to pool/main/v/vim/vim-doc_7.2.025-2_all.deb
vim-full_7.2.025-2_all.deb
  to pool/main/v/vim/vim-full_7.2.025-2_all.deb
vim-gnome_7.2.025-2_i386.deb
  to pool/main/v/vim/vim-gnome_7.2.025-2_i386.deb
vim-gtk_7.2.025-2_i386.deb
  to pool/main/v/vim/vim-gtk_7.2.025-2_i386.deb
vim-gui-common_7.2.025-2_all.deb
  to pool/main/v/vim/vim-gui-common_7.2.025-2_all.deb
vim-lesstif_7.2.025-2_i386.deb
  to pool/main/v/vim/vim-lesstif_7.2.025-2_i386.deb
vim-nox_7.2.025-2_i386.deb
  to pool/main/v/vim/vim-nox_7.2.025-2_i386.deb
vim-perl_7.2.025-2_all.deb
  to pool/main/v/vim/vim-perl_7.2.025-2_all.deb
vim-python_7.2.025-2_all.deb
  to pool/main/v/vim/vim-python_7.2.025-2_all.deb
vim-ruby_7.2.025-2_all.deb
  to pool/main/v/vim/vim-ruby_7.2.025-2_all.deb
vim-runtime_7.2.025-2_all.deb
  to pool/main/v/vim/vim-runtime_7.2.025-2_all.deb
vim-tcl_7.2.025-2_all.deb
  to pool/main/v/vim/vim-tcl_7.2.025-2_all.deb
vim-tiny_7.2.025-2_i386.deb
  to pool/main/v/vim/vim-tiny_7.2.025-2_i386.deb
vim_7.2.025-2.diff.gz
  to pool/main/v/vim/vim_7.2.025-2.diff.gz
vim_7.2.025-2.dsc
  to pool/main/v/vim/vim_7.2.025-2.dsc
vim_7.2.025-2_i386.deb
  to pool/main/v/vim/vim_7.2.025-2_i386.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 493937@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
James Vega <jamessan@debian.org> (supplier of updated vim package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Mon, 20 Oct 2008 12:13:42 -0400
Source: vim
Binary: vim-common vim-gui-common vim-runtime vim-doc vim-tiny vim vim-dbg vim-perl vim-python vim-ruby vim-tcl vim-gtk vim-nox vim-lesstif vim-gnome vim-full
Architecture: source i386 all
Version: 2:7.2.025-2
Distribution: unstable
Urgency: low
Maintainer: Debian Vim Maintainers <pkg-vim-maintainers@lists.alioth.debian.org>
Changed-By: James Vega <jamessan@debian.org>
Description: 
 vim        - Vi IMproved - enhanced vi editor
 vim-common - Vi IMproved - Common files
 vim-dbg    - Vi IMproved - enhanced vi editor (debugging symbols)
 vim-doc    - Vi IMproved - HTML documentation
 vim-full   - Vi IMproved - enhanced vi editor (transitional package)
 vim-gnome  - Vi IMproved - enhanced vi editor - with GNOME2 GUI
 vim-gtk    - Vi IMproved - enhanced vi editor - with GTK2 GUI
 vim-gui-common - Vi IMproved - Common GUI files
 vim-lesstif - Vi IMproved - enhanced vi editor - with LessTif GUI
 vim-nox    - Vi IMproved - enhanced vi editor
 vim-perl   - Vi IMproved - enhanced vi editor (transitional package)
 vim-python - Vi IMproved - enhanced vi editor (transitional package)
 vim-ruby   - Vi IMproved - enhanced vi editor (transitional package)
 vim-runtime - Vi IMproved - Runtime files
 vim-tcl    - Vi IMproved - enhanced vi editor (transitional package)
 vim-tiny   - Vi IMproved - enhanced vi editor - compact version
Closes: 493937
Changes: 
 vim (2:7.2.025-2) unstable; urgency=low
 .
   * Remove "deprecated" warnings about (g)vimrc.local from /etc/vim/(g)vimrc.
   * src/if_python.c: Strip empty directories from Python's sys.path to prevent
     Vim from using its current working directory as a module import path.
     (Closes: #493937)
   * debian/rules: Do not run tests in parallel as that may interfere with
     their results.
Checksums-Sha1: 
 dda410dc07b745a19890dcd6d69855ade2bd6e0b 1703 vim_7.2.025-2.dsc
 669a1bfc2b87af2da9e707658c433ddb7602e302 181366 vim_7.2.025-2.diff.gz
 7607c3d270cc3079c01f3c2d872aa17d6adab10a 999454 vim-gtk_7.2.025-2_i386.deb
 5d70f61c74e7e9b553c8449d47395e529549a146 1000972 vim-gnome_7.2.025-2_i386.deb
 f980c2944b50ad5ddd880ca2dba5ac6ddf83a8c7 868240 vim-nox_7.2.025-2_i386.deb
 b4a6667661a6826d088828424f05833acba89d0b 335102 vim-tiny_7.2.025-2_i386.deb
 1a356a17194a54d6653dc652293f736228e869ea 201310 vim-common_7.2.025-2_i386.deb
 17c97809b5a2bb5c68081775f294c315902d8995 781354 vim_7.2.025-2_i386.deb
 ac3e534cf90342f15826198035a5bec9462a794f 991844 vim-lesstif_7.2.025-2_i386.deb
 d15795017edac0dd7fd9b2909d7674327529700c 8417042 vim-dbg_7.2.025-2_i386.deb
 4749b4b8e8c89d2e956a1ce1e0eca3fffcb84f34 161718 vim-gui-common_7.2.025-2_all.deb
 feeeb56269f738fba476b5c378da5ce2032e0186 5991996 vim-runtime_7.2.025-2_all.deb
 b79fa1d43af98a010bf252b345ed42fd3758e3fe 1971726 vim-doc_7.2.025-2_all.deb
 42379cda62025d160596b9efd696d8935b42b0f6 77526 vim-perl_7.2.025-2_all.deb
 8e8a69b939fac74f62a5f7a0dbed5d5262c01eb4 77536 vim-python_7.2.025-2_all.deb
 fb932d0963189653d5d9db3f050cea1d398d2c74 77528 vim-ruby_7.2.025-2_all.deb
 ad60edf25ffab71b9ed04246df7e3b9f0f55f92e 77528 vim-tcl_7.2.025-2_all.deb
 135fe7d4453d9ec9f0331bba0037d7bfa28e88b2 77548 vim-full_7.2.025-2_all.deb
Checksums-Sha256: 
 63aa66292caa640121478bf5a985da9bfad7938d87ba529e844ec1245757160b 1703 vim_7.2.025-2.dsc
 fd4239a9740eba3f699780f47777c6a05b6ede43a9062a88fd4a9212498fd4f7 181366 vim_7.2.025-2.diff.gz
 2974a7ef5bd154faf4ffa40546fdc9dc557361b19a48f2059a24179a71b7cffe 999454 vim-gtk_7.2.025-2_i386.deb
 b3dd66993389fdf8485476fcf2332006403efe121c87d8a3309a04940ea00de2 1000972 vim-gnome_7.2.025-2_i386.deb
 639afda0ce1a3f9487a070f707f0464c44405a78324d2d00319efb08b7ba747b 868240 vim-nox_7.2.025-2_i386.deb
 69776dacc8cc56f84f99a6ff56e82f9acde18349d2bf10b8f97de0589287ff12 335102 vim-tiny_7.2.025-2_i386.deb
 5ed97a57cbd2d3a722326076a08c947afa439691f012037c6cb8a1a0dcedc235 201310 vim-common_7.2.025-2_i386.deb
 5136a9de4cd9ea63a50673e5c6b13dce82fef8c2bd390070b79060491023fd70 781354 vim_7.2.025-2_i386.deb
 15873ceb2e3d960829b24c84558966a41dcc2cdeffda0f7dc9af8c6dd535a96e 991844 vim-lesstif_7.2.025-2_i386.deb
 dc36fe008ea662b428532ea89dca88f82a022e82abce1f1a118f8d77cd3c2981 8417042 vim-dbg_7.2.025-2_i386.deb
 fabbb695df7e449d69e41b90717817b4146dfe571bf0e178e9c707574059403f 161718 vim-gui-common_7.2.025-2_all.deb
 62cb2f32bede91d9a94956915ffd211f3aebeff54192cbd84e3de520a50eb279 5991996 vim-runtime_7.2.025-2_all.deb
 b13d8efb0596b4513a8687b53829634b11f6ff7e63ad840c38fccf7c29e46250 1971726 vim-doc_7.2.025-2_all.deb
 299e67262cd9d226177ce595ba285757638e7c3b319dbb35e246c0538282ed77 77526 vim-perl_7.2.025-2_all.deb
 50ad687b0fe4ab8e98d70a13d96d829102cdd44775187c01835060deb6de8a7e 77536 vim-python_7.2.025-2_all.deb
 d54153f3277b753c0e04975b868f90003945812c8b5da28a970a883f89769a12 77528 vim-ruby_7.2.025-2_all.deb
 60db22487a3d3f7ab5d0c7a5392d35ab660e5f832ff590b9a4c4a21b3f6faf2f 77528 vim-tcl_7.2.025-2_all.deb
 5a30126d0e534a35e18952822c23c9bf9f745f64c595688c5f525ffa72422dfe 77548 vim-full_7.2.025-2_all.deb
Files: 
 a1dcda8a537ddc1d0eff71b372075394 1703 editors optional vim_7.2.025-2.dsc
 2cd03a6827cb9694529312db77f54a82 181366 editors optional vim_7.2.025-2.diff.gz
 d7ab5da374ccc2b0dba80796270949c8 999454 editors extra vim-gtk_7.2.025-2_i386.deb
 8d1a5a9334e258648dfe07c93d0b32e6 1000972 editors extra vim-gnome_7.2.025-2_i386.deb
 8e63582e4bb0057feffaa36958a9d631 868240 editors extra vim-nox_7.2.025-2_i386.deb
 213262ad35ebb1ef22dfd238f83b317f 335102 editors important vim-tiny_7.2.025-2_i386.deb
 96ad1405867376e1392a830679dfee12 201310 editors important vim-common_7.2.025-2_i386.deb
 9f426dac179d3872e969a3f601d9d957 781354 editors optional vim_7.2.025-2_i386.deb
 3adfdb41e47950d918cede6553d29128 991844 editors extra vim-lesstif_7.2.025-2_i386.deb
 7d2b5bbdaa0caed837e40fe39b643dc6 8417042 editors extra vim-dbg_7.2.025-2_i386.deb
 c36b7766e7311e39a4fef5e2afe8089b 161718 editors optional vim-gui-common_7.2.025-2_all.deb
 9d5ae3e8b1aaa263bd3fb6614854f01c 5991996 editors optional vim-runtime_7.2.025-2_all.deb
 b0eee745f0accc7a2113eb0bf4abca46 1971726 doc optional vim-doc_7.2.025-2_all.deb
 a4cc106429883e27122546671c908a06 77526 editors extra vim-perl_7.2.025-2_all.deb
 d0524d1a80791288d4400ffc3ca862d1 77536 editors extra vim-python_7.2.025-2_all.deb
 b48b4125a532852b126513b10ffebddc 77528 editors extra vim-ruby_7.2.025-2_all.deb
 5ff0de8c6f1ff2ac43940dff341d1453 77528 editors extra vim-tcl_7.2.025-2_all.deb
 ec95cc52923a9f2d9de7ed9d8f3ae108 77548 editors extra vim-full_7.2.025-2_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkj8zjgACgkQDb3UpmEybUDojgCfWOs3YJZ/r+12JXo7W2r8a8QR
vl0An0mmDMeISARwm5GNPak3e4wLEGWs
=89Oc
-----END PGP SIGNATURE-----





Reply sent to James Vega <jamessan@debian.org>:
You have marked Bug as forwarded. (Mon, 03 Nov 2008 03:09:07 GMT) Full text and rfc822 format available.

Message #95 received at 493937-forwarded@bugs.debian.org (full text, mbox):

From: James Vega <jamessan@debian.org>
To: Bram Moolenaar <Bram@moolenaar.net>
Cc: 493937-forwarded@bugs.debian.org
Subject: [Patch] Prevent loading of Python modules in working directory
Date: Sun, 2 Nov 2008 22:05:16 -0500
[Message part 1 (text/plain, inline)]
Bram,

Vim's python interface calls PySys_SetArgv with an argv[0] that doesn't
resolve to a filename.  This causes Python to prepend sys.path with an
empty string which, due to Python's use of relative imports, allows the
possibility to run arbitrary code on the user's system if a file in
Vim's working directory matches the name of a python module a
Python-using vim script tries to import.

This should be fixed by Python 2.6 as it uses absolute imports by
default, but I have not been able to test it.  The attached patch fixes
the problem in Vim by removing any empty strings from sys.path.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@debian.org>
[sanitize_sys.path.diff (text/x-diff, attachment)]
[signature.asc (application/pgp-signature, inline)]

Message #96 received at 493937-forwarded@bugs.debian.org (full text, mbox):

From: Bram Moolenaar <Bram@moolenaar.net>
To: James Vega <jamessan@debian.org>
Cc: 493937-forwarded@bugs.debian.org
Subject: Re: [Patch] Prevent loading of Python modules in working directory
Date: Mon, 03 Nov 2008 22:23:27 +0100
James -

> Bram,
> 
> Vim's python interface calls PySys_SetArgv with an argv[0] that doesn't
> resolve to a filename.  This causes Python to prepend sys.path with an
> empty string which, due to Python's use of relative imports, allows the
> possibility to run arbitrary code on the user's system if a file in
> Vim's working directory matches the name of a python module a
> Python-using vim script tries to import.
> 
> This should be fixed by Python 2.6 as it uses absolute imports by
> default, but I have not been able to test it.  The attached patch fixes
> the problem in Vim by removing any empty strings from sys.path.

This is a Python bug, right?  One should never add an empty entry to
sys.path.  And probably should not add a path relative to the executable
anyway.

Another solution would be to make the first argument to argv[] an
absolute path, e.g. "/".  Is there something against that?

- Bram

-- 
If Microsoft would build a car...
... the oil, water temperature, and alternator warning lights would
all be replaced by a single "General Protection Fault" warning light.

 /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Vim Maintainers <pkg-vim-maintainers@lists.alioth.debian.org>:
Bug#493937; Package vim-python. (Mon, 03 Nov 2008 22:54:26 GMT) Full text and rfc822 format available.

Acknowledgement sent to James Vega <jamessan@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Vim Maintainers <pkg-vim-maintainers@lists.alioth.debian.org>. (Mon, 03 Nov 2008 22:54:27 GMT) Full text and rfc822 format available.

Message #101 received at 493937@bugs.debian.org (full text, mbox):

From: James Vega <jamessan@debian.org>
To: Bram Moolenaar <Bram@moolenaar.net>
Cc: 493937@bugs.debian.org
Subject: Re: [Patch] Prevent loading of Python modules in working directory
Date: Mon, 3 Nov 2008 17:21:08 -0500
[Message part 1 (text/plain, inline)]
On Mon, Nov 03, 2008 at 10:23:27PM +0100, Bram Moolenaar wrote:
> 
> James -
> 
> > Bram,
> > 
> > Vim's python interface calls PySys_SetArgv with an argv[0] that doesn't
> > resolve to a filename.  This causes Python to prepend sys.path with an
> > empty string which, due to Python's use of relative imports, allows the
> > possibility to run arbitrary code on the user's system if a file in
> > Vim's working directory matches the name of a python module a
> > Python-using vim script tries to import.
> > 
> > This should be fixed by Python 2.6 as it uses absolute imports by
> > default, but I have not been able to test it.  The attached patch fixes
> > the problem in Vim by removing any empty strings from sys.path.
> 
> This is a Python bug, right?  One should never add an empty entry to
> sys.path.  And probably should not add a path relative to the executable
> anyway.

Yes, it is a Python bug but it's one that they chose to ignore.  The
code for PySys_SetArgv specifically adds the empty entry when it is not
able to resolve a filename (and therefore its parent directory).  The
default use of absolute imports in Python 2.6 (assuming that also
affects their C interface) will only workaround the issue of empty
entries in sys.path.

> Another solution would be to make the first argument to argv[] an
> absolute path, e.g. "/".  Is there something against that?

That still adds an unnecessary directory to sys.path.  In the case of
Vim, I think the safest measure is to remove the extra entry from
sys.path.  For other applications, where there is a directory from which
they want to load python plugins, it would make sense to add that
directory to sys.path.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@debian.org>
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Vim Maintainers <pkg-vim-maintainers@lists.alioth.debian.org>:
Bug#493937; Package vim-python. (Tue, 04 Nov 2008 21:09:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bram Moolenaar <Bram@moolenaar.net>:
Extra info received and forwarded to list. Copy sent to Debian Vim Maintainers <pkg-vim-maintainers@lists.alioth.debian.org>. (Tue, 04 Nov 2008 21:09:09 GMT) Full text and rfc822 format available.

Message #106 received at 493937@bugs.debian.org (full text, mbox):

From: Bram Moolenaar <Bram@moolenaar.net>
To: James Vega <jamessan@debian.org>
Cc: 493937@bugs.debian.org
Subject: Re: [Patch] Prevent loading of Python modules in working directory
Date: Tue, 04 Nov 2008 22:08:09 +0100
James -

> > > Vim's python interface calls PySys_SetArgv with an argv[0] that doesn't
> > > resolve to a filename.  This causes Python to prepend sys.path with an
> > > empty string which, due to Python's use of relative imports, allows the
> > > possibility to run arbitrary code on the user's system if a file in
> > > Vim's working directory matches the name of a python module a
> > > Python-using vim script tries to import.
> > > 
> > > This should be fixed by Python 2.6 as it uses absolute imports by
> > > default, but I have not been able to test it.  The attached patch fixes
> > > the problem in Vim by removing any empty strings from sys.path.
> > 
> > This is a Python bug, right?  One should never add an empty entry to
> > sys.path.  And probably should not add a path relative to the executable
> > anyway.
> 
> Yes, it is a Python bug but it's one that they chose to ignore.  The
> code for PySys_SetArgv specifically adds the empty entry when it is not
> able to resolve a filename (and therefore its parent directory).  The
> default use of absolute imports in Python 2.6 (assuming that also
> affects their C interface) will only workaround the issue of empty
> entries in sys.path.
> 
> > Another solution would be to make the first argument to argv[] an
> > absolute path, e.g. "/".  Is there something against that?
> 
> That still adds an unnecessary directory to sys.path.  In the case of
> Vim, I think the safest measure is to remove the extra entry from
> sys.path.  For other applications, where there is a directory from which
> they want to load python plugins, it would make sense to add that
> directory to sys.path.

I suppose adding "/" won't break anything, but still isn't nice.
Your solution indeed looks like the best solution.

- Bram

-- 
The CIA drives around in cars with the "Intel inside" logo.

 /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///




Message #107 received at 493937-forwarded@bugs.debian.org (full text, mbox):

From: Bram Moolenaar <Bram@moolenaar.net>
To: James Vega <jamessan@debian.org>
Cc: 493937-forwarded@bugs.debian.org
Subject: Re: [Patch] Prevent loading of Python modules in working directory
Date: Wed, 12 Nov 2008 12:34:16 +0100
James -

> Vim's python interface calls PySys_SetArgv with an argv[0] that doesn't
> resolve to a filename.  This causes Python to prepend sys.path with an
> empty string which, due to Python's use of relative imports, allows the
> possibility to run arbitrary code on the user's system if a file in
> Vim's working directory matches the name of a python module a
> Python-using vim script tries to import.
> 
> This should be fixed by Python 2.6 as it uses absolute imports by
> default, but I have not been able to test it.  The attached patch fixes
> the problem in Vim by removing any empty strings from sys.path.

I have now applied and tried this patch.  It does not really work as
expected for me.  Apparently the empty string in argv[0] is interpreted
as the current directory.  My first entry in sys.path is then the
directory above the current directory.  The filter you added in the
patch doesn't change anything.

For me it does work if I use:

   static char *(argv[2]) = {"/must>not&exist/ls", NULL};

The first entry in path is then "/must>not&exist", which we can filter
out with:

   PyRun_SimpleString("import sys; sys.path = filter(lambda x: x != '/must>not&exist', sys.path)");

This is with Python 2.5.  I don't know about other versions...
Does this solution look OK to you?

- Bram

-- 
Google is kind of like Dr. Who's Tardis; it's wierder on the
inside than on the outside...

 /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Vim Maintainers <pkg-vim-maintainers@lists.alioth.debian.org>:
Bug#493937; Package vim-python. (Wed, 12 Nov 2008 22:17:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to James Vega <jamessan@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Vim Maintainers <pkg-vim-maintainers@lists.alioth.debian.org>. (Wed, 12 Nov 2008 22:17:35 GMT) Full text and rfc822 format available.

Message #112 received at 493937@bugs.debian.org (full text, mbox):

From: James Vega <jamessan@debian.org>
To: Bram Moolenaar <Bram@moolenaar.net>
Cc: 493937@bugs.debian.org
Subject: Re: [Patch] Prevent loading of Python modules in working directory
Date: Wed, 12 Nov 2008 17:00:53 -0500
[Message part 1 (text/plain, inline)]
On Wed, Nov 12, 2008 at 12:34:16PM +0100, Bram Moolenaar wrote:
> 
> James -
> 
> > Vim's python interface calls PySys_SetArgv with an argv[0] that doesn't
> > resolve to a filename.  This causes Python to prepend sys.path with an
> > empty string which, due to Python's use of relative imports, allows the
> > possibility to run arbitrary code on the user's system if a file in
> > Vim's working directory matches the name of a python module a
> > Python-using vim script tries to import.
> > 
> > This should be fixed by Python 2.6 as it uses absolute imports by
> > default, but I have not been able to test it.  The attached patch fixes
> > the problem in Vim by removing any empty strings from sys.path.
> 
> I have now applied and tried this patch.  It does not really work as
> expected for me.  Apparently the empty string in argv[0] is interpreted
> as the current directory.

argv[0] is used to seed the value that is prepended to sys.path.

You can take a look at what PySys_SetArgv does at
http://svn.python.org/view/python/branches/release25-maint/Python/sysmodule.c?rev=54836&view=markup

What it boils down to in the simple case is checking for the existence
of a path separator in argv0.  If that doesn't exist, then a PyString is
created from argv0 with size 0 and sys.path is prepended with that --
empty string used for the first element of sys.path.

> My first entry in sys.path is then the directory above the current
> directory.  The filter you added in the patch doesn't change anything.

This is incorrect.  In Vim's current code, PySys_SetArgv is called with
an argv that is simply an empty string (and a terminating NULL
sentinel).  This causes sys.path's first element to be the empty string,
thus causing any Python import statements to use Vim's current working
directory as the first location to check for the requested module.

The filter specifically removes any elements in sys.path that evaluate
to false (i.e., the empty string).

Using the attached print_sys.path.diff, the following is printed when I
start Vim (the sys.path before and after my suggested filter() command):

['', '/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', '/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']

You can also test it with the simple pytest.c that I've attached by
specifying different arguments as the first element of the argv passed
to PySys_SetArgv.

$ gcc -o pytest $(python-config --cflags) $(python-config --ldflags) pytest.c
$ ./pytest ''
['', '/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', '/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']
$ ./pytest '/must>not&exist/bogusbinary'
['/must>not&exist', '/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']
['/must>not&exist', '/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']

> For me it does work if I use:
> 
>    static char *(argv[2]) = {"/must>not&exist/ls", NULL};
> 
> The first entry in path is then "/must>not&exist", which we can filter
> out with:
> 
>    PyRun_SimpleString("import sys; sys.path = filter(lambda x: x != '/must>not&exist', sys.path)");

This is just extra work for no gain.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@debian.org>
[pytest.c (text/x-csrc, attachment)]
[print_sys.path.diff (text/x-diff, attachment)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Vim Maintainers <pkg-vim-maintainers@lists.alioth.debian.org>:
Bug#493937; Package vim-python. (Thu, 13 Nov 2008 10:27:25 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bram Moolenaar <Bram@moolenaar.net>:
Extra info received and forwarded to list. Copy sent to Debian Vim Maintainers <pkg-vim-maintainers@lists.alioth.debian.org>. (Thu, 13 Nov 2008 10:27:26 GMT) Full text and rfc822 format available.

Message #117 received at 493937@bugs.debian.org (full text, mbox):

From: Bram Moolenaar <Bram@moolenaar.net>
To: James Vega <jamessan@debian.org>
Cc: 493937@bugs.debian.org
Subject: Re: [Patch] Prevent loading of Python modules in working directory
Date: Thu, 13 Nov 2008 11:23:07 +0100
James -

> > > Vim's python interface calls PySys_SetArgv with an argv[0] that doesn't
> > > resolve to a filename.  This causes Python to prepend sys.path with an
> > > empty string which, due to Python's use of relative imports, allows the
> > > possibility to run arbitrary code on the user's system if a file in
> > > Vim's working directory matches the name of a python module a
> > > Python-using vim script tries to import.
> > > 
> > > This should be fixed by Python 2.6 as it uses absolute imports by
> > > default, but I have not been able to test it.  The attached patch fixes
> > > the problem in Vim by removing any empty strings from sys.path.
> > 
> > I have now applied and tried this patch.  It does not really work as
> > expected for me.  Apparently the empty string in argv[0] is interpreted
> > as the current directory.
> 
> argv[0] is used to seed the value that is prepended to sys.path.
> 
> You can take a look at what PySys_SetArgv does at
> http://svn.python.org/view/python/branches/release25-maint/Python/sysmodule.c?rev=54836&view=markup
> 
> What it boils down to in the simple case is checking for the existence
> of a path separator in argv0.  If that doesn't exist, then a PyString is
> created from argv0 with size 0 and sys.path is prepended with that --
> empty string used for the first element of sys.path.
> 
> > My first entry in sys.path is then the directory above the current
> > directory.  The filter you added in the patch doesn't change anything.
> 
> This is incorrect.  In Vim's current code, PySys_SetArgv is called with
> an argv that is simply an empty string (and a terminating NULL
> sentinel).  This causes sys.path's first element to be the empty string,
> thus causing any Python import statements to use Vim's current working
> directory as the first location to check for the requested module.
> 
> The filter specifically removes any elements in sys.path that evaluate
> to false (i.e., the empty string).

That is not what happens for me.  Somehow somewhere the empty entry is
changed to the full path of the directory above the current directory.
I don't know where, but I see it happening.  I have tried this with:

	:py import sys
	:py print sys.path

> Using the attached print_sys.path.diff, the following is printed when I
> start Vim (the sys.path before and after my suggested filter() command):
> 
> ['', '/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', '/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']

As mentioned, for me the first entry is not '' but a path.   The filter
command you suggested doesn't remove it.  I don't know where the
difference between our systems comes from.

> You can also test it with the simple pytest.c that I've attached by
> specifying different arguments as the first element of the argv passed
> to PySys_SetArgv.
> 
> $ gcc -o pytest $(python-config --cflags) $(python-config --ldflags) pytest.c
> $ ./pytest ''
> ['', '/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', '/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']
> $ ./pytest '/must>not&exist/bogusbinary'
> ['/must>not&exist', '/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']
> ['/must>not&exist', '/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']
> 
> > For me it does work if I use:
> > 
> >    static char *(argv[2]) = {"/must>not&exist/ls", NULL};
> > 
> > The first entry in path is then "/must>not&exist", which we can filter
> > out with:
> > 
> >    PyRun_SimpleString("import sys; sys.path = filter(lambda x: x != '/must>not&exist', sys.path)");
> 
> This is just extra work for no gain.

It does work for me.  Does it also work for you?

- Bram

-- 
hundred-and-one symptoms of being an internet addict:
249. You've forgotten what the outside looks like.

 /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Vim Maintainers <pkg-vim-maintainers@lists.alioth.debian.org>:
Bug#493937; Package vim-python. (Thu, 13 Nov 2008 23:21:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to James Vega <jamessan@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Vim Maintainers <pkg-vim-maintainers@lists.alioth.debian.org>. (Thu, 13 Nov 2008 23:21:06 GMT) Full text and rfc822 format available.

Message #122 received at 493937@bugs.debian.org (full text, mbox):

From: James Vega <jamessan@debian.org>
To: Bram Moolenaar <Bram@moolenaar.net>, 493937@bugs.debian.org
Subject: Re: Bug#493937: [Patch] Prevent loading of Python modules in working directory
Date: Thu, 13 Nov 2008 18:17:24 -0500
[Message part 1 (text/plain, inline)]
On Thu, Nov 13, 2008 at 11:23:07AM +0100, Bram Moolenaar wrote:
> 
> James -
> 
> > This is incorrect.  In Vim's current code, PySys_SetArgv is called with
> > an argv that is simply an empty string (and a terminating NULL
> > sentinel).  This causes sys.path's first element to be the empty string,
> > thus causing any Python import statements to use Vim's current working
> > directory as the first location to check for the requested module.
> > 
> > The filter specifically removes any elements in sys.path that evaluate
> > to false (i.e., the empty string).
> 
> That is not what happens for me.  Somehow somewhere the empty entry is
> changed to the full path of the directory above the current directory.
> I don't know where, but I see it happening.  I have tried this with:
> 
> 	:py import sys
> 	:py print sys.path
> 
> > Using the attached print_sys.path.diff, the following is printed when I
> > start Vim (the sys.path before and after my suggested filter() command):
> > 
> > ['', '/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', '/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']
> 
> As mentioned, for me the first entry is not '' but a path.   The filter
> command you suggested doesn't remove it.  I don't know where the
> difference between our systems comes from.

This is bizarre as I don't see how this could be happening in vanilla
Python code, so it seems like your install has been patched to add this
behavior.  Either way, I see two options:

1) Save sys.path before calling PySys_SetArgv and restore it afterward.
2) Prune the first element of sys.path after calling PySys_SetArgv.

We know that PySys_SetArgv always adds an element to the front of
sys.path and we know that we're giving it a value that isn't valid (to
prevent a segfault in some warn() function I can't find a reference to).

Adding an arbitrary, hopefully non-existent path in order to search for
and remove it just smells bad to me when there's defined behavior.  My
initial idea when I got this bug was to simply do 2) but I changed to
the filter() patch later to be (I thought) more robust.

I'd be interested in knowing where your Python install comes from so I
can see why it's behaving differently.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@debian.org>
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian Vim Maintainers <pkg-vim-maintainers@lists.alioth.debian.org>:
Bug#493937; Package vim-python. (Fri, 14 Nov 2008 20:48:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bram Moolenaar <Bram@moolenaar.net>:
Extra info received and forwarded to list. Copy sent to Debian Vim Maintainers <pkg-vim-maintainers@lists.alioth.debian.org>. (Fri, 14 Nov 2008 20:48:02 GMT) Full text and rfc822 format available.

Message #127 received at 493937@bugs.debian.org (full text, mbox):

From: Bram Moolenaar <Bram@moolenaar.net>
To: James Vega <jamessan@debian.org>
Cc: 493937@bugs.debian.org
Subject: Re: Bug#493937: [Patch] Prevent loading of Python modules in working directory
Date: Fri, 14 Nov 2008 21:42:08 +0100
James -

> > > This is incorrect.  In Vim's current code, PySys_SetArgv is called with
> > > an argv that is simply an empty string (and a terminating NULL
> > > sentinel).  This causes sys.path's first element to be the empty string,
> > > thus causing any Python import statements to use Vim's current working
> > > directory as the first location to check for the requested module.
> > > 
> > > The filter specifically removes any elements in sys.path that evaluate
> > > to false (i.e., the empty string).
> > 
> > That is not what happens for me.  Somehow somewhere the empty entry is
> > changed to the full path of the directory above the current directory.
> > I don't know where, but I see it happening.  I have tried this with:
> > 
> > 	:py import sys
> > 	:py print sys.path
> > 
> > > Using the attached print_sys.path.diff, the following is printed when I
> > > start Vim (the sys.path before and after my suggested filter() command):
> > > 
> > > ['', '/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', '/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']
> > 
> > As mentioned, for me the first entry is not '' but a path.   The filter
> > command you suggested doesn't remove it.  I don't know where the
> > difference between our systems comes from.
> 
> This is bizarre as I don't see how this could be happening in vanilla
> Python code, so it seems like your install has been patched to add this
> behavior.  Either way, I see two options:
> 
> 1) Save sys.path before calling PySys_SetArgv and restore it afterward.
> 2) Prune the first element of sys.path after calling PySys_SetArgv.
> 
> We know that PySys_SetArgv always adds an element to the front of
> sys.path and we know that we're giving it a value that isn't valid (to
> prevent a segfault in some warn() function I can't find a reference to).
> 
> Adding an arbitrary, hopefully non-existent path in order to search for
> and remove it just smells bad to me when there's defined behavior.  My
> initial idea when I got this bug was to simply do 2) but I changed to
> the filter() patch later to be (I thought) more robust.
> 
> I'd be interested in knowing where your Python install comes from so I
> can see why it's behaving differently.

I'm using Python 2.5.  The implementation of PySys_SetArgv() uses
realpath().  It expands "" to the current directory.  I haven't looked
at the details, but I suspect that's what is causing the behavior I
notice.

You can see this file here:
http://svn.python.org/view/python/trunk/Python/sysmodule.c?rev=64856&view=markup

I think using a magic directory name works better than assuming
something about the python code, e.g. prepending an entry to sys.path.
A later version may correct the mistake and not change sys.path for an
empty string.  I think my version of the fix handles those situations.

- Bram

-- 
hundred-and-one symptoms of being an internet addict:
252. You vote for foreign officials.

 /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Vim Maintainers <pkg-vim-maintainers@lists.alioth.debian.org>:
Bug#493937; Package vim-python. (Fri, 14 Nov 2008 21:53:19 GMT) Full text and rfc822 format available.

Acknowledgement sent to "James Vega" <jamessan@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Vim Maintainers <pkg-vim-maintainers@lists.alioth.debian.org>. (Fri, 14 Nov 2008 21:53:22 GMT) Full text and rfc822 format available.

Message #132 received at 493937@bugs.debian.org (full text, mbox):

From: "James Vega" <jamessan@debian.org>
To: "Bram Moolenaar" <Bram@moolenaar.net>
Cc: 493937@bugs.debian.org
Subject: Re: Bug#493937: [Patch] Prevent loading of Python modules in working directory
Date: Fri, 14 Nov 2008 16:40:00 -0500
On Fri, Nov 14, 2008 at 3:42 PM, Bram Moolenaar <Bram@moolenaar.net> wrote:
>
> James -
>
>> Either way, I see two options:
>>
>> 1) Save sys.path before calling PySys_SetArgv and restore it afterward.
>> 2) Prune the first element of sys.path after calling PySys_SetArgv.
>>
>> We know that PySys_SetArgv always adds an element to the front of
>> sys.path and we know that we're giving it a value that isn't valid (to
>> prevent a segfault in some warn() function I can't find a reference to).
>>
>> Adding an arbitrary, hopefully non-existent path in order to search for
>> and remove it just smells bad to me when there's defined behavior.  My
>> initial idea when I got this bug was to simply do 2) but I changed to
>> the filter() patch later to be (I thought) more robust.
>>
>> I'd be interested in knowing where your Python install comes from so I
>> can see why it's behaving differently.
>
> I'm using Python 2.5.  The implementation of PySys_SetArgv() uses
> realpath().  It expands "" to the current directory.  I haven't looked
> at the details, but I suspect that's what is causing the behavior I
> notice.

Then this appears to be a difference (bug?) in your libc.  This is not
the case with glibc 2.7 or 2.8 (the two systems I can currently test
on).  Those error with ENOENT (as specified by SUS[0]).

> You can see this file here:
> http://svn.python.org/view/python/trunk/Python/sysmodule.c?rev=64856&view=markup
>
> I think using a magic directory name works better than assuming
> something about the python code, e.g. prepending an entry to sys.path.

This is one of the express purposes of PySys_SetArgv, as I mentioned
earlier.  The Python developers have stated multiple times[1][2] that
they consider the sys.path adjustment to be intended behavior and the
actual bug is implicit relative imports instead of defaulting to
absolute imports and using relative imports when requested.

Either way, thanks for pointing out the issue about using a buggy libc.
I'll keep that in mind when I push patches to other projects.

[0] - http://www.opengroup.org/onlinepubs/009695399/functions/realpath.html
[1] - http://bugs.python.org/issue946373
[2] - http://lists.gnu.org/archive/html/emacs-devel/2008-09/msg00215.html

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




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Vim Maintainers <pkg-vim-maintainers@lists.alioth.debian.org>:
Bug#493937; Package vim-python. (Sat, 15 Nov 2008 11:57:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bram Moolenaar <Bram@moolenaar.net>:
Extra info received and forwarded to list. Copy sent to Debian Vim Maintainers <pkg-vim-maintainers@lists.alioth.debian.org>. (Sat, 15 Nov 2008 11:57:03 GMT) Full text and rfc822 format available.

Message #137 received at 493937@bugs.debian.org (full text, mbox):

From: Bram Moolenaar <Bram@moolenaar.net>
To: "James Vega" <jamessan@debian.org>
Cc: 493937@bugs.debian.org
Subject: Re: Bug#493937: [Patch] Prevent loading of Python modules in working directory
Date: Sat, 15 Nov 2008 12:52:49 +0100
James -

> >> Either way, I see two options:
> >>
> >> 1) Save sys.path before calling PySys_SetArgv and restore it afterward.
> >> 2) Prune the first element of sys.path after calling PySys_SetArgv.
> >>
> >> We know that PySys_SetArgv always adds an element to the front of
> >> sys.path and we know that we're giving it a value that isn't valid (to
> >> prevent a segfault in some warn() function I can't find a reference to).
> >>
> >> Adding an arbitrary, hopefully non-existent path in order to search for
> >> and remove it just smells bad to me when there's defined behavior.  My
> >> initial idea when I got this bug was to simply do 2) but I changed to
> >> the filter() patch later to be (I thought) more robust.
> >>
> >> I'd be interested in knowing where your Python install comes from so I
> >> can see why it's behaving differently.
> >
> > I'm using Python 2.5.  The implementation of PySys_SetArgv() uses
> > realpath().  It expands "" to the current directory.  I haven't looked
> > at the details, but I suspect that's what is causing the behavior I
> > notice.
> 
> Then this appears to be a difference (bug?) in your libc.  This is not
> the case with glibc 2.7 or 2.8 (the two systems I can currently test
> on).  Those error with ENOENT (as specified by SUS[0]).

I'm on FreeBSD.  I used this test program:

#include <stdio.h>
#include <sys/param.h>
#include <stdlib.h>
#include <errno.h>

main()
{
        char buf[PATH_MAX];
        char *s;
        errno = 0;
        buf[0] = 0;
        s = realpath("", buf);
        printf("errno = %d; s = %s; buf = %s\n", errno, s, buf);
}

Result (when pwd is /tmp):

errno = 0; s = /tmp; buf = /tmp

The definition of realpath() doesn't say what happens for an empty
string.  It might handle it as "." or give an error.

> > You can see this file here:
> > http://svn.python.org/view/python/trunk/Python/sysmodule.c?rev=64856&view=markup
> >
> > I think using a magic directory name works better than assuming
> > something about the python code, e.g. prepending an entry to sys.path.
> 
> This is one of the express purposes of PySys_SetArgv, as I mentioned
> earlier.  The Python developers have stated multiple times[1][2] that
> they consider the sys.path adjustment to be intended behavior and the
> actual bug is implicit relative imports instead of defaulting to
> absolute imports and using relative imports when requested.
> 
> Either way, thanks for pointing out the issue about using a buggy libc.
> I'll keep that in mind when I push patches to other projects.
> 
> [0] - http://www.opengroup.org/onlinepubs/009695399/functions/realpath.html
> [1] - http://bugs.python.org/issue946373
> [2] - http://lists.gnu.org/archive/html/emacs-devel/2008-09/msg00215.html

Did you test my proposed solution on Linux?  I think it should work
everywhere.

- Bram

-- 
hundred-and-one symptoms of being an internet addict:
255. You work for a newspaper and your editor asks you to write an
     article about Internet addiction...in the "first person."

 /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Vim Maintainers <pkg-vim-maintainers@lists.alioth.debian.org>:
Bug#493937; Package vim-python. (Mon, 17 Nov 2008 15:48:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to "James Vega" <jamessan@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian Vim Maintainers <pkg-vim-maintainers@lists.alioth.debian.org>. (Mon, 17 Nov 2008 15:48:06 GMT) Full text and rfc822 format available.

Message #142 received at 493937@bugs.debian.org (full text, mbox):

From: "James Vega" <jamessan@debian.org>
To: "Bram Moolenaar" <Bram@moolenaar.net>
Cc: 493937@bugs.debian.org
Subject: Re: Bug#493937: [Patch] Prevent loading of Python modules in working directory
Date: Mon, 17 Nov 2008 10:42:59 -0500
On Sat, Nov 15, 2008 at 6:52 AM, Bram Moolenaar <Bram@moolenaar.net> wrote:
>
> James -
>
>> Then this appears to be a difference (bug?) in your libc.  This is not
>> the case with glibc 2.7 or 2.8 (the two systems I can currently test
>> on).  Those error with ENOENT (as specified by SUS[0]).
>
> I'm on FreeBSD.  I used this test program:
>
> #include <stdio.h>
> #include <sys/param.h>
> #include <stdlib.h>
> #include <errno.h>
>
> main()
> {
>        char buf[PATH_MAX];
>        char *s;
>        errno = 0;
>        buf[0] = 0;
>        s = realpath("", buf);
>        printf("errno = %d; s = %s; buf = %s\n", errno, s, buf);
> }
>
> Result (when pwd is /tmp):
>
> errno = 0; s = /tmp; buf = /tmp

errno = 2; s = (null); buf =

> The definition of realpath() doesn't say what happens for an empty
> string.  It might handle it as "." or give an error.

SUS does specify what should happen.  It's an error.  FWIW, I've filed a
bug[0] against FreeBSD's behavior so we'll see what they think about it.

> Did you test my proposed solution on Linux?  I think it should work
> everywhere.

Yes, I did. It works fine.

[0] - http://www.freebsd.org/cgi/query-pr.cgi?pr=128933
-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@debian.org>




Information forwarded to debian-bugs-dist@lists.debian.org, Debian Vim Maintainers <pkg-vim-maintainers@lists.alioth.debian.org>:
Bug#493937; Package vim-python. (Mon, 17 Nov 2008 21:51:24 GMT) Full text and rfc822 format available.

Acknowledgement sent to Bram Moolenaar <Bram@moolenaar.net>:
Extra info received and forwarded to list. Copy sent to Debian Vim Maintainers <pkg-vim-maintainers@lists.alioth.debian.org>. (Mon, 17 Nov 2008 21:51:25 GMT) Full text and rfc822 format available.

Message #147 received at 493937@bugs.debian.org (full text, mbox):

From: Bram Moolenaar <Bram@moolenaar.net>
To: "James Vega" <jamessan@debian.org>
Cc: 493937@bugs.debian.org
Subject: Re: Bug#493937: [Patch] Prevent loading of Python modules in working directory
Date: Mon, 17 Nov 2008 22:38:47 +0100
James -

> >> Then this appears to be a difference (bug?) in your libc.  This is not
> >> the case with glibc 2.7 or 2.8 (the two systems I can currently test
> >> on).  Those error with ENOENT (as specified by SUS[0]).
> >
> > I'm on FreeBSD.  I used this test program:
> >
> > #include <stdio.h>
> > #include <sys/param.h>
> > #include <stdlib.h>
> > #include <errno.h>
> >
> > main()
> > {
> >        char buf[PATH_MAX];
> >        char *s;
> >        errno = 0;
> >        buf[0] = 0;
> >        s = realpath("", buf);
> >        printf("errno = %d; s = %s; buf = %s\n", errno, s, buf);
> > }
> >
> > Result (when pwd is /tmp):
> >
> > errno = 0; s = /tmp; buf = /tmp
> 
> errno = 2; s = (null); buf =
> 
> > The definition of realpath() doesn't say what happens for an empty
> > string.  It might handle it as "." or give an error.
> 
> SUS does specify what should happen.  It's an error.  FWIW, I've filed a
> bug[0] against FreeBSD's behavior so we'll see what they think about it.

OK.  It's good to have uniform behavior.  Unspecified behavior is
annoying.

> > Did you test my proposed solution on Linux?  I think it should work
> > everywhere.
> 
> Yes, I did. It works fine.

Well, in that case I'll use this not-that-nice-but-works-everywhere
solution.  Thanks for testing.

- Bram

-- 
hundred-and-one symptoms of being an internet addict:
270. You are subscribed to a mailing list for every piece of software
     you use.

 /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Tue, 16 Dec 2008 07:26:36 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sun Apr 20 21:48:48 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.