So, looks like you don't need to use random password generator, entering just wrong current password freezes the password change window on Users tab in gcc. Doing Alt + F4 makes it unstuck.

Proposed as a Blocker for 31-final by Fedora user frantisekz using the blocker tracking app because:

 "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test."

And that's to be discussed if it's basic functionality :) .

There is no hang when I boot a regular fully upgraded installation of Fedora 31 and try to change the currents user password. The "change" button is disabled until I enter the correct old password. Maybe related to having no password set after an install?

gnome-control-center-3.34.1-4.fc31.x86_64

Hmm, I see change button active no matter what I enter as current password (there is also a symbol for correctly filled value, even if it's wrong).

gnome-control-center-3.34.1-4.fc31.x86_64

(In reply to František Zatloukal from comment #4)
> Hmm, I see change button active no matter what I enter as current password
> (there is also a symbol for correctly filled value, even if it's wrong).

Same here. Note that once the control center freezes due to the wrong current password value, you can close it using the X button, but you can't start it again (until you log out and back in, it seems).

In the log I see:
Oct 21 12:30:27 f31 passwd[2115]: pam_pwquality(passwd:chauthtok): pam_parse: unknown or broken option; local_users_only
Oct 21 12:30:27 f31 unix_chkpwd[2117]: password check failed for user (kparal)
Oct 21 12:30:27 f31 passwd[2115]: pam_unix(passwd:chauthtok): authentication failure; logname= uid=1000 euid=0 tty= ruser= rhost=  user=kparal
Oct 21 12:30:30 f31 realmd[992]: quitting realmd service after timeout
Oct 21 12:30:30 f31 realmd[992]: stopping service
Oct 21 12:30:30 f31 systemd[1]: realmd.service: Succeeded.
Oct 21 12:30:30 f31 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=realmd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Oct 21 12:30:41 f31 audit[2115]: USER_CHAUTHTOK pid=2115 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:passwd_t:s0-s0:c0.c1023 msg='op=PAM:chauthtok grantors=? acct="kparal" exe="/usr/bin/passwd" hostname=? addr=? terminal=? res=failed'
Oct 21 12:30:41 f31 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=fprintd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

Note that the errors in the first 3 lines are printed out before I even hit the Change button.

I'm somewhat inclined to vote -1 blocker on this. It's fixable in an update and it's not going to be common for people to change their password via gnome-control-center immediately after installation. And even when hitting this bug, it's not as if it's unrecoverable.

Discussed during the 2019-10-21 blocker review meeting: [0]

The decision to classify this bug as a "RejectedBlocker" was made as, while this is an awkward bug, we agree it is not severe enough to violate the "basic functionality" requirement, especially as this is not something that is likely to be used in a live environment or immediately after install.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-10-21/f31-blocker-review.2019-10-21-16.00.txt

I see the following on my system when I entered a wrong password to passwd:

$ passwd
Changing password for user oholy.
Current password: 
Current Password: 
passwd: Authentication token manipulation error

The second "Current Password: " prompt is what confuses the logic used in g-c-c. Is this what you see with clean installation also?

So something similar to https://gitlab.gnome.org/GNOME/gnome-control-center/commit/7cbccd357814a6c0f2a8574d0f8b49da9e581b43 commit is needed to fix this issue.

However, does anyone have an idea of why the second prompt is printed and how the pam stack can be easily debugged?

This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days