On 2023-07-04, Bram Moolenaar <b...@moolenaar.net> wrote:
>
>> On 2023-07-03, Bram Moolenaar <b...@moolenaar.net> 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
> 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
>> > 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.
>
> 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.
>> 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.
> 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.
> 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.
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/u84pbs%24c2d%241%40ciao.gmane.io.
