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>
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, mbox, link).
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, mbox, link).
Message #5 received at submit@bugs.debian.org (full text, mbox, reply):
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, mbox, link).
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, mbox, link).
Message #10 received at 484305@bugs.debian.org (full text, mbox, reply):
[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, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Robert Collins <robertc@robertcollins.net>:
Bug#484305; Package bicyclerepair.
(full text, mbox, link).
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, mbox, link).
Message #17 received at 484305@bugs.debian.org (full text, mbox, reply):
[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, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Robert Collins <robertc@robertcollins.net>:
Bug#484305; Package bicyclerepair.
(full text, mbox, link).
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, mbox, link).
Message #24 received at 484305@bugs.debian.org (full text, mbox, reply):
[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, mbox, link).
Information forwarded to debian-bugs-dist@lists.debian.org, Robert Collins <robertc@robertcollins.net>:
Bug#484305; Package bicyclerepair.
(full text, mbox, link).
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, mbox, link).
Message #31 received at 484305@bugs.debian.org (full text, mbox, reply):
[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, mbox, link).
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, mbox, link).
Message #36 received at 484305@bugs.debian.org (full text, mbox, reply):
[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, mbox, link).
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, mbox, link).
Message #41 received at 484305@bugs.debian.org (full text, mbox, reply):
[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, mbox, link).
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, mbox, link).
Message #46 received at 484305@bugs.debian.org (full text, mbox, reply):
[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, mbox, link).
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, mbox, link).
Message #51 received at 484305@bugs.debian.org (full text, mbox, reply):
[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, mbox, link).
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, mbox, link).
Message #56 received at 484305@bugs.debian.org (full text, mbox, reply):
[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, mbox, link).
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, mbox, link).
Message #61 received at 484305@bugs.debian.org (full text, mbox, reply):
[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, mbox, link).
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, mbox, link).
Message #66 received at 484305@bugs.debian.org (full text, mbox, reply):
[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, mbox, link).
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, mbox, link).
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, mbox, link).
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, mbox, link).
Message #75 received at 493937@bugs.debian.org (full text, mbox, reply):
[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, mbox, link).
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, mbox, link).
Message #80 received at 493937@bugs.debian.org (full text, mbox, reply):
[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, mbox, link).
Reply sent
to James Vega <jamessan@debian.org>:
You have taken responsibility.
(Fri, 17 Oct 2008 21:33:05 GMT) (full text, mbox, link).
Notification sent
to Thomas Arendsen Hein <thomas@intevation.de>:
Bug acknowledged by developer.
(Fri, 17 Oct 2008 21:33:47 GMT) (full text, mbox, link).
Message #87 received at 493937-close@bugs.debian.org (full text, mbox, reply):
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, mbox, link).
Notification sent
to Thomas Arendsen Hein <thomas@intevation.de>:
Bug acknowledged by developer.
(Mon, 20 Oct 2008 19:21:09 GMT) (full text, mbox, link).
Message #92 received at 493937-close@bugs.debian.org (full text, mbox, reply):
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, mbox, link).
Message #95 received at 493937-forwarded@bugs.debian.org (full text, mbox, reply):
[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, reply):
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, mbox, link).
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, mbox, link).
Message #101 received at 493937@bugs.debian.org (full text, mbox, reply):
[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, mbox, link).
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, mbox, link).
Message #106 received at 493937@bugs.debian.org (full text, mbox, reply):
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, reply):
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, mbox, link).
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, mbox, link).
Message #112 received at 493937@bugs.debian.org (full text, mbox, reply):
[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, mbox, link).
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, mbox, link).
Message #117 received at 493937@bugs.debian.org (full text, mbox, reply):
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, mbox, link).
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, mbox, link).
Message #122 received at 493937@bugs.debian.org (full text, mbox, reply):
[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, mbox, link).
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, mbox, link).
Message #127 received at 493937@bugs.debian.org (full text, mbox, reply):
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, mbox, link).
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, mbox, link).
Message #132 received at 493937@bugs.debian.org (full text, mbox, reply):
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, mbox, link).
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, mbox, link).
Message #137 received at 493937@bugs.debian.org (full text, mbox, reply):
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, mbox, link).
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, mbox, link).
Message #142 received at 493937@bugs.debian.org (full text, mbox, reply):
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, mbox, link).
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, mbox, link).
Message #147 received at 493937@bugs.debian.org (full text, mbox, reply):
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, mbox, link).
Send a report that this bug log contains spam.
Debbugs is free software and licensed under the terms of the GNU General Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.
Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.