Description: Version: 7.3.7.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: de-DE (en_US.UTF-8); UI: en-US Ubuntu package version: 1:7.3.7-0ubuntu0.22.04.5 on Linux Mint Mate 21.2 with kernel 6.5.0-44-generic Steps to Reproduce: 1. Open LibreOffice Draw and begin with creating a text box containing “Hello World”. 2. Place a rectangle filled with black over this text box as it typically happens when trying to mask confidential stuff in scanned documents. 3. Then use the File/Export/blah.pdf option, leave all tabs untouched but set a permission pasword in the security tab. 4. Check the (o) Changes > Not permitted radio button and export the file. 5. Close Libre Office Draw. 6. Reopen blah.pdf with Libre Office Draw. 7. Dismiss the “Enter Password” prompt with [CANCEL]. => The file blah.pdf will open, allowing to move or even delete the black rectangle placed over the “Hello World” text box. (Alternatively use InkScape to open blah.pdf. Does not even ask for a password.) Actual Results: Document opens in R/W mode. Expected Results: Document opens in readonly mode. Reproducible: Always User Profile Reset: No Additional Info: If I remove the "W" attribute from a PDF, LibreOffice Draw behaves corrrectly, i. e. how I would expect it after opening a modification protected PDF without providing a password.
(In reply to kderujdewod from comment #0) > Steps to Reproduce: > 1. Open LibreOffice Draw and begin with creating a text box containing > “Hello World”. > 2. Place a rectangle filled with black over this text box as it typically > happens when trying to mask confidential stuff in scanned documents. This way of redacting is not proper and has been the cause of several high-profile information leaks. What you should rather do is to use View - Toolbars - Redaction: https://help.libreoffice.org/latest/en-US/text/shared/guide/redaction.html I confirm the reported issue of changes being allowed even though the permission password dialog was dismissed. This is already seen in the first version where PDF import worked, 3.6.
As you'd asked in your ASK note: "All I wanted to achieve is an easy, straightforards way to hide some information from and unskilled user without unnecessarily bloating or degrading an already existing PDF file (which originally was a scanned document in my case). No CIA-NSA-CSSS level of security." PDF is not intended to be an editable format. Even if we have created the PDF "roundtrip", we don't edit the PDF. Rather we parse its content using poppler libs (or pdfium just for conversion to full PDF sized image for now). We honor both User and Owner password when set on encrypted PDF--which we also apply on creation of an encrypted PDF--but we consume what poppler parses (and meets our needs for creating draw objects and text spans). We don't open a PDF read only--we either open it or we don't. The use case is to always open for import to Draw canvas page or Writer text document, or to insert as full PDF "page" images. And when we do we are taking an existing PDF through the LibreOffice Draw module by filter import, converting its content (images and any OCR text spans) into sd Draw objects. And if exporting back to PDF, those same Draw elements are written back into a PDF. As noted, and acknowledged by you in the Ask article, the "Redaction" feature for export to PDF performs the necessary masking of the document canvas as a "flattened" image--the underlaying content truly removed. There is no implementation error, we parse poppler lib filter streams as intended. And there is no use case in LibreOffice to do more with the limited 'print:' 'copy:' 'change:' 'addNotes:' document protection "encrypted" PDF provides--on import or export. (In reply to Buovjaga from comment #1) > > I confirm the reported issue of changes being allowed even though the > permission password dialog was dismissed. This is already seen in the first > version where PDF import worked, 3.6. isn't that bug 49697
(In reply to V Stuart Foote from comment #2) > (In reply to Buovjaga from comment #1) > > > > I confirm the reported issue of changes being allowed even though the > > permission password dialog was dismissed. This is already seen in the first > > version where PDF import worked, 3.6. > > isn't that bug 49697 Yes. Ok, let's close.
(In reply to V Stuart Foote from comment #2) > There is no implementation error, we parse poppler lib filter streams as > intended. And there is no use case in LibreOffice to do more with the > limited 'print:' 'copy:' 'change:' 'addNotes:' document protection > "encrypted" PDF provides--on import or export. > And I just verified that our PDF Export Security dialog with password(s) applied does create PDF with printing and change controls that affect actual PDF viewers like Adobe Reader/Acrobat. While as expected our import filter does honor the password--either owner or user pw as set--to open the PDF stream, and then parses the PDF into full feature sd Draw objects as intended. =-testing-= Version: 24.2.5.1 (X86_64) / LibreOffice Community Build ID: 2ccb78ad6bdfe3f3356a7a7f294ec388775c5816 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 1b61a0737e3600aadf42f28a15c70aface9ab61e CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded