Re: Patch 7.1.168 (extra)
Hello Bram, On 3 Dez., 22:20, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > Patch 7.1.168 (extra) > Problem:Win32 GUI: Since patch 7.1.095, when the Vim window does not have > focus, clicking in it doesn't position the cursor. (Juergen > Kraemer) > Solution: Don't reset s_button_pending just after receiving focus. > Files: src/gui_w48.c clicking into the text area of Vim works correctly now, but there is still a problem with clicking inside the (right) scrollbar. Here's how to reproduce it: gvim -u NONE - U NONE :let i = 0 :while i < 100 : let i += 1 : put ='Line ' . i :endwhile :normal ggdd :set lines=20 Now move focus to a different application and get back to Vim by clicking in the right scrollbar just below the slider: the slider is moved down, but line 1 is still the top line. Click again just below the slider: the slider is moved again and now line 35 is the top line -- lines 20 to 34 have been jumped over have and never been displayed. If instead of clicking a second time you enter Lj in normal mode, line 20 is moved into view *and* the position of the scrollbar slider is corrected. Can you have a look at this? Regards, Jürgen --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
Charles E. Campbell, Jr. wrote: > Matt Wozniski wrote: > >> Fixing that to use a script-local variable would definitely be >> a worthwhile change that should be made ASAP, though it still wouldn't >> protect you from plaintext passwords being in your core files. >> >> > Yes, I've done that for v116g. > >> While we're at it, what is a reasonable use-case for why someone would >> need a getpid() function? Why would we need to know our PID? >> >> > Assuming that I have an encrypt/decrypt function pair, the pid could be > used as a single-session p/w that would be transparent to the user. I > don't see any point in saving a ftp password but requiring the user to > enter some other password to make the ftp password available. Such > things as recording the hundredth of a second that vim/gvim started > along with the pid would act as an improved session-only password. > > Regards, > Chip Campbell The sequence :mks! :qa gvim -S would invalidate the password (since the PID changes). I suppose this is what you want? Similarly Gnome-enabled versions over closedown/restart of the Gnome or KDE winmanager. Best regards, Tony. -- Get GUMMed --- -- The Gurus of Unix Meeting of Minds (GUMM) takes place Wednesday, April 1, 2076 (check THAT in your perpetual calendar program), 14 feet above the ground directly in front of the Milpitas Gumps. Members will grep each other by the hand (after intro), yacc a lot, smoke filtered chroots in pipes, chown with forks, use the wc (unless uuclean), fseek nice zombie processes, strip, and sleep, but not, we hope, od. Three days will be devoted to discussion of the ramifications of whodo. Two seconds have been allotted for a complete rundown of all the user- friendly features of Unix. Seminars include "Everything You Know is Wrong", led by Tom Kempson, "Batman or Cat:man?" led by Richie Dennis "cc C? Si! Si!" led by Kerwin Bernighan, and "Document Unix, Are You Kidding?" led by Jan Yeats. No Reader Service No. is necessary because all GUGUs (Gurus of Unix Group of Users) already know everything we could tell them. -- Dr. Dobb's Journal, June '84 --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
That's good unless your /proc/sys/kernel/core_pattern contains %p, or /proc/sys/kernel/core_uses_pid == 1 On 03/12/2007, Charles E. Campbell, Jr. <[EMAIL PROTECTED]> wrote: > > > Matt Wozniski wrote: > > >On Dec 3, 2007 2:05 PM, Charles E. Campbell, Jr. wrote: > > > > > >>Assuming that I have an encrypt/decrypt function pair, the pid could be > >>used as a single-session p/w that would be transparent to the user. I > >>don't see any point in saving a ftp password but requiring the user to > >>enter some other password to make the ftp password available. Such > >>things as recording the hundredth of a second that vim/gvim started > >>along with the pid would act as an improved session-only password. > >> > >> > > > >Sure, I understand that you could use it as a key to encrypt the > >password, but what I'm really asking is what you gain from that. Is it > >really more secure to have an encrypted string and its decryption key > >stored in memory than it is to have an unencrypted string in memory? > >Particularly on an open-source project where anyone who wants to can > >view your source code? > > > > > > Where's the part where I said I'd store the session pid in some > variable? Something like getpid() would be called during > encrypt/decrypt, not stored. > > Chip Campbell > > > > > -- Registered Linux User #445632 http://counter.li.org --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
Matt Wozniski wrote: >On Dec 3, 2007 2:05 PM, Charles E. Campbell, Jr. wrote: > > >>Assuming that I have an encrypt/decrypt function pair, the pid could be >>used as a single-session p/w that would be transparent to the user. I >>don't see any point in saving a ftp password but requiring the user to >>enter some other password to make the ftp password available. Such >>things as recording the hundredth of a second that vim/gvim started >>along with the pid would act as an improved session-only password. >> >> > >Sure, I understand that you could use it as a key to encrypt the >password, but what I'm really asking is what you gain from that. Is it >really more secure to have an encrypted string and its decryption key >stored in memory than it is to have an unencrypted string in memory? >Particularly on an open-source project where anyone who wants to can >view your source code? > > Where's the part where I said I'd store the session pid in some variable? Something like getpid() would be called during encrypt/decrypt, not stored. Chip Campbell --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Patch 7.1.168 (extra)
Patch 7.1.168 (extra)
Problem:Win32 GUI: Since patch 7.1.095, when the Vim window does not have
focus, clicking in it doesn't position the cursor. (Juergen
Kraemer)
Solution: Don't reset s_button_pending just after receiving focus.
Files: src/gui_w48.c
*** ../vim-7.1.167/src/gui_w48.cTue Nov 20 17:21:28 2007
--- src/gui_w48.c Mon Dec 3 22:13:16 2007
***
*** 290,295
--- 290,300
/* Local variables */
static ints_button_pending = -1;
+
+ /* s_getting_focus is set when we got focus but didn't see mouse-up event yet,
+ * so don't reset s_button_pending. */
+ static ints_getting_focus = FALSE;
+
static ints_x_pending;
static ints_y_pending;
static UINT s_kFlags_pending;
***
*** 671,676
--- 676,683
{
int vim_modifiers = 0x0;
+ s_getting_focus = FALSE;
+
if (keyFlags & MK_SHIFT)
vim_modifiers |= MOUSE_SHIFT;
if (keyFlags & MK_CONTROL)
***
*** 792,797
--- 799,805
{
int button;
+ s_getting_focus = FALSE;
if (s_button_pending > -1)
{
/* Delayed action for mouse down event */
***
*** 1951,1958
allow_scrollbar = FALSE;
/* Clear pending mouse button, the release event may have been
!* taken by the dialog window. */
! s_button_pending = -1;
return OK;
}
--- 1959,1968
allow_scrollbar = FALSE;
/* Clear pending mouse button, the release event may have been
!* taken by the dialog window. But don't do this when getting
!* focus, we need the mouse-up event then. */
! if (!s_getting_focus)
! s_button_pending = -1;
return OK;
}
***
*** 2702,2707
--- 2712,2718
HWND hwndOldFocus)
{
gui_focus_change(TRUE);
+ s_getting_focus = TRUE;
(void)MyWindowProc(hwnd, WM_SETFOCUS, (WPARAM)hwndOldFocus, 0);
}
***
*** 2711,2716
--- 2722,2728
HWND hwndNewFocus)
{
gui_focus_change(FALSE);
+ s_getting_focus = FALSE;
(void)MyWindowProc(hwnd, WM_KILLFOCUS, (WPARAM)hwndNewFocus, 0);
}
*** ../vim-7.1.167/src/version.cMon Dec 3 21:31:56 2007
--- src/version.c Mon Dec 3 22:16:32 2007
***
*** 668,669
--- 668,671
{ /* Add new patch number below this line */
+ /**/
+ 168,
/**/
--
Rule #1: Don't give somebody a tool that he's going to hurt himself with.
/// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Patch 7.1.167
Patch 7.1.167
Problem:Xxd crashes when using "xxd -b -c 110". (Debian bug 452789)
Solution: Allocate more memory. Fix check for maximum number of columns.
Files: src/xxd/xxd.c
*** ../vim-7.1.166/src/xxd/xxd.cThu May 10 19:07:42 2007
--- src/xxd/xxd.c Thu Nov 29 21:05:16 2007
***
*** 212,218
#define TRY_SEEK /* attempt to use lseek, or skip forward by reading */
#define COLS 256 /* change here, if you ever need more columns */
! #define LLEN (9 + (5*COLS-1)/2 + 2 + COLS)
char hexxa[] = "0123456789abcdef0123456789ABCDEF", *hexx = hexxa;
--- 212,218
#define TRY_SEEK /* attempt to use lseek, or skip forward by reading */
#define COLS 256 /* change here, if you ever need more columns */
! #define LLEN (11 + (9*COLS-1)/1 + COLS + 2)
char hexxa[] = "0123456789abcdef0123456789ABCDEF", *hexx = hexxa;
***
*** 590,596
default:octspergrp = 0; break;
}
! if (cols < 1 || (!hextype && (cols > COLS)))
{
fprintf(stderr, "%s: invalid number of columns (max. %d).\n", pname,
COLS);
exit(1);
--- 590,597
default:octspergrp = 0; break;
}
! if (cols < 1 || ((hextype == HEX_NORMAL || hextype == HEX_BITS)
! && (cols > COLS)))
{
fprintf(stderr, "%s: invalid number of columns (max. %d).\n", pname,
COLS);
exit(1);
***
*** 750,755
--- 751,757
}
if (ebcdic)
e = (e < 64) ? '.' : etoa64[e-64];
+ /* When changing this update definition of LLEN above. */
l[11 + (grplen * cols - 1)/octspergrp + p] =
#ifdef __MVS__
(e >= 64)
*** ../vim-7.1.166/src/version.cSat Dec 1 21:12:23 2007
--- src/version.c Mon Dec 3 21:30:31 2007
***
*** 668,669
--- 668,671
{ /* Add new patch number below this line */
+ /**/
+ 167,
/**/
--
hundred-and-one symptoms of being an internet addict:
178. You look for an icon to double-click to open your bedroom window.
/// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Taglist plugin gives errors when switching tabs
Hi, I'm using the Taglist plugin version 4.5. If I open a taglist window with `:Tlist` in one tab, switch to another tab and back again, I get Error detected while processing function 17_Tlist_Refresh_Folds: line 24: E16: invalid range: 67,145fold Nico --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
On Dec 3, 2007 2:05 PM, Charles E. Campbell, Jr. wrote: > > Matt Wozniski wrote: > > > Fixing that to use a script-local variable would definitely be > >a worthwhile change that should be made ASAP, though it still wouldn't > >protect you from plaintext passwords being in your core files. > > Yes, I've done that for v116g. Glad to hear it. :) > >While we're at it, what is a reasonable use-case for why someone would > >need a getpid() function? Why would we need to know our PID? > > > > > Assuming that I have an encrypt/decrypt function pair, the pid could be > used as a single-session p/w that would be transparent to the user. I > don't see any point in saving a ftp password but requiring the user to > enter some other password to make the ftp password available. Such > things as recording the hundredth of a second that vim/gvim started > along with the pid would act as an improved session-only password. Sure, I understand that you could use it as a key to encrypt the password, but what I'm really asking is what you gain from that. Is it really more secure to have an encrypted string and its decryption key stored in memory than it is to have an unencrypted string in memory? Particularly on an open-source project where anyone who wants to can view your source code? ~Matt --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
Matt Wozniski wrote: > Fixing that to use a script-local variable would definitely be >a worthwhile change that should be made ASAP, though it still wouldn't >protect you from plaintext passwords being in your core files. > > Yes, I've done that for v116g. >While we're at it, what is a reasonable use-case for why someone would >need a getpid() function? Why would we need to know our PID? > > Assuming that I have an encrypt/decrypt function pair, the pid could be used as a single-session p/w that would be transparent to the user. I don't see any point in saving a ftp password but requiring the user to enter some other password to make the ftp password available. Such things as recording the hundredth of a second that vim/gvim started along with the pid would act as an improved session-only password. Regards, Chip Campbell --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
On Dec 3, 2007 1:17 PM, Erik Falor wrote: > > On 03/12/2007, Matt Wozniski wrote: > > > > 3. This entire discussion seems to basically be a moot point since > > any cracker worth his salt would just be sniffing the network... > > FTP transmits passwords in plaintext; security in how netrw handles > > the passwords seems to be a rather moot point to me. > > netrw doesn't only handle FTP transfers. Better types of traffic are > supported. > > I just don't like the idea that my password is sitting in a global vim > variable for all to see. If I walk away from my keyboard, someone > could walk by and type :echo netrw_passwd > > Plus, if/when I dump core, my password is there, in cleartext, in the > dumpfile. Again, something I don't want to leave to filesystem perms > to protect me from. Especially if I happen to be using an OS that > FTPs dumpfiles back to the mothership for you. That's a very good point (and I hadn't thought of core files) but you also point out two important considerations: first, that even laying aside the fact that this encryption idea only provides security through obscurity, you could achieve a similar amount of security by having netrw store the password in a script-local variable, rather than a global variable (global variables are particularly awful, since a malicious user at your keyboard, or anyone who convinces you to install their vim script, can just scan through the output of :let searching for /pass/). Fixing that to use a script-local variable would definitely be a worthwhile change that should be made ASAP, though it still wouldn't protect you from plaintext passwords being in your core files. The second important point you make is that netrw supports other protocols for which this isn't an issue. If a user is sufficiently worried about security to not want a plaintext ftp password stored in vim's memory, he can always use ssh key-based authentication and make it a moot point. While we're at it, what is a reasonable use-case for why someone would need a getpid() function? Why would we need to know our PID? ~Matt --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
On 03/12/2007, Matt Wozniski <[EMAIL PROTECTED]> wrote: > > > 3. This entire discussion seems to basically be a moot point since > any cracker worth his salt would just be sniffing the network... > FTP transmits passwords in plaintext; security in how netrw > handles the passwords seems to be a rather moot point to me. > netrw doesn't only handle FTP transfers. Better types of traffic are supported. I just don't like the idea that my password is sitting in a global vim variable for all to see. If I walk away from my keyboard, someone could walk by and type :echo netrw_passwd Plus, if/when I dump core, my password is there, in cleartext, in the dumpfile. Again, something I don't want to leave to filesystem perms to protect me from. Especially if I happen to be using an OS that FTPs dumpfiles back to the mothership for you. Erik -- Registered Linux User #445632 http://counter.li.org --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
On 30/11/2007, Yakov Lerner <[EMAIL PROTECTED]> wrote:
On windows, somebody should know name of the library and
> name of the function for correct libcallnr() call.
>
This was bugging me all weekend:
:echo libcallnr('crtdll', '_getpid', '')
Provided, of course, that every install of WinXP comes with the C runtime
library. I would imagine that this is an important, standard system
library. But on the other hand, I wouldn't put it past those chair-throwers
to optionally provide it. After all, they don't even ship their OS with a
compiler. Maybe I only have it because I've installed Visual Studio.
Could somebody else that uses Windows confirm that this works? Even better,
a non-XP user?
Erik
--
Registered Linux User #445632
http://counter.li.org
--~--~-~--~~~---~--~~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
On Dec 3, 2007 12:56 PM, thomas wrote: > > > since the cracker will only need to > > get two values from vim's memory instead of one. Am I missing > > something? > > This assumes an attack that is specifically targeted at an individual > vim user using a specific version of the netrw plugin. This isn't the > most likely scenario though. (Depending on your workplace maybe.) 1. I daresay that most attacks are specific to a particular version of a piece of software. 2. This entire discussion seems to be based upon an attack targeted at an individual vim user and a particular piece of software. 3. This entire discussion seems to basically be a moot point since any cracker worth his salt would just be sniffing the network... FTP transmits passwords in plaintext; security in how netrw handles the passwords seems to be a rather moot point to me. ~Matt --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
> since the cracker will only need to > get two values from vim's memory instead of one. Am I missing > something? This assumes an attack that is specifically targeted at an individual vim user using a specific version of the netrw plugin. This isn't the most likely scenario though. (Depending on your workplace maybe.) --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
On Nov 28, 2007 5:23 PM, Charles E Campbell Jr wrote: >⋅ > Hello! >⋅ > I don't see any way to encrypt/decrypt strings in the vim function > library, but there is a way to encrypt a file buffer. Netrw tries to > make use of ftp, etc and its associated passwords simpler by retaining > the password in a variable (which is not normally saved). Thus one > reads a file via ftp, say, provides the password to do so, and writing > is done without requiring another entry of the password. I thought > about making a temporary "password" automatically using localtime() at > first invocation of netrw and the process's pid. Any good way to get > the vim process's pid? How about under Windows? Unless I'm misreading your intent, you seem to be saying that you want to replace the current method (storing a password in plaintext) with a new method (storing a password encrypted and an encryption key in plaintext). What security advantage does this provide? It seems to just be security through obscurity, since the cracker will only need to get two values from vim's memory instead of one. Am I missing something? ~Matt --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
Re: encrypt/decrypt functions for a session
On 02/12/2007, Yakov Lerner <[EMAIL PROTECTED]> wrote: > > > Maybe a patch to add getpid() function to vimscript is > not bad idea ? Even without relation to Charles ciphering troubles. I second Yakov's idea. -- Registered Linux User #445632 http://counter.li.org --~--~-~--~~~---~--~~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~--~~~~--~~--~--~---
