<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - support for digital signatures" href="https://bugs.freedesktop.org/show_bug.cgi?id=16770#c97">Comment # 97</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - support for digital signatures" href="https://bugs.freedesktop.org/show_bug.cgi?id=16770">bug 16770</a> from <a class="email" href="mailto:aguerreiro1985@gmail.com" title="Andre Guerreiro <aguerreiro1985@gmail.com>"> Andre Guerreiro</a> <pre>(In reply to Adrian Johnson from <a href="show_bug.cgi?id=16770#c79">comment #79</a>) > + r_values[0] = r2.isInt64() ? r2.getInt64() : r2.getInt(); > + r_values[1] = r3.isInt64() ? r3.getInt64() : r3.getInt(); > + r_values[2] = r4.isInt64() ? r4.getInt64() : r4.getInt(); > > According the PDF Reference, the ByteRange array contains pairs of > (offset,length). > > Why do we ignore the first offset and later assume it is 0? Why do we assume > there are exactly two pairs. > > I only skimmed over the digital signatures section so maybe I missed > something. Actually the PDF spec allows for more than 2 pairs of values in /ByteRange but it would mean that there is more than one gap in the signed data apart from the signature itself. Quoting from ISO 32000-1 section 12.8.1: "This range should be the entire file, including the signature dictionary but excluding the signature value itself (the Contents entry). Other ranges may be used but since they do not check for all changes to the document, their use is not recommended." Obviously in a file with multiple signatures each signature should cover the latest revision present in the file when the signature was appended.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>