Better fix to insecure password check (fixes #501)

1 files changed, 30 insertions, 32 deletions

diff --git a/manual/qpdf-manual.xml b/manual/qpdf-manual.xml
index 5b4d2cee..09ba7408 100644
--- a/manual/qpdf-manual.xml
+++ b/manual/qpdf-manual.xml
@@ -1239,10 +1239,11 @@ make
    <para>
     Either or both of the user password and the owner password may be
     empty strings. Starting in qpdf 10.2, qpdf defaults to not
-    allowing creation of PDF files with an empty owner password or an
-    owner password that matches the user password. If you want to
-    create such files, specify the encryption option
-    <option>--allow-insecure</option>, as described below.
+    allowing creation of PDF files with a non-empty user password, an
+    empty owner password, and a 256-bit key since such files can be
+    opened with no password. If you want to create such files, specify
+    the encryption option <option>--allow-insecure</option>, as
+    described below.
    </para>
    <para>
     The value for
@@ -1252,25 +1253,6 @@ make
     fully permissive.
    </para>
    <para>
-    For all key lengths, the following options are available:
-    <variablelist>
-     <varlistentry>
-      <term><option>--allow-insecure</option></term>
-      <listitem>
-       <para>
-        From qpdf 10.2, qpdf defaults to not allowing creation of PDF
-        files where the owner password is blank or matches the user
-        password. Files created in this way are insecure and can't be
-        opened by some viewers. Users would ordinarily never want to
-        create such files. If you are using qpdf to intentionally
-        created strange files for testing (a definite valid use of
-        qpdf!), this option allows you to create such insecure files.
-       </para>
-      </listitem>
-     </varlistentry>
-    </variablelist>
-   </para>
-   <para>
     If <option><replaceable>key-length</replaceable></option> is 40,
     the following restriction options are available:
     <variablelist>
@@ -1466,6 +1448,21 @@ make
       </listitem>
      </varlistentry>
      <varlistentry>
+      <term><option>--allow-insecure</option></term>
+      <listitem>
+       <para>
+        From qpdf 10.2, qpdf defaults to not allowing creation of PDF
+        files where the user password is non-empty, the owner password
+        is empty, and a 256-bit key is in use. Files created in this
+        way are insecure since they can be opened without a password.
+        Users would ordinarily never want to create such files. If you
+        are using qpdf to intentionally created strange files for
+        testing (a definite valid use of qpdf!), this option allows
+        you to create such insecure files.
+       </para>
+      </listitem>
+     </varlistentry>
+     <varlistentry>
       <term><option>--force-V4</option></term>
       <listitem>
        <para>
@@ -4877,15 +4874,16 @@ print "\n";
         <listitem>
          <para>
           By default, <command>qpdf</command> no longer allows
-          creation of encrypted PDF files whose owner password is
-          empty or matches the user password. The
-          <option>--allow-insecure</option>, specified inside the
-          <option>--encrypt</option> options, allows creation of such
-          files. Behavior changes in the CLI are avoided when
-          possible, but an exception was made here because this is
-          security-related. qpdf must always allow creation of weird
-          files for testing purposes, but it should not default to
-          letting users unknowingly create insecure files.
+          creation of encrypted PDF files whose user password is
+          non-empty and owner password is empty when a 256-bit key is
+          in use. The <option>--allow-insecure</option> option,
+          specified inside the <option>--encrypt</option> options,
+          allows creation of such files. Behavior changes in the CLI
+          are avoided when possible, but an exception was made here
+          because this is security-related. qpdf must always allow
+          creation of weird files for testing purposes, but it should
+          not default to letting users unknowingly create insecure
+          files.
          </para>
         </listitem>
        </itemizedlist>