*** 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 explicit and fine-grained control over theirdata storage policy. EOF -- -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/PS2P216MB0275858D7D0C286BD1B36AC8C0640%40PS2P216MB0275.KORP216.PROD.OUTLOOK.COM.
