Description: LibreOffice automatically updated on my computer to the newest version, and now the password protection feature no longer works. I am following the same steps as previously, which are as follows: 1) Open a PDF file with LibreOffice Draw 2) Export as PDF 3) Click on Security 4) Click on Set Passwords 5) Enter passwords and click on Export 6) Save/replace the PDF file Unfortunately, this process no longer creates password protection, as I am able to open the PDF file without entering a password. Steps to Reproduce: 1) Open a PDF file with LibreOffice Draw 2) Export as PDF 3) Click on Security 4) Click on Set Passwords 5) Enter passwords and click on Export 6) Save/replace the PDF file Actual Results: No password protection Expected Results: The PDF files should have been password-protected Reproducible: Always User Profile Reset: No Additional Info: ?
Works for me with Version: 25.2.3.1 (X86_64) / LibreOffice Community Build ID: d8d1af5f77df955194e52baabe19324532ac8e8b CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win Locale: en-US (es_ES); UI: en-US Calc: CL threaded Please test in safe mode, Menu/Help/Restart in Safe Mode Please paste here the information on Menu/Help/About LibreOffice (There is an icon to copy)
I downloaded the latest version, 25.2.2.2, and the password-protection still does not work.
I just upgraded again and am having the same problem. Version: 25.2.3.1 (X86_64) / LibreOffice Community Build ID: d8d1af5f77df955194e52baabe19324532ac8e8b CPU threads: 22; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
I see that you asked me in your first comment to "Please test in safe mode, Menu/Help/Restart in Safe Mode" I am unsure how to do what you are requesting.
Version 25.2.1.2 Build ID: d3abf4aee5fd705e4a92bba33a32f40bc4e56f49 CPU threads: 8; OS: Windows 11 x86_64 UI render: Skia/Raster; VCL: win Locale: en-US; UI: en-US Calc: threaded I am unable to reproduce bug. PDFs are password protected as expected.
I also can't reproduce this bug. Password protection works as expected for me and I have tested it multiple times with different PDF documents. Version: 25.2.2.2 (AARCH64) / LibreOffice Community Build ID: 7370d4be9e3cf6031a51beef54ff3bda878e3fac CPU threads: 8; OS: macOS 15.3.2; UI render: Skia/Metal; VCL: osx Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded
Nothing I tried worked for me. So I restored to an earlier version, and I can once again password-protect my PDF files without a problem. Version: 24.8.4.2 (X86_64) / LibreOffice Community Build ID: fddf2685c70b461e7832239a0162a77216259f22 CPU threads: 22; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Did you check the save directory when exporting? (See TDF#165917)
Created attachment 200624 [details] password failed file
File (odt.) opens in draw without password. File can't be opened with Writer functionality - opening in writer displays draw mode. Password for the file is/ should be: LO Version: 25.2.2.2 (X86_64) / LibreOffice Community Build ID: 520(Build:2) CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: de-DE Ubuntu package version: 4:25.2.2-0ubuntu0.22.04.1~lo3 Calc: threaded
Exporting an odt file to a hybrid PDF with permissions password protection Reproducible Version: 25.2.3.2 (X86_64) / LibreOffice Community Build ID: bbb074479178df812d175f709636b368952c2ce3 CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: ja-JP Calc: CL threaded Do not reproduce Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 923da8a3855afae1f3f3a5f50d1fec08bbc02438 CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win Locale: ja-JP (ja_JP); UI: en-US Calc: threaded
@Saburo: You're right ;-))) It works!!!! After 25 years of using Star-, Open-, and LibreOffice the first time I had installed a preview.....
The fix in 25.8 could be bibisected and possibly backported to 25.2
(In reply to Saburo from comment #11) > Exporting an odt file to a hybrid PDF with permissions password protection > > Do not reproduce > Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: 923da8a3855afae1f3f3a5f50d1fec08bbc02438 > CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; > VCL: win > Locale: ja-JP (ja_JP); UI: en-US > Calc: threaded Ah, no need to bibisect: this is implemented by David Gilbert in bug 55425 and bug 66580 But it is a bit strange that the original report says "no longer able" when importing password-protected hybrid PDFs never worked before. *** This bug has been marked as a duplicate of bug 55425 ***
Probably the change of topic in comment 9 threw me off, undoing duplication. becourtnel: do you reproduce with unstable version Win-x86_64@tb77-TDF from https://dev-builds.libreoffice.org/daily/master/current.html ?
There is _something_ weird about the attached PDF but I'm not sure what. It opens OK in okular for me, but... a) It shows an embedded file like a hybrid should, but okular has trouble displaying the filename of it, and when it exports it gets a 0 length file. b) trying to get info using podofopdfinfo gets a crash from it trying to decrypt with RC4. Looking at the pdf by hand, the embeddefile name looks correct to me (not encrypted). Adding in Tomaž
Maybe it's an issue that was solved with: https://cgit.freedesktop.org/libreoffice/core/commit/?id=a30330702d4dcafab3f8b0deae2485997e28a01d
BTW. I couldn't reproduce the issue of becourtnel@yahoo.com, but just opening the PDF in Draw and exporting to add a password is risky by itself as opening the PDF in Draw with PDFImport filter doesn't guarantee that the document format is preserved. In any way - that shouldn't influence the PDF export saving a password protected file.
(In reply to Tomaz Vajngerl from comment #17) > Maybe it's an issue that was solved with: > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=a30330702d4dcafab3f8b0deae2485997e28a01d Yeh that looks like the right type of problem and the right timescale for the reporters problems, so lets mark as already-fixed.