"backupcopy" option appears not to function.

[Sihera Andre]

Hello all,

The "backupcopy" option does not appear to be working as
documented in the version of VIM I have built locally. As the
run-time contains online help for the feature I assume that
my version of VIM supports it, or does it?

Binary: 8.0.1766
Runtime: 8.0.1766
(full information at bottom)

This is the age-old chestnut about trying to symbolic link
"~/.viminfo" to another directory. The following URL is what
appears to be the most recent bug raised on the issue:

  https://github.com/vim/vim/issues/2506

It was marked as resolved but my experiences beg to differ.
These are the situations I am seeing:

1) I have no ".vimrc"; I edit shell script "x"; syntax highlighting
   is normal; ":set backupcopy" returns "auto"; I cursor around
   in file; I exit file; ".viminfo" is written as a regular file with
   lastediting position in "x".

2) I copy "~/.viminfo" to "~/temp/.viminfo" and symbolic link
   "~/.viminfo" to "~/temp/.viminfo"; I have no ".vimrc"; I edit
   script file "x"; syntax highlighting is normal; "set backupcopy"
   returns "auto"; I enter ":set backupcopy=yes"; I cursoraround
   in file; I exit file; ".viminfo" is written as a regular filewith
   last editing position in "x" and the symbolic link vanishes.

3) I copy "~/.viminfo" to "~/temp/.viminfo" and symbolic link
   "~/.viminfo" to "~/temp/.viminfo"; In the shell I execute
   "echo 'set backupcopy=yes' >~/.vimrc"; I edit file "x"; all
   *syntax highlighting disappears* and all text renders in white;
   ":set backupcopy" returns "yes"; I cursor around in file; I
   exit file; ".viminfo" is written as a regular file with last
   editingposition in "x" and the symbolic link vanishes.

4) Setting "backupcopy" to "no" when performing (2) or (3)
   above has no effect. In this case it performs as documented.

So, from my experiences, "backupcopy" is not working as
documented for "backupcopy=yes" in that it is not preserving
file attributes (in this case, symbolic link). Furthermore, there
is the mystery about why creating a one-line ".vimrc" with
"set backupcopy=yes" in it removes all syntax highlighting.

Any comments would be appreciated.

Thanks in advance,

Andre.


[ SYSTEM INFO ]


System: Ubuntu 18.10

VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Oct 25 2019 10:17:56)
Included patches: 1-1766
Compiled by andre@pegasus
Huge version with GTK2 GUI.  Features included (+) or not (-):
+acl               +farsi             +mouse_sgr -tag_any_white
+arabic            +file_in_path      -mouse_sysmouse -tcl
+autocmd           +find_in_path      +mouse_urxvt +termguicolors
-autoservername    +float             +mouse_xterm +terminal
+balloon_eval      +folding           +multi_byte +terminfo
+balloon_eval_term -footer            +multi_lang +termresponse
+browse            +fork()            -mzscheme +textobjects
++builtin_terms    +gettext           +netbeans_intg +timers
+byte_offset       -hangul_input      +num64 +title
+channel           +iconv             +packages +toolbar
+cindent           +insert_expand     +path_extra +user_commands
+clientserver      +job               -perl +vertsplit
+clipboard         +jumplist          +persistent_undo +virtualedit
+cmdline_compl     +keymap            +postscript +visual
+cmdline_hist      +lambda            +printer +visualextra
+cmdline_info      +langmap           +profile +viminfo
+comments          +libcall           -python +vreplace
+conceal           +linebreak         -python3 +wildignore
+cryptv            +lispindent        +quickfix +wildmenu
+cscope            +listcmds          +reltime +windows
+cursorbind        +localmap          +rightleft +writebackup
+cursorshape       -lua               -ruby +X11
+dialog_con_gui    +menu              +scrollbind -xfontset
+diff              +mksession         +signs +xim
+digraphs          +modify_fname      +smartindent +xpm
+dnd               +mouse             +startuptime +xsmp_interact
-ebcdic            +mouseshape        +statusline +xterm_clipboard
+emacs_tags        +mouse_dec         -sun_workshop -xterm_save
+eval              -mouse_gpm         +syntax
+ex_extra          -mouse_jsbterm     +tag_binary
+extra_search      +mouse_netterm     +tag_old_static

   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
  system gvimrc file: "$VIM/gvimrc"
    user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
    system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/usr/local/share/vim"

Compilation:
gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK  -pthread
-I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include
-I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0
-I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/fribidi
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
-I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libpng16
-g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1

Linking:
gcc   -L/usr/local/lib -Wl,--as-needed -o vim -lgtk-x11-2.0 -lgdk-x11-2.0
-lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0
-lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfontconfig -lfreetype -lSM -lICE
-lXpm -lXt -lX11 -lXdmcp -lSM -lICE  -lm -ltinfo -lnsl -lselinux -ldl

[Sihera Andre]

On 25/10/2019 13:06, Andre Sihera wrote:
> Hello all,
>
> The "backupcopy" option does not appear to be working as
> documented in the version of VIM I have built locally. As the
> run-time contains online help for the feature I assume that
> my version of VIM supports it, or does it?
>
> Binary: 8.0.1766
> Runtime: 8.0.1766
> (full information at bottom)

I have just tried my original tests against the HEAD version
(v8.1.2168) and there is no difference. In fact,  the per-file
jump list doesn't seem to work at all in the HEAD version
whereas it seems to work intermittently in 8.0.1766.

Cheers,

Andre.

[Tony Mechelynck]

The online help covers all versions of Vim, including those (if any)
,which features that you excluded at compile-time.

To see if the 'backupcopy' option is included, type (in Vim and in Normal mode)

:echo exists('+backupcopy')

followed by Enter. The answer is normally 0 or 1. 0 means No, anything
else (normally 1) means Yes.

Best regards,
Tony.

[Sihera Andre]

Hi Tony,

Thanks for your comprehensive and helpful notes on building and
configuring ViM.

Regarding the "backupcopy" option, can you please tell me exactly
what option that is I should be enabling on the "configure" command
line? I have searched the entire source code, including all labels in
src/feature.h and there is no label resembling "backupcopy". There
is a "+/iwritebackup" option, there is the "backupskip" command,
enabled as part of the "+/-wildignore" feature, but I don't see a
"backupcopy" feature.

Additionally, I have configured for "huge" builds and there is no
"backupoption" in the outputof ":version", either as a "+" or a "-"
(which would indicate it is inthe source code but has been disabled).

For your reference, I attach the output of ":version" for my build as
sent out in my original email.

Cheers,

Andre.

On 25/10/2019 13:06, Andre Sihera wrote:

[Tony Mechelynck]

What is the output of

:echo exists('+backupcopy')

? If it is 1, you already got it. In that case, «:help 'backupcopy'»
(with the single quotes but without the French ones) will tell you how
to use it, e.g. by settiing it to one of its possible values in your
vimrc.


Best regards,
Tony.

[Christian Brabandt]

The backupcopy option tells vim how to handle backup files. I don't
think it handles how the viminfo file is written.

It does not tell how the actual file is written. Have a look at `:h
backup-table` for how this interacts. Note for tests, make sure not to
use a temporary directory, as the `backupskip` option might catch this
and you might get different results. BTW: I don't understand what you
mean with

,----

| 3) I copy "~/.viminfo" to "~/temp/.viminfo" and symbolic link
| "~/.viminfo" to "~/temp/.viminfo"; In the shell I execute

`----

Are you copying it or symlinking it?
Also can you please provide step by steps of what you did and what you
expect? Thanks.

> "echo 'set backupcopy=yes' >~/.vimrc"; I edit file "x"; all
> *syntax highlighting disappears* and all text renders in white;

Check :h defaults.vim

Best,
Christian
--
Viele, die ihrer Zeit vorausgeeilt waren, mußten auf sie in sehr
unbequemen Unterkünften warten.
-- Stanislaw Jerzy Lec (eig. S. J. de Tusch-Letz)

[Christian Brabandt]

BTW: see also here, why symlinking of the viminfo file does not work:
https://groups.google.com/forum/#!msg/vim_dev/D-gkgoJh3Z4/WnERHnAKfEQJ

Best,
Christian
--
Kommt ein Zombie nachts vorbei, gibt's im Bett 'ne Keilerei.

[Tony Mechelynck]

I've been sending mail to the wrong address. Too little coffee or too
little sleep. Going to bed now, I'll check later today if you two have
got the problem ironed out.

Best regards,
Tony.

[Sihera Andre]

Hi Tony,

This outputs "1", indicating it is compiled in.

Cheers,

Andre.

[Sihera Andre]

Hi Christian,

Strictly speaking, I should have said 'I move "~/.viminfo" to "~/temp"'.
Apologies. What I meant was:

$ cd ${HOME}
$ mkdir temp
$ mv .viminfo temp/
$ ln -s temp/.viminfo

This "temp" directory is not a system "tmp" directory nor should it be
a VIM "tmp" directory. The directory could be anywhere; it should work.

> BTW: see also here, why symlinking of the viminfo file does not work:
> https://groups.google.com/forum/#!msg/vim_dev/D-gkgoJh3Z4/WnERHnAKfEQJ
>
> Best,
> Christian

This is a very thorny issue. For the same reason that you could be subject
to a symlink attack (which means that the current policy is good), now the
problem is that personal information about what files you've being editing
and where are stored in a file that cannot be easily relocated to a secure
device (which means the current policy is not fit for purpose).

To cut a very long story short, I have being running encrypted home areas
(i.e., fully encrypted partitions and swap areas that automatically mount
and dismount as you login and logout) for years before major distributions
finally thought it was fashionable. However, unlike most systems which
typically encrypt the *entire* partition (e.g., all of "/", all of "/home"
or all of "/home/<user>"), my system enables all your secure data to be on
a separate device and for your home area to symlink all the relevant areas
under "/home/<user>", on login, to any configuration of secure devices. This
has two major advantages:

1) The default account profile, typically stored under /etc/ which is fixed
   for every new account created, doesn't have to know it is being set
up on
   an encrypted device. This makes my system portable across all OS
   distributions.

2) When the OS is upgraded, I detach the encrypted partitions, upgrade OS
   complete with new, initialised "/", "/home", or "/home/<user>",
whatever,
   then I remount old partition on login and re-link all the secure places
   under "/home/<user>" as before. Quick, painless, and no
incompatibilities.

Except that .viminfo, which I would like to relocate to my encrypted
partitions, cannot be stored there because it can't be symbolic linked.

This, for me, is the security hole. This file is permanently out in the open
and it contains all manner of information about my editing history. And
that information is increasing with each new major version of ViM. Plus the
fact that I don't like being told how to manage my security. Software should
be providing all features and setting reasonable defaults; not patronising
professionals by trying to "save them from themselves".


I think there should be another debate enabling .viminfo to be a symlink
and giving computer professionals the ability to manage their own security.


Cheers,

Andre.

[Christian Brabandt]

Have you tried the 'viminfofile' option setting?

Best,
Christian
--
Etwas ist nicht recht, weil es Gesetz ist, sondern es muß Gesetz sein,
weil es recht ist.
-- Charles-Louis Baron de Montesquieu

[Sihera Andre]

HI Christian,

On 25/10/2019 18:24, Christian Brabandt wrote:
> On Fr, 25 Okt 2019, Sihera Andre wrote:
>
>> Except that .viminfo, which I would like to relocate to my encrypted
>> partitions, cannot be stored there because it can't be symbolic linked.
>>
>> This, for me, is the security hole. This file is permanently out in the open
>> and it contains all manner of information about my editing history. And
>> that information is increasing with each new major version of ViM. Plus the
>> fact that I don't like being told how to manage my security. Software should
>> be providing all features and setting reasonable defaults; not patronising
>> professionals by trying to "save them from themselves".
>>
>>
>> I think there should be another debate enabling .viminfo to be a symlink
>> and giving computer professionals the ability to manage their own security.
> Have you tried the 'viminfofile' option setting?
>
> Best,
> Christian

I didn't previously know about this option, but I have just tried it.

It works for the "-i" command line invocation but a single line

    set viminfofile="...."

in .vimrc does not seem to have any effect. ViM ignores the setting
in .vimrc and only seems to be looking at the command line "-i" option.

The whole advantage (and, I dare say, security risk) of using a symlink
is that the symlink can point to any location but the symlink itself can
stay in the same place. Having to encode a pre-resolved location to a
physical
device in an "alias" just so I can specify the "-i" option when I launch
"vi"
is not a satisfactory solution. It ties my ".profile" etc. to a single
system
instead of being generic to all (my current) systems.

Cheers,

Andre.

[Bram Moolenaar]

What you apparently are doing (securing individual files in your home
directory) sounds very unusual. The normal way is that the whole home
directory of a user is secure/safe. And then perhaps making an
exception for some files (e.g. a large video) by symlinking to another
disk.

Only securing individual files is not secure, in my opinion, since you
never know what files an application are going to create, assuming that
the home directory is safe/secure, which is the normal situation.
E.g. what if a new version of the shell decides to rename the history
file?

--
"You're fired." (1980)
"You're laid off." (1985)
"You're downsized." (1990)
"You're rightsized." (1992)
(Scott Adams - The Dilbert principle)

/// 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 ///

[Sihera Andre]

Hi Bram,


On 25/10/2019 22:17, Bram Moolenaar wrote:
> Sihera Andre wrote:
>
>>
>> <snip> However, unlike most systems which

>> typically encrypt the *entire* partition (e.g., all of "/", all of "/home"
>> or all of "/home/<user>"), my system enables all your secure data to be on
>> a separate device and for your home area to symlink all the relevant areas
>> under "/home/<user>", on login, to any configuration of secure devices. This
>> has two major advantages:
>>
>> 1) The default account profile, typically stored under /etc/ which is fixed
>>    for every new account created, doesn't have to know it is being set
>> up on
>>    an encrypted device. This makes my system portable across all OS
>>    distributions.
>>
>> 2) When the OS is upgraded, I detach the encrypted partitions, upgrade OS
>>    complete with new, initialised "/", "/home", or "/home/<user>",
>> whatever,
>>    then I remount old partition on login and re-link all the secure places
>>    under "/home/<user>" as before. Quick, painless, and no
>> incompatibilities.
>>

> What you apparently are doing (securing individual files in your home
> directory) sounds very unusual. The normal way is that the whole home
> directory of a user is secure/safe. And then perhaps making an
> exception for some files (e.g. a large video) by symlinking to another
> disk.

Not "apparent", intended. As originally explained, this is the intended
design.

> E.g. what if a new version of the shell decides to rename the history
> file?
>

Exactly my point. Which is why regardless of whatever names or locations
the shell, ViM, or any other tool for that matter, wants to to assign to
its files, that tool should not be dictating local administration policy
regarding file placement or security. If the operation of the tool isn't
aligned with local policy, it should be possible to force the tool to
place its files where the policy requires. Unix has had thesymbolic link
since very early on to assist in file placement management andits use is
well provenfor effective system administration.

ViM is a power tool, and some of the users and administrators whorely
on its flexibility also demand the same flexibility from the systems they
run ViM on. For such people, ViM should be providing all features and
setting reasonable defaults; not patronising those users by trying to
"save them from themselves".In /bin/sh, eval() certainly has its dangers,
but there is no technical justification for not implementing eval() as a
feature. It is useful, so it is available.

Apart from your (personal?) objection to the idea of ".viminfo" supporting
being symlinked, I can see no technical justification for not implementing
it. Like "backupcopy" or any of the other literally hundreds of options
already available, why can't we just link the management of ".viminfo" to
another option and give that option a sensible default?


Cheers,

Andre.

P.S. Separate to the ".viminfo" question, I have responded below (somewhat
     lengthily) to youropinion regardingthe apparent "insecurity" of my
     take on encrypted home areas.A little "background info", if you will.







=========================================================================

> What you apparently are doing (securing individual files in your home
> directory) sounds very unusual. The normal way is that the whole home
> directory of a user is secure/safe. And then perhaps making an
> exception for some files (e.g. a large video) by symlinking to another
> disk.
> Only securing individual files is not secure, in my opinion, since you
> never know what files an application are going to create, assuming that
> the home directory is safe/secure, which is the normal situation.

However, the whole home area of a user then becomes either all locked
down or completely wide open - no middle ground. People who leave their
machines powered up at the "lock screen"all the timeleave all their
dataunlocked. The machine cannot haveyou at the lock screen with your
datalocked down as the OS needs access to the home area to function,
irrespectiveof whether accessto your protected data is actually
required or not. Forthose who really understand why such security is
desirable in the first place, whole home-area encryption is a virtually
useless proposition.See:

https://askubuntu.com/questions/439782/encrypted-lock-screens
https://security.stackexchange.com/questions/103111/breaching-security-of-a-notebook-with-full-disc-encryption-when-screen-is-locked

The the home area and the operation of the OS itself being inextricably
linked (in this case, the "lock screen" feature) prevents the user locking
down their data independently of their home area's physical operation.
This is where the method of only securing known files guarantees security.
Anything you don't know about you use at your own risk. Standard stuff.

Whole home-area encryption does have its merits. As you correctly point out,
if applicationscan create files wherever they like, securing the entire
home area can save having to worry about where unruly applications save
their data. At present, this fear factor alone means the concept of whole
home-area encryption is an all too easy sell.

However, it is no good having your data, secure or not, beingfused
inextricably to the physical operation or usage pattern of your OS or
filesystem.Given the normal usage pattern of a PC or mobile device, not
only isit insecure, but youcannot take data anywhere without taking your
entiresystem with you. What is the point of having an encrypted homearea
if,themoment you have to move a document from the machine, it isout in
theclear? Pointless. Or maybe you fancy you could mount the home area in
an environmentsimilarto your original environment? What happens ifthe
remotesystem doesn't fully understand the layout of your encrypted home
area and,when you mount your partition, the remote system modifies it
causing theoriginal system to lose its integrity? Serious trouble.

Much more importantly, whole home-area encryption *assumes that you
are the administratorofyour entire machine*. At home, maybe. But
elsewhere? Just not so.Assuming one hascontrol over their machine such
that they can configureencrypting theirentire home area is not only an
unwise assumption, itis impossible in anumber of very well known cases.
For example, company-supplied hardware,internet cafes, etc., etc., etc.

Whole home-area encryption is completely counter-intuitive to the notion
of *data independence*, the primary offshoot being the notion you can
take your data anywhere and it is usable anywhere. Thus, if you need to
have both an encrypted homearea *and* an encrypted removable media, then
the argument can be easilybe made for not having whole home-area
encryption at all, particularly in thecases where you're only dealing
with knownfiles within the home area.

And if you do away with whole home-area encryption, the "lock screen"
problem is also solved. You can be logged into your machine but the *data*
can still remain 100% secure.

In addition to these normal data movement needs, users in the *NIX world
generally rebuild their systems at a far more frequent rate than most
other communities, and not having a user's data fused inextricably to the
physical operation or layout of the file system/OS significantly insulates
that user from a range of data migration issues during a system rebuild.
100% compatibility across systems, even between different revisions of the
same system, is not a guarantee and therefore must be mitigated.

So you see, my method is neither "unusual" nor without merit. Far from it.
Both methods have their merits and that doesn't make either method less
ormore secure than the other; it just depends on the data use case. That
said, the always-on "lock screen" operation of nearly all mobile phones
and a good proportion of PCs does mean that my method offers the option to
configure 100% guaranteed security for use cases that involve only known
files, even if the user chooses not to exercise that option.

The current fashion is whole home-area encryption as such security is
an easy sell to the masses. For those who are in aposition to completely
administer their system (and with Linux, regardlessof the pretty GUIs
and trendy branding, *everybody* has become theirown system administrator
whether they like it or not) whole home-areaencryption is a nice catch-
all for those who just need a quick solution thatdoes it all for them. My
method is maybe for the more conscientiousprofessional who prefers more
explicit and fine-grained control over theirdata storage policy.


EOF

[Sihera Andre]

*** Word spacing fixed. Last transmission had corrupted word spacing ***

Hi Bram,


On 25/10/2019 22:17, Bram Moolenaar wrote:
> Sihera Andre wrote:
>
>>

>> <snip>                               However, unlike most systems which

>> typically encrypt the *entire* partition (e.g., all of "/", all of
"/home"
>> or all of "/home/<user>"), my system enables all your secure data to
be on
>> a separate device and for your home area to symlink all the relevant
areas
>> under "/home/<user>", on login, to any configuration of secure
devices. This
>> has two major advantages:
>>
>> 1) The default account profile, typically stored under /etc/ which
is fixed
>>      for every new account created, doesn't have to know it is being set
>> up on
>>      an encrypted device. This makes my system portable across all OS
>>      distributions.
>>
>> 2) When the OS is upgraded, I detach the encrypted partitions,
upgrade OS
>>      complete with new, initialised "/", "/home", or "/home/<user>",
>> whatever,
>>      then I remount old partition on login and re-link all the
secure places
>>      under "/home/<user>" as before. Quick, painless, and no
>> incompatibilities.
>>

> What you apparently are doing (securing individual files in your home
> directory) sounds very unusual.  The normal way is that the whole home
> directory of a user is secure/safe.  And then perhaps making an
> exception for some files (e.g. a large video) by symlinking to another
> disk.

Not "apparent", intended. As originally explained, this is the intended
design.

> E.g. what if a new version of the shell decides to rename the history
> file?
>

Exactly my point. Which is why regardless of whatever names or locations
the shell, ViM, or any other tool for that matter, wants to to assign to
its files, that tool should not be dictating local administration policy
regarding file placement or security. If the operation of the tool isn't
aligned with local policy, it should be possible to force the tool to

place its files where the policy requires. Unix has had the symbolic link

since very early on to assist in file placement management and its use is

well proven for effective system administration.

ViM is a power tool, and some of the users and administrators who rely
on its flexibility also demand the same flexibility from the systems they

run ViM on. For such people, ViM should be providing all features and
setting reasonable defaults; not patronising those users by trying to
"save them from themselves". In /bin/sh, eval() certainly has its dangers,

but there is no technical justification for not implementing eval() as a
feature. It is useful, so it is available.

Apart from your (personal?) objection to the idea of ".viminfo" supporting
being symlinked, I can see no technical justification for not implementing
it. Like "backupcopy" or any of the other literally hundreds of options
already available, why can't we just link the management of ".viminfo" to
another option and give that option a sensible default?


Cheers,

Andre.

P.S. Separate to the ".viminfo" question, I have responded below (somewhat
     lengthily) to youropinion regardingthe apparent "insecurity" of my

     take on encrypted home areas. A little "background info", if you will.







=========================================================================

> What you apparently are doing (securing individual files in your home
> directory) sounds very unusual.  The normal way is that the whole home
> directory of a user is secure/safe.  And then perhaps making an
> exception for some files (e.g. a large video) by symlinking to another
> disk.
> Only securing individual files is not secure, in my opinion, since you
> never know what files an application are going to create, assuming that
> the home directory is safe/secure, which is the normal situation.

However, the whole home area of a user then becomes either all locked
down or completely wide open - no middle ground. People who leave their
machines powered up at the "lock screen"all the timeleave all their

data unlocked. The machine cannot have you at the lock screen with your
data locked down as the OS needs access to the home area to function,
irrespective of whether access to your protected data is actually
required or not. For those who really understand why such security is

desirable in the first place, whole home-area encryption is a virtually
useless proposition.See:

https://askubuntu.com/questions/439782/encrypted-lock-screens
https://security.stackexchange.com/questions/103111/breaching-security-of-a-notebook-with-full-disc-encryption-when-screen-is-locked

The the home area and the operation of the OS itself being inextricably
linked (in this case, the "lock screen" feature) prevents the user locking
down their data independently of their home area's physical operation.
This is where the method of only securing known files guarantees security.
Anything you don't know about you use at your own risk. Standard stuff.

Whole home-area encryption does have its merits. As you correctly point out,

if applications can create files wherever they like, securing the entire

home area can save having to worry about where unruly applications save
their data. At present, this fear factor alone means the concept of whole
home-area encryption is an all too easy sell.

However, it is no good having your data, secure or not, being fused

inextricably to the physical operation or usage pattern of your OS or

filesystem. Given the normal usage pattern of a PC or mobile device, not
only is it insecure, but you cannot take data anywhere without taking your
entire system with you. What is the point of having an encrypted homearea
if, the moment you have to move a document from the machine, it is out in
the clear? Pointless. Or maybe you fancy you could mount the home area in
an environment similarto your original environment? What happens if the
remote system doesn't fully understand the layout of your encrypted home
area and, when you mount your partition, the remote system modifies it
causing the original system to lose its integrity? Serious trouble.

Much more importantly, whole home-area encryption *assumes that you

are the administrator of your entire machine*. At home, maybe. But
elsewhere? Just not so. Assuming one hascontrol over their machine such
that they can configure encrypting theirentire home area is not only an
unwise assumption, it is impossible in anumber of very well known cases.
For example, company-supplied hardware, internet cafes, etc., etc., etc.

Whole home-area encryption is completely counter-intuitive to the notion
of *data independence*, the primary offshoot being the notion you can
take your data anywhere and it is usable anywhere. Thus, if you need to
have both an encrypted homearea *and* an encrypted removable media, then
the argument can be easilybe made for not having whole home-area

encryption at all, particularly in the cases where you're only dealing
with known files within the home area.

And if you do away with whole home-area encryption, the "lock screen"
problem is also solved. You can be logged into your machine but the
*data* can still remain 100% secure.

In addition to these normal data movement needs, users in the *NIX world
generally rebuild their systems at a far more frequent rate than most
other communities, and not having a user's data fused inextricably to the
physical operation or layout of the file system/OS significantly insulates
that user from a range of data migration issues during a system rebuild.
100% compatibility across systems, even between different revisions of the
same system, is not a guarantee and therefore must be mitigated.

So you see, my method is neither "unusual" nor without merit. Far from it.
Both methods have their merits and that doesn't make either method less

or more secure than the other; it just depends on the data use case. That

said, the always-on "lock screen" operation of nearly all mobile phones
and a good proportion of PCs does mean that my method offers the option to
configure 100% guaranteed security for use cases that involve only known
files, even if the user chooses not to exercise that option.

The current fashion is whole home-area encryption as such security is
an easy sell to the masses. For those who are in aposition to completely

administer their system (and with Linux, regardless of the pretty GUIs
and trendy branding, *everybody* has become their own system administrator
whether they like it or not) whole home-area encryption is a nice catch-

all for those who just need a quick solution thatdoes it all for them. My

method is maybe for the more conscientious professional who prefers more

[Christian Brabandt]

On Fr, 25 Okt 2019, Sihera Andre wrote:

> HI Christian,
>
>
> On 25/10/2019 18:24, Christian Brabandt wrote:
> > On Fr, 25 Okt 2019, Sihera Andre wrote:
> >
> >> Except that .viminfo, which I would like to relocate to my encrypted
> >> partitions, cannot be stored there because it can't be symbolic linked.
> >>
> >> This, for me, is the security hole. This file is permanently out in the open
> >> and it contains all manner of information about my editing history. And
> >> that information is increasing with each new major version of ViM. Plus the
> >> fact that I don't like being told how to manage my security. Software should
> >> be providing all features and setting reasonable defaults; not patronising
> >> professionals by trying to "save them from themselves".
> >>
> >>
> >> I think there should be another debate enabling .viminfo to be a symlink
> >> and giving computer professionals the ability to manage their own security.
> > Have you tried the 'viminfofile' option setting?
> >
> > Best,
> > Christian
>
> I didn't previously know about this option, but I have just tried it.
>
> It works for the "-i" command line invocation but a single line
>
>     set viminfofile="...."
>
> in .vimrc does not seem to have any effect. ViM ignores the setting
> in .vimrc and only seems to be looking at the command line "-i" option.

You might also try the 'n flag for the viminfo option. IIRC, it worked
correctly using full path years ago, while the viminfofile option is a
relative recent addition. Might be indeed a bug.

Note, in the linked thread, I did mention a patch. I just updated it, so
try the following:

diff --git a/runtime/doc/starting.txt b/runtime/doc/starting.txt
index 1626bf19b..ae26ae882 100644
--- a/runtime/doc/starting.txt
+++ b/runtime/doc/starting.txt
@@ -1528,8 +1528,6 @@ Notes for Unix:
"real" user. This helps for when you did "su" to become root, but your
$HOME is still set to a normal user's home directory. Otherwise Vim would
create a viminfo file owned by root that nobody else can read.
-- The viminfo file cannot be a symbolic link. This is to avoid security
- issues.

Marks are stored for each file separately. When a file is read and 'viminfo'
is non-empty, the marks for that file are read from the viminfo file. NOTE:
diff --git a/src/viminfo.c b/src/viminfo.c
index b16282856..399b4eb5d 100644
--- a/src/viminfo.c
+++ b/src/viminfo.c
@@ -3018,6 +3018,16 @@ write_viminfo(char_u *file, int forceit)
fname = viminfo_filename(file); // may set to default if NULL
if (fname == NULL)
return;
+#ifdef HAVE_READLINK
+ {
+ char_u buf[MAXPATHL];
+ if (resolve_symlink(fname, buf) == OK)
+ {
+ vim_free(fname);
+ fname = vim_strsave(buf);
+ }
+ }
+#endif

fp_in = mch_fopen((char *)fname, READBIN);
if (fp_in == NULL)


Best,
Christian
--
Einigkeit macht stark, aber meistens auch blind.
-- Sigmund Graff

[James McCoy]

On Fri, Oct 25, 2019 at 09:54:33AM +0000, Sihera Andre wrote:
> On 25/10/2019 18:24, Christian Brabandt wrote:
> > On Fr, 25 Okt 2019, Sihera Andre wrote:
> >> I think there should be another debate enabling .viminfo to be a symlink
> >> and giving computer professionals the ability to manage their own security.
> > Have you tried the 'viminfofile' option setting?
>

> I didn't previously know about this option, but I have just tried it.
>
> It works for the "-i" command line invocation but a single line
>
>     set viminfofile="...."

" is Vim's comment character, so that command is effectively the same as

set viminfofile=

Do not quote the filename. If there's white space, then you need to
escape it -- see “:help option-backslash”.

Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB

[Sihera Andre]

Hi Christian,

I checked the online help and while I can find an explanation of
the "n" option there is no explanation on how to actually set it.

My current "viminfo" setting is:

    viminfo='100,<50,s10,h

How do I add the "-n" option to the current setting? If I want to
specify the filename "~/mnt/secure-home/.viminfo" to this list
then what should I specify?

    :set viminfo= <what???>

Incidentally, why isn't this kind of fundamental explanation in the
online help? Another debate for another time.


Kind Regards,

Andre.

[Sihera Andre]

Hi James,

Thanks for your suggestion. I did try it but to no avail.My .vimrc contains
the single line:

    viminfofile=/home/andre/mnt/secure-home/.viminfo

However, regardless of the setting of "viminfofile", the file always
gets written
to "${HOME}/.viminfo"

Thanks for your input.

Cheers,

Andre.

[Sihera Andre]

Hi James and Christian,

On 27/10/2019 23:56, Andre Sihera wrote:
> Hi James,
>
>
> On 26/10/2019 21:26, James McCoy wrote:

> Thanks for your suggestion. I did try it but to no avail.My .vimrc
> contains
> the single line:
>
>     viminfofile=/home/andre/mnt/secure-home/.viminfo
>
> However, regardless of the setting of "viminfofile", the file always
> gets written
> to "${HOME}/.viminfo"
>
> Thanks for your input.
>
> Cheers,
>
> Andre.

Due to an oversight on my part, this setting for "viminfofile" in .vimrc
did actually work.
(the actual problem was a delay in the propagation of file updates across
NFS on my local network which led me to believe the setting was not
effective).


It appears that my desired configuration is supported and all of vim's
files are now where I want them to be.

I thank you both for your time and assistance.


Cheers,

Andre.

[Tony Mechelynck]

To set the n suboption in 'viminfo', RTFM:
- :help 'viminfo'
- :help :set
- :h :set+=

tl;dr: :set vi+=n/full/path/to/.viminfo

Best regards,
Tony.

[Sihera Andre]

Mr. Mechelynck

On 28/10/2019 02:01, Tony Mechelynck wrote:
> To set the n suboption in 'viminfo', RTFM:

No, I will not "Read The Fucking Manual".

Kindly keep your course language to yourself.

Kind Regards,

Andre Sihera.