Re: Bug: writing encrypted file, while asked for password, destroys contents
Christian Brabandt wrote: > On Do, 15 Aug 2013, Bram Moolenaar wrote: > > > Christian Brabandt wrote: > > > Wouldn't it be a good idea, to have the file set readonly for as long it > > > hasn't been encrypted (e.g. the current windows behaviour)? > > > > You mean, until it has been decrypted. That makes sense. > > Actually, when a file is encrypted and the user just hits enter and the > > prompt for the key, it should also be marked as readonly. > > Err, yes that was what I meant. > > I think this patch does it: Thanks, I'll look into it. Your "diff" lost a "d" -- >From "know your smileys": |-(Contact lenses, but has lost them /// 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/groups/opt_out.
Re: Bug: writing encrypted file, while asked for password, destroys contents
On Do, 15 Aug 2013, Bram Moolenaar wrote:
> Christian Brabandt wrote:
> > Wouldn't it be a good idea, to have the file set readonly for as long it
> > hasn't been encrypted (e.g. the current windows behaviour)?
>
> You mean, until it has been decrypted. That makes sense.
> Actually, when a file is encrypted and the user just hits enter and the
> prompt for the key, it should also be marked as readonly.
Err, yes that was what I meant.
I think this patch does it:
iff --git a/src/fileio.c b/src/fileio.c
--- a/src/fileio.c
+++ b/src/fileio.c
@@ -2926,9 +2926,15 @@
int*did_ask; /* flag: whether already asked for key
*/
{
int method = crypt_method_from_magic((char *)ptr, *sizep);
+int b_p_ro = curbuf->b_p_ro;
if (method >= 0)
{
+ /* prevent nasty side-effects by e.g.
+* FocusLeave autocommands, trying to write the file
+* or the user accidently hitting enter on the password
+* prompt and accidently writing the file */
+ curbuf->b_p_ro = TRUE;
set_crypt_method(curbuf, method);
if (method > 0)
(void)blowfish_self_test();
@@ -2977,6 +2983,7 @@
*sizep -= CRYPT_MAGIC_LEN + salt_len + seed_len;
mch_memmove(ptr, ptr + CRYPT_MAGIC_LEN + salt_len + seed_len,
(size_t)*sizep);
+ curbuf->b_p_ro = b_p_ro; /* resetting ro flag */
}
}
/* When starting to edit a new file which does not have encryption, clear
regards,
Christian
--
Wenn du etwas Glück dein Eigen nennst, verheimliche es.
-- Saul Bellow
--
--
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/groups/opt_out.
Re: Bug: writing encrypted file, while asked for password, destroys contents
Christian Brabandt wrote: > On Di, 13 Aug 2013, Christian Brabandt wrote: > > > On Tue, August 13, 2013 01:00, Einar Lielmanis wrote: > > > Encrypted file contents are destroyed, if something (e.g autocmd) > > > triggers write event, while user is being asked for password. > > > > > > To repro: > > > 1. have an encrypted.txt ready (:X) > > > 2. gvim, :au focuslost * w > > > 3. :e encrypted.txt, don't type in the password yet, > > > 4. lose window focus, e.g via switching to another window, to trigger > > >the focuslost event, > > > > > > Expected: > > > The file hasn't changed, so it should stay unmodified, > > > > > > Actual behavior: > > > encrypted.txt is truncated to a zero size. > > > > > > I don't see this. Using Vim 7.4 on Windows I get > > vim -u NONE -N -i NONE > > :au FocusLost * w > > :e encrypted.txt > > (change Focus) > > Error detected while processing FocusLost Auto commands for "*": > > E505: "c:\temp\encrypted.txt" is read-only (add ! to override) > > "c:\temp\encrypted.txt" [crypted] 2L, 13C > > > > > > In any case, the file is *not* written. > > > > If you used au FocusLost * :w! the file is indeed truncated > > but even then after entering the correct password Vim can read > > the encrypted file (but you would need to make sure > > you have written the file or else you would be left with an empty > > file). > > Hm, on Linux, it indeed truncates the encrypted file. > Anybody else sees this difference? > > Wouldn't it be a good idea, to have the file set readonly for as long it > hasn't been encrypted (e.g. the current windows behaviour)? You mean, until it has been decrypted. That makes sense. Actually, when a file is encrypted and the user just hits enter and the prompt for the key, it should also be marked as readonly. -- >From "know your smileys": =):-) Uncle Sam /// 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/groups/opt_out.
Re: Bug: writing encrypted file, while asked for password, destroys contents
On Wednesday, August 14, 2013 4:34:12 PM UTC-5, Christian Brabandt wrote: > On Di, 13 Aug 2013, Christian Brabandt wrote: > > > > > On Tue, August 13, 2013 01:00, Einar Lielmanis wrote: > > > > Encrypted file contents are destroyed, if something (e.g autocmd) > > > > triggers write event, while user is being asked for password. > > > > > > > > To repro: > > > > 1. have an encrypted.txt ready (:X) > > > > 2. gvim, :au focuslost * w > > > > 3. :e encrypted.txt, don't type in the password yet, > > > > 4. lose window focus, e.g via switching to another window, to trigger > > > >the focuslost event, > > > > > > > > Expected: > > > > The file hasn't changed, so it should stay unmodified, > > > > > > > > Actual behavior: > > > > encrypted.txt is truncated to a zero size. > > > > > > > > > I don't see this. Using Vim 7.4 on Windows I get > > > vim -u NONE -N -i NONE > > > :au FocusLost * w > > > :e encrypted.txt > > > (change Focus) > > > Error detected while processing FocusLost Auto commands for "*": > > > E505: "c:\temp\encrypted.txt" is read-only (add ! to override) > > > "c:\temp\encrypted.txt" [crypted] 2L, 13C > > > > > > > > > In any case, the file is *not* written. > > > > > > If you used au FocusLost * :w! the file is indeed truncated > > > but even then after entering the correct password Vim can read > > > the encrypted file (but you would need to make sure > > > you have written the file or else you would be left with an empty > > > file). > > > > Hm, on Linux, it indeed truncates the encrypted file. > > Anybody else sees this difference? > > > > Wouldn't it be a good idea, to have the file set readonly for as long it > > hasn't been encrypted (e.g. the current windows behaviour)? > I agree that's a good idea. Would it even make sense to temporarily set 'nomodifiable' too? -- -- 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/groups/opt_out.
Re: Bug: writing encrypted file, while asked for password, destroys contents
On Di, 13 Aug 2013, Christian Brabandt wrote: > On Tue, August 13, 2013 01:00, Einar Lielmanis wrote: > > Encrypted file contents are destroyed, if something (e.g autocmd) > > triggers write event, while user is being asked for password. > > > > To repro: > > 1. have an encrypted.txt ready (:X) > > 2. gvim, :au focuslost * w > > 3. :e encrypted.txt, don't type in the password yet, > > 4. lose window focus, e.g via switching to another window, to trigger > >the focuslost event, > > > > Expected: > > The file hasn't changed, so it should stay unmodified, > > > > Actual behavior: > > encrypted.txt is truncated to a zero size. > > > I don't see this. Using Vim 7.4 on Windows I get > vim -u NONE -N -i NONE > :au FocusLost * w > :e encrypted.txt > (change Focus) > Error detected while processing FocusLost Auto commands for "*": > E505: "c:\temp\encrypted.txt" is read-only (add ! to override) > "c:\temp\encrypted.txt" [crypted] 2L, 13C > > > In any case, the file is *not* written. > > If you used au FocusLost * :w! the file is indeed truncated > but even then after entering the correct password Vim can read > the encrypted file (but you would need to make sure > you have written the file or else you would be left with an empty > file). Hm, on Linux, it indeed truncates the encrypted file. Anybody else sees this difference? Wouldn't it be a good idea, to have the file set readonly for as long it hasn't been encrypted (e.g. the current windows behaviour)? regards, Christian -- -- -- 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/groups/opt_out.
Re: Bug: writing encrypted file, while asked for password, destroys contents
> Reading the tip on the wiki, it's recommending ":wa", not > ":write", which is similar to Bram's suggested ":update" in that > it writes only modified files. Yes, I reasonably, yet incorrectly assumed that :w is doing the same that :wa, only on the active buffer. I updated the focuslost wiki page to mention the :update needed for the active-file operation, in hope it'd help somebody else as well. Thank you all, my password-file no longer suddenly disappears :) Einar -- -- 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/groups/opt_out.
Re: Bug: writing encrypted file, while asked for password, destroys contents
On 08/13/2013 05:47 AM, Ingo Karkat wrote: > On 13-Aug-2013 11:15 +0200, Bram Moolenaar wrote: >> Doing a ":write" on FocusLost is a bad idea. > > This is a common idiom to auto-save, e.g. see > http://vim.wikia.com/wiki/Auto_save_files_when_focus_is_lost > >> Perhaps ":update" would be acceptable, but generally a FocusLost event >> should not do something like this, because it can happen at any time. Reading the tip on the wiki, it's recommending ":wa", not ":write", which is similar to Bram's suggested ":update" in that it writes only modified files. Michael Henry -- -- 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/groups/opt_out.
Re: Bug: writing encrypted file, while asked for password, destroys contents
Ingo Karkat wrote: > On 13-Aug-2013 11:15 +0200, Bram Moolenaar wrote: > > > Einar Lielmanis wrote: > > > >> Encrypted file contents are destroyed, if something (e.g autocmd) > >> triggers write event, while user is being asked for password. > >> > >> To repro: > >> 1. have an encrypted.txt ready (:X) > >> 2. gvim, :au focuslost * w > >> 3. :e encrypted.txt, don't type in the password yet, > >> 4. lose window focus, e.g via switching to another window, to trigger > >>the focuslost event, > >> > >> Expected: > >> The file hasn't changed, so it should stay unmodified, > >> > >> Actual behavior: > >> encrypted.txt is truncated to a zero size. > > > > Doing a ":write" on FocusLost is a bad idea. > > This is a common idiom to auto-save, e.g. see > http://vim.wikia.com/wiki/Auto_save_files_when_focus_is_lost > > > Perhaps ":update" would be acceptable, but generally a FocusLost event > > should not do something like this, because it can happen at any time. > > Doesn't "at any time" imply more multithreading than is actually > available in Vim(script)?! It's not multi-threading, it is like handling an interrupt. And yes, autocommands have the danger of doing something bad. There is a warning in the documentation about that. > I had naively assumed that the FocusLost event would only be processed > after the blocking password query has been concluded. Not only would that require queueing events, it would also cause the FocusLost to be executed when focus has been regained (how else would one type the password?). > Isn't that (blocking, or maybe just ignoring autocmd events if that's > simpler to implement) a proper way to fix the problem? No, because Vim does not know what the autocommand will do. It won't guess what the user actually wanted. It could result in making the event not working while the user did want to do something useful. You can use the mode() function to find out what state Vim is in. While typing the encryption key it's "c". -- >From "know your smileys": :~)A man with a tape recorder up his nose /// 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/groups/opt_out.
Re: Bug: writing encrypted file, while asked for password, destroys contents
On Tue, August 13, 2013 01:00, Einar Lielmanis wrote: > Encrypted file contents are destroyed, if something (e.g autocmd) > triggers write event, while user is being asked for password. > > To repro: > 1. have an encrypted.txt ready (:X) > 2. gvim, :au focuslost * w > 3. :e encrypted.txt, don't type in the password yet, > 4. lose window focus, e.g via switching to another window, to trigger >the focuslost event, > > Expected: > The file hasn't changed, so it should stay unmodified, > > Actual behavior: > encrypted.txt is truncated to a zero size. I don't see this. Using Vim 7.4 on Windows I get vim -u NONE -N -i NONE :au FocusLost * w :e encrypted.txt (change Focus) Error detected while processing FocusLost Auto commands for "*": E505: "c:\temp\encrypted.txt" is read-only (add ! to override) "c:\temp\encrypted.txt" [crypted] 2L, 13C In any case, the file is *not* written. If you used au FocusLost * :w! the file is indeed truncated but even then after entering the correct password Vim can read the encrypted file (but you would need to make sure you have written the file or else you would be left with an empty file). regards, Christian -- -- 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/groups/opt_out.
Re: Bug: writing encrypted file, while asked for password, destroys contents
On 13-Aug-2013 11:15 +0200, Bram Moolenaar wrote: > Einar Lielmanis wrote: > >> Encrypted file contents are destroyed, if something (e.g autocmd) >> triggers write event, while user is being asked for password. >> >> To repro: >> 1. have an encrypted.txt ready (:X) >> 2. gvim, :au focuslost * w >> 3. :e encrypted.txt, don't type in the password yet, >> 4. lose window focus, e.g via switching to another window, to trigger >>the focuslost event, >> >> Expected: >> The file hasn't changed, so it should stay unmodified, >> >> Actual behavior: >> encrypted.txt is truncated to a zero size. > > Doing a ":write" on FocusLost is a bad idea. This is a common idiom to auto-save, e.g. see http://vim.wikia.com/wiki/Auto_save_files_when_focus_is_lost > Perhaps ":update" would be acceptable, but generally a FocusLost event > should not do something like this, because it can happen at any time. Doesn't "at any time" imply more multithreading than is actually available in Vim(script)?! I had naively assumed that the FocusLost event would only be processed after the blocking password query has been concluded. Isn't that (blocking, or maybe just ignoring autocmd events if that's simpler to implement) a proper way to fix the problem? -- regards, ingo -- -- 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/groups/opt_out.
Re: Bug: writing encrypted file, while asked for password, destroys contents
Einar Lielmanis wrote: > Encrypted file contents are destroyed, if something (e.g autocmd) > triggers write event, while user is being asked for password. > > To repro: > 1. have an encrypted.txt ready (:X) > 2. gvim, :au focuslost * w > 3. :e encrypted.txt, don't type in the password yet, > 4. lose window focus, e.g via switching to another window, to trigger >the focuslost event, > > Expected: > The file hasn't changed, so it should stay unmodified, > > Actual behavior: > encrypted.txt is truncated to a zero size. Doing a ":write" on FocusLost is a bad idea. Perhaps ":update" would be acceptable, but generally a FocusLost event should not do something like this, because it can happen at any time. -- >From "know your smileys": :-)Funny |-)Funny Oriental (-:Funny Australian /// 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/groups/opt_out.
