Description of problem: as per #151328: rhn/eng/backend/server/rhnUser.py:validate_new_password() either the error message is wrong, or the regex/logic is wrong. I'm not entirely sure what the intended behaviour is. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
ping
Should be fixed in rhns-4.0.0-53 and newer. Test case: see bug 151328 Essentially, try to put a * in your password. Should work. Try to put a * at the beginning of the password. Should work. Try to use only * chars. Should fail.
*** Bug 157375 has been marked as a duplicate of this bug. ***
*** Bug 151328 has been marked as a duplicate of this bug. ***
This bug is considered CanFix for RHEL 3 U6 by RHN Engineering.
Mass move to ON_QA
Dev & PM ACKs for U6
6/28/2005 -- bnackash 1- Using the web UI to create a new user, I was able to successfully choose a password of "*******" and log in as the new user. Bug 151328 states that the web UI does allow all asterisks for the password, but I'm not sure if that's a feature or a bug. If feature, then disregard this comment. 2- Using the web UI, I was able to successfully change my RHN password to *********** or something of that ilk. (At least the web UI indicated my information had been updated.) And now I can't remember how many ********s I used and locked myself out of RHN :( Again, not sure if this is a feature or a bug. 3- There's a small typo in the error message: "password can not be all asterisks" should say "password cannot be all asterisks". Other comments from Beth: Using up2date --register (up2date-4.4.5.6-2), I was unable to enter a password with all asterisks. I was able to enter a password with one or more asterisks. This is correct behavior.
#3 from comment #8 fixed in svn rest is pending discussion on whats the correct behaviour
Seems we decided client is doing the right thing, so moving this to ON_QA
up2date-4.4.30-3 still says "password can not be all asterisks" Which up2date fixes this?
re comment #12 It's a server side change, not a client side change, so fix should appear for next QA push.
Do you mean the fix should have made it into Thursday's (7/14) QA push? Because it didn't.
doh, never actually committed it. Next QA push.
verified fix