[Desktop-packages] [Bug 1044868] Re: Ubuntu should encourage stronger passwords using stronger algorithms, note i18n issues

2020-03-05 Thread Marcus Tomlinson
Thanks for the update Gunnar. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-control-center in Ubuntu. https://bugs.launchpad.net/bugs/1044868 Title: Ubuntu should encourage stronger passwords using stronger algorithms, note

[Desktop-packages] [Bug 1044868] Re: Ubuntu should encourage stronger passwords using stronger algorithms, note i18n issues

2020-03-05 Thread Gunnar Hjalmarsson
Yes, the password check in the installer is still not in sync with the check in g-c-c. ** Changed in: ubiquity (Ubuntu) Status: Incomplete => Triaged -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gnome-control-center in Ubuntu.

[Desktop-packages] [Bug 1044868] Re: Ubuntu should encourage stronger passwords using stronger algorithms, note i18n issues

2020-03-05 Thread Marcus Tomlinson
This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know. ** Changed in: ubiquity (Ubuntu) Status: Triaged => Incomplete -- You received this bug notification because you are a member of Desktop

[Desktop-packages] [Bug 1044868] Re: Ubuntu should encourage stronger passwords using stronger algorithms, note i18n issues

2012-11-24 Thread Gunnar Hjalmarsson
On 2012-11-24 03:56, Jeremy Bicha wrote: This is fixed with gnome-control-center 3.6.3 which has been uploaded to raring for Ubuntu 13.04. You can't set 123456 as your password via System Settings. I'm reopening the ubiquity task as ubiquity should be updated to use libpwquality. It's

[Desktop-packages] [Bug 1044868] Re: Ubuntu should encourage stronger passwords using stronger algorithms, note i18n issues

2012-11-24 Thread Jeremy Bicha
Here's the bug to allow overriding the strong password check: https://bugzilla.gnome.org/show_bug.cgi?id=688315 I still think ubiquity should use the same library for password strength checking (python-pwquality). Also, contraseña is a valid password because it's 9 characters long; passwords is

[Desktop-packages] [Bug 1044868] Re: Ubuntu should encourage stronger passwords using stronger algorithms, note i18n issues

2012-11-24 Thread Gunnar Hjalmarsson
On 2012-11-24 22:38, Jeremy Bicha wrote: Here's the bug to allow overriding the strong password check: https://bugzilla.gnome.org/show_bug.cgi?id=688315 So it was already written. Thanks! I'll add a comment saying that I support it. Hopefully it will make Matthias happy, so he supports my

[Desktop-packages] [Bug 1044868] Re: Ubuntu should encourage stronger passwords using stronger algorithms, note i18n issues

2012-11-23 Thread Jeremy Bicha
This is fixed with gnome-control-center 3.6.3 which has been uploaded to raring for Ubuntu 13.04. You can't set 123456 as your password via System Settings. I'm reopening the ubiquity task as ubiquity should be updated to use libpwquality. It's frustrating that it's possible to set a very easy

[Desktop-packages] [Bug 1044868] Re: Ubuntu should encourage stronger passwords using stronger algorithms, note i18n issues

2012-09-07 Thread Sebastian Benvenuti
reinodeespana = Weak (miss spelled) reinodeespaña = Fair (spelled properly) it's the Ñ, witch is NOT a special character in any es_ locale. republiquefrancaise = Weak (miss spelled) républiquefrançaise = Good (spelled properly) the é and the ç add extra strength, thought it's how french people

[Desktop-packages] [Bug 1044868] Re: Ubuntu should encourage stronger passwords using stronger algorithms, note i18n issues

2012-09-06 Thread Sebastian Benvenuti
Most of those words are already on the installation media. The country names, being the most basic are obviously there since I have to choose it on previous steps. The most important thing is that special characters should be based on the keymap and/or the selected locale. Being ambiguous, like

[Desktop-packages] [Bug 1044868] Re: Ubuntu should encourage stronger passwords using stronger algorithms, note i18n issues

2012-09-06 Thread Dmitrijs Ledkovs
Some country names are, but not all. Converting to ascii is not that easy, think about arabic languages. I am confused about your remark about unitedkingdon and unitedstatesofamerica, we use geonames database which has comprehensive official, alternative and local/slang names of

[Desktop-packages] [Bug 1044868] Re: Ubuntu should encourage stronger passwords using stronger algorithms, note i18n issues

2012-09-06 Thread Dmitrijs Ledkovs
Thank you for taking the time to make Ubuntu better. Since what you submitted is not really a bug, or a problem, but rather an idea to improve Ubuntu, you are invited to post your idea in Ubuntu Brainstorm at http://brainstorm.ubuntu.com/ where it can be discussed, voted by the community and

[Desktop-packages] [Bug 1044868] Re: Ubuntu should encourage stronger passwords using stronger algorithms, note i18n issues

2012-09-06 Thread Jeremy Bicha
As Seb already mentioned https://fedorahosted.org/libpwquality/ is a smarter password strength checker. The library itself is already in main. $ rmadison -S libpwquality libpam-pwquality |1.1.1-1 | quantal/universe | amd64, armel, armhf, i386, powerpc libpwquality |1.1.1-1 |

[Desktop-packages] [Bug 1044868] Re: Ubuntu should encourage stronger passwords using stronger algorithms, note i18n issues

2012-09-06 Thread Sebastian Benvenuti
xnox, I have no intent to improve the password strength verification on the installer itself. That was a suggestion on the first post. My intentions in this thread is to make the same relative rules apply to the installer verification algorithm. As absolute ones, such as treating ñ as a special

[Desktop-packages] [Bug 1044868] Re: Ubuntu should encourage stronger passwords using stronger algorithms, note i18n issues

2012-09-06 Thread Sebastian Benvenuti
There are many installations and context where a strong password is not needed, nor desired by design. E.g. cloud images have passwordless accounts passwordless root. Because access to those machines is locked down via public-key ssh connections. There is no way to know what authentication