From e076c9bf084ba5f90f52d829255e4ef04e3a8031 Mon Sep 17 00:00:00 2001 From: Jay Berkenbilt Date: Sat, 6 Feb 2021 16:25:10 -0500 Subject: Remove erroneous handling of /EFF for stream decryption I thought /EFF was supposed to be used as a default for decrypting embedded file streams, but actually it's supposed to be advice to a conforming writer about handling new ones. This makes sense since the findAttachmentStreams code, which is not actually needed, was never right. --- TODO | 26 +++++++------------------- 1 file changed, 7 insertions(+), 19 deletions(-) (limited to 'TODO') diff --git a/TODO b/TODO index a63af638..d8e262fc 100644 --- a/TODO +++ b/TODO @@ -425,25 +425,13 @@ I find it useful to make reference to them in this list. http://multivalent.sourceforge.net/Tools/pdf/Extract.html http://multivalent.sourceforge.net/Tools/pdf/Embed.html - * The description of Crypt filters is unclear with respect to how to - use them to override /StmF for specific streams. I'm not sure - whether qpdf will do the right thing for any specific individual - streams that might have crypt filters, but I believe it does based - on my testing of a limited subset. The specification seems to imply - that only embedded file streams and metadata streams can have crypt - filters, and there are already special cases in the code to handle - those. Most likely, it won't be a problem, but someday someone may - find a file that qpdf doesn't work on because of crypt filters. - There is an example in the spec of using a crypt filter on a - metadata stream. - - For now, we notice /Crypt filters and decode parameters consistent - with the example in the PDF specification, and the right thing - happens for metadata filters that happen to be uncompressed or - otherwise compressed in a way we can filter. This should handle - all normal cases, but it's more or less just a guess since I don't - have any test files that actually use stream-specific crypt filters - in them. + * Qpdf does not honor /EFF when adding new file attachments. When it + encrypts, it never generates streams with explicit crypt filters. + Prior to 10.2, there was an incorrect attempt to treat /EFF as a + default value for decrypting file attachment streams, but it is not + supposed to mean that. Instead, it is intended for comforming + writers to obey this when adding new attachments. Qpdf is not a + conforming writer in that respect. * The second xref stream for linearized files has to be padded only because we need file_size as computed in pass 1 to be accurate. If -- cgit v1.2.3-54-g00ecf