Encryption is not considered a change by the :x command

[Ninu-Ciprian Marginean]

When we look at the quickref documentation we find:

:xit    :x[it][!] [file]      like ":wq" but write only when changes have

                                   been made

If we open an existing file and we do not do any changes except for changing the encryption key(with the ":X" command) and then use the ":x" command to exit, the changes to the encryption key will not be applied. Note that the ":X" is not mandatory to be used, the behavior is the same even if we use ":set key=value". By changing the encryption key I mean all 3 scenarios(1 - file is not encrypted to file is encrypted; 2 - file is encrypted to file is encrypted, but with a different key; 3 - file is encrypted to file is not encrypted), since a key with an empty value means the file is not encrypted.

Note that ":wq" does change the encryption.

Is this a bug? Is it intended? Anyways, I just wanted to leave this here for people to know the workaround. If it's a bug, I'm willing to report one on github.

[Tony Mechelynck]

If it's a bug (I'm not sure) most developers read this mailing list too anyway.

Which Vim version? (The latest and greatest is 8.2.717 as of this
writing.) Which OS? When you type :version (in Normal mode and
followed by Enter) does it say +cryptv or -cryptv? (I would expect +
but it _is_ possible to compile Vim without encryption support) I
think there has been something of that kind but it was already quite
some time ago; but anyway, when reporting a problem (with _any_
software, not just Vim) it is always better to report which version of
the software has the problem, on which OS, and which relevant
serttings are enabled.

It is not clear to me whether it is intended or not that after setting
or changing the encryption key but making no other change, the file is
not considered 'modified'. I suppose that if you want to set or change
the key but make no other change (yet) in the file you should write it
immediately (possibly with :wq followed by :bw to make sure that none
of that file's text remains in memory).

Best regards,
Tony.

[Ninu-Ciprian Marginean]

I knew I forgot something :)

So the OS is Debian 10 (Buster), VIm 8.1(18 May 2018, compiled 15 Jun 2019 16:41:15), +cryptv.

[Bram Moolenaar]

This is similar to changing the 'fileformat' option. The buffer is
considered modified then. So yes, I think we can call this a bug.
I'll add it to the todo list. You can create an issue on github for
more visibility.

--
hundred-and-one symptoms of being an internet addict:
78. You find yourself dialing IP numbers on the phone.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Christian Brabandt]

On Sa, 09 Mai 2020, Bram Moolenaar wrote:

>
> Ninu-Ciprian Marginean wrote:
>
> > When we look at the quickref documentation we find:
> >
> > :xit :x[it][!] [file] like ":wq" but write only when changes have
> > been made
> >
> > If we open an existing file and we do not do any changes except for
> > changing the encryption key(with the ":X" command) and then use the ":x"
> > command to exit, the changes to the encryption key will not be applied.
> > Note that the ":X" is not mandatory to be used, the behavior is the same
> > even if we use ":set key=value". By changing the encryption key I mean all
> > 3 scenarios(1 - file is not encrypted to file is encrypted; 2 - file is
> > encrypted to file is encrypted, but with a different key; 3 - file is
> > encrypted to file is not encrypted), since a key with an empty value means
> > the file is not encrypted.
> >
> > Note that ":wq" does change the encryption.
> >
> > Is this a bug? Is it intended? Anyways, I just wanted to leave this here
> > for people to know the workaround. If it's a bug, I'm willing to report one
> > on github.
>
> This is similar to changing the 'fileformat' option. The buffer is
> considered modified then. So yes, I think we can call this a bug.
> I'll add it to the todo list. You can create an issue on github for
> more visibility.

No need for an issue. I have a look tomorrow.

Best,
Christian
--
Handle immer richtig. Das wird einige Leute zufriedenstellen und den
Rest in Erstaunen versetzen.
-- Mark Twain (eigl. Samuel Langhorne Clemens)

[Eli the Bearded]

Tony Mechelynck <antoine.m...@gmail.com> wrote:
> Ninu-Ciprian Marginean <ninu.cipria...@gmail.com> wrote:
>> When we look at the quickref documentation we find:

>> If we open an existing file and we do not do any changes except for
>> changing the encryption key(with the ":X" command) and then use the ":x"
>> command to exit, the changes to the encryption key will not be applied.

...

>> Is this a bug? Is it intended? Anyways, I just wanted to leave this
>> here for people to know the workaround. If it's a bug, I'm willing to
>> report one on github.
> If it's a bug (I'm not sure) most developers read this mailing list too
> anyway.

I don't think it is a bug. I make use of encrypted files regularly. I
believe it is that way to prevent any accidental encryption of a
previously plaintext file. Because that is a real pain in the neck.[*]

There are many ways cryptmethod and key can be set: $HOME/.vimrc, "set
exrc" and ./.vimrc, "set modeline" and modelines, etc. Vim can try (and
may actually do so) to protect you against key being set
non-deliberately, but it can only go so far.

Additionally using :X to encrypt-save the file is the recommended way to
set the encryption key because it is the most robust against the key
being exposed.

[*] That one time in the early 1990s when I hit <colon><x> with capslock
on and vi (or vim2 or vim3) accepted a password of a bunch of
control keys like backspace, <ctrl-c>, <ctrl-z>, etc, is seared into
*my* memory. It really made me hate programming languages with
all caps keywords and case-sensitivity.

Elijah

[Bram Moolenaar]

Isn't that avoided by Vim requiring you to enter the same password
again? Can hardly accidentlly type the same random text twice.

It really only makes a difference when using ZZ or a similar "write only
when changed" command.

--
Warning label on a superhero Halloween costume:
"Caution: Cape does not enable user to fly."