Dubious scripts at vim.org
John Beckett
scan of recent scripts. That shows another ten dubious scripts
which need to be deleted (I'll handle those).
But what about this:
http://www.vim.org/scripts/script.php?script_id=3811
It has no English description, and the download is a zip which
includes two executables called cscope.exe and ctags.exe, as
well as NERD_tree.vim, and a couple of other files.
We do not have the resources to monitor script uploads for their
desirability, but I would strongly discourage hosting packages
which include random executables, or someone else's plugin.
Any thoughts on whether scripts like this should be kept?
John
Roy Fulbright
> To: vim...@googlegroups.com
> Subject: Dubious scripts at vim.org
> Date: Thu, 24 Nov 2011 14:00:56 +1100
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
I say better safe than sorry . . . if there is any doubt, throw it out.
I'd hate to see vim user's machines infected this way.
Marc Weber
choice.
Imagine you're Japanese and you're not fluent in English.
Doing what has been done seems to be the straight forward way to share
your script.
They usually meet on lingr.com. I'll sent a message.
Hopefully they reply. I've also CCd the author of the script in this
mail. [1]
Distributing .exe files is of course a security risk - but runnig VimL
is as well (it can use system()).. - I agree that reviewing VimL can be
done - reviewing .exe files is very hard.
We can't review - but PHP has a Zip implementation - thus checking for
.exe files would be trivial.
We can't do security review of all those plugins - and many
users don't have the skills to do so themselves. Using plugins always
means running risk :( How can we improve this in general? Its not
related to .exe files or using a foreign language..
VAM contais a hint that I considered doing exactly that: distributing
curl.exe as vim plugin for bootstrapping which would be useful for
Windows users ..
Marc Weber
[1]: this thread http://groups.google.com/group/vim_use/browse_thread/thread/a43196f035faa840
Boyko Bantchev
Besides being potentially dangerous to Windows users, distribution
of .exe files as "scripts" runs counter to the idea that scripts'
execution depends on Vim alone, and not on a particular operating
system.
Marc Weber
> Besides being potentially dangerous to Windows users, distribution
> of .exe files as "scripts" runs counter to the idea that scripts'
> execution depends on Vim alone, and not on a particular operating
> system.
So do we all agree that Vim is missing a :call download('http://','destination') function?
Then scripts could ask and download exe files for the user.
I'd also vote for an md5 implementation then so that the download can be verified?
Yes - I know, Vim is an editor only - and not Emacs. But shipping with
enough tools to bootstrap more features would not hurt much.
Think about the problem this script tries to solve.
Its not an arbitrary executable, its ctags. I haven't verified it. But
we should also think about the "why did this happen" in addition to "do
we want this?".
Marc Weber
John Beckett
>> Besides being potentially dangerous to Windows users,
>> distribution of .exe files as "scripts" runs counter to the
>> idea that scripts' execution depends on Vim alone, and not
>> on a particular operating system.
>
> So do we all agree that Vim is missing a :call
> download('http://','destination') function?
> Then scripts could ask and download exe files for the user.
> I'd also vote for an md5 implementation then so that the
> download can be verified?
The problem is that a plugin author has something that works
with, say, Exuberant Ctags so they want people who download the
plugin to have that utility.
The solution is to include a link to the official distribution
in the plugin documentation.
> Its not an arbitrary executable, its ctags.
It's probably a particular version of someone's ctags. But it
might be a hacked version which installs a keylogger.
John
Marc Weber
> It's probably a particular version of someone's ctags. But it
> might be a hacked version which installs a keylogger.
15.5. looks like they recommend cygwin now - but the script does not hip
with cygwin.dll ? If asked google to find md5 and sha1 sums of one of
the executables - no match. This does not mean its malicious though.
Should we keep it? Should we add a warning? .. Well in the end
www.vim.org is not the place to put binaries - I agree.
We don't want the database to be flooded with huge amounts of binary
data - equally important - the same binary data over and over again.
Great that you found it.
How to protect against it in the future?
Does removing it protect users?
I mean browsing scripts at www.vim.org is not that great at all:
You don't see the files which are contained in a zip. You have to
provide duplicate install and plugin information (worst case 3 times:
1) doc/*.txt 2) READMe for github 3) instructions for www.vim.org)
...
Having exe for windows is easy.. What about #! scripts on linux?
Do you expect users to read every line ?
http://stackoverflow.com/questions/2866787/how-to-create-a-bat-file-to-download-file-from-http-ftp-server
shows that its pretty simple to download applications by FTP using VimL
and system ?
I haven't tested it.
But looks trivial to do.
How can we improve security? Switch OS: Use sandboxes, ... ?
Marc Weber
Bram Moolenaar
Marc Weber wrote:
I think it's better not to allow download of .exe files from Vim
scripts. Especially when it's something not Vim-specific such as
ctags.exe, this should be hosted elsewhere.
There should be some English text in the description. If someone can't
write English well and the script is specific for a non-English
language, there may be details in another language. I don't think this
script is non-English, someone should be able to translate the text so
that the plugin is useful for more people.
Marc, can you contact the author and ask him to take care of this?
--
hundred-and-one symptoms of being an internet addict:
169. You hire a housekeeper for your home page.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Marc Weber
> Marc, can you contact the author and ask him to take care of this?
- CCing the author. So if he reads mail - he knows about the issue.
- Put a note on lingr.com (vim_users_en) (some days ago) and reposted it
in vim-users.jp today however I can write English only.
Thus we have tried to notifying the author.
There is one last thing I could do: use google translation to write a
mail in Japanese - but the results are not always good. I can't judge
the translation at all. Can someone judge this translation quality or
sent an email in Japanese?
I'm fine with removing the scripts download file.
But the real fix is to fix the site - and I feel that PHP doesn't scale
compared to how I'd like the website to look like..
Marc Weber
Yasuhiro MATSUMOTO
Marc Weber
> I'm administrator of http://vim-jp.org/ .
> Have I better to notify to all? Then, I'll post entry about this.
There should be enough English text to understand what the plugin is
about.
The plugin contained executables. For the reasons given in this thread
it should be discouraged:
- less trustworthy
- avoid duplication and outdated software.
- avoid huge amounts of binary data.
If there are very strong reasons to contain executables - then it should
be easy to verify their origin.
Additionally it contains NERD_tree.vim which was taken from
The_NERD_tree plugin on www.vim.org.
For distributing sets of foreign plugins I personally recommend VAM
(vim-addon-manager [1]) because it can resolve dependencies - but does not
care about versions which seems to be just good enough for most use
cases.
Eg you add an addon-info.json file with these contents:
{'dependencies': {'The_NERD_tree':{}}}
Then VAM will fetch the up to date version of that plugin automatically.
The intention was writing a plugin making it easy to reuse other
people's work.
If you trust me http://www.mawercer.de/~marc/vam/index.php can be used
to checkout many plugins at once for Windows users - because installing
git and curl on Windows causes some work to setup (too much for my case)
If this implementation (which is running VAM zipping the fetch result)
is used more often I'll think about improving Windows support even more
so that everybody can checkout things himself without trusting my
website. VAM's documentation contains more info about what could be done
such as asking github to return .zip files for windows users.
This way dependencies on third people's homepages/scripts like me can be
dropped. I'm lazy - I only do what I need - or what some people ask me
to do. That's why comments exist right now.
Thanks for replying to this thread!
Marc Weber
Benjamin R. Haskell
> Excerpts from Yasuhiro MATSUMOTO's message of Fri Nov 25 04:21:39 +0100 2011:
>> I'm administrator of http://vim-jp.org/ .
>> Have I better to notify to all? Then, I'll post entry about this.
> :) Great. That would be perfect. What to post?
>
> There should be enough English text to understand what the plugin is
> about.
Why? That seems like a pointless restriction. Just because a plugin
author is unable to write in English doesn't make the plugin somehow
unworthy of being on vim.org.
If a malicious plugin is published with only a description in Japanese,
and someone who doesn't speak Japanese downloads it and suffers damage
to their system, certainly the blame is on the uninformed user, not the
scripts archive.
And, in the more likely case that the plugin is useful, but the author
simply can't write in English, there's no reason to prevent the script's
presence on vim.org.
--
Best,
Ben
Yasuhiro MATSUMOTO
Marc Weber
Japanese - but Chinese. Sorry for this.
I just tried Google translation from Japanese to German - and it
returned a translation (which did not make too much sense) - and lot's
of untranslated characters. The Chinese -> German translation looks much
better. Sorry for my mistake.
I'll send a new email to the author using google translation.
I've verified that the chinese translation is at least understandable -
because the translation back to English is understandable.
Marc Weber
Yasuhiro MATSUMOTO
Marc Weber
> Why? That seems like a pointless restriction. Just because a plugin
> author is unable to write in English doesn't make the plugin somehow
> unworthy of being on vim.org.
Even Chinese people are likely to know people knowing enough English -
so they could ask a friend to translate a minimal description.
I agree that we should be open to everyone. But - we should also try to
protect users if possible and sensible.
I'll take notes about this issue. Eventually we can offer translations
for popular plugins in the future - or ask site visitors to do the
translation if it doesn't exist yet - or use google translator - because
it looks like getting the job done reasonably.
By the way: Additional steps must be taken to make Windows run those
executable by Vim.
Marc Weber
uj
including the script you mentioned which is written in Chinese.
alick
I am a Chinese and I can confirm that the descriptions are in Chinese.
If I understand correctly(it should be...), the script serves as a
plugin bundle (as well as configuation bundle) to ease the set-up of C
programming environment on Windows. (The author mentioned Linux stating
that support is not realized.) That is to say, the author use these
tools to initialize C project environment quickly.
I personally dislike this kind of distribution of plugins. But maybe
someone just like it because it can really speed up the environment
setting-up things.
I can provide more explanation of the Chinese stuff, if needed.
--
alick
Fedora 14 (Laughlin) user
https://fedoraproject.org/wiki/User:Alick
Marc Weber
" Hi, thank you for your tips! I'll try to fix this problem this weekend. "
Looks like the author knows how to write English and that the executable
issue is going to be resolved :)
Great.
Marc Weber