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.

1 files changed, 7 insertions, 19 deletions

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