Description of problem: Recently I've started noticing that my root password is very often not accepted by anaconda, because "the fields don't match". It happened way too often for me to become suspicious. Then Vratislav Podzimek told me he started seeing the same. Then Corey McLaughlin confirmed the same experience on test list: https://lists.fedoraproject.org/pipermail/test/2014-October/123080.html The biggest roadblock when debugging this issue is that anaconda does not allow the user to display his/her own provided password (something like "Show password" check box). So it's very hard to say whether it's a bug in anaconda/gtk, or my fingers. Finally I recorded a video with a keyboard monitor overlayed over the VM. If you use a movie player capable to going frame by frame (smplayer works very well, use '.' to advance by frames), you can see that I really input the same password ('fedora') into both fields, but they "don't match". I don't really know what's in them (once again, my rant about missing "show password" check box), but if I replace the characters one by one, I finally find one (or at least one) which was incorrect and then the passwords match. The timing is extremely important to trigger this bug. It is a race condition, I believe, and you have to be very fast. I was only able to trigger this bug on the first time I entered Root Password spoke. No subsequent entry triggered the bug. Also, the first time I enter it, I need to start typing _immediately_. My theory is that the form is not fully initialized by the time it is displayed, and when I start typing immediately, it fully initialized in the mean time (after I started typing and before I finished typing). And that breaks the input for one or more characters. It's very interesting that when testing this in VM, usually the first password is broken, the first or the second character. Once I replace it, the fields match. But when I had screen recording active, it was always the second password, usually the last but one character. That again seems to indicate that it's a race condition and you need to hit some kind of a time window. When my host CPU was more busy, the problem occurred later. Maybe if I hogged the CPU even more, I'd type down both passwords before the "buggy window" had even started. Which also means that you might be able to hit this problem even if you are not lightning fast with your finger, provided that you have slow enough machine (single core, perhaps?). I believe I did the same problem even on bare metal, not just VM. But on bare metal I don't have any convenient keylogger installed, so I wasn't able to verify this (sure, I could install it if it's really needed). It seems the problem might be caused both by anaconda or gtk. I don't know which one, but I'm fully sure it did not happen in F20. It might even not have happened with early F21 composes, if really necessary, I can burn a lot of time, go one by one, and test them. It's very time consuming, though. I think the best step forward would be to add "show password" checkbox to both Root and User spokes (I assume User spoke is affected as well, you just can't reach the password fields soon enough to hit the race. The checkbox would still be useful, though). After we are able to display the actual contents of the fields, we can then find out what got wrong with the input and debug it further. Version-Release number of selected component (if applicable): anaconda 21.48.7-1 gtk2-2.24.24-3.fc21.x86_64 gtk3-3.14.0-1.fc21.x86_64 gnome-shell-3.14.0-2.fc21.x86_64 How reproducible: quite often on my laptop, probably difficult on other computers (race condition) Steps to Reproduce: 1. start the installation 2. click into Root Password dialog and IMMEDIATELY 3. start typing password, hit Tab, type the password again 4. if you were affected by the race, the fields won't match 5. wish for 'show password' checkbox
Created attachment 944585 [details] example video 1 See the video frame by frame to confirm that my input was correct.
Created attachment 944586 [details] example video 2
Created attachment 944599 [details] list of rpm packages from the live image I forgot to mention, the image used was F20 Beta TC1 Workstation Live x86_64.
Created attachment 944601 [details] anaconda.log System logs from the time when the bug occurred.
Created attachment 944602 [details] program.log
Created attachment 944603 [details] system journal
I think this is serious enough to at least warrant a blocker bug discussion. I don't know how many people can be affected, but screwing with people password is bad. It's true that it can be corrected if you retype both fields, and the chance of actually setting unintended password is probably extremely low. On the other hand Corey McLaughlin reported [0] that he had to enter the spoke three or four times to be able to input his password correctly. I could not reproduce that, but it might happen that some people will have a hard time to set up the password at all. [0] https://lists.fedoraproject.org/pipermail/test/2014-October/123080.html
I do wonder if maybe the passwords really don't match. There's a character reordering problem in bug 1147670 if you type in several characters while gtk is working on something else. https://dshea.fedorapeople.org/showpasswords.img is a quick and dirty show passwords checkbox as an updates image, if you can reproduce with that.
*** This bug has been marked as a duplicate of bug 1147670 ***
Ugh, sorry that I wasn't able to retest this sooner. Will try to do it today or tomorrow.
Created attachment 947273 [details] the ultimate proof video I have tested TC1 Live again with updates.img from comment 8 and I can confirm the passwords don't match. Even though I typed in 'fedora' and it's visible in the video if you go frame by frame, the first password field received 'feodra', two letters swapped. PS: Can we please keep the 'show password' checkbox there?