Do you think this is a security risk and if not is it a bad UI decision?

[Stef Walter]

On 06.05.2013 21:51, Adam Williamson wrote:
> On Mon, 2013-05-06 at 21:37 +0200, Stef Walter wrote:
>> On 06.05.2013 18:38, Adam Williamson wrote:
>>> On Mon, 2013-05-06 at 11:43 -0400, Rahul Sundaram wrote:
>>>> On 05/06/2013 10:48 AM, Miloslav Trmač wrote:
>>>>
>>>>>
>>>>> On Sat, May 4, 2013 at 6:31 AM, Rahul Sundaram wrote:
>>>>>         On 05/04/2013 12:24 AM, Eric Sandeen wrote:
>>>>>                 On the other hand, if it's the right thing to do,
>>>>>                 then it needs to be done for GUI password change
>>>>>                 dialogs and the passwd command should be updated as
>>>>>                 well, for consistency, no?
>>>>>         
>>>>>         
>>>>>         On a related note, Anaconda,  GNOME, KDE etc seems to be
>>>>>         relying on different rules about what an acceptable password
>>>>>         is.  We really need to settle on one library and provide a
>>>>>         consistent way to tweak it.
>>>>> "Everything" (certainly Anaconda and GNOME, not sure about KDE) is
>>>>> supposed to use libpwquality.  Is that not so?
>>>>>
>>>>
>>>> They are definitely not enforcing the same rules. 
>>>
>>> One obvious area of inconsistency is that some of the tools _warn_ on
>>> weak passwords, and some _block_ on weak passwords. We should
>>> standardize on one or the other of those.
>>
>> Not really. It makes complete sense to allow overriding the rules in
>> certain contexts. For example when root is setting another user's password.
> 
> But they have different behaviours for the same operation. For e.g.,
> initial-setup and g-i-s have different behaviours for setting the
> password for the first user account.

True.

It's on my list of things to do to make AccountsService be able to use
PAM to set the password, which then puts it through libpwquality. How
that interacts with the password complexity requirements in g-i-s and
g-c-c would need to be solved.

Cheers,

Stef