FESCo has ratified https://fedoraproject.org/wiki/Passphrase_policy as the distro wide policy for local passwords/passphrases. As such we would like to adjust anacondas setup for this policy. I can split this out into seperate bugs or keep everything here as you prefer. The changes I think we need: * anaconda currently passes: +pwpolicy root --strict --minlen=8 --minquality=50 --nochanges --emptyok +pwpolicy user --strict --minlen=8 --minquality=50 --nochanges --emptyok +pwpolicy luks --strict --minlen=8 --minquality=50 --nochanges --emptyok It should instead not pass minquality or len, but let libpwquality handle those. If the password is unacceptable to libpwquality, it will return an exception, which should be if at all possible passed on to the user. The user should be able to override the exception and use the poor password if they wish, but they should be informed that the password is poor, etc. Optional changes: Show 'score' as a analog meter (low, medium, high) show password feedback after the first entry field is filled in (but of course they still have to match in the second one before they can be done). I'm happy to take any changes or concerns or clarifications back to fesco if needed, just let me know if thats desired. Additionally, anyone who doesn't care for this policy should also likewise take it up with FESCo, not you folks.
*** Bug 1230293 has been marked as a duplicate of this bug. ***
*** Bug 1253204 has been marked as a duplicate of this bug. ***
*** Bug 1254620 has been marked as a duplicate of this bug. ***
I do not get why a person who installs the operating system is forced to use strong passwords? On many occasions it doesn't really matter how strong or weak password is - it does not matter on my VM, which I am using for testing. It does not matter on my desktop computer at home, where I disable password anyway. This is bad for user experience and is a huge annoyance.
You realize you can just not use a password, right? There's a checkbox for it!
I didn't see any check box there and I don't think there's a check box for root user either. I just want to use a weak easy to remember password for my desktop computer at home. I don't need Military level security / protection there.
There is indeed no checkbox for a root nonpassword account. So the only way to create a low-security VM seems to be in Anaconda create a passwordless nonroot account with admin privs, then *later* set a root password and a password on this account. I raised 1253204 about this and it was closed as a dup of this bug, which at the very least misses the point (and possibly is plain mendacious). I don't care what FESCo thinks, you have made my life difficult my making unwarranted assumptions about my needs any my environment. It's a bug.
> I raised 1253204 about this and it was closed as a dup of this bug, which at > the very least misses the point (and possibly is plain mendacious). ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This needs to stop, and it needs to stop right now. First, you need to read the Fedora code of conduct (https://getfedora.org/code-of-conduct). Second, you need to consider that simply from a selfish standpoint, saying things like that does not motivate people to work on things for you. It in fact does the opposite. It makes us far less likely to do much of anything for you in the future.
(In reply to Chris Lumens from comment #8) > This needs to stop, and it needs to stop right now. First, you need to read > the Fedora code of conduct (https://getfedora.org/code-of-conduct). Second, > you need to consider that simply from a selfish standpoint, saying things > like that does not motivate people to work on things for you. It in fact > does the opposite. It makes us far less likely to do much of anything for > you in the future. I think the problem is spreading from the Gnome Developers - some time ago they have decided not to listen to their users. They've started the trend "we are gods and we know what's best for users" - this has created unnecessary frustration among community. Take a Gnome Shell thingy - I would love to use it on a tablet, but it not working for me on a desktop. I've tried to voice my frustration, but no one would listen and the only response I would get was "go away and use something else". This approach is bad for community - I was happy to contribute to Fedora, but I stopped. I stopped because of developer's arrogance. I've stopped because my bug reports were ignored. Btw: it's good that Fedora now has a Code of Conduct, I find it a little bit funny that now Fedora devs are using Code of Conduct to protect themselves from users and their criticism. Back on topic - requiring users to set strong and meaningful password *during* the installation is a really bad idea. Enforcing strong passwords should not be systems responsibility - in most cases strong passwords are unnecessary annoyance and obstruction. If users care about their security, they will set their password strong - in most cases it's not required/necessary.
(In reply to markm from comment #9) ...snip... > Btw: it's good that Fedora now has a Code of Conduct, I find it a > little bit funny that now Fedora devs are using Code of Conduct to protect > themselves from users and their criticism. Criticism is fine, but criticize the plan or policy, not people. Do not make personal attacks or assume some sinister motives to people disagreeing with you. > Back on topic - requiring users to set strong and meaningful password > *during* the installation is a really bad idea. Enforcing strong passwords > should not be systems responsibility - in most cases strong passwords are > unnecessary annoyance and obstruction. If users care about their security, > they will set their password strong - in most cases it's not > required/necessary. Did you read this bug and the FESCo policy? "The user should be able to override the exception and use the poor password if they wish" Additionally, if you have issues with the FESCo policy, please direct them to FESCo.
Kevin, This may have come up before, but for the sake of a reminder and having it documented here: would it be acceptable if these pwpolicy changes were carried by the fedora-productimg-* packages? These packages already modify the stylesheet and installclass settings provided by anaconda, and they seem to me like a good place to add Fedora-specific settings such as this. One issue I foresee is that interactive-defaults.ks contains more than just pwpolicy information, and to carry interactive-defaults.ks in the productimg packages would mean also carrying irrelevant settings and possibly diverging from anaconda in the future. To address that, I could add a setting to the installclass to specify the default kickstart file, similar to how the stylesheet is handled now, and then the productimg kickstart file could look something like: %include /usr/share/anaconda/interactive-defaults.ks %anaconda new pwpolicy stuff %end How does that sound? If it's too late for F23, would that be acceptable for F24?
I'm not sure I understand, so forgive me for asking this, but by "these pwpolicy changes" you mean the default policy? Or the way to overide that default policy? We really prefer to have the default itself be in libpwquality so we have just one place to change things if we need to instead of it being multiple places. Does that make sense? or is there some non libpwquality settings that may need to be adjusted on a per image basis?
I just mean the changes you laid out in the first comment. If the productimg packages were to install kickstarts overriding interactive-defaults.ks that included: %anaconda pwpolicy root --nochanges --emptyok pwpolicy user --nochanges --emptyok pwpolicy luks --nochanges --emptyok %end that would configure anaconda as desired, and it would mean that, since --minlen and --minquality are removed, that the length and quality settings are entirely dictated by pwquality, and changes in the length and quality settings can happen in one place: pwquality. The problem I have is the problem that caused this whole issue in the first place: removing --strict to restore the double-done weak password behavior. This behavior is not something controlled by pwquality, but rather a change that you are asking for in the behavior of anaconda itself. Simply put, this is a Fedora configuration, and anaconda upstream is not Fedora. We've provided the tools to configure this behavior in Fedora, and I'm willing to make more changes to make that configuration integrate more smoothly with the upstream configuration, but I do not think that the configuration change itself should be upstream. But again, if time is a concern for 23 the change can go on the branch for 23, like it did for 22, and the rest can be worked out for 24.
(In reply to David Shea from comment #13) > I just mean the changes you laid out in the first comment. If the productimg > packages were to install kickstarts overriding interactive-defaults.ks that > included: > OK, so I think I see where the confusion lies here. interactive-defaults.ks actually affects two different things. 1. It can override the default libpwquality settings 2. It enables or disables the --strict/--non-strict option Kevin was (I think) confused because he thought you were asking for libpwquality settings to not be added to interactive-defaults.ks, which you are not. Presumably, you will just inherit the defaults for this value from the library and not override them. The remaining issue then is that the policy as agreed-upon by FESCo includes the phrase "The user should be able to override the exception and use the poor password if they wish". The way this is implemented is by having the the pwpolicy lines include --non-strict. David is asking whether they could retain --strict (the upstream default) in the Fedora package's interactive-defaults.ks and instead have the individual product install media override this to use --non-strict in the fedora-productimg-$EDITION packages (which already make certain branding changes to Anaconda). So, assuming I have properly described the problem... here is my response: The productimg packages are only viable for making changes to Edition-branded media. In at least their current incarnation, they cannot affect any live media produced in a non-product manner (such as for KDE or any of the other spins). These spins currently will only inherit the interactive-defaults.ks as shipped by Anaconda. Thus, it is far easier to set a global "Fedora" default in that one single place. The alternative would be to submit and manage additional fedora-productimg-$SPIN packages that override this value for each and every Spin in the distribution (or just have a fedora-productimg-nonproduct one that all Spins must include). This is non-trivial and would add an easily-forgotten step to Spin creation. So I'd prefer that we not do this. I realize that part of the concern here is because Anaconda maintains its Fedora specfile upstream and synchronizes it when doing releases, which means that it becomes a bit more difficult to maintain a different set of upstream defaults from downstream ones. However, would it be possible to simply carry a patchfile in a contrib directory and adjust the upstream specfile such that application of that patch would occur if we're running on 'if %{?fedora}>=23'? Could that serve as a reasonable workaround?
The idea of a contrib patches directory sounds like more trouble than it's worth, so just pushed the pwpolicy change.
python-blivet-1.12.2-1.fc23 anaconda-23.19.2-1.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-15030
anaconda-23.19.2-1.fc23, python-blivet-1.12.2-1.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.\nIf you want to test the update, you can install it with \n su -c 'yum --enablerepo=updates-testing update anaconda python-blivet'. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-15030
(In reply to Kevin Fenzi from comment #10) > Did you read this bug and the FESCo policy? > "The user should be able to override the exception and use the poor password > if they wish" Excuse my ignorance, but how do I allow weak passwords during the installation process in anaconda? it forces me to set a strong password. That's a bug to me. > Additionally, if you have issues with the FESCo policy, please direct them > to FESCo. I've found a bug, I reported it here. Requesting user to set a strong password during the installation is a bug to me. How/where do I complain about FESCo policy?
anaconda-23.19.2-1.fc23, python-blivet-1.12.2-1.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to markm from comment #18) > (In reply to Kevin Fenzi from comment #10) > > Did you read this bug and the FESCo policy? > > "The user should be able to override the exception and use the poor password > > if they wish" > > Excuse my ignorance, but how do I allow weak passwords during the > installation process in anaconda? it forces me to set a strong password. > That's a bug to me. When did you test. If you will note, these changes only just now pushed to stable, so only after today will they be in live media. Yes, it's a bug... this very bug in fact. ;) Please test with tomorrow's media. > > > Additionally, if you have issues with the FESCo policy, please direct them > > to FESCo. > > I've found a bug, I reported it here. Requesting user to set a strong > password during the installation is a bug to me. How/where do I complain > about FESCo policy? https://fedorahosted.org/fesco/ But you were not actually testing anything that was following the policy at the time... so please retest.
(In reply to Kevin Fenzi from comment #20) > (In reply to markm from comment #18) > > (In reply to Kevin Fenzi from comment #10) > > > Did you read this bug and the FESCo policy? > > > "The user should be able to override the exception and use the poor password > > > if they wish" > > > > Excuse my ignorance, but how do I allow weak passwords during the > > installation process in anaconda? it forces me to set a strong password. > > That's a bug to me. > > When did you test. If you will note, these changes only just now pushed to > stable, so only after today will they be in live media. Yes, it's a bug... > this very bug in fact. ;) I did test Alpha release, to test this I will probably need to wait for Beta release, right? > Please test with tomorrow's media. > > > > > Additionally, if you have issues with the FESCo policy, please direct them > > > to FESCo. > > > > I've found a bug, I reported it here. Requesting user to set a strong > > password during the installation is a bug to me. How/where do I complain > > about FESCo policy? > > https://fedorahosted.org/fesco/ > > But you were not actually testing anything that was following the policy at > the time... so please retest. I will, thanks.
*** Bug 1263025 has been marked as a duplicate of this bug. ***