Apache OpenOffice (AOO) Bugzilla – Issue 12626
PDF Export: control security settings
Last modified: 2006-07-27 18:54:34 UTC
In StarOffice 6.1 Beta 1, german localization, I generated a PDF document by exporting from a writer document. After opening the PDF file I checked the security settings. None of the security settings are used, so the PDF can be easily changed using Acrobat. I guess most users will expect the generated PDF exports to be write protected, since usually they only want to exchange these files with non-StarOffice/OpenOffice-Users for readonly-purposes. It should be configurable as a general setting if the files will be write-disabled and if so, which password for changing the security setting is used. Since saving passwords is not a good idea, one possibility would be to popup a window asking for the security password to use for the exported PDF in case the user has chosen readonly to be his default.
TM->BH: This one is an enhancement, please have a look, thanks !
Hello Matthias, please can you give a statemant concerning security and PDF-Export as you are very closed to that theme, thank you. I have changed the priority according priority rules.
yes, we like to offer more settings for PDF export
-
*** Issue 19726 has been marked as a duplicate of this issue. ***
Yes, http://specs.openoffice.org/appwide/pdf_export/KickOffOct2003.sxw
MMP>CP: Thanks for taking over.
*** Issue 14505 has been marked as a duplicate of this issue. ***
not handled for 8 according to http://specs.openoffice.org/appwide/pdf_export/PDFExport.sxw
cp->pl: pdf ehancement
will need encryption for that
*** Issue 44254 has been marked as a duplicate of this issue. ***
I sign under the request for this feature with both my hands and legs :) I totally agree that the main reason for creating PDFs is to make them read-only. And there are no easy to use free tools to secure PDFs generated by OOo (the cheapest I've found is around $50 - nearly as much as the whole StarOffice suite), which makes this enhancement even more needed. Developers might probably want to take a look at Java tools for PDF manipulation by Tom Phelps: http://multivalent.sourceforge.net.
*** Issue 50158 has been marked as a duplicate of this issue. ***
*** Issue 62041 has been marked as a duplicate of this issue. ***
Set target, this should probably be implemented alongside PDF/A support (issue 59651)
added myself to CC
cc me
I send a mail to the dev@gsl (http://gsl.openoffice.org/servlets/ReadMsg?list=dev&msgNo=1779) list, but no one commented, I'm going to write a few words here. The PDF spec I'm referring to is vers. 1.4. The encryption is detailed in section 3.5 of said spec. Not all the PDF file is encrypted: strings and streams composing the document are encrypted, the rest of the file is not encrypted. The streams must be encrypted after the filters are applied, and decrypted (by the viewer, not OOo) before the filters are applied. The encryption catalog defines the 'security handler' used to perform the encryption task. What PDF security handler OOo should support ? I think that the Standard Security Handler (3.5.2) would be sufficient. From what I've seen in the comments here seems that this is what the OOo users ask for. The building blocks needed to implement standard handler encryption are already present in the OOo source tree (MD5, ARCFOUR: both in sal/rlt IIRC). Are there any spec available re: PDF security ( e.g. implementation description as in http://specs.openoffice.org/appwide/security/Electronic_Signatures_and_Security.sxw for OOo ) ? ->pl. Implementation idea: all the crypt stuff should go to pdfwriter_impl.cxx, a good point to insert the crypt routines can be the PDFWriterImpl::writeBuffer method, using a flag to determine if the data must be encrypted. According to what I've seen so far, that method is the lowest level of data delivery before writing to a physical file. And what is the impact of PDF encryption wrt PDF/A ? You mentioned it in a former comment of this issue. I think I can start working on this issue, if nobody is working on it.
prio and target change to OOo2.4/prio3 (16 votes and my opinion)
You can ignore the comment regarding PDF/A; PDF/A cannot be encrypted, but switching that off in the PDF/A case should be easy. As for using writeBuffer: i also think this is the right place to do the encryption.
*** Issue 64635 has been marked as a duplicate of this issue. ***
assign to myself
->pl. ->mmp I'll start by writing a draft about how I think this issue can be implemented.
add Götz (StarOffice Product Program Manager) to cc list.
->mmp. Can you provide me a couple of shots of the selection dialog regarding security from Acro 5 and/or Acro 7 ? Same as the ones in the issue 61139 spec. English and/or German will do fine. I'd like to have a rough idea how the dialog there is implemented. Unfortunately I can't grab those...
yes - just gimmie some dayss.
add myself to CC
Created attachment 36656 [details] Draft specification, need much reworking !
-> mmp. can you have a look at the preceeding draft ? The competitive analysis is needed because I don't have the competing tools. -> pl. the current CWS contains the buildable draft implementation, almost working. I'll wait for comments.
Hi Beppec56, can you add a use case to the spec, that explains why it make sense to switch the high-level encryption off. I can not imagine one... Regards Jörg
-> joergwartenberg. I think that the 40 bit key encryption will seldom be used, if ever. I simply proposed it because it is in the PDF spec. This is just a starting point for a discussion.
I compiled the checked in version an built a linux install set. Great work ! Regarding the UI we need to make the security options clearer; i hope we get some input from mmp. I'll give some suggestions for discussion: - we have "document assembly" twice, once for "low level security" and once for "high level". I know this represents two different bits, but i hope we can come up with something that can be understood without having section 3.5 of the PDF reference at hand :-) Problem here is that the difference between the two cannot easily explained by one sentence. I suggest using "Allow document modification" for the first option and "Allow adding and removing pages" for the second. - "Content extract for copying and accessibility support" is a little fuzzy to me, how about "Allow extraction of text and graphics" - "Commenting, form filling and signing", how about "Allow modification to annotations" ? - "High level security" is good already; i asked myself whether we want to add "Revision 3" here somehow ? - "Fill form and signing", what about "Allow modification of form fields" - "Extraction for accessibility", i suggest "Allow extraction of text and graphics for accessibility" Aside from that i noticed that initially the dialog shows "High level security" unchecked but the lower three check boxes were enabled; this changed as soon a the "High level security" checkbox was changed. For convenience i suggest that on enabling "High level security" bit 11 should be set to the value of bit 4, bit 10 to the value of bit 5 and bit 9 to the value of bit 6. This should only be done initially, though. Alternatively we could only support level 3 security and save one checkbox as well as eventual dependencies between the checkboxes. I think if people want to encrypt they would rather have 128bit encryption anyway instead of 40. Final thought: for this one people will definitely need the online help :-)
-> pl. Since you compiled, ASA you can, can you check the encryption especially on forms ? I'm not sure I got all the strings there, some where tricky. Re options. When I started I hoped to mimic the status of the document security information (see preceeding screenshot, it was obtained opening an encrypted document with Acrobat Reader, then Document|Security|Show security setting, then button Show details... ) showed on Acrobat Reader, but I failed. Mainly because a security option on PDF Export Security dialog tab can actually enable more than one document security information. For example if you turn on the "Commenting form filling and signing", in the mentioned Acrobat Reader information you end up having both "Commenting" and "Form field fill-in or signing" enabled. Besides, being the dialog a starting point for a discussion, it is unfinished work. An idea would be to use only 128 bit encryption, and trying to rearrange the options in a more straightforward manner, may be with some input from mmp. Re help. You are right, in order to understand what's happening, a well written on line help is needed, but IIRC the people writing help can jump in only when we are done with the code (merged with the mainline). Or can the tooltips be added directly in the dialog layout, with the text strings ?
Created attachment 36688 [details] the document security screenshot (should have been _before_ the preceeding comment)
Screenshots from Adobe Acrobat 7.0 at http://specs.openoffice.org/appwide/pdf_export/Acrobat7-Security.odg
-> mmp. Thanks for the screenshots, I had a quick look at them. The page of interest here is Password Security, page n.2 in the draw docu; since this is the kind of security implemented in this issue. Can you provide the contents of the two listbox under the frame titled "Permissions": the lb titled "Printing Allowed" and the one titled "Changes Allowed" ? ASA I have them I'll try to reconfigure the dialog box I proposed. Quick comment on "Select document component to encrypt" frame: to be able to implement the other selections (and have search engine snoop at the document metadata), PDF version should be changed (statically or dinamically) to 1.5 and 1.6.
update of screenshots at http://specs.openoffice.org/appwide/pdf_export/Acrobat7-Security.odg
Created attachment 36713 [details] new version of password security tab page
The previous attachement is a screenshot reflecting the changes I made to the Security dialog. Of course there is still work to. In particular: - the selections are many, resulting in a higher dialog box, may be some of them can be changed into combobox; - the strings are long, resulting in a wider dialog box, the dialog items in the other pages would need trimming; - the way the passwords are requested is not very good, may be they should be requested twice to check for correctess, alert the user if the password are empty and saved among the filter call, so far they are saved but not recalled the next time the dialog is recalled. - the propertiy names in configuration are still to be updated, I'll do it when the spec of this issue will freeze. A note about the printing: as I've already said in the draft spec, the low resolution printing is onored only in Windows systems. I did some test and it resulted in some color images in the my test doc printed in black and white. -> mmp. Can you have a look ? ASA I can I'll provide an updated draft spec wrt the way the dialog items work. -> pl. As usual the CWS is updated and buildable. As for me, I'll try to investigate the password input, I've seen in other part of OOo something of the sort is used. Any suggestion here will be _greatly_ appreciated.
That dialog tab page looks rather good to me. As for the long strings: i think you can omit the "and signing existing signature fields" part, because first we don't export signature fields anyway and second they are part of form fields sematically anyway. What exactly do you want to know about password input ? Normally you'd have two edit fields for each password which are switched to asterisk echo (SetEchoChar('*') on the edit); one to enter the password and one to confirm it. In this case would not be strictly necessary but probably at least some users will expect that anyway.
Some more thoughts: you can move the whole set of controls below Permissions a little to the left i think so that they match the X-position of the FixedLine. Also i think you can replace "Enable text access for screen readers for the visually impaired" by "Enable text access for accessibility applications".
Re. password: I'd like to use the input method used by OOo in: Tools|Options|Security, file sharing options. There exists a push button used to add the password. There is a specialised dialog box I'd like to use in this dialog, but I still don't know how. That is what I'm investigating. Re "Permissions" fixed line: I scaled all that is under that because the items are enabled/disabled according to the state of the "Require password to change permission" check box. Re: the strings I'll do the changes you suggested and report back when done. They appear consistent and I'll be able to reduce the dialog dimensions.
Sorry for the delay. The dialog used on the security tabpage is (according to pb) in svx/inc/passwd.hxx.
sorry, that is not svx/inc/passwd.hxx but sfx2/inc/passwd.hxx
->pl. Thanks for the hint. So far I was not able to figure out a sensible way to use it. I'll continue to work on it anyway. I modified the dialog tab page following your suggestion, and the following attached file is a new version of the draft spec I wrote earlier. The CWS is updated to this level. Comments welcome.
Created attachment 36907 [details] new version of specification draft
Created attachment 37002 [details] password dialog sample code for discussion
I haven't tried but i would imagine that you would create a pushbutton for each password and then execute something like the appended mockup code to run the dialog. The Strings would of course need to come out of the resource file.
Created attachment 37003 [details] new password input snapshot
-> pl. Thanks for the ideas. I've implemented something of the sort, see the attached snapshot. I've just updated the CWS to reflect this change, it's buildable, so you can compile and try yourself, if you can. I changed only a password field. I deleted the edit field for password and put a pushbutton there, to mimick the behavior OOo has somewhere else. The pushbutton test switches between Set and Change, depending on the fact that the password is empty or not. When you first select the checkbox, the dialog pops up asking for a password. If you look at the code, you'll see I set the minimum lenght to zero, for test. If you don't set the minimum line to 0 the defaul is 5. I wasn't able to set the password dialog title, it appears to be some grouping line title that I was able to display only if I use the password dialog with all the options (e.g. User name, password, confirm password). To confirm the password I used the standard method provided by the dialog itself. The whole thing seems to work in a sensible manner. There is some issues re: this dialog: issue 44979 and issue 21923, they don't seem influential on the use we want to put the dialog to.
looks good to me (the button needs to move to the right, though, it interferes with the fixed text in front). An idea for discussion: having the set/change button we could get rid of the checkboxes "require a password to ...". Since the button already indicates that a password is set or not, the checkboxes seem unnecessary. We should then also eliminate the fixed text in front of the button and set its text to "set document open password" (or "change document open pasword" respectively). As for the dialog title: "Enter password" seems already appropriate, however you can change the dialog title by using SetText on the dialog itself.
Good ideas, I'll remove the check box, expand the button to include the full string. With this changes the dialog will be reduced in its heigh, may be at the previous size. Didn't think of method SetText I'll give it a try.
Created attachment 37017 [details] dialog with new password pushbuttons
Created attachment 37018 [details] the password dialog in action...
->pl. The two attached files show how the dialog appears with the last changes. I changed it as you suggested, the second attachement shows how OOo appears when confirming the document open password. To clear the password, you click the OK pushbutton on the password dialog, with the two password edit field empty. This clear the password and switch the pushbutton text to "Set....". This is the reason why I set the minimum password length to zero. When the password has a value (not empty) the pushbutton text is "Change..." The password dialog opens up with the two field empty, to maintain the current password value you hit Cancel. The encryption is forced to 128 bit. The CWS is updated to reflect this.
The last changes look very good to me. The last question is whether we want to enforce setting a password when encryption is enabled; we could do this by disabling the "OK" button as long as encryption is selected and no password is set or (perhaps better) bring up a query dialog if the user presses OK while encryption is enabled but no password set to inquire whether the user really wants to proceed. As you stated there does not seem to be much sense in having the document encrypted but not having a password.
I think that the warning message about the empty password would be better. The empty password is something that is needed, at least in the case of the document open ( a document can be permission protected, but every one can read it ). I'll have a look into adding this message.
Created attachment 37057 [details] warning dialog for empty password
The previous attachement shows the aspect of the warning dialog that shows up if the password is confirmed empty. So, the current aspect of the dialog is: - http://www.openoffice.org/nonav/issues/showattachment.cgi/37017/PDF-document-security4.png the security tab; - http://www.openoffice.org/nonav/issues/showattachment.cgi/37018/PDF-document-security5.png introducing the password, and: - http://www.openoffice.org/nonav/issues/showattachment.cgi/37057/PDF-document-security6.png to warn the user if the password is empty.
-> pl. I updated the CWS. I did some testing with the samples hi provided, all seems fine. There is a string I'm not sure if needs encryption. Can you have a look in vcl/source/gdi/pdfwriter_impl.cxx:4123, current CWS ? My comments there. Thanks.
As far as i can see you are right: that string is part of a stream and currently should not be encrypted as the stream already is.
So what is missing before CWS pdfencryption is complete ? Things seem to be pretty much done on the code side ?
Current CWS status is: - low level code ( PDFWriter and down levels ): only to be polished, completely functional. To be decided if 40 bit encryption should stay there even if now is not used. only some revision of my debug comment there; - UI side code: it works according to the last screenshots I attached to this issue. UI people observations and modifications pending. If you perform a full build from this CWS, you'll end up with a functional PDF encryption, of course not QA'ed. To be done: - work out a final specification, or upgrading the last spec issued for issue 61139; I suppose this is mmp bound; - realign the CWS to the spec: change name of properties in configuration if need arise for example; - then the usual steps to have the CWS merged into main.
I thought so. As for the 40bit support: ithink we can let it in unused for the time being (the same as PDF1.2 output) if you want to, but i think this is basically your decision. As for the spec: yes that is mmp bound :-) mmp: can you please have a look ? For the rest of the steps: a resync to a current version is in order; I'd suggest waiting for the integration of CWS warnings01 for this. With warnings01 all compiler warnings will be treated as errors in vcl and filter, so there may be some places to fix for that; also warnings01 is a huge change, so there is the distinct possibility of merge conflicts that need to be solved.
The 40bit support: I'll let it there, forcing to 128bit in the filter/pdf section, so in case it's needed for whatever reason from the UI, it'll be there. I'll wait for warnings01 integration, a huge CWS ! At a quick glance it seems all the modules are there.
-> mmp. Any news about spec ? Let me know if I can be of help.
Hi, your spec draft (very godd work) is now part of the PDF Export dialog spec at http://specs.openoffice.org/appwide/pdf_export/PDFExportDialog.odt. Proposed new stuff is marked yellow. I adjusted the layout, strings, and logic a little bit. I hope we can agree on this layout. Now I continue to add the German strings.
-> mmp. I had a quick glance to the spec. It seems OK. Today evening I'll have a deeper look, since now I'm at another site and I cannot grab my docs. I'll comment the spec using the revision/change registration of OOo.
Spec: Persistency for securioty panel (configuration) Set Password dialog German strings Mnemonics for English and German strings // Please not, I am on vacation from Jul 10-28
Created attachment 37576 [details] spec with a few comments embedded
I attached the specification with a few comments on my part. If there is something to be clarified, e.g. how the PDF is produced with encryption, I can encrypt the specification with the working copy I have.
Sorry, the previous comment was sent unfinished. I meant: I can encrypt the specification and attach it here to show what I mean.
pl->hi: please verify in CWS pdfencryption, behaviour of spec at http://specs.openoffice.org/appwide/pdf_export/PDFExportDialog.odt and install sets is now consistent as far as i can see
setting to fixed
Verified with cws pdfencryption = Security settings for opening and changing is now a additional tabpage at the options dialog.
Seen in m177 - thank you very much for your work!
Created attachment 37957 [details] Test specification
For any one interested, I added issue 67578 to start user documentation of this issue.
Lots of people on this list, sorry for the spam. Testing M178 and it doesn't work as I expected. We want to be able to lock down printing on documents, but it seems like one shouldn't have to put in a password to get to that checkbox. When you check [x] Restrict Permissions, the whole lower area should enable and let you make selections. Entering the password should be optional, right? Then Acrobat File >> Print is totally disabled and doesn't even prompt the reader for a password.
-> drichard. The reason you should set the password toghether with the "Restrict permission" check box is to prevents other people to unlock your PDF file and change the print permissions (or any other you may have set). Have a look at issue 67578, the attachment http://www.openoffice.org/nonav/issues/showattachment.cgi/37895/draft-doc-pdf-security.odt is the draft of the documentation, you'll find inside the doc suggestions on how to use the feature. I'd like to suggest you ask for further help in the users@openoffice.org list, even if this is a feature available on a snapshoot download, so other users can benefit as well. I'm monitoring that list as well.