I've gotten lost in this discussion. The question was just initially about getting the functionality of using Preview back instead of sending directly to a printer. This has turned into a deeper discussion about file security and making sure the PDF is encrypted. Are people auto encrypting the text files they are editing in Vim? Isn't the plain text file getting converted to a PDF for Preview/printing on the same computer as the PDF? What makes a PDF so much more of a security risk?
On Thursday, July 6, 2023 at 5:52:35 AM UTC-4 Bram Moolenaar wrote: > > > On 2023-07-04, Bram Moolenaar <[email protected]> wrote: > > > > > >> On 2023-07-03, Bram Moolenaar <[email protected]> wrote: > > >> > I suppose encrypting the file won't be possible, since the reader > does > > >> > not know how to decrypt it. Or does the Preview app support > encryption > > >> > somehow? > > >> > > >> Yes, macOS's Preview supports (at least some?) encrypted PDFs. I did > > >> a quick test by encrypting a random PDF document with qpdf: > > >> > > >> qpdf --encrypt PASSWORD OWNERPASSWORD 256 -- in.pdf out.pdf > > >> > > >> and by opening out.pdf with Preview, which prompted for a password > > >> before opening the document. > > > > > > I could find help with: > > > % qpdf --help=encryption > > > Create encrypted files. Usage: > > > > > > --encrypt user-password owner-password key-length [options] -- > > > > > > Either or both of user-password and owner-password may be empty > > > strings. key-length may be 40, 128, or 256. Encryption options are > > > terminated by "--" by itself. > > > > > > I don't like passing the password on the command line, but I suppose > > > there is no other way. > > > > I was using qpdf as a quick way to get an encrypted PDF, as I had it > > installed in my system. But there are probably other ways. The passwords > > can be read from stdin (one per line) by using @-: > > > > qpdf --encrypt @- @- 256 -- in.pdf encrypted.pdf > > That looks useful. We do have to make sure to get the line separator > right and make sure there are no leading or trailing white space > characters. > > > > There is no explanation of "user-password" and "owner-password", other > > > than that they may be empty. Is there a recommended usage? > > > > Take this with a grain of salt, as I know qpdf only superficially, and > > I am not very familiar with PDF encryption either: probably, setting > > both user and owner password to the same password suffices: > > > > > https://unix.stackexchange.com/questions/535946/encrypting-pdf-with-qpdf-and-only-user-password > > OK. I found a warning somewhere to not use an empty password, it can be > considered equal to "not encrypted". > > > >> > The alternative is to not use a temp file but write the text > through a > > >> > pipe/socket. That also avoids the need to find the right moment to > > >> > delete the temp file. Can we do this somehow? > > >> > > >> With Preview? I don't think so. But if one wants to get fancy, the PDF > > >> can be written to the system clipboard and then Preview can be asked > to > > >> create a new document from the clipboard's content (using > AppleScript). > > >> Then, the clipboard content can be erased. > > That still leaves a short time that another program can grab the > password, only a matter of checking the clipboard at the right time. > Hacking tools can be used to slow down the system and have a better > chance of grabbing it. Since Vim is open source we can't use obscurity > to hide the way the password can be accessed. Better not go that way. > > > > The big question is: is this safe? Is it impossible for someone else to > > > get the text in not encrypted form? > > > > As the clipboard is a shared memory area, I'd say that no, it is not > > safe in general. Although apps such as KeepassXC do paste sensitive > > information into the system clipboard for a limited amount of time, > > typically ten seconds. If the goal is to defend against other processes > > in the same user space, the method below may be safer. > > Right, let's avoid using the clipboard. > > > >> 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? > > > > OK, so there are options. Which one should we use? > > > > The clipboard and RAM disk options use only commands that are available > > in macOS, so they may be preferable to using qpdf, which must be > > installed by the user. An encrypted RAM disk may be better than using > > the clipboard, although it has some visible side-effects, namely the > > disk icon usually appears on the desktop. > > > > But the question is whether it is worth going to such lengths instead of > > writing to a temporary file (which is deleted after ten seconds) as > > MacVim currently does. Security conscious people have disk encryption > > enabled by default at the system level (FileVault), and afaik a deleted > > file is not recoverable. > > Every file that was written to a harddisk can be read back. > Relying on "being lucky" is a bad strategy. It used to be OK to > overwrite the file with random data, but with SSDs that doesn't work > (blocks are reallocated when writing the second time, a recovery tool > can still read the older data). > > > > 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? We need to add > something for the directory structure as well. > > -- > God made the integers; all else is the work of Man. > -- Kronecker > > /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ > /// \\\ > \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// > \\\ help me help AIDS victims -- http://ICCF-Holland.org /// > -- -- 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/fe6458ee-ec8a-4bb8-84a7-99d80f44a481n%40googlegroups.com.
