Issue 21923

After retrying some times: it seems that the password must be at 
least 5 characters to work (it doesn't work with 4 characters in 
Spreadsheet and it does work with 5 characters in Writer). This is 
however not clear in this window. It would be better to allow less 
than 5 characters and after clicking Ok pop up a window that this is 
not allowed (just as the confirmation-password is incorrect). 

I will make this an "enhancement" instead of a "defect".

it is stated in the help, but you're right that there should be an
indication that the password is not long enough. But I don't think
that accepting the password and then saying "Sorry, your password is
too short" would be desireable. Instead the Dialog should state
something like 
"Enter password (must be at least 5 characters)"

confirming, reassigning, updated summary, target-milestone not
determined, OS to ALL

SBA: Reassigned to Thorsten.

TM->BH: Please have a look, thanks !

*** Issue 39497 has been marked as a duplicate of this issue. ***

reassigning to requirements.

*** Issue 44979 has been marked as a duplicate of this issue. ***

Created attachment 38127 [details]
proposed patch for standard password dialog

The patch I attached simply adds a test string to the standard password dialog.
It is changed according to SfxPasswordDialog::mnMinLen data member.
It's based on src680-m177 tag and it's a little improved wrt the one proposed in
issue 44979, desc2.
This password dialog seems to be the one more widely used throughout OOo.

If the calling sequence is something as:

	SfxPasswordDialog aPwdDialog( this );
	aPwdDialog.SetMinLen( 0 );
	aPwdDialog.ShowExtras( SHOWEXTRAS_CONFIRM );
	aPwdDialog.SetText( sDlgTitle );
	if( aPwdDialog.Execute() == RET_OK )  //OK issued get password and set it
		sDestPassword = aPwdDialog.GetPassword();

Then the minimum password length required will be shown to the user.

Mikhail, please have a look

The patch looks good. The string specifying the number of required symbols
should be probably changed, I will ask the UserExp. The empty password will be
never accepted, so there is no need to have the related string.

FL: See section 6.2 'New Password Dialogs' in the following spec: 
http://specs.openoffice.org/appwide/security/Electronic_Signatures_and_Security.sxw
I have updated the spec and moved these new passowrd dialogs from the Future
section to the specification part.

Ok, the new specs requires more changes than I have expected. So this task is
now about the dialogs reimplementation to adjust them to the new specs. I am
changing the type to enhancement.

Changing the target.

Created attachment 48633 [details]
revised beppec56's nice patch to apply to the latest milestone (committed into ooo-build).

mav->kohei: As I have already written the change has to be done according the
new specification provided by FL. So this patch is not acceptable, sorry.

mav: yes, I'm aware.  I'm just posting this patch just in case other people need
it as an interim solution.

The new dialog will be integrated into 3.0. Changing the target.

Please revert this patch together with the whole password length restriction:
It is more important OOo is INCOMPATIBLE with the Microsoft Office as it does
not allow the short passwords - despite MS Office apparently allows it.
I got now a MS Excel document encrypted by password "150" (three letters) and I
could not convert it into ODS with the same password.
There may be some warnings but such short password should be permitted in
general - it is the user's document, please do not dictate her how well should
be her data protected.

@jankratochvil

For what it's worth, the attached patch only displays the required password
length in the UI when appropriate instead of making it secret.  The patch itself
does not set the required password length.

@kohei

OK, moved to the new Issue 85453.

Created attachment 52701 [details]
The patch to uui project, dialogs modified according to specification

Created attachment 52702 [details]
The patch to sfx2 project, password create dialog is integrated in interaction handler

mav->zhangxiaofei:
Thank you for the patch, it looks good. There is a small failure in the method
FileDialogHelper_Impl::execute()
it is not checked whether the password was entered (
RequestDocumentPassword::isPassword() method should be used ) or a cancel was
pressed. As result, if user presses cancel the saving process will not stop. But
it is a small change and can be introduced during integration.

Unfortunately the UI change is relative big to be taken for OOo3.0, only small
and important changes are planned to be taken after the Beta. Changing the
target to OOo3.1.

Ups, in my last comment please read
"...only small and important
UI  changes are planned to be taken after the Beta."
^^^

integrated in fwk92

mav->tm: Please test the new implementation. Please see section 6.2 'New
Password Dialogs' in the following spec: 
http://specs.openoffice.org/appwide/security/Electronic_Signatures_and_Security.sxw

Checked and verified in cws fwk92 -> OK !

The behaviour does not correspond to the specs. When you enter a password that
doesn't match, the dialog "The password confirmation does not match." appears,
but when you click OK, both fields are not empty when the spec says "The
password dialog is being shown after pressing the OK button. The focus is then
set to the “Enter Password” field and both input fields are empty." Only the
second field is cleared.
Kind regards - Sophie

The behaviour does not correspond to the specs. When you enter a password that
doesn't match, the dialog "The password confirmation does not match." appears,
but when you click OK, both fields are not empty when the spec says "The
password dialog is being shown after pressing the OK button. The focus is then
set to the “Enter Password” field and both input fields are empty." Only the
second field is cleared.
Kind regards - Sophie

adding me to cc - 

reassign and re-target

It is never good to mix multiple problems in the same issue. There is a
successor issue 101207 related to the password field cleaning. The problem
referred in this issue is fixed and verified by tm.

Setting back to verified.

This issue is closed automatically and wasn't rechecked in a current version of
OOo. This fixed issue should be integrated in OOo since more than half a year.
If you think this issue isn't fixed in a current version (OOo 3.1), please
reopen it and change the field 'Target Milestone' accordingly.

If you want to download a current version of OOo =>
http://download.openoffice.org/index.html
If you want to know more about the handling of fixed/verified issues =>
http://wiki.services.openoffice.org/wiki/Handle_fixed_verified_issues

Sorry this issue was wrongly closed. This issue will be reopened automatically.
And will be set after that back to fixed/verified.

Set to state 'fixed'.

Set back to state 'verified/fixed'.

Again. Sorry for the mass of mails.

Hello frederikretsema, thorstenziem, *,
I stumbled upon this issue during my TCM test. On my system (Debian
SID/Experimental AMD64) I am able to enter a password with only one character
(though I find it a dumb idea to allow such short passwords. They will not
protect the document but will lighten the cracking of the password enormously
... :( ), so I think, this issue is fixed. Could someone else confirm this (and
hopefully close this issue afterwards as "closed fixed")?
TIA
Thomas.