Thanks for the reply! Your response makes compete sense. Even my question about my message getting deleted, got deleted. Odd.
On Sunday, July 9, 2023 at 4:46:28 AM UTC-4 Yee Cheng Chin wrote: > I don't know why your replies got deleted Richard, but regarding your > question about encrypted files, Bram is concerned about a very specific use > case where Vim can be used to edit files in an encrypted format. See ":h > cryptmethod" and ":h :X" for example. > > I personally find this to be quite an edge case. People who are paranoid > enough to edit encrypted files and need them encrypted at rest are probably > unlikely going to be printing their files out, although I could be wrong > regarding that depending on what type of content we are talking about here. > And "printexpr" has always generated temporary files (v:fname_in) to allow > for passing to a print command. > > Looking around, it does seem a little hard to directly pass a PDF to > Preview to open. In theory it should definitely be possible, and you can > copy / paste to clipboard and then load it that way but then you are > exposing it to all applications. In macOS there is an ability to take a > screenshot and directly send it to Preview.app but I think there is a very > specific service (basically a way for Mac applications to advertise what > capabilities they have) and Preview.app only exposes it for TIFF image > files (which I think is how the screenshot utility sends the image to it > without saving to a file). > > As for RAM file system, I think they may make it a little more secure, but > we still have a core system that the file was exposed to a global name > space (file system) that all apps can access. > > Otherwise we could just load the Postscript / PDF completely in app > instead of going through an external app if we really want to. > > On Sat, Jul 8, 2023 at 1:32 AM Richard Mitchell <[email protected]> > wrote: > >> Why was my message/question deleted? > > >> >> On Thursday, July 6, 2023 at 5:37:25 PM UTC-4 Lifepillar wrote: >> >>> On 2023-07-06, Bram Moolenaar <[email protected]> wrote: >>> > >>> >> On 2023-07-04, Bram Moolenaar <[email protected]> wrote: >>> >> >> Or, even better, one could create a (sufficiently large) RAM disk >>> with >>> >> >> something like: >>> >> >> >>> >> >> hdiutil attach -nomount ram://204800 >>> >> >> diskutil erasevolume APFS TempDisk /dev/diskN >>> >> >> >>> >> >> use it as volatile storage, then destroy it: >>> >> >> >>> >> >> diskutil eject /Volumes/TempDisk >>> >> >> >>> >> >> The RAM disk can likely be formatted with an encrypted file >>> system, too. >>> >> >>> >> I was able to do that with the following commands; there is probably >>> >> a simpler way: >>> >> >>> >> hdiutil attach -nomount ram://20480 >>> >> >>> >> This will return the path to the new device, e.g., /dev/disk4. >>> >> >>> >> diskutil erasevolume APFS TempDisk /dev/disk4 >>> >> >>> >> This will initialize the disk. Unfortunately, this command does not >>> >> return the volume's path, which, for some reason, is /dev/disk5s1 (I >>> >> would have expected /dev/disk4s1). >>> >> >>> >> diskutil apfs deleteVolume disk5s1 >>> >> diskutil apfs addVolume disk5 APFS encrypted -nomount >>> -stdinpassphrase >>> >> >>> >> Enter a password. Finally, mount the encrypted volume: >>> >> >>> >> diskutil apfs unlockVolume disk5s1 -stdinpassphrase >>> >> >>> >> and enter the password. >>> > >>> > Does this give a prompt, does the user know when to type the password? >>> >>> No prompt: that reads the password from stdin, then decrypts and mounts >>> the volume. If the password were to be read from a file called pwd.txt, >>> you would it in the obvious way: >>> >>> diskutil apfs unlockVolume disk5s1 -stdinpassphrase <pwd.txt >>> >>> >> > I can guess that "ram://" specifies using a RAM disk. What is the >>> >> > "204800" for? >>> >> >>> >> 204800 is the number of 512-byte sectors of the disk. So, the command >>> >> above will create a 100MB RAM disk. >>> > >>> > OK, so we divide the file size by 512 and use the resulting number. >>> > Or do we need to round it up to a multiple of 1024? >>> >>> Rounding is not necessary (but it doesn't hurt), but a minimum size is. >>> About 20MB seems a safe lower bound. >>> >>> Note, however, that the commands above will create something that looks >>> and behaves like a mounted volume, including with a mount point (e.g., >>> /Volumes/TempDisk). Even if the file system is encrypted and volatile, >>> it will still be accessible like a normal volume to anyone with access >>> to the mount point as long as the disk is mounted (usual file system >>> permissions will apply to the content). >>> >>> Is your purpose to include some macOS-specific mechanism for secure >>> inter-process communication to Vim? Maybe, that should be done using >>> some OS-specific API. >>> >>> Life. >>> >>> >>> -- >> -- >> You received this message from the "vim_mac" 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_mac" 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_mac/846f5a73-5d36-4234-98c6-faee4daac21bn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/vim_mac/846f5a73-5d36-4234-98c6-faee4daac21bn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- -- You received this message from the "vim_mac" 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_mac" 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_mac/3838352b-9a93-41f0-a195-a534b10b8b62n%40googlegroups.com.
