Bug 4557 - correct password not accepted
Summary: correct password not accepted
Status: RESOLVED FIXED
Alias: None
Product: poppler
Classification: Unclassified
Component: glib frontend (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Kristian Høgsberg
QA Contact:
URL: http://acroeng.adobe.com/Test_Files/s...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-09-22 11:03 UTC by Christian Persch (GNOME)
Modified: 2007-11-24 09:19 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
add password support to test-poppler-glic (1.26 KB, patch)
2005-09-22 11:05 UTC, Christian Persch (GNOME)
Details | Splinter Review

Description Christian Persch (GNOME) 2005-09-22 11:03:19 UTC
Steps to repro:
0) Open
http://acroeng.adobe.com/Test_Files/security/MacUpperAsciiPasswords/MyOpenPasswordIs_gar%C3%A7on.pdf
 in evince
1) Type the correct password, "garçon"

Result:
Error: Incorrect password
Error: Couldn't read xref table

Poppler 0.4.x branch from today.

Works fine in xpdf 3.01.
Comment 1 Christian Persch (GNOME) 2005-09-22 11:05:19 UTC
Created attachment 3365 [details] [review]
add password support to test-poppler-glic

So you can actually try this in poppler :)
Comment 2 Michael R Head 2006-04-09 08:18:55 UTC
Neither does the poppler decrypt its own test case at
http://webcvs.freedesktop.org/*checkout*/poppler/test/unittestcases/PasswordEncrypted.pdf?rev=1.1
Comment 3 Michael R Head 2006-04-09 08:23:13 UTC
(In reply to comment #2)

burner@phoenix:~/Desktop$ evince PasswordEncrypted.pdf
Error: Unsupported version/revision (4/4) of Standard security handler
Error: Incorrect password

(I do type 'password' when evince asks).

burner@phoenix:~/Desktop$ evince --version
Gnome evince 0.5.2
burner@phoenix:~/Desktop$ pkg-config --modversion poppler
0.5.1
Comment 4 Henning Norén 2006-05-07 21:55:48 UTC
I recently stumbled on a file that gave me the same problem.
The password contained the letter 'ä' that was encoded with iso-latin 1 (gives
the number 227) and when I try to write the same character in evince on my
FC5-system I get the utf-encoded caracheter instead (numbers 195 and 164).
XPDF handles the problem fine but I have not looked at the code to see if it
defaults to latin-1 or if it does some clever encoding-conversions.

I think this is unrelated to the problem with comment #2 as the test-case is
with a unsupported version of the protocol but I bet it is the same
encoding-trouble that chpe is reporting.
Comment 5 Brad Hards 2007-10-27 00:08:08 UTC
The problem with #4 is probably that we don't support AES128 encryption yet.
Comment 6 Brad Hards 2007-10-27 01:12:35 UTC
This looks like an 8-bit cleanliness problem.
Comment 7 Brad Hards 2007-10-31 02:03:52 UTC
I have done some investigation - the password needs to be in Latin1 encoding to work correctly.
Comment 8 Brad Hards 2007-11-04 00:23:59 UTC
Works in Qt4 (if you do the right encoding), so the problem isn't in poppler. Either this in an evince problem after all, or the glib front end needs to be enhanced.
Comment 9 Carlos Garcia Campos 2007-11-24 09:19:01 UTC
Fixed in both master and poppler-0.6. 


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.