Reading gpg-encrypted files fails

[piater]

When opening a gpg-encrypted PDF, epa - the EasyPG Assistant - transparently decrypts it and loads it into a buffer named by the original, encrypted file. Consequently, epdfinfo expects to find a PDF file by this name and fails.

A quick fix is to handle encrypted files like compressed and remote files and store a decrypted copy in the current buffer’s dedicated temp directory. This is achieved by adding a simple, four-line condition to pdf-view-mode in pdf-view.el, replacing

  (when (and (or jka-compr-really-do-compress
                 (let ((file-name-handler-alist nil))
                   (not (and buffer-file-name
                             (file-readable-p buffer-file-name)))))
             (pdf-tools-pdf-buffer-p))

by

  (when (and (or jka-compr-really-do-compress
                 (let ((file-name-handler-alist nil))
                   (not (and buffer-file-name
                             (file-readable-p buffer-file-name)
			     (or (not (boundp 'epa-inhibit))
				 epa-inhibit
				 (not (string-match epa-file-name-regexp
						    buffer-file-name)))))))
	     (pdf-tools-pdf-buffer-p))

Caveats:

1. The condition may not be the best one, but I have not found a way to directly test whether the (decrypted) contents of a given buffer were loaded from an encrypted file.
2. Storing an unencrypted copy (even inside a 700 directory) poses certain privacy risks, so this quick fix is not universally applicable. Perhaps this behavior should be customizable, defaulting to off.
3. This implements reading only. I haven't looked into writing altered PDF back to their encrypted files. Stay tuned.

[piater]

Following up on the three caveats:

1. The condition is perhaps correct after all; de- and encryption are documented to be based on file names.
2. This arguably does not further increase privacy risks as the EasyPG Assistant already creates clear-text temp files under certain circumstances.
3. Currently, saving a PDF read from an encrypted PDF file overwrites the encrypted file with the clear-text PDF, despite the .gpg extension. The mechanism is probably the same as Writing files read via jka-compr overwrites compressed file with uncompressed file #257. Thus, either that issue should be fixed first, or reading gpg-encrypted files should only be enabled together with a stop-gap measure to disable writing such files.