| Summary: | Password required on document that opens without using Acrobat | ||
|---|---|---|---|
| Product: | poppler | Reporter: | Daniel Stone <daniel> |
| Component: | general | Assignee: | poppler-bugs <poppler-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | high | CC: | bradh, jan.kratochvil, mark, nshmyrev, rolf.offermanns, sonicwarrior |
| Version: | unspecified | ||
| Hardware: | x86 (IA32) | ||
| OS: | FreeBSD | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: |
testcase
Patch fixing the issue. My take on fixing the bug |
||
|
Description
FreeDesktop Bugzilla Database Corruption Fix User
2005-06-08 13:44:39 UTC
Looks like comments, attachments and reported information got lost during the disk crash - closing. According to http://bugzilla.gnome.org/show_bug.cgi?id=301498, this was just the upstream copy of that bug. Comments from that bug: -Comment 0- The following document opens fine with adobe acrobat but evince states that it is locked and requires a password: http://ucfv.ca/ar/200505/UCFVTimetable.pdf The link is from http://ucfv.ca/ar Note that GPDF does this as well; I've not tried XPDF yet - so I'm not sure if this is a "default" password with adobe or whether evince is sharing a bug with GPDF. Steps to reproduce: 1. Open http://ucfv.ca/ar/200505/UCFVTimetable.pdf with evince. -Comment 4- Here's my test w/ xpdf. It printed that stuff out, then asked me for a password, I hit [OK] and it wouldn't let me see the document. [clarkbw@rhbw bin]$ xpdf UCFVTimetable.pdf Error: Unsupported version/revision (4/4) of Standard security handler Error: Couldn't read xref table Acroread 5 couldn't open the document. It popped up an error about decrypting it. [clarkbw@rhbw bin]$ pdf2ps UCFVTimetable.pdf ****This file uses an unknown standard security handler revision: 4 Error: /undefined in pdf_check_user_password -Comment 6- I'm using [acrobat] version 7 to read it. The site says version 6 is required - I couldn't read it with 5. -Gnome bug 321152- Apparently also happens with another file that reporter gives this info on: I have a link to pdf file. You can download it from rapidshare. It is a book. Not very legal, you know ;-) http://rapidshare.de/files/6809105/toni_natahaus.ru_.rar.html mirror: http://www.megaupload.com/?d=WP2K15C2" -Gnome bug 344497- Apparently also happens with this file: http://www.highpoint-tech.com/manuals/RR2300_UM_EN_1.0_031306.pdf Link to another similar documents http://formeradvent.temp.powweb.com/Proclamacion06_1_2.pdf http://www.islenska.de./pdf/Islenska.de_Preiskrieg%20in%20Island.pdf (In reply to comment #2) > Link to another similar documents > http://formeradvent.temp.powweb.com/Proclamacion06_1_2.pdf > http://www.islenska.de./pdf/Islenska.de_Preiskrieg%20in%20Island.pdf I ran into this problem days ago, and it persists on latest version of Evince version (0.8.0). Some webpages say this problem has not been solved yet. Although the first document mentioned is not available now, one shared thing between the second document and mine is that: they both allow viewing without password, but some operations (e.g.: printing) are password-protected. Adobe Reader (for Linux and Windows) seems to handle these documents quite well, but Evince don't. So I guess if this bug is caused by incomplete implementation of pdf security management somewhere in poppler? Hope this helpful. There weren't a lot of useable samples in this bug, but http://www.islenska.de./pdf/Islenska.de_Preiskrieg%20in%20Island.pdf and http://www.highpoint-tech.com/manuals/RR2300_UM_EN_1.0_031306.pdf both work with the Qt4 test tool. Please advise if this is still a problem Bugzilla Upgrade Mass Bug Change
NEEDSINFO state was removed in Bugzilla 3.x, reopening any bugs previously listed as NEEDSINFO.
- benjsc
fd.o Wrangler
I wonder if these documents are protected by Adobe Lifecycle management. Acroread 8.1.2 asks to accept to connect to such a server, who knows if older versions sid just silently connect. Evince asks for a password for such documents. Created attachment 39110 [details] testcase New test case of a file with password security that opens in acrobat and does not open in evince. Originally reported in https://bugzilla.gnome.org/show_bug.cgi?id=631144 Problem in document from #8 is that it uses AESV3 encryption that we do not support This bug is 6 years old and still not fixed? Additional examples (I'm using Ubuntu 10.10/AMD64 with libpoppler 0.14.3/evince 2.32.0): http://www.jlmaudio.com/Baby%20Animal%20Mic%20Pre%20with%20JLM14%20&%20OPA2604.pdf http://www.jlmaudio.com/Baby%20Animal%20Mic%20Pre%20PCB%20Full%20Circuit.pdf Seems to work with poppler 0.20 It still requires password and fails to open the attachment 39110 [details]
with poppler-0.20.1-2.fc18.x86_64 and evince-3.5.4-2.fc18.x86_64.
Something is broken in the glib frontend, using qt4/tests/test-poppler-qt4 renders the like like a charm Created attachment 65106 [details] [review] Patch fixing the issue. Indeed, currently the glib frontend passes a NULL pointer as password when creating the Doc, while the qt4 frontend passes an empty Goostring. So it seems that the file in the comment 8 actually needs an empty password, instead of not needing one... So, the patch attached makes the glib frontend to behave as the qt4 frontend and fixes the issue. For evince one cannot enter an empty password. With the Comment 14 patch it really works, without asking for any password, thanks. It requires patched poppler-0.20. Patched popppler-0.18 still did not work ("Weird encryption info"). I found even with xpdf and poppler-0.18 it works, just one has to click empty password. But even with poppler-0.20 from Comment 14 xpdf asks for password and non-empty password does not work; this is not acceptable for users, is it a bug of xpdf or can it be fixed in poppler? This is xpdf regression against Adobe Acrobat Reader. 0.18 0.18+patch 0.20 0.20+patch evince FAIL FAIL FAIL PASS xpdf EMPTY EMPTY EMPTY EMPTY PASS = opened without asking anything FAIL = cannot open (probably because one cannot enter empty password) EMPTY = opened but one has to click empty password; not acceptable for users Jan, we do not develop xpdf nor xpdf uses poppler, so i don't really understand your question at all. Created attachment 65121 [details] [review] My take on fixing the bug Jose, i'd prefer to commit this patch since this way we also fix the utils that have the same problem the glib frontend has (passing null null as passwords). What do you think? (In reply to comment #16) > Jan, we do not develop xpdf nor xpdf uses poppler, so i don't really understand > your question at all. OK, true, sorry, I got confused by Fedora xpdf dependency on poppler-utils. Albert, I agree that fixing it in core is bettter, so please go ahead. And thanks for asking. Pushed. *** Bug 53917 has been marked as a duplicate of this bug. *** |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.