ICEpdf
  1. ICEpdf
  2. PDF-105

Incremental Update of encrypted strings

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: 4.0 - Beta
          • Fix Version/s: 4.0 - Beta, 4.0
          • Component/s: Core/Parsing
          • Labels:
            None
          • Environment:
            An encrypted PDF document.

            Description

            During testing, Mark identified two areas of concern when writing out encrypted pdf documents.

            NameNode.decryptIfText(Object) :: line 136
            - we create a new StringLiteral when decrypting a name tree node but don't copy the old parent reference neede for encryption.

            URIAction.setURI(String) :: line 87
            - uri was being saved a java.lang.String stead of StringObject.

              Issue Links

              blocks

              New Feature - A new feature of the product, which has yet to be developed. PDF-72 PDF incremental updates

              • Major - Major loss of function.
              • Closed

                Activity

                Ascending order - Click to sort in descending order
                Hide
                Permalink
                Patrick Corless added a comment -

                The NameNode issue isn't to big a deal as we always save named references as Name object which aren't encrypted. However I did tidy up the code so we don't loose the object reference.

                URIAction issue is definately a bug and would likely result in a URI that would be readable. I've update the code so that the save the URI value back to the URIAction dictionary as a StringObject. Encryption checks are now done on getURI():String call.

                Show
                Patrick Corless added a comment - The NameNode issue isn't to big a deal as we always save named references as Name object which aren't encrypted. However I did tidy up the code so we don't loose the object reference. URIAction issue is definately a bug and would likely result in a URI that would be readable. I've update the code so that the save the URI value back to the URIAction dictionary as a StringObject. Encryption checks are now done on getURI():String call.
                Hide
                Permalink
                Patrick Corless added a comment -

                Updated the the Literal string class to encrypt and decrypt strings as the algorithm isn't symmetric, for some reason I thought is was.

                We are correctly encrypting and decrypting uri actions now but the output is being converted to unicode which is causing problems with reading the saved file.

                Show
                Patrick Corless added a comment - Updated the the Literal string class to encrypt and decrypt strings as the algorithm isn't symmetric, for some reason I thought is was. We are correctly encrypting and decrypting uri actions now but the output is being converted to unicode which is causing problems with reading the saved file.

                  People

                  • Assignee:
                    Patrick Corless
                    Reporter:
                    Patrick Corless
                  • Votes:
                    0 Vote for this issue
                    Watchers:
                    1 Start watching this issue

                    Dates

                    • Created:
                      Updated:
                      Resolved: