> 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/20230706095229.D508C1C02BC%40moolenaar.net.
