[Libreoffice-bugs] [Bug 70183] characters £ ì è é ò ç à ° § ù © not accepted in PDF passwords

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=70183

--- Comment #11 from Mike Kaganski <mikekaganski at hotmail.com> ---
The PDF encryption was implemented here:
https://bz.apache.org/ooo/show_bug.cgi?id=12626

Code pointers:
1. Setting the password dialog to only accept ASCII:
> aPwdDialog->AllowAsciiOnly();
in IMPL_LINK_NOARG(ImpPDFTabSecurityPage, ClickmaPbSetPwdHdl, Button*, void)
(filter/source/pdf/impdialog.cxx)

2. Using the string encoded as ANSI-1252:
> OString aString( OUStringToOString( i_rPassword, RTL_TEXTENCODING_MS_1252 ) );
in void PDFWriterImpl::padPassword( const OUString& i_rPassword, sal_uInt8*
o_pPaddedPW ) (vcl/source/gdi/pdfwriter_impl2.cxx)

3. Code that checks if an allowed character is entered:
void SfxPasswordDialog::ModifyHdl(Edit* pEdit) (sfx2/source/dialog/passwd.cxx)

I am now unsure if it would be good idea to make both fields (password and
verification) working identically: if they both filtered user input, then user
could not notice that some of characters were rejected, and be sure that the
password is as entered; and after that, would discover the password (containing
non-1252 characters) be wrong. But anyhow, the code that filters out characters
could make visual and audible hints that some characters got filtered (e.g.,
balloon hints or something).

The other idea (to use UTF-8 encoding, and thus allow any input) looks more
appealing.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20170708/9070d509/attachment.html>