[jira] Commented: (PDFBOX-912) PDF signing interface and improvments

["Adam Nichols (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PDFBOX-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976589#action_12976589 ] 

Adam Nichols commented on PDFBOX-912:
-------------------------------------

Danke, und glückliches neues Jahr

Re: don't pass the int[] to the signature interface, it'll make it more complex than necessary
1. In retrospect, I agree that passing in the int[] seems like a bit much.  But we could pass in a COSFilterInputStream instead, this keeps it simple since they can just read from the stream and not be bothered by the fact that it is split into multiple chunks.
2. The reason to pass it in as a stream are because it is more memory efficient.  Some devices simply don't have the memory available, and the ones that do have lots of memory don't want to use the memory unnecessarily.

Optimization
1. I've started working on a conforming parser which will create a RandomAccess object.  The current problem I'm having is I can't figure out what the PDF spec means when it says "the byte offset in the decoded stream from the beginning of the file to the beginning of the xref keyword in the last cross-reference section." in reference to startxref (section 7.5.5).  I tried using various tools to decompress PDFs, but the startxref value doesn't match up to the offset there the xref table starts.  Once I figure out what needs to be decoded and how to get that offset, I should be able to get moving quickly on the conforming parser.  It's just that this one little problem is really holding me up.
2. I'd imagine so, but there's not much code there and it's only called if you're actually signing or verifying a signature, so there's very little overhead by keeping it within PDFBox.  I remember there was talk about splitting up PDFBox into different sections so it'd be smaller (mainly for devices with limited memory like cellphones).  The people involved in that would be the best ones to answer this.
3. Good to know.  Are linearized documents very common?  I don't think I've run into them yet.  Either way, it's better to have limited support for signatures than no support.


> PDF signing interface and improvments
> -------------------------------------
>
>                 Key: PDFBOX-912
>                 URL: https://issues.apache.org/jira/browse/PDFBOX-912
>             Project: PDFBox
>          Issue Type: Improvement
>          Components: PDFReader, PDModel, PDModel.AcroForm, Writing
>    Affects Versions: 1.4.0
>            Reporter: Thomas Chojecki
>            Assignee: Adam Nichols
>            Priority: Minor
>         Attachments: cos_object_improvement_patch.txt, fields_annotations_patch.txt, interface_options_patch.txt, io_patch.txt, main_documents_patch.txt, parser_patch.txt, signature_exception_patch.txt, test.pdf, test_signed.pdf, writer_patch.txt
>
>
> This is a first version of a signing interface for pdfbox. There are some design issues i could not handle without rewriting too much of the code.
> Here we go:
> - incremental update support (tested for signatures with pdf/a compatibility), not compatible with encrypted documents nor with xref-streams
> - cos object improvment
>   -- COSString with ability to force writing hexbin for given string
>   -- COSBase with ability to write direct into a dictionary (that means if this is set, no indirect object will be wrote) (sry hard to explain what i mean, actualy needed for incremental update to lower the rate of indirect objects)
>   -- COSBase with ability to force writing object (this hook help the COSWriter write needed objects for inkremental update)
>   -- COSName added new names
>   -- COSDocument some getter and setter for handling new signature and incremental features
> - SignatureException with some exceptions for handling the bunch of new possible errors
> -Parser improvments
>   -- PDFParser saves now the position of the last startxref
>   -- VisualSignatureParser (hook for parsing visual signature templates) (it's only for prepared visualisation that should be merged with the document)
> -IO improvments
>   -- COSFilterInput helps to find the proper content that should be hashed / signed
>   -- COSStandardOutputStream is tricky, it helps the writer to jump to the right place in the document
>   -- COSWriter got some improvments for incremental update
>   -- COSWriterXRefEntry needed for incremental updates and writing the new Xref table
> - PDDocument
>  -- got a new method addSignature with the needed implementation (do the whole signature stuff)
>  -- cleanup
> - Fields and Annotations
>  -- PDSignature represent the signature dictionary 
>  -- PDSignatureFild / Annotation are the visible & unvisible signature representations
> - Signature Interface and options
>  -- SignatureInterface the interface that shall be implemented for proper signing
>  -- SignatureOptions, some additional options for signing
> Patch splited into pieces
> sry for spelling, didn't include a spellchecker for english.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.