Details
Bug
Major
Description
The PDF in question contains an owner password and no users password. A use has noticed that if they open the permission dialog followed by the document information dialog there is a security exception.
Activity
| Field | Original Value | New Value |
|---|---|---|
| ICEsoft Forum Reference | http://www.icesoft.org/JForum/posts/list/23282.page |
| Fix Version/s | 6.2.3 [ 13098 ] |
Fix applied to 6.2 branch and trunk
Show
Patrick Corless
added a comment - Fix applied to 6.2 branch and trunk
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] |
| Repository | Revision | Date | User | Message |
| ICEsoft Public SVN Repository | #51317 | Tue Mar 14 08:45:08 MDT 2017 | patrick.corless | user password as not ot corrupt the current encryption key. |
| Files Changed | ||||
MODIFY
/icepdf/trunk/icepdf/viewer/viewer-awt/src/main/java/org/icepdf/ri/common/PermissionsDialog.java
|
| Repository | Revision | Date | User | Message |
| ICEsoft Public SVN Repository | #51318 | Tue Mar 14 09:00:58 MDT 2017 | patrick.corless | user password as not ot corrupt the current encryption key. |
| Files Changed | ||||
|
MODIFY
/icepdf/branches/icepdf-6.2.0/icepdf/viewer/src/org/icepdf/ri/common/PermissionsDialog.java
|
| Status | Resolved [ 5 ] | Closed [ 6 ] |
The PDF contains an owner password which usually we don't access to render the document, instead we default to the user password which is an empty string by default. When the Permission dialog is opened we check the user and owner password which sets off a chain of calls which invalidated the default user password. This turns out to be an ordering issue in our calls.
To minimize any further changes to the encryption code making a simple change to the PermissionsDialog fixed the issue. Calling isOwnerAuthorized first will invalidate the encryption key but a following call to isUserAuthorized() will reinstate the default user password and create a valid encryption key.