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 <rwmitch...@gmail.com> 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 <br...@moolenaar.net> wrote: >> > >> >> On 2023-07-04, Bram Moolenaar <br...@moolenaar.net> 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 vim_mac+unsubscr...@googlegroups.com. > 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 vim_mac+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_mac/CAHTeOx_yM-uwPPQ37brKZiC6%2BT5WmE60TO%3D2rrUVmtxtj%3DQEQQ%40mail.gmail.com.
