Re: Security risk of vim swap files
Hi, 2017/11/1 Wed 6:20:27 UTC+9 Bram Moolenaar wrote: > Hanno Böck wrote: > > > I wanted to point out an issue here with vim swap files that make them > > a security problem. > > > > By default vim creates a file with the name .filename.swp in the same > > directory while editing. They contain the full content of the edited > > file. This usually gets deleted upon exit, but not if vim crashes or > > gets killed (e.g. due to a reboot). > > > > On web servers this can be a severe security risk. One can e.g. scan > > for web hosts that have swap files of PHP configuration files and thus > > expose settings like database passwords. (e.g. wget > > http://example.com/.wp-config.php.swp ) > > Why would a web server expose and serve such a file? That clearly is > the problem, not that Vim happens to create swap files (and undo and > backup files, depending on your configuration). > > You probably also create new files and copies of files that should not > be served. If you care about security, the web server must always use > whitelisting, only serve files that were intentionally made public. > > > In a scan of the alexa top 1 million I found ~750 instances of such > > files. I tried to inform affected people as best as I could. I also > > discovered such scans in my own web server logs, so I assume black hats > > are already aware of this and it's actively exploitet. > > > > I was wondering how to best avoid this on my own servers and I first > > thought about saving the swap files to tmp ( with "set directory"). > > However on multiuser systems this creates another security problem. > > These files are world readable, thus instead of leaking information to > > the world it's now leaking information to other users on the same > > system. Thus even if one is aware of the issue it's nontrivial to get > > secure settings (I've now worked around this by having per-user tmp > > dirs with secure permissions.) > > > > I think vim should change the behavior of swap files: > > 1. they should be stored in /tmp by default > > No, on Linux this is wiped clean on reboot. You lose your work on a > system crash. > > > 2. they should have secure permissions (tmp file security is > > a tricky thing and needs careful consideration to avoid symlink attacks > > and the like, but there are dedicated functions for this like mkstemp). > > The permissions are the same as the original file, and that is exactly > how it should be. > > > 3. Ideally they also shouldn't leak currently edited filenames (e.g. > > they shouldn't be called /tmp/.test.txt.swp, but more something > > like /tmp/.vim_swap.123782173) > > Infeasible, Vim can't find that file when trying to recover the original > file. An issue related to this (not the same) is filed as CVE-2017-1000382: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000382 https://security-tracker.debian.org/tracker/CVE-2017-1000382 It seems that the problem is that Vim ignores umask: http://www.openwall.com/lists/oss-security/2017/10/31/15 (Similar one for Emacs: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000383 ) Regards, Ken Takata -- -- You received this message from the "vim_dev" 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: vim 7.3
Another thing I don't like (or maybe don't understand) in git is the existence of "garbage collection". On the contrary, a basic tenet of Mercurial philosophy is that history is frozen in stone, so if I let a clone stand without updating it for, let's say, a year, and then run "hg pull -u" or "hg fetch", Mercurial will be able to continue from where I left off and (barring timeouts and brownouts) get the clone back up to date. Once I did that with git, and when I came back after a year my clone was so hopelessly out of date that git didn't know how to update it: the only way I found to make it up to date again was to delete the clone and make a new one. Best regards, Tony. P.S. Happily for me, Christian understands both of them (or ;-) seems to) so I enjoy the luxury of a Mercurial mirror to Bram's git repository. -- -- You received this message from the "vim_dev" 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Not seeing source code with :Termdebug
> Tom Lebreux wrote: > >> the source code doesn't appear in the source buffer >> when using :Termdebug. I can use gdb fine to step,continue,break,etc >> but I cannot see the source code (unless I `list` manually in the gdb >> window. Also, the buttons in the tabbar don't seem to be doing anything. >> >> I tried with a simple program compiled with `-g` for debug info. I also >> tried doing exactly what is described in the scenario shown in >> :help Termdebug. >> >> I tried with `vim -u NONE` just to be sure no plugins or configs messed >> with this functionality. My vim version patch 1176. > What do you see in the communication window? > > sbuf communication I see `-exec-next`, `-exec-finish`,`-exec-continue` and `data-evaluate-expression ""`. I have gdb version 8.0.1. As Christian Brabandt replied in another email, it sounds like I have the same problem as in https://github.com/vim/vim/issues/2154 Tom Lebreux -- -- You received this message from the "vim_dev" 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: vim 7.3
2017-10-30 16:51 GMT+03:00 Marius Gedminas :
> On Sat, Oct 28, 2017 at 02:50:48AM +0200, Tony Mechelynck wrote:
>> On Thu, Oct 26, 2017 at 7:19 PM, tooth pik wrote:
>> > you don't use git?
>> >
>> No I don't, not for Vim anyway. Somehow I understand Mercurial but not
>> git, so given a choice between them I always choose Mercurial. (For
>> instance, does git have a specific function to list incoming
>> changesets, other than "git pull --dry-run"? I like the "log-style"
>> format of "hg incoming".)
>
> I've a git alias `incoming` for this:
>
> # ~/.gitconfig
> [alias]
> incoming = !git fetch && git log --oneline ..@{u}
>
> (I do not remember what the format of `hg incoming` is.)
`hg incoming` has exactly the same format as `hg log`, including
ability to use `--template`. But it does not save anything and it
works with whatever branch(es) you need. I would say that it would be
hard to have yours `incoming` or `new` if you want to get more then
one branch with one command, and configuring git to pull in all
branches from remote at once is normally the first thing I do.
>
> I also have another git alias, `new`, that shows me the contents of the
> last pull after I've done it:
>
> new = !sh -c 'git log $1@{1}..$1@{0} "$@"'
>
> Regards,
> Marius Gedminas
> --
> /*
> * This function is about (re)setting the class of a held lock,
> * yet we're not actually holding any locks. Naughty user!
> */
>
> --
> --
> You received this message from the "vim_dev" 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
>
> ---
> You received this message because you are subscribed to the Google Groups
> "vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vim_dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
--
You received this message from the "vim_dev" 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
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.0.1241
On Tue, Oct 31, 2017 at 10:20:14PM +0100, Bram Moolenaar wrote:
> *** ../vim-8.0.1240/src/testdir/test_popup.vim2017-10-27
> 01:34:55.093306847 +0200
> --- src/testdir/test_popup.vim2017-10-31 22:15:48.865608389 +0100
> ***
> *** 639,645
> endif
> let g:buf = term_start([GetVimProg(), '--clean', '-c', 'set noswapfile'],
> {'term_rows': h / 3})
> call term_sendkeys(g:buf, (h / 3 - 1)."o\")
> ! call term_wait(g:buf, 200)
> call term_sendkeys(g:buf, "Gi\")
> call term_sendkeys(g:buf, "\")
> call term_wait(g:buf, 100)
> --- 639,645
> endif
> let g:buf = term_start([GetVimProg(), '--clean', '-c', 'set noswapfile'],
> {'term_rows': h / 3})
> call term_sendkeys(g:buf, (h / 3 - 1)."o\")
> ! call term_wait(g:buf, 500)
Wouldn't something more deterministic be better? How about this?
diff --git i/src/testdir/test_popup.vim w/src/testdir/test_popup.vim
index 2781aabcd..a4bed18d9 100644
--- i/src/testdir/test_popup.vim
+++ w/src/testdir/test_popup.vim
@@ -639,7 +639,8 @@ func Test_popup_and_window_resize()
endif
let g:buf = term_start([GetVimProg(), '--clean', '-c', 'set noswapfile'],
{'term_rows': h / 3})
call term_sendkeys(g:buf, (h / 3 - 1)."o\")
- call term_wait(g:buf, 500)
+ " Wait for the nested Vim to exit insert mode, where it will show the ruler
+ call WaitFor(printf('term_getline(g:buf, %d) =~ "\<%d,1\>"', h, h / 3))
call term_sendkeys(g:buf, "Gi\")
call term_sendkeys(g:buf, "\")
call term_wait(g:buf, 100)
Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
--
--
You received this message from the "vim_dev" 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
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.0.1227
On So, 29 Okt 2017, Christian Brabandt wrote:
> On Sa, 28 Okt 2017, Bram Moolenaar wrote:
> > Feel free to make one.
>
> I kind of knew that this answer would come :)
>
> Okay, will look into that one and the other undefined behaviour patches.
>
> > I can't reproduce the error.
>
> I was thinking, it would still make sense to have them as test, even if
> those don't trigger the error in every environment.
Okay, how about this patch:
diff --git a/src/testdir/test_normal.vim b/src/testdir/test_normal.vim
index f6b1a43b8..7d31373c9 100644
--- a/src/testdir/test_normal.vim
+++ b/src/testdir/test_normal.vim
@@ -1208,6 +1208,13 @@ func! Test_normal19_z_spell()
call assert_match("Word 'goood' added to ./Xspellfile2.add", a)
call assert_equal('goood', cnt[0])
+ " Test for :spellgood!
+ let temp=execute(':spe!0/0')
+ call assert_match('Invalid region', temp)
+ let spellfile=matchstr(temp, 'Invalid region nr in \zs.*\ze line \d: 0')
+ call assert_equal(['# goood', '# goood/!', '#oood', '0/0'],
readfile(spellfile))
+ call delete(spellfile)
+
" clean up
exe "lang" oldlang
call delete("./Xspellfile.add")
diff --git a/src/testdir/test_search.vim b/src/testdir/test_search.vim
index b863fcbba..9e3b8783c 100644
--- a/src/testdir/test_search.vim
+++ b/src/testdir/test_search.vim
@@ -567,3 +567,22 @@ func Test_search_cmdline_incsearch_highlight_attr()
bwipe!
endfunc
+
+func Test_search_undefined_behaviour()
+ if !has("terminal")
+return
+ endif
+ let h = winheight(0)
+ if h < 3
+return
+ endif
+ " did cause an undefined left shift
+ let g:buf = term_start([GetVimProg(), '--clean', '-e', '-s', '-c', 'call
search(getline("."))', 'samples/test000'], {'term_rows': 3})
+ call assert_equal([''], getline(1, '$'))
+ call term_sendkeys(g:buf, ":qa!\")
+ bwipe!
+endfunc
+
+func Test_search_undefined_behaviour2()
+ call assert_fails("call search('\\%UC000')", 'E486')
+endfu
This already includes a test for issue #2255, that currently fails.
Christian
--
Wie man sein Kind nicht nennen sollte:
Reiner Zufall
--
--
You received this message from the "vim_dev" 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
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Test_popup_and_window_resize() failures
Dominique Pellé wrote:
> > Christian Brabandt wrote:
> >
> >> On Mo, 30 Okt 2017, James McCoy wrote:
> >>
> >>> I recently uploaded 8.0.1226 to Debian and nearly every build failed[0].
> >>> The most common failure is
> >>>
> >>> Found errors in Test_popup_and_window_resize():
> >>> function RunTheTest[34]..Test_popup_and_window_resize line 16:
> >>> Pattern '^!\\s*$' does not match ''
> >>> function RunTheTest[34]..Test_popup_and_window_resize line 26:
> >>> Pattern '^!\\s*$' does not match '~
> >>> '
> >>> function RunTheTest[34]..Test_popup_and_window_resize line 28:
> >>> Pattern '^!\\s*$' does not match ''
> >>>
> >>> I investigated some and that test appears to be extremely flaky in those
> >>> environments. I haven't had a failure yet locally (amd64 system), but
> >>> those architectures fail almost every run.
> >>>
> >>> Attached is a log from that test and the associated diff showing where I
> >>> added ch_log() calls.
> >>>
> >>> [0]:
> >>> https://buildd.debian.org/status/logs.php?pkg=vim&ver=2%3A8.0.1226-1&suite=sid
> >>
> >> Is it possible to run those tests interactively on those architectures?
> >> Or does it succeed when run interactively and only fails when run in the
> >> test suite?
> >>
> >>
> >> Christian
> >
> > I've seen the same test failures on my Linux machine a few days ago.
> > It happened several times in a row.
> > Somehow it's not happening anymore. Note sure why.
> > I'll try to reproduce it.
> >
> > Dominique
>
> I can now reproduce the test failure 100% of the times
> when Vim-8.0.1238 is configured with:
>
> $ CC=gcc-7 ./configure --with-features=huge --enable-gui=none
>
> and when building with asan i.e. with this change:
>
> diff --git a/src/Makefile b/src/Makefile
> index 0b95c6e..50c0fff 100644
> --- a/src/Makefile
> +++ b/src/Makefile
> @@ -681,7 +681,7 @@ LINT_OPTIONS = -beprxzF
> # address sanitizer or with the undefined sanitizer. Works with gcc and
> # clang. May make Vim twice as slow. Errors reported on stderr.
> # More at: https://code.google.com/p/address-sanitizer/
> -#SANITIZER_CFLAGS = -g -O0 -fsanitize=address -fno-omit-frame-pointer
> +SANITIZER_CFLAGS = -g -O0 -fsanitize=address -fno-omit-frame-pointer
> #SANITIZER_CFLAGS = -g -O0 -fsanitize=undefined -fno-omit-frame-pointer
> SANITIZER_LIBS = $(SANITIZER_CFLAGS)
>
> Here is how it fails:
>
> $ cd vim/src
> $ make test_popup
> ...
> Executed 20 tests
> 1 FAILED:
> Found errors in Test_popup_and_window_resize():
> function RunTheTest[34]..Test_popup_and_window_resize line 16: Pattern
> '^!\\s*$' does not match ''
> function RunTheTest[34]..Test_popup_and_window_resize line 26: Pattern
> '^!\\s*$' does not match '~
> '
> function RunTheTest[34]..Test_popup_and_window_resize line 28: Pattern
> '^!\\s*$' does not match ''
>
>
> Increasing the time to wait like this fixes it for me:
>
> diff --git a/src/testdir/test_popup.vim b/src/testdir/test_popup.vim
> index 1be4e6f..cedcd26 100644
> --- a/src/testdir/test_popup.vim
> +++ b/src/testdir/test_popup.vim
> @@ -639,7 +639,7 @@ func Test_popup_and_window_resize()
>endif
>let g:buf = term_start([GetVimProg(), '--clean', '-c', 'set
> noswapfile'], {'term_rows': h / 3})
>call term_sendkeys(g:buf, (h / 3 - 1)."o\")
> - call term_wait(g:buf, 200)
> + call term_wait(g:buf, 400)
>call term_sendkeys(g:buf, "Gi\")
>call term_sendkeys(g:buf, "\")
>call term_wait(g:buf, 100)
Thanks for digging in to this. Time-dependent tests are bad, but in
this case it's hard to do otherwise. I'll make it 500 msec to give it a
bit more room.
I was also thinking of making the vim instance that's started extra
slow, e.g. by running it under valgrind, but didn't get to that yet.
I assume ASAN also makes it a bit slower (but less than valgrind).
--
Shaw's Principle: Build a system that even a fool can use, and
only a fool will want to use it.
/// Bram Moolenaar -- b...@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///
--
--
You received this message from the "vim_dev" 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
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Not seeing source code with :Termdebug
Tom Lebreux wrote: > the source code doesn't appear in the source buffer > when using :Termdebug. I can use gdb fine to step,continue,break,etc > but I cannot see the source code (unless I `list` manually in the gdb > window. Also, the buttons in the tabbar don't seem to be doing anything. > > I tried with a simple program compiled with `-g` for debug info. I also > tried doing exactly what is described in the scenario shown in > :help Termdebug. > > I tried with `vim -u NONE` just to be sure no plugins or configs messed > with this functionality. My vim version patch 1176. What do you see in the communication window? sbuf communication -- LAUNCELOT: Isn't there a St. Arrggghhh's in Cornwall? ARTHUR:No, that's Saint Ives. "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@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/// -- -- You received this message from the "vim_dev" 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Patch 8.0.1241
Patch 8.0.1241
Problem:Popup test is flaky. (James McCoy)
Solution: Increase the wait time. (Dominique Pelle)
Files: src/testdir/test_popup.vim
*** ../vim-8.0.1240/src/testdir/test_popup.vim 2017-10-27 01:34:55.093306847
+0200
--- src/testdir/test_popup.vim 2017-10-31 22:15:48.865608389 +0100
***
*** 639,645
endif
let g:buf = term_start([GetVimProg(), '--clean', '-c', 'set noswapfile'],
{'term_rows': h / 3})
call term_sendkeys(g:buf, (h / 3 - 1)."o\")
! call term_wait(g:buf, 200)
call term_sendkeys(g:buf, "Gi\")
call term_sendkeys(g:buf, "\")
call term_wait(g:buf, 100)
--- 639,645
endif
let g:buf = term_start([GetVimProg(), '--clean', '-c', 'set noswapfile'],
{'term_rows': h / 3})
call term_sendkeys(g:buf, (h / 3 - 1)."o\")
! call term_wait(g:buf, 500)
call term_sendkeys(g:buf, "Gi\")
call term_sendkeys(g:buf, "\")
call term_wait(g:buf, 100)
*** ../vim-8.0.1240/src/version.c 2017-10-30 21:56:18.623439255 +0100
--- src/version.c 2017-10-31 22:16:31.005347354 +0100
***
*** 763,764
--- 763,766
{ /* Add new patch number below this line */
+ /**/
+ 1241,
/**/
--
"When I die, I want a tombstone that says "GAME OVER" - Ton Richters
/// Bram Moolenaar -- b...@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///
--
--
You received this message from the "vim_dev" 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
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
Hanno Böck wrote: > I wanted to point out an issue here with vim swap files that make them > a security problem. > > By default vim creates a file with the name .filename.swp in the same > directory while editing. They contain the full content of the edited > file. This usually gets deleted upon exit, but not if vim crashes or > gets killed (e.g. due to a reboot). > > On web servers this can be a severe security risk. One can e.g. scan > for web hosts that have swap files of PHP configuration files and thus > expose settings like database passwords. (e.g. wget > http://example.com/.wp-config.php.swp ) Why would a web server expose and serve such a file? That clearly is the problem, not that Vim happens to create swap files (and undo and backup files, depending on your configuration). You probably also create new files and copies of files that should not be served. If you care about security, the web server must always use whitelisting, only serve files that were intentionally made public. > In a scan of the alexa top 1 million I found ~750 instances of such > files. I tried to inform affected people as best as I could. I also > discovered such scans in my own web server logs, so I assume black hats > are already aware of this and it's actively exploitet. > > I was wondering how to best avoid this on my own servers and I first > thought about saving the swap files to tmp ( with "set directory"). > However on multiuser systems this creates another security problem. > These files are world readable, thus instead of leaking information to > the world it's now leaking information to other users on the same > system. Thus even if one is aware of the issue it's nontrivial to get > secure settings (I've now worked around this by having per-user tmp > dirs with secure permissions.) > > I think vim should change the behavior of swap files: > 1. they should be stored in /tmp by default No, on Linux this is wiped clean on reboot. You lose your work on a system crash. > 2. they should have secure permissions (tmp file security is > a tricky thing and needs careful consideration to avoid symlink attacks > and the like, but there are dedicated functions for this like mkstemp). The permissions are the same as the original file, and that is exactly how it should be. > 3. Ideally they also shouldn't leak currently edited filenames (e.g. > they shouldn't be called /tmp/.test.txt.swp, but more something > like /tmp/.vim_swap.123782173) Infeasible, Vim can't find that file when trying to recover the original file. -- BEDEVERE: Oh! LAUNCELOT: No "Arrggghhh ... " at the back of the throat. BEDEVERE: No! "Oh!" in surprise and alarm! "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- b...@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/// -- -- You received this message from the "vim_dev" 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 8.0.1238
On So, 29 Okt 2017, Bram Moolenaar wrote: > Patch 8.0.1238 > Problem:Incremental search only shows one match. > Solution: When 'incsearch' and and 'hlsearch' are both set highlight all > matches. (haya14busa, closes #2198) > Files: runtime/doc/options.txt, src/ex_getln.c, src/proto/search.pro, > src/search.c, src/testdir/test_search.vim It looks like the test does not work correctly on Windows. I see some failures: https://ci.appveyor.com/project/chrisbra/vim-win32-installer/build/job/g4p49k5gh6k3nbq5 , | From test_search.vim: | Found errors in Test_search_cmdline_incsearch_highlight_attr(): function RunTheTest[34]..Test_search_cmdline_incsearch_highlight_attr | line 28: Expected not equal to 292 function RunTheTest[34]..Test_search_cmdline_incsearch_highlight_attr | line 29: Expected not equal to 292 function RunTheTest[34]..Test_search_cmdline_incsearch_highlight_attr | line 30: Expected not equal to 292 | TEST FAILURE NMAKE : fatal error U1077: 'if' : return code '0x1' ` This test is now disabled for the vim-win32-installer build. Once it builds again, I'll try to debug this test. Christian -- In Hollywood gibt es keinen Taxifahrer, der nicht am Abend Drehbücher schreibt. -- Wim Wenders -- -- You received this message from the "vim_dev" 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Test_popup_and_window_resize() failures
Dominique Pellé wrote:
> Christian Brabandt wrote:
>
>> On Mo, 30 Okt 2017, James McCoy wrote:
>>
>>> I recently uploaded 8.0.1226 to Debian and nearly every build failed[0].
>>> The most common failure is
>>>
>>> Found errors in Test_popup_and_window_resize():
>>> function RunTheTest[34]..Test_popup_and_window_resize line 16: Pattern
>>> '^!\\s*$' does not match ''
>>> function RunTheTest[34]..Test_popup_and_window_resize line 26: Pattern
>>> '^!\\s*$' does not match '~
>>> '
>>> function RunTheTest[34]..Test_popup_and_window_resize line 28: Pattern
>>> '^!\\s*$' does not match ''
>>>
>>> I investigated some and that test appears to be extremely flaky in those
>>> environments. I haven't had a failure yet locally (amd64 system), but
>>> those architectures fail almost every run.
>>>
>>> Attached is a log from that test and the associated diff showing where I
>>> added ch_log() calls.
>>>
>>> [0]:
>>> https://buildd.debian.org/status/logs.php?pkg=vim&ver=2%3A8.0.1226-1&suite=sid
>>
>> Is it possible to run those tests interactively on those architectures?
>> Or does it succeed when run interactively and only fails when run in the
>> test suite?
>>
>>
>> Christian
>
> I've seen the same test failures on my Linux machine a few days ago.
> It happened several times in a row.
> Somehow it's not happening anymore. Note sure why.
> I'll try to reproduce it.
>
> Dominique
I can now reproduce the test failure 100% of the times
when Vim-8.0.1238 is configured with:
$ CC=gcc-7 ./configure --with-features=huge --enable-gui=none
and when building with asan i.e. with this change:
diff --git a/src/Makefile b/src/Makefile
index 0b95c6e..50c0fff 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -681,7 +681,7 @@ LINT_OPTIONS = -beprxzF
# address sanitizer or with the undefined sanitizer. Works with gcc and
# clang. May make Vim twice as slow. Errors reported on stderr.
# More at: https://code.google.com/p/address-sanitizer/
-#SANITIZER_CFLAGS = -g -O0 -fsanitize=address -fno-omit-frame-pointer
+SANITIZER_CFLAGS = -g -O0 -fsanitize=address -fno-omit-frame-pointer
#SANITIZER_CFLAGS = -g -O0 -fsanitize=undefined -fno-omit-frame-pointer
SANITIZER_LIBS = $(SANITIZER_CFLAGS)
Here is how it fails:
$ cd vim/src
$ make test_popup
...
Executed 20 tests
1 FAILED:
Found errors in Test_popup_and_window_resize():
function RunTheTest[34]..Test_popup_and_window_resize line 16: Pattern
'^!\\s*$' does not match ''
function RunTheTest[34]..Test_popup_and_window_resize line 26: Pattern
'^!\\s*$' does not match '~
'
function RunTheTest[34]..Test_popup_and_window_resize line 28: Pattern
'^!\\s*$' does not match ''
Increasing the time to wait like this fixes it for me:
diff --git a/src/testdir/test_popup.vim b/src/testdir/test_popup.vim
index 1be4e6f..cedcd26 100644
--- a/src/testdir/test_popup.vim
+++ b/src/testdir/test_popup.vim
@@ -639,7 +639,7 @@ func Test_popup_and_window_resize()
endif
let g:buf = term_start([GetVimProg(), '--clean', '-c', 'set
noswapfile'], {'term_rows': h / 3})
call term_sendkeys(g:buf, (h / 3 - 1)."o\")
- call term_wait(g:buf, 200)
+ call term_wait(g:buf, 400)
call term_sendkeys(g:buf, "Gi\")
call term_sendkeys(g:buf, "\")
call term_wait(g:buf, 100)
Regards
Dominique
--
--
You received this message from the "vim_dev" 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
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Test_popup_and_window_resize() failures
Christian Brabandt wrote: > On Mo, 30 Okt 2017, James McCoy wrote: > >> I recently uploaded 8.0.1226 to Debian and nearly every build failed[0]. >> The most common failure is >> >> Found errors in Test_popup_and_window_resize(): >> function RunTheTest[34]..Test_popup_and_window_resize line 16: Pattern >> '^!\\s*$' does not match '' >> function RunTheTest[34]..Test_popup_and_window_resize line 26: Pattern >> '^!\\s*$' does not match '~ >> ' >> function RunTheTest[34]..Test_popup_and_window_resize line 28: Pattern >> '^!\\s*$' does not match '' >> >> I investigated some and that test appears to be extremely flaky in those >> environments. I haven't had a failure yet locally (amd64 system), but >> those architectures fail almost every run. >> >> Attached is a log from that test and the associated diff showing where I >> added ch_log() calls. >> >> [0]: >> https://buildd.debian.org/status/logs.php?pkg=vim&ver=2%3A8.0.1226-1&suite=sid > > Is it possible to run those tests interactively on those architectures? > Or does it succeed when run interactively and only fails when run in the > test suite? > > > Christian I've seen the same test failures on my Linux machine a few days ago. It happened several times in a row. Somehow it's not happening anymore. Note sure why. I'll try to reproduce it. Dominique -- -- You received this message from the "vim_dev" 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: vim 7.3
On Mo, 30 Okt 2017, Marius Gedminas wrote:
> On Sat, Oct 28, 2017 at 02:50:48AM +0200, Tony Mechelynck wrote:
> > On Thu, Oct 26, 2017 at 7:19 PM, tooth pik wrote:
> > > you don't use git?
> > >
> > No I don't, not for Vim anyway. Somehow I understand Mercurial but not
> > git, so given a choice between them I always choose Mercurial. (For
> > instance, does git have a specific function to list incoming
> > changesets, other than "git pull --dry-run"? I like the "log-style"
> > format of "hg incoming".)
>
> I've a git alias `incoming` for this:
>
> # ~/.gitconfig
> [alias]
> incoming = !git fetch && git log --oneline ..@{u}
>
> (I do not remember what the format of `hg incoming` is.)
So do it :)
However, one might also want to check git shortlog
Christian
--
Das Leben besteht in dem, was ein Mensch den ganzen Tag über denkt.
-- Ralph Waldo Emerson
--
--
You received this message from the "vim_dev" 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
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Test_popup_and_window_resize() failures
On Mo, 30 Okt 2017, James McCoy wrote: > I recently uploaded 8.0.1226 to Debian and nearly every build failed[0]. > The most common failure is > > Found errors in Test_popup_and_window_resize(): > function RunTheTest[34]..Test_popup_and_window_resize line 16: Pattern > '^!\\s*$' does not match '' > function RunTheTest[34]..Test_popup_and_window_resize line 26: Pattern > '^!\\s*$' does not match '~ > ' > function RunTheTest[34]..Test_popup_and_window_resize line 28: Pattern > '^!\\s*$' does not match '' > > I investigated some and that test appears to be extremely flaky in those > environments. I haven't had a failure yet locally (amd64 system), but > those architectures fail almost every run. > > Attached is a log from that test and the associated diff showing where I > added ch_log() calls. > > [0]: > https://buildd.debian.org/status/logs.php?pkg=vim&ver=2%3A8.0.1226-1&suite=sid Is it possible to run those tests interactively on those architectures? Or does it succeed when run interactively and only fails when run in the test suite? Christian -- Ein einziger Aufwiegler taugt manchmal mehr als alle Abwiegler zusammen. -- Georg Büchner -- -- You received this message from the "vim_dev" 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
On Di, 31 Okt 2017, Hanno Böck wrote: > Hi, > > I wanted to point out an issue here with vim swap files that make them > a security problem. > > By default vim creates a file with the name .filename.swp in the same > directory while editing. They contain the full content of the edited > file. This usually gets deleted upon exit, but not if vim crashes or > gets killed (e.g. due to a reboot). > > On web servers this can be a severe security risk. One can e.g. scan > for web hosts that have swap files of PHP configuration files and thus > expose settings like database passwords. (e.g. wget > http://example.com/.wp-config.php.swp ) > > In a scan of the alexa top 1 million I found ~750 instances of such > files. I tried to inform affected people as best as I could. I also > discovered such scans in my own web server logs, so I assume black hats > are already aware of this and it's actively exploitet. > > I was wondering how to best avoid this on my own servers and I first > thought about saving the swap files to tmp ( with "set directory"). > However on multiuser systems this creates another security problem. > These files are world readable, thus instead of leaking information to > the world it's now leaking information to other users on the same > system. Thus even if one is aware of the issue it's nontrivial to get > secure settings (I've now worked around this by having per-user tmp > dirs with secure permissions.) > > I think vim should change the behavior of swap files: > 1. they should be stored in /tmp by default > 2. they should have secure permissions (tmp file security is > a tricky thing and needs careful consideration to avoid symlink attacks > and the like, but there are dedicated functions for this like mkstemp). > 3. Ideally they also shouldn't leak currently edited filenames (e.g. > they shouldn't be called /tmp/.test.txt.swp, but more something > like /tmp/.vim_swap.123782173) It is true, that this can cause a problem. However, I am not sure its correct to blame vim here. First, I think you need to configure your webserver to be able to view dotfiles. I believe a default installation of at least apache won't let you show dotfiles. Second, I wonder why those swapfiles are not deleted. Somehow Vim must have crashed or be killed and in that case one certainly don't want that the swapfiles are deleted (think of recovery). Finally, using git for managing your document root, can show you those rubbish swap files, since the directory is not clean than, if you really need to edit your files on the server directly and do not use a deployment of some kind. One could argue, that swap files should be stored below ~/.vim directory tree. But what if several users edit the same file? One also needs to make sure, the path would be encoded into the name, but then we might run into trouble with filename length limitations. So I think it in the users responsibility to configure Vim correctly (check the directory option) to not have him litter his document root with old swap files. The best I can think of currently, is to add a warning to the documentation, that swapfiles may cause a security problem. Christian -- "Wenn man alle Gesetze studieren sollte, so hätte man gar keine Zeit, sie zu übertreten." -- Goethe, Maximen und Reflektionen, Nr. 347 -- -- You received this message from the "vim_dev" 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Not seeing source code with :Termdebug
On Di, 31 Okt 2017, tom leb wrote: > Hi, > > the source code doesn't appear in the source buffer > when using :Termdebug. I can use gdb fine to step,continue,break,etc > but I cannot see the source code (unless I `list` manually in the gdb > window. Also, the buttons in the tabbar don't seem to be doing anything. > > I tried with a simple program compiled with `-g` for debug info. I also > tried doing exactly what is described in the scenario shown in > :help Termdebug. > > I tried with `vim -u NONE` just to be sure no plugins or configs messed > with this functionality. My vim version patch 1176. Sounds like issue https://github.com/vim/vim/issues/2154 Christian -- Wie man sein Kind nicht nennen sollte: Rolf Fläche -- -- You received this message from the "vim_dev" 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Not seeing source code with :Termdebug
Hi, the source code doesn't appear in the source buffer when using :Termdebug. I can use gdb fine to step,continue,break,etc but I cannot see the source code (unless I `list` manually in the gdb window. Also, the buttons in the tabbar don't seem to be doing anything. I tried with a simple program compiled with `-g` for debug info. I also tried doing exactly what is described in the scenario shown in :help Termdebug. I tried with `vim -u NONE` just to be sure no plugins or configs messed with this functionality. My vim version patch 1176. Tom Lebreux -- -- You received this message from the "vim_dev" 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
On Tue, Oct 31, 2017 at 6:30 AM, Hanno Böck wrote: > > 3. Ideally they also shouldn't leak currently edited filenames (e.g. > they shouldn't be called /tmp/.test.txt.swp, but more something > like /tmp/.vim_swap.123782173) > But Vim needs to know which swapfile is associated with which non-swap file. How can it do that, other than by having the swapfile's name contain the original file's name? Anyway I don't think it's Vim's job to cover up for foolish admins. -Manny -- -- You received this message from the "vim_dev" 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
* Hanno Böck [171031 06:32]: > I wanted to point out an issue here with vim swap files that make them > a security problem. > > By default vim creates a file with the name .filename.swp in the same > directory while editing. They contain the full content of the edited > file. This usually gets deleted upon exit, but not if vim crashes or > gets killed (e.g. due to a reboot). > > On web servers this can be a severe security risk. One can e.g. scan > for web hosts that have swap files of PHP configuration files and thus > expose settings like database passwords. (e.g. wget > http://example.com/.wp-config.php.swp ) See the 'directory' option. I don't see this as a problem with Vim; Vim gives the user appropriate means to avoid it. The problem is one or both of (1) a web server that serves files that the admin did not intend to serve and (2) the admin's Vim configuration that puts temporary files in a location that the web server serves without appropriate filtering. Both problems are fixable with appropriate configuration. It would be inappropriate for Vim's default to be to assume that having both the file being edited and its swap file in the same directory would be a security issue. The implication is that in most cases, if someone can read the swap file, they can also read the original. This happens to not always be true in the case of a web server that filters the PHP configuration files but not Vim's swap files in the same directory. ...Marvin -- -- You received this message from the "vim_dev" 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
On Tue, 31 Oct 2017 11:59:41 +0100 Tony Mechelynck wrote: > Isn't /tmp deleted at every bootup? If it is, or on the systems where > it is, this makes it useless for files whose chief utility is to allow > recovery after a program or system crash. That is an interesting point, however this is not unified among systems. An alternative would be to place them in a location like ~/.vim > IMHO, the kind of considerations in Herrn Böcks message should not be > handled at Vim level but at the level of system security in general. > In particular neither system configuration files, nor files containing > passwords or the backups of such files, nor "invisible" files (whose > names start with a dot) — and this includes Vim swapfiles — should > IMHO be visible to the lambda web user. This seems quite vague and more like trying to discuss the issue away instead of solving it. Can you be more specific what you have in mind? It sounds like you expect from web servers to generally block access to dot files. However that won't work, as there are standardized locations on web servers i dot files (e.g. .well-known URLs, part of a couple of modern standards). So how should that specifically work while not breaking existing things? And who exactly should solve it in what way? > Whether a privileged login > should be allowed from a remote console is for every sysadmin to weigh > seriously, with consideration of the particular system's requirements. > On my machine I don't allow any remote login, and I don't open (other > than in "view source" mode) emails from dubious sources, but of course > other systems have other requirements: it is not always practical to > require that privileged logins should be allowed only from one > particular keyboard and screen located in the head office computer > room, to which only a few select operators (or BOFHs) are allowed > entry. Sorry, can you explain what this part has to do with the problem? Because I see no connection whatsoever. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 -- -- You received this message from the "vim_dev" 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Security risk of vim swap files
On Tue, Oct 31, 2017 at 11:30 AM, Hanno Böck wrote: > Hi, > > I wanted to point out an issue here with vim swap files that make them > a security problem. > > By default vim creates a file with the name .filename.swp in the same > directory while editing. They contain the full content of the edited > file. This usually gets deleted upon exit, but not if vim crashes or > gets killed (e.g. due to a reboot). > > On web servers this can be a severe security risk. One can e.g. scan > for web hosts that have swap files of PHP configuration files and thus > expose settings like database passwords. (e.g. wget > http://example.com/.wp-config.php.swp ) > > In a scan of the alexa top 1 million I found ~750 instances of such > files. I tried to inform affected people as best as I could. I also > discovered such scans in my own web server logs, so I assume black hats > are already aware of this and it's actively exploitet. > > I was wondering how to best avoid this on my own servers and I first > thought about saving the swap files to tmp ( with "set directory"). > However on multiuser systems this creates another security problem. > These files are world readable, thus instead of leaking information to > the world it's now leaking information to other users on the same > system. Thus even if one is aware of the issue it's nontrivial to get > secure settings (I've now worked around this by having per-user tmp > dirs with secure permissions.) > > I think vim should change the behavior of swap files: > 1. they should be stored in /tmp by default > 2. they should have secure permissions (tmp file security is > a tricky thing and needs careful consideration to avoid symlink attacks > and the like, but there are dedicated functions for this like mkstemp). > 3. Ideally they also shouldn't leak currently edited filenames (e.g. > they shouldn't be called /tmp/.test.txt.swp, but more something > like /tmp/.vim_swap.123782173) > > -- > Hanno Böck > https://hboeck.de/ Isn't /tmp deleted at every bootup? If it is, or on the systems where it is, this makes it useless for files whose chief utility is to allow recovery after a program or system crash. IMHO, the kind of considerations in Herrn Böcks message should not be handled at Vim level but at the level of system security in general. In particular neither system configuration files, nor files containing passwords or the backups of such files, nor "invisible" files (whose names start with a dot) — and this includes Vim swapfiles — should IMHO be visible to the lambda web user. Whether a privileged login should be allowed from a remote console is for every sysadmin to weigh seriously, with consideration of the particular system's requirements. On my machine I don't allow any remote login, and I don't open (other than in "view source" mode) emails from dubious sources, but of course other systems have other requirements: it is not always practical to require that privileged logins should be allowed only from one particular keyboard and screen located in the head office computer room, to which only a few select operators (or BOFHs) are allowed entry. Best regards, Tony. -- -- You received this message from the "vim_dev" 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Security risk of vim swap files
Hi, I wanted to point out an issue here with vim swap files that make them a security problem. By default vim creates a file with the name .filename.swp in the same directory while editing. They contain the full content of the edited file. This usually gets deleted upon exit, but not if vim crashes or gets killed (e.g. due to a reboot). On web servers this can be a severe security risk. One can e.g. scan for web hosts that have swap files of PHP configuration files and thus expose settings like database passwords. (e.g. wget http://example.com/.wp-config.php.swp ) In a scan of the alexa top 1 million I found ~750 instances of such files. I tried to inform affected people as best as I could. I also discovered such scans in my own web server logs, so I assume black hats are already aware of this and it's actively exploitet. I was wondering how to best avoid this on my own servers and I first thought about saving the swap files to tmp ( with "set directory"). However on multiuser systems this creates another security problem. These files are world readable, thus instead of leaking information to the world it's now leaking information to other users on the same system. Thus even if one is aware of the issue it's nontrivial to get secure settings (I've now worked around this by having per-user tmp dirs with secure permissions.) I think vim should change the behavior of swap files: 1. they should be stored in /tmp by default 2. they should have secure permissions (tmp file security is a tricky thing and needs careful consideration to avoid symlink attacks and the like, but there are dedicated functions for this like mkstemp). 3. Ideally they also shouldn't leak currently edited filenames (e.g. they shouldn't be called /tmp/.test.txt.swp, but more something like /tmp/.vim_swap.123782173) -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 -- -- You received this message from the "vim_dev" 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Security risk of vim swap files
Hi, I wanted to point out an issue here with vim swap files that make them a security problem. By default vim creates a file with the name .filename.swp in the same directory while editing. They contain the full content of the edited file. This usually gets deleted upon exit, but not if vim crashes or gets killed (e.g. due to a reboot). On web servers this can be a severe security risk. One can e.g. scan for web hosts that have swap files of PHP configuration files and thus expose settings like database passwords. (e.g. wget http://example.com/.wp-config.php.swp ) In a scan of the alexa top 1 million I found ~750 instances of such files. I tried to inform affected people as best as I could. I also discovered such scans in my own web server logs, so I assume black hats are already aware of this and it's actively exploitet. I was wondering how to best avoid this on my own servers and I first thought about saving the swap files to tmp ( with "set directory"). However on multiuser systems this creates another security problem. These files are world readable, thus instead of leaking information to the world it's now leaking information to other users on the same system. Thus even if one is aware of the issue it's nontrivial to get secure settings (I've now worked around this by having per-user tmp dirs with secure permissions.) I think vim should change the behavior of swap files: 1. they should be stored in /tmp by default 2. they should have secure permissions (tmp file security is a tricky thing and needs careful consideration to avoid symlink attacks and the like, but there are dedicated functions for this like mkstemp). 3. Ideally they also shouldn't leak currently edited filenames (e.g. they shouldn't be called /tmp/.test.txt.swp, but more something like /tmp/.vim_swap.123782173) -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 -- -- You received this message from the "vim_dev" 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: vim 7.3
On Sat, Oct 28, 2017 at 02:50:48AM +0200, Tony Mechelynck wrote:
> On Thu, Oct 26, 2017 at 7:19 PM, tooth pik wrote:
> > you don't use git?
> >
> No I don't, not for Vim anyway. Somehow I understand Mercurial but not
> git, so given a choice between them I always choose Mercurial. (For
> instance, does git have a specific function to list incoming
> changesets, other than "git pull --dry-run"? I like the "log-style"
> format of "hg incoming".)
I've a git alias `incoming` for this:
# ~/.gitconfig
[alias]
incoming = !git fetch && git log --oneline ..@{u}
(I do not remember what the format of `hg incoming` is.)
I also have another git alias, `new`, that shows me the contents of the
last pull after I've done it:
new = !sh -c 'git log $1@{1}..$1@{0} "$@"'
Regards,
Marius Gedminas
--
/*
* This function is about (re)setting the class of a held lock,
* yet we're not actually holding any locks. Naughty user!
*/
--
--
You received this message from the "vim_dev" 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
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: PGP signature
