This Friday's build of Anaconda will no longer allow you to use weak passwords and click done twice. In order to promote more secureish default systems I have increased the password length required to 8 characters and removed allowing weak (as defined by libpwquality) passwords.
I *know* this is going to be a bit of a pain to get used to. But the increased security is worth it. Super simple passwords will no longer be allowed, but it is still easy to come up with one that passes the checks. pwgen has lots of suggestions.
And on the bright side, you don't have to click done twice anymore :)
On Wed, Jan 28, 2015 at 08:53:42 -0800, "Brian C. Lane" bcl@redhat.com wrote:
I *know* this is going to be a bit of a pain to get used to. But the increased security is worth it. Super simple passwords will no longer be allowed, but it is still easy to come up with one that passes the checks. pwgen has lots of suggestions.
As I mentioned in a related tgread, for people who need to do this a lot, a yubikey might be helpful.
Super simple passwords will no longer be allowed... increased security is worth it.
No, you just made installation more bothersome - the user will then have to set the passwords he wants after installation is complete. It is good to warn about a weak password, but I feel I know better than you the environment in which the machine I install will run. What you think is good I might feel is inadequate, or what you think is poor might be just fine for my purpose.
On Wed, Jan 28, 2015 at 5:53 PM, Brian C. Lane bcl@redhat.com wrote:
I *know* this is going to be a bit of a pain to get used to. But the increased security is worth it.
Depends ... if you force user to choose a password that they can't possibly remember you increase the likelihood of them just writing it on a piece of paper (and in the worst case have it near the computer).
drago01 <drago01 <at> gmail.com> writes:
On Wed, Jan 28, 2015 at 5:53 PM, Brian C. Lane <bcl <at> redhat.com> wrote:
I *know* this is going to be a bit of a pain to get used to. But the increased security is worth it.
Depends ... if you force user to choose a password that they can't possibly remember you increase the likelihood of them just writing it on a piece of paper (and in the worst case have it near the computer).
One could use the passwd command to change the password after the install (assuming the passwd command won't require strong passwords as well). There is the danger that since the definition of "weak" will change, one might be doing an install and suddenly find that one's password is now considered weak, and have to make up a new one on the spot. If they don't write it down, they could forget it after the install, and be locked out. I was also wondering about ways to get around the password - for example if the disk isn't encrypted, or there's no bootloader password. Wouldn't anaconda need to enforce some of that as well, to be consistent?
On Wed, Jan 28, 2015 at 22:20:54 +0000, Andre Robatino robatino@fedoraproject.org wrote:
down, they could forget it after the install, and be locked out. I was also wondering about ways to get around the password - for example if the disk isn't encrypted, or there's no bootloader password. Wouldn't anaconda need to enforce some of that as well, to be consistent?
That depends on the threat model they are attemping to defend against. It may be that attacks requiring physical access are out of scope for their model.
On 01/28/2015 05:20 PM, Andre Robatino wrote:
One could use the passwd command to change the password after the install (assuming the passwd command won't require strong passwords as well). There
Only root can force passwd to allow weak passwords unless you change the pam config files. You can't even disable the password strength checking with the authentication config tool...
On Wed, Jan 28, 2015 at 9:53 AM, Brian C. Lane bcl@redhat.com wrote:
I *know* this is going to be a bit of a pain to get used to. But the increased security is worth it. Super simple passwords will no longer be allowed, but it is still easy to come up with one that passes the checks. pwgen has lots of suggestions.
It's not worth it. It's a PITA. It's security theater. Windows, OS X, Android, iOS - none of these require strong passwords, and the last two don't even require passwords at all. The new password requirement merely exposes the fact we're deficient in other areas of system security, and we're masking that with this insulting baby sitting nonsense.
Instead of coercion, it's more polite to call the user names (stupid, idiot, moron, imbecile, etc) if they choose weak passwords. Name calling is kinder, more convenient, and honest and capitulation is optional. This password policy is complete utter bullcrap. This doesn't happen on any other OS I use and it pisses me off that Fedora is deciding to do this exactly wrong. It's really that offensive.
On Wed, 2015-01-28 at 16:05 -0700, Chris Murphy wrote:
On Wed, Jan 28, 2015 at 9:53 AM, Brian C. Lane bcl@redhat.com wrote:
I *know* this is going to be a bit of a pain to get used to. But the increased security is worth it. Super simple passwords will no longer be allowed, but it is still easy to come up with one that passes the checks. pwgen has lots of suggestions.
It's not worth it. It's a PITA. It's security theater. Windows, OS X, Android, iOS - none of these require strong passwords, and the last two don't even require passwords at all. The new password requirement merely exposes the fact we're deficient in other areas of system security, and we're masking that with this insulting baby sitting nonsense.
Instead of coercion, it's more polite to call the user names (stupid, idiot, moron, imbecile, etc) if they choose weak passwords. Name calling is kinder, more convenient, and honest and capitulation is optional. This password policy is complete utter bullcrap. This doesn't happen on any other OS I use and it pisses me off that Fedora is deciding to do this exactly wrong. It's really that offensive.
Note that just last release, I managed to get g-i-s changed to allow 'weak' passwords with a warning, in order to be consistent with anaconda and initial-setup...so now it'll have to get changed back again.
https://bugzilla.gnome.org/show_bug.cgi?id=735578
On Wed, Jan 28, 2015 at 4:17 PM, Adam Williamson adamwill@fedoraproject.org wrote:
Note that just last release, I managed to get g-i-s changed to allow 'weak' passwords with a warning, in order to be consistent with anaconda and initial-setup...so now it'll have to get changed back again.
I thought of this. And I'm also wondering if this babysitting horse manure policy is going to be equally enforced across all products? And will it be enforced in kickstart? I don't see how that's possible but I want to know if this is a Fedora wide policy, or if it's basically just picking on GUI installations?
Chris Murphy composed on 2015-01-28 16:05 (UTC-0700):
Brian C. Lane wrote:
I *know* this is going to be a bit of a pain to get used to. But the
Much more than just "a bit" on a maintainer of multi multiboot systems. If this actually makes it in and stays through F22 release, it'll be yet another reason not to test future Anacondas (it still steams me that target / *must* be formatted by Anaconda), and yet another reason to upgrade an existing instead of installing fresh.
increased security is worth it. Super simple passwords will no longer be allowed, but it is still easy to come up with one that passes the checks.
Not so easy for one that is easy enough to both remember and type repeatedly while testing.
pwgen has lots of suggestions.
It's not worth it. It's a PITA. It's security theater. Windows, OS X, Android, iOS - none of these require strong passwords, and the last two don't even require passwords at all. The new password requirement merely exposes the fact we're deficient in other areas of system security, and we're masking that with this insulting baby sitting nonsense.
+ + + + +
Instead of coercion, it's more polite to call the user names (stupid, idiot, moron, imbecile, etc) if they choose weak passwords. Name calling is kinder, more convenient, and honest and capitulation is optional. This password policy is complete utter bullcrap. This doesn't happen on any other OS I use and it pisses me off that Fedora is deciding to do this exactly wrong. It's really that offensive.
+ + + + +
On Qua, 2015-01-28 at 16:05 -0700, Chris Murphy wrote:
On Wed, Jan 28, 2015 at 9:53 AM, Brian C. Lane bcl@redhat.com wrote:
I *know* this is going to be a bit of a pain to get used to. But the increased security is worth it. Super simple passwords will no longer be allowed, but it is still easy to come up with one that passes the checks. pwgen has lots of suggestions.
It's not worth it. It's a PITA. It's security theater. Windows, OS X, Android, iOS - none of these require strong passwords, and the last two don't even require passwords at all. The new password requirement merely exposes the fact we're deficient in other areas of system security, and we're masking that with this insulting baby sitting nonsense.
Instead of coercion, it's more polite to call the user names (stupid, idiot, moron, imbecile, etc) if they choose weak passwords. Name calling is kinder, more convenient, and honest and capitulation is optional. This password policy is complete utter bullcrap. This doesn't happen on any other OS I use and it pisses me off that Fedora is deciding to do this exactly wrong. It's really that offensive.
+1 , I'm against enforce 'good' passwords , it is pretty clear, double click if you want have an insecure password and system .
-- Chris Murphy
On Thu, Jan 29, 2015 at 12:56:56AM +0000, Sérgio Basto wrote:
+1 , I'm against enforce 'good' passwords , it is pretty clear, double click if you want have an insecure password and system .
+1, enforcing will create lots of frustrations for people often creating internal test systems, etc. A very, very bad idea...
On Thu, Jan 29, 2015 at 01:37:39PM +0100, Jos Vos wrote:
On Thu, Jan 29, 2015 at 12:56:56AM +0000, Sérgio Basto wrote:
+1 , I'm against enforce 'good' passwords , it is pretty clear, double click if you want have an insecure password and system .
+1, enforcing will create lots of frustrations for people often creating internal test systems, etc. A very, very bad idea...
OK, I think there's been a great many emails saying this is a bad idea and none that I've seen, at least, saying it's a good one. Is there a bug filed, or a place to voice opinion? I think this should also be mentioned on Fedora forums so that the people who actually USE the thing should have a voice
On 01/29/2015 06:30 PM, Scott Robbins wrote:
On Thu, Jan 29, 2015 at 01:37:39PM +0100, Jos Vos wrote:
On Thu, Jan 29, 2015 at 12:56:56AM +0000, Sérgio Basto wrote:
+1 , I'm against enforce 'good' passwords , it is pretty clear, double click if you want have an insecure password and system .
+1, enforcing will create lots of frustrations for people often creating internal test systems, etc. A very, very bad idea...
OK, I think there's been a great many emails saying this is a bad idea and none that I've seen, at least, saying it's a good one. Is there a bug filed, or a place to voice opinion?
This can not be filed as bug, as it is not a faulty behavior. It should be filed an RFE.
Thanks, Amita
I think this should also be mentioned on Fedora forums so that the people who actually USE the thing should have a voice
A ticket has been opened with FESCo.
https://fedorahosted.org/fesco/ticket/1412
On Wed, Jan 28, 2015 at 04:05:55PM -0700, Chris Murphy wrote:
On Wed, Jan 28, 2015 at 9:53 AM, Brian C. Lane bcl@redhat.com wrote:
I *know* this is going to be a bit of a pain to get used to. But the increased security is worth it. Super simple passwords will no longer be allowed, but it is still easy to come up with one that passes the checks. pwgen has lots of suggestions.
Oh for goodness' sakes. It's going to do nothing but make it more of a nuisance. The old adage was that Unix doesn't stop you from doing stupid things because it would also stop you from doing clever things. You already have the weak password thing, confirm you're doing it.
Instead of coercion, it's more polite to call the user names (stupid, idiot, moron, imbecile, etc) if they choose weak passwords. Name calling is kinder, more convenient, and honest and capitulation is optional. This password policy is complete utter bullcrap. This doesn't happen on any other OS I use and it pisses me off that Fedora is deciding to do this exactly wrong. It's really that offensive.
Agreed. Seriously, who do you think really uses this? Generally, if they are completely inexperienced, they use Ubuntu or Mint.
I understand the need, or at least want, to appeal to all manner of users, but this seems to really be overdoing it.
On 01/29/15 00:53, Brian C. Lane wrote:
This Friday's build of Anaconda will no longer allow you to use weak passwords and click done twice. In order to promote more secureish default systems I have increased the password length required to 8 characters and removed allowing weak (as defined by libpwquality) passwords.
I *know* this is going to be a bit of a pain to get used to. But the increased security is worth it. Super simple passwords will no longer be allowed, but it is still easy to come up with one that passes the checks. pwgen has lots of suggestions.
And on the bright side, you don't have to click done twice anymore :)
You use the pronoun "I" in your message. Can we, the community, know if it was a unilateral decision or if it was discussed with others? If it was discussed with others is there a record of the discussion so we can know the arguments presented?
On Thu, 2015-01-29 at 07:41 +0800, Ed Greshko wrote:
On 01/29/15 00:53, Brian C. Lane wrote:
This Friday's build of Anaconda will no longer allow you to use weak passwords and click done twice. In order to promote more secureish default systems I have increased the password length required to 8 characters and removed allowing weak (as defined by libpwquality) passwords.
I *know* this is going to be a bit of a pain to get used to. But the increased security is worth it. Super simple passwords will no longer be allowed, but it is still easy to come up with one that passes the checks. pwgen has lots of suggestions.
And on the bright side, you don't have to click done twice anymore :)
You use the pronoun "I" in your message. Can we, the community, know if it was a unilateral decision or if it was discussed with others? If it was discussed with others is there a record of the discussion so we can know the arguments presented?
It was done as a follow-up / alternative to this Change proposal:
https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
a lot of the reaction to that was along the lines of 'well, why not just make sure the root password is secure', and that got picked up by anaconda folks. You can follow the discussion in the devel@ and anaconda-devel-list archives.
On 01/28/2015 06:54 PM, Adam Williamson wrote:
a lot of the reaction to that was along the lines of 'well, why not just make sure the root password is secure', and that got picked up by anaconda folks. You can follow the discussion in the devel@ and anaconda-devel-list archives.
Is it just the root password (not really ok) or the user passwords as well (really not ok)?
On Wed, 2015-01-28 at 19:29 -0500, Samuel Sieb wrote:
On 01/28/2015 06:54 PM, Adam Williamson wrote:
a lot of the reaction to that was along the lines of 'well, why not just make sure the root password is secure', and that got picked up by anaconda folks. You can follow the discussion in the devel@ and anaconda-devel-list archives.
Is it just the root password (not really ok) or the user passwords as well (really not ok)?
If I read the patches correctly, it's both, plus the passphrase for encrypted disks if you do that.
On 01/28/2015 06:54 PM, Adam Williamson wrote:
It was done as a follow-up / alternative to this Change proposal:
https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
a lot of the reaction to that was along the lines of 'well, why not just make sure the root password is secure', and that got picked up by anaconda folks. You can follow the discussion in the devel@ and anaconda-devel-list archives.
I just don't understand the reasoning here. Sure, make it very clear that the chosen password is weak. Make me jump through several hoops before accepting the weak password. But it's my computer! Why can't I make the (informed) choice to use a weak password?
On Wed, 2015-01-28 at 19:33 -0500, Samuel Sieb wrote:
On 01/28/2015 06:54 PM, Adam Williamson wrote:
It was done as a follow-up / alternative to this Change proposal:
https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
a lot of the reaction to that was along the lines of 'well, why not just make sure the root password is secure', and that got picked up by anaconda folks. You can follow the discussion in the devel@ and anaconda-devel-list archives.
I just don't understand the reasoning here.
Your understanding is no longer required. It is the new alien thinking that goes with the alien tech. Developers make the rules, users use the system as it is given unto them and are happy; because developers know things and stuff and users are idiots who must be protected from their idiocy. In times past a Linux installer was written with the notion that the person on the other end was another knowledgeable person, a peer, thus they were assumed to know what they were doing. A scratch install doesn't really need a strong password or whatever. Warn about unwise actions if developer time permits, otherwise let em get on with it.
The same mindset was on exhibit last week with the discussion of forced formatting of partitions. The whole notion of any action not explicitly planned for and whitelisted is forbidden. Who cares if an admin has a good (if unusual) reason for wanting to do something, admins are obsolete now; now there are developers and users and Linux must shed the UNIX legacy that holds it back and become Chrome or Android.... or maybe it is OS X this week, who cares anymore. The pain threshold for reinstall isn't there yet I have probably made my last fresh Fedora install.
On Wed, 2015-01-28 at 19:23 -0600, John Morris wrote:
On Wed, 2015-01-28 at 19:33 -0500, Samuel Sieb wrote:
On 01/28/2015 06:54 PM, Adam Williamson wrote:
It was done as a follow-up / alternative to this Change proposal:
https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
a lot of the reaction to that was along the lines of 'well, why not just make sure the root password is secure', and that got picked up by anaconda folks. You can follow the discussion in the devel@ and anaconda-devel-list archives.
I just don't understand the reasoning here.
Your understanding is no longer required. It is the new alien thinking that goes with the alien tech.
(snip)
This is clearly against the Fedora code of conduct's requirement that Fedora community members be awesome to one another. It is perfectly fine to question design decisions, but it is *not* OK to impute nasty motives to those decisions without any evidence. Please exercise some restraint and discuss decisions based on the facts, not based on imagined motivations.
On Wed, Jan 28, 2015 at 5:33 PM, Samuel Sieb samuel@sieb.net wrote:
I just don't understand the reasoning here. Sure, make it very clear that the chosen password is weak. Make me jump through several hoops before accepting the weak password. But it's my computer! Why can't I make the (informed) choice to use a weak password?
What was the reasoning from the Anaconda team the last time they tried to enforce a password policy change without consulting anyone else about it? It was conjecture. And they didn't ask any security experts about the idea in advance then either. Calm, rational criticism was met with stubborn condescension from the developers. It took a firestorm on devel@ to get them to change their mind.
And this time, once again several people have offered calm, rational feedback (on anaconda-devel@) about how this doesn't improve security in any meaningful way, but does inhibit testing in a meaningful way. But this has been ignored and summarily rejected. While consistent with the track record, it's beyond tedious that anaconda devs tend to respond better to vinegar than honey.
So, I'm not sure why you'd expect any kind of reasoning to be presented for yet another installer security mis-feature that's completely orthogonal to the original sshd proposal.
If this is really an improvement in security, which it isn't because an 8 character "good" password still has very low entropy, then it should have to go through the feature process, which it hasn't. Such enforcement doesn't happen on Ubuntu, openSUSE, Android, iOS, Windows, or OS X and I think the anaconda developers need to be very clear what problem they're trying to address. Because right now it's a faux-solution in search of a problem.
On Thu, 2015-01-29 at 14:01 -0700, Chris Murphy wrote:
On Wed, Jan 28, 2015 at 5:33 PM, Samuel Sieb samuel@sieb.net wrote:
I just don't understand the reasoning here. Sure, make it very clear that the chosen password is weak. Make me jump through several hoops before accepting the weak password. But it's my computer! Why can't I make the (informed) choice to use a weak password?
What was the reasoning from the Anaconda team the last time they tried to enforce a password policy change without consulting anyone else about it? It was conjecture. And they didn't ask any security experts about the idea in advance then either. Calm, rational criticism was met with stubborn condescension from the developers. It took a firestorm on devel@ to get them to change their mind.
And this time, once again several people have offered calm, rational feedback (on anaconda-devel@) about how this doesn't improve security in any meaningful way, but does inhibit testing in a meaningful way. But this has been ignored and summarily rejected. While consistent with the track record, it's beyond tedious that anaconda devs tend to respond better to vinegar than honey.
So, I'm not sure why you'd expect any kind of reasoning to be presented for yet another installer security mis-feature that's completely orthogonal to the original sshd proposal.
Seriously. Stop this. I have already asked people to stop assigning negative motivations to others without due cause. This is not being excellent to each other. The next person to do this is going into moderation.
I have already explained that the change was made in response to extensive discussion of a proposed Fedora 22 Change:
https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no
it is not hard to follow this discussion. Just go read the devel@ archives:
https://lists.fedoraproject.org/pipermail/devel/2015-January/206157.html is the start of the thread https://lists.fedoraproject.org/pipermail/devel/2015-January/206513.html is an example of someone not at all involved in anaconda development proposing password strength enforcement
You were involved in that thread yourself, so you *know* this is not just coming from anaconda.
The anaconda-devel-list discussion couldn't really be clearer about the relationship to the Change proposal - the whole thread was kicked off by the Change owner:
https://www.redhat.com/archives/anaconda-devel-list/2015-January/msg00026.ht...
It is simply and clearly _false_ to claim that "the Anaconda team...tried to enforce a password policy change without consulting anyone else about it?", when the change was in fact discussed on two high-profile public project mailing lists, both threads which you *posted in yourself*.
You may not like the change, I don't like it much either, but it's not acceptable to cast entirely insupportable aspersions on the people making it.
On Thu, Jan 29, 2015 at 2:23 PM, Adam Williamson adamwill@fedoraproject.org wrote:
Seriously. Stop this. I have already asked people to stop assigning negative motivations to others without due cause. This is not being excellent to each other.
"Your user password for your computer is arbitrarily unacceptable to the Fedora Project" is not being excellent either.
The anaconda-devel-list discussion couldn't really be clearer about the relationship to the Change proposal - the whole thread was kicked off by the Change owner:
https://www.redhat.com/archives/anaconda-devel-list/2015-January/msg00026.ht...
That change proposal was rejected, so how is it that one of its proposed changes has managed to make it through to the installer barely two weeks later?
The substantive discussion on devel@ was centered on the sshd portion, not changes to the installer enabling password quality enforcement. That happened on anaconda-devel@ which most Fedora users don't even monitor let alone participate. The main notice of this change actually occurring happened for the first time in test@ which arguably most users also don't monitor.
It is simply and clearly _false_ to claim that "the Anaconda team...tried to enforce a password policy change without consulting anyone else about it?", when the change was in fact discussed on two high-profile public project mailing lists, both threads which you *posted in yourself*.
I was mostly referring to the last time a password change materialized without conversation, but I accept being 50% inaccurate on this.
On Thu, 2015-01-29 at 15:09 -0700, Chris Murphy wrote:
On Thu, Jan 29, 2015 at 2:23 PM, Adam Williamson < adamwill@fedoraproject.org> wrote:
Seriously. Stop this. I have already asked people to stop assigning negative motivations to others without due cause. This is not being excellent to each other.
"Your user password for your computer is arbitrarily unacceptable to the Fedora Project" is not being excellent either.
Come on, that's sophistry. You can't interpret code as a personal insult.
(It's not 'arbitrary', anyway. It's using a well-known and widely-used password quality library.)
The anaconda-devel-list discussion couldn't really be clearer about the relationship to the Change proposal - the whole thread was kicked off by the Change owner:
https://www.redhat.com/archives/anaconda-devel-list/2015-January/msg00026.ht...
That change proposal was rejected, so how is it that one of its proposed changes has managed to make it through to the installer barely two weeks later?
It's not actually something that is part of the Change's scope, but an alternative way to try and achieve the same goal: the overall thought process was "well, what the Change proposer really wants is to reduce the likelihood of compromise via password access to the root account, but no-one was particularly keen on the approach he proposed, so one different way to do it is to improve the strength of the root password". As bcl's mail explicitly says:
https://www.redhat.com/archives/anaconda-devel-list/2015-January/msg00030.ht...
The substantive discussion on devel@ was centered on the sshd portion, not changes to the installer enabling password quality enforcement. That happened on anaconda-devel@ which most Fedora users don't even monitor let alone participate. The main notice of this change actually occurring happened for the first time in test@ which arguably most users also don't monitor.
If someone's interested in Fedora development, they need to read the Fedora development mailing lists. *Any* code change is presumably of interest to someone, or it wouldn't be done in the first place; this is not a reason for us to go mailing users@ every time someone commits to anaconda.
You can argue that the change is significant enough to be a Change, I guess, though personally I don't think it really is, unless it affects kickstart installs (in which case people would be surprised at their kickstarts suddenly not working right any more - but I don't think it does). It's a bit hard to argue about, though, since one of the things the Change process appears to be missing is an actual definition of what should be considered to constitute a 'Change', exactly. It's thus impossible to declare conclusively that X or Y *must* be a Change, unless FESCo has stated it or something. You can suggest that it should be, but it's impossible to make a completely definitive declaration since there's literally no basis on which you could do that outside of a formal FESCo vote or something.
https://fedoraproject.org/wiki/Changes/Policy
On Thu, Jan 29, 2015 at 3:18 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2015-01-29 at 15:09 -0700, Chris Murphy wrote:
On Thu, Jan 29, 2015 at 2:23 PM, Adam Williamson < adamwill@fedoraproject.org> wrote:
Seriously. Stop this. I have already asked people to stop assigning negative motivations to others without due cause. This is not being excellent to each other.
"Your user password for your computer is arbitrarily unacceptable to the Fedora Project" is not being excellent either.
Come on, that's sophistry. You can't interpret code as a personal insult.
Sure I can. Code is copyrightable language owned by the author if not in property certainly in the consequences, just like any form of written communication. I don't actually know the motives of the Anaconda team, I'm only observing patterns that I think have lead and continue to lead to questionable outcomes.
The last time this happened Anaconda only considered (questionable) usability aspects without considering security aspects - that's what the blow up on devel@ entailed; and this time Anaconda considers the (questionable) security aspects without considering the usability aspects.
(It's not 'arbitrary', anyway. It's using a well-known and widely-used password quality library.)
The decision to enforce is what's arbitrary, not the tool being used to grade the password. If a password library library that arbitrarily pass/fails passwords, that would at least be funny.
The anaconda-devel-list discussion couldn't really be clearer about the relationship to the Change proposal - the whole thread was kicked off by the Change owner:
https://www.redhat.com/archives/anaconda-devel-list/2015-January/msg00026.ht...
That change proposal was rejected, so how is it that one of its proposed changes has managed to make it through to the installer barely two weeks later?
It's not actually something that is part of the Change's scope, but an alternative way to try and achieve the same goal: the overall thought process was "well, what the Change proposer really wants is to reduce the likelihood of compromise via password access to the root account, but no-one was particularly keen on the approach he proposed, so one different way to do it is to improve the strength of the root password". As bcl's mail explicitly says:
https://www.redhat.com/archives/anaconda-devel-list/2015-January/msg00030.ht...
That's not the point at all, which is, is it correct policy to activate a sub-change in a rejected change proposal? And is it prudent to dig heels in when there's been more negative feedback on that change presented on anaconda-devel@ and test@ than positive? I can't even find positive feedback except from the original change owner.
The substantive discussion on devel@ was centered on the sshd portion, not changes to the installer enabling password quality enforcement. That happened on anaconda-devel@ which most Fedora users don't even monitor let alone participate. The main notice of this change actually occurring happened for the first time in test@ which arguably most users also don't monitor.
If someone's interested in Fedora development, they need to read the Fedora development mailing lists. *Any* code change is presumably of interest to someone, or it wouldn't be done in the first place; this is not a reason for us to go mailing users@ every time someone commits to anaconda.
I'm suggesting instead of being presented only on test@, it should also have been presented on devel@.
You can argue that the change is significant enough to be a Change, I guess, though personally I don't think it really is, unless it affects kickstart installs (in which case people would be surprised at their kickstarts suddenly not working right any more - but I don't think it does). It's a bit hard to argue about, though, since one of the things the Change process appears to be missing is an actual definition of what should be considered to constitute a 'Change', exactly. It's thus impossible to declare conclusively that X or Y *must* be a Change, unless FESCo has stated it or something. You can suggest that it should be, but it's impossible to make a completely definitive declaration since there's literally no basis on which you could do that outside of a formal FESCo vote or something.
I was thinking of this one http://fedoraproject.org/wiki/Features/Policy/Definitions and I think certainly 1, and probably 5 apply, and though ill-conceived 3 could apply too seeing as thus far it's only Fedora going down this absurd road of negative efficacy.
On Thu, 2015-01-29 at 16:24 -0700, Chris Murphy wrote:
It's not actually something that is part of the Change's scope, but an alternative way to try and achieve the same goal: the overall thought process was "well, what the Change proposer really wants is to reduce the likelihood of compromise via password access to the root account, but no-one was particularly keen on the approach he proposed, so one different way to do it is to improve the strength of the root password". As bcl's mail explicitly says:
https://www.redhat.com/archives/anaconda-devel-list/2015-January/msg00030.ht...
That's not the point at all, which is, is it correct policy to activate a sub-change in a rejected change proposal?
It's *not* a sub-change in a rejected change proposal. It wasn't part of the rejected change proposal at all.
And is it prudent to dig heels in when there's been more negative feedback on that change presented on anaconda-devel@ and test@ than positive? I can't even find positive feedback except from the original change owner.
Um. Take a step back, relax, and look at the timeframe here.
bcl mailed the list *yesterday*. He hasn't posted back to the thread since. You should give someone a hell of a lot more than one day before you start talking about 'digging heels in'.
I was thinking of this one
that whole thing is obsolete, the Change process replaced the Feature process. Nothing with 'Feature' in its URL is current any more.
On Thu, Jan 29, 2015 at 4:32 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Thu, 2015-01-29 at 16:24 -0700, Chris Murphy wrote:
It's not actually something that is part of the Change's scope, but an alternative way to try and achieve the same goal: the overall thought process was "well, what the Change proposer really wants is to reduce the likelihood of compromise via password access to the root account, but no-one was particularly keen on the approach he proposed, so one different way to do it is to improve the strength of the root password". As bcl's mail explicitly says:
https://www.redhat.com/archives/anaconda-devel-list/2015-January/msg00030.ht...
That's not the point at all, which is, is it correct policy to activate a sub-change in a rejected change proposal?
It's *not* a sub-change in a rejected change proposal. It wasn't part of the rejected change proposal at all.
That'd seem to make it less appropriate of a change. However, what I'm drawing on from that proposal is:
Scope Proposal owners: to communicate with the Fedora maintainers of packages: Anaconda, OpenSSH, GNOME, etc. Other developers: packages like Anaconda, GNOME etc. need to update their workflow to enable compulsory non-root user account creation and ensure good password strength for it.
And is it prudent to dig heels in when there's been more negative feedback on that change presented on anaconda-devel@ and test@ than positive? I can't even find positive feedback except from the original change owner.
Um. Take a step back, relax, and look at the timeframe here.
bcl mailed the list *yesterday*. He hasn't posted back to the thread since. You should give someone a hell of a lot more than one day before you start talking about 'digging heels in'.
Um, you realize that correcthorse is disqualified even though it's more than 8 characters, right?
I was thinking of this one
that whole thing is obsolete, the Change process replaced the Feature process. Nothing with 'Feature' in its URL is current any more.
Is there a bit recycling program?
Once upon a time, Adam Williamson adamwill@fedoraproject.org said:
It's not actually something that is part of the Change's scope, but an alternative way to try and achieve the same goal: the overall thought process was "well, what the Change proposer really wants is to reduce the likelihood of compromise via password access to the root account,
So, why didn't this change have to go through a proposal? The original change was rejected (which should show there is disagreement about this), so such a change should not just be pushed without open discussion.
If there is disagreement about this change, is there no recourse? Or do anaconda devs get to determine system policy now on their own?
On Thu, 2015-01-29 at 19:55 -0600, Chris Adams wrote:
Once upon a time, Adam Williamson adamwill@fedoraproject.org said:
It's not actually something that is part of the Change's scope, but an alternative way to try and achieve the same goal: the overall thought process was "well, what the Change proposer really wants is to reduce the likelihood of compromise via password access to the root account,
So, why didn't this change have to go through a proposal? The original change was rejected (which should show there is disagreement about this), so such a change should not just be pushed without open discussion.
There's no policy (AFAIK) on what is and is not a Change. FESCo has the power to effectively declare something to be a Change (and thus subject to review and so forth) if it decides to do so, but there's nothing beyond that. And as I said to otherChris, 'without open discussion' is just plainly false. There's a ton of 'open discussion', spread across three mailing lists.
If there is disagreement about this change, is there no recourse? Or do anaconda devs get to determine system policy now on their own?
Eh, that seems like a pointlessly loaded question. I mean, in a sense, sure, they always have. They *write the installer*. That's always going to involve some degree of 'determining system policy', if you interpret that phrase broadly enough. What do you want, every anaconda commit to go through a committee review phase?
And 'recourse' seems like such a weird word that, again, I don't really know how to reply to it. You can discuss the decision, in a respectful fashion, here or on devel@ or on anaconda-devel-list@. You can take it up with FESCo. You could also, of course, wait more than one lousy day to give the devs a chance to reply before whipping up a storm of righteous indignation, but so often that seems too much to ask?
Adam Williamson composed on 2015-01-29 18:23 (UTC-0800):
You could also, of course, wait more than one lousy day to give the devs a chance to reply before whipping up a storm of righteous indignation, but so often that seems too much to ask?
I wonder if a point of Brian's OP was to gauge strength and swiftness of opposition?
I'm surely glad to have gotten a warning.
On Thu, Jan 29, 2015 at 7:23 PM, Adam Williamson adamwill@fedoraproject.org wrote:
And as I said to otherChris, 'without open discussion' is just plainly false. There's a ton of 'open discussion', spread across three mailing lists.
That's confused. On devel@ the discussion was about the original change feature. On anaconda-devel@ there was really no meaningful discussion, because there was no acknowledgement of dissenting opinions let alone addressing them with exactly why this is necessary on Fedora and apparently nowhere else. On test@, 100% of the discussion happened after we were informed of the change, which is in the very first sentence of the first email in this thread.
Ton no. Modicum perhaps.
You could also, of course, wait more than one lousy day to give the devs a chance to reply before whipping up a storm of righteous indignation, but so often that seems too much to ask?
You mean like the reply you got after suggesting a secret cmdline option to make this requirement go away while testing so that you don't go crazy? That was 13 days ago.
Once upon a time, Adam Williamson adamwill@fedoraproject.org said:
There's no policy (AFAIK) on what is and is not a Change. FESCo has the power to effectively declare something to be a Change (and thus subject to review and so forth) if it decides to do so, but there's nothing beyond that. And as I said to otherChris, 'without open discussion' is just plainly false. There's a ton of 'open discussion', spread across three mailing lists.
There was discussion about a different proposal on devel, apparently discussion about this change by anaconda devs, and then the announcement here that the change had been made (no discussion until after the fact, and all "discussion" about not liking the decision being largely met with a response of "too bad"). It is not reasonable to expect everybody interested in Fedora to subscribe to the anaconda developer list (which isn't even a Fedora list, but a Red Hat list); there are dozens of Fedora mailing lists, and the vast majority of people cannot keep up with all of them.
Eh, that seems like a pointlessly loaded question. I mean, in a sense, sure, they always have. They *write the installer*. That's always going to involve some degree of 'determining system policy', if you interpret that phrase broadly enough. What do you want, every anaconda commit to go through a committee review phase?
Hyperbole much? The majority of anaconda commits don't make significant changes to installed system policy. When they do, they tend to be discussed (not just announced) on other lists. For example, see the recent thread about /boot and /var and mkfs. Somebody _asked_ if that would be a big deal, people spoke up, and the input was accepted and the change modified.
And 'recourse' seems like such a weird word that, again, I don't really know how to reply to it. You can discuss the decision, in a respectful fashion, here or on devel@ or on anaconda-devel-list at . You can take it up with FESCo. You could also, of course, wait more than one lousy day to give the devs a chance to reply before whipping up a storm of righteous indignation, but so often that seems too much to ask?
Again, "be excellent to each other"?
This change was _announced_ here, not discussed (and some responses make it sound like it is not open to discussion). There was no real justification for the change in the announcement, except for a vague "better security" bit. That will almost always cause a negative response from people that disagree.
On Fri, 2015-01-30 at 08:05 -0600, Chris Adams wrote:
This change was _announced_ here, not discussed (and some responses make it sound like it is not open to discussion). There was no real justification for the change in the announcement, except for a vague "better security" bit. That will almost always cause a negative response from people that disagree.
Things can be discussed after they're announced. That's what we're doing now. F22 won't be released for another four months.
Chris Murphy <lists <at> colorremedies.com> writes:
If this is really an improvement in security, which it isn't because an 8 character "good" password still has very low entropy, then it
It depends - if the only concern is remote access, and there is a limit on the number of login attempts (either by number or rate, or both), and the attacker doesn't know the password hash, even 8 characters is pretty strong. And if local access is a concern, then anaconda should take other measures (requiring disk encryption or a bootloader password?) as well, to be consistent. (Personally I agree with you, as long as the user is informed that the password is weak, at that point they should be allowed to use it if they want.)
On Wednesday, January 28, 2015 08:53:42 AM Brian C. Lane wrote:
This Friday's build of Anaconda will no longer allow you to use weak passwords and click done twice. In order to promote more secureish default systems I have increased the password length required to 8 characters and removed allowing weak (as defined by libpwquality) passwords.
What if security is not a concern for you?
What are your suggestions for folks who create a lot of VMs, use them specific cases, where password protection is merely an annoyance, and then throw them away?
On 01/29/2015 05:59 PM, Sudhir Khanger wrote:
On Wednesday, January 28, 2015 08:53:42 AM Brian C. Lane wrote:
This Friday's build of Anaconda will no longer allow you to use weak passwords and click done twice. In order to promote more secureish default systems I have increased the password length required to 8 characters and removed allowing weak (as defined by libpwquality) passwords.
What if security is not a concern for you?
yeah, it will be an issue for people who are doing a lot of testing in this way ( creating, testing, tearing off VMs)
- Amita
What are your suggestions for folks who create a lot of VMs, use them specific cases, where password protection is merely an annoyance, and then throw them away?
On 01/29/2015 06:29 AM, Sudhir Khanger wrote:
On Wednesday, January 28, 2015 08:53:42 AM Brian C. Lane wrote:
This Friday's build of Anaconda will no longer allow you to use weak passwords and click done twice. In order to promote more secureish default systems I have increased the password length required to 8 characters and removed allowing weak (as defined by libpwquality) passwords.
What if security is not a concern for you?
What are your suggestions for folks who create a lot of VMs, use them specific cases, where password protection is merely an annoyance, and then throw them away?
Pick a single "strong" password that you can remember and use it for all of them. Pretty easy, really.
On 01/30/2015 01:00 AM, David Lehman wrote:
On 01/29/2015 06:29 AM, Sudhir Khanger wrote:
On Wednesday, January 28, 2015 08:53:42 AM Brian C. Lane wrote:
This Friday's build of Anaconda will no longer allow you to use weak passwords and click done twice. In order to promote more secureish default systems I have increased the password length required to 8 characters and removed allowing weak (as defined by libpwquality) passwords.
What if security is not a concern for you?
What are your suggestions for folks who create a lot of VMs, use them specific cases, where password protection is merely an annoyance, and then throw them away?
Pick a single "strong" password that you can remember and use it for all of them. Pretty easy, really.
Using a pass-phrase is pretty good in circumstances where the password strength should be good, yet the password be easy to remember.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/29/2015 11:04 PM, Rejy M Cyriac wrote:
On 01/30/2015 01:00 AM, David Lehman wrote:
On 01/29/2015 06:29 AM, Sudhir Khanger wrote:
On Wednesday, January 28, 2015 08:53:42 AM Brian C. Lane wrote:
This Friday's build of Anaconda will no longer allow you to use weak passwords and click done twice. In order to promote more secureish default systems I have increased the password length required to 8 characters and removed allowing weak (as defined by libpwquality) passwords.
What if security is not a concern for you?
What are your suggestions for folks who create a lot of VMs, use them specific cases, where password protection is merely an annoyance, and then throw them away?
Pick a single "strong" password that you can remember and use it for all of them. Pretty easy, really.
Using a pass-phrase is pretty good in circumstances where the password strength should be good, yet the password be easy to remember.
Have we considered what this will do when used with fedup if anything? Or will the F21 "weak" password be grandfathered in?
Bob Lightfoot
- -- Sincerely, Bob Lightfoot "As iron sharpens iron, so one man sharpens another." Proverbs 27:17 {NIV/84}
On Thu, 2015-01-29 at 23:36 -0500, Bob Lightfoot wrote:
Have we considered what this will do when used with fedup if anything? Or will the F21 "weak" password be grandfathered in?
It's a change to the installer. It has nothing at all to do with fedup.
On Thursday, January 29, 2015 01:30:11 PM David Lehman wrote:
Pick a single "strong" password that you can remember and use it for all of them. Pretty easy, really.
It's not my memory but its my fingers. I will have to enter a long password over and over again for no real reasons.
On Fri, 30 Jan 2015 22:11:12 +0530 Sudhir Khanger ml@sudhirkhanger.com wrote:
On Thursday, January 29, 2015 01:30:11 PM David Lehman wrote:
Pick a single "strong" password that you can remember and use it for all of them. Pretty easy, really.
It's not my memory but its my fingers. I will have to enter a long password over and over again for no real reasons.
Well, thats not entirely true... the reason is so that all those people who actually use the thing you are testing have more secure passwords.
apg (along with many other things) can generate you a list of passwords and 'pwscore' can make sure they will pass the same tests anaconda would give them.
IMHO, this isn't so big a deal. I'll have to change my throw away instance test password from 'abc123' to something like 'tacosyum99' Shrug.
kevin
On Friday, January 30, 2015 09:54:00 AM Kevin Fenzi wrote:
IMHO, this isn't so big a deal. I'll have to change my throw away instance test password from 'abc123' to something like 'tacosyum99' Shrug.
I agree. It is surely not a big deal but the logic behind it is a little weak and paternalistic.
On Fri, Jan 30, 2015 at 9:54 AM, Kevin Fenzi kevin@scrye.com wrote:
On Fri, 30 Jan 2015 22:11:12 +0530 Sudhir Khanger ml@sudhirkhanger.com wrote:
On Thursday, January 29, 2015 01:30:11 PM David Lehman wrote:
Pick a single "strong" password that you can remember and use it for all of them. Pretty easy, really.
It's not my memory but its my fingers. I will have to enter a long password over and over again for no real reasons.
Well, thats not entirely true... the reason is so that all those people who actually use the thing you are testing have more secure passwords.
ATMs have rate and retry limits, among other mechanisms, to permit a 4 digit numeric PIN being adequately secure. Does Fedora have limits on rate and retries? If not, why not?
User who want or need more secure passwords can always opt in without affect anyone else. Why is the project's installer not merely questioning the user's veracity and competency, but disallowing them, by force, from doing what they think is in their best interest?
What is the plan should no one care to harden Fedora security in other ways? 16 character passwords are next? The diceware minimum recommended passphrase is made of 5 words. If the project cares so much about other people's minimum acceptable security that it's willing to enforce this under duress, why not make it actually meaningful? Oh, because a 20 character passphrase being compulsory might actually make too many users angry for suggesting their passwords are shit.
apg (along with many other things) can generate you a list of passwords and 'pwscore' can make sure they will pass the same tests anaconda would give them.
IMHO, this isn't so big a deal.
And apg and pwscore are going to be integrated into the Anaconda GUI? Or will the GUI simply be an enforcer while providing zero assistance in selecting an appropriate password? What feedback will the user be given so they understand what exact change in behavior they need to make?
Have you actually played with pwscore?
# pwscore root shrkobtk 1 # pwscore root tableprison 41 # pwscore root inforats Password quality check failed: The password fails the dictionary check - it is based on a dictionary word
This defies belief. Random scores lowest. Two dictionary words scores average. A dictionary word fragment and a plural noun is disqualified. Ridiculous.
I'll have to change my throw away instance test password from 'abc123' to something like 'tacosyum99' Shrug.
You fail to understand the can of worms opened up by this. My trust in Fedora is diminished because of the theatrics and indiscriminately shifting this burden onto all users. The arguments in favor thus far are demonstrably specious, so there must be some other explanation for why the change is being made.
How insecure is Fedora compared to other platforms, or even other distributions? Where's the assessment? Are successful brute force attacks being made on Fedora systems in the wild? And instead of those particular systems and use cases having stronger passwords, everyone needs to have them by force? And two more characters totalling maybe a scant 10 bits of additional entropy really has a meaningful change of thwarting those brute force attacks? What's the actual, real world, non-imaginary impetus behind the change?
I see hand waiving, and I see dog shit in a bag with sparklers on it. It looks impressive and useful, but inside it's just crap.
Just FYI, this will likely be my last post to this thread.
On Fri, 30 Jan 2015 12:59:12 -0700 Chris Murphy lists@colorremedies.com wrote:
ATMs have rate and retry limits, among other mechanisms, to permit a 4 digit numeric PIN being adequately secure. Does Fedora have limits on rate and retries? If not, why not?
I think there are in ssh. I don't know the details.
User who want or need more secure passwords can always opt in without affect anyone else. Why is the project's installer not merely questioning the user's veracity and competency, but disallowing them, by force, from doing what they think is in their best interest?
Because you cannot just say "This is some decision, I know whatever I do will have good and bad tradeoffs, therefore, I will just not decide and expose all the possible choices to the user". Thats just not tenable.
What is the plan should no one care to harden Fedora security in other ways? 16 character passwords are next? The diceware minimum recommended passphrase is made of 5 words. If the project cares so much about other people's minimum acceptable security that it's willing to enforce this under duress, why not make it actually meaningful? Oh, because a 20 character passphrase being compulsory might actually make too many users angry for suggesting their passwords are shit.
I don't know that there's any plans to go higher. The Fedora account system requires 9 (if mixed with different case and puncuation).
apg (along with many other things) can generate you a list of passwords and 'pwscore' can make sure they will pass the same tests anaconda would give them.
IMHO, this isn't so big a deal.
And apg and pwscore are going to be integrated into the Anaconda GUI?
I doubt it?
Or will the GUI simply be an enforcer while providing zero assistance in selecting an appropriate password? What feedback will the user be given so they understand what exact change in behavior they need to make?
I don't know. Perhaps you could provide some sensible RFE on what feedback it should/could give?
Have you actually played with pwscore?
Yes.
# pwscore root shrkobtk 1 # pwscore root tableprison 41 # pwscore root inforats Password quality check failed: The password fails the dictionary check - it is based on a dictionary word
This defies belief. Random scores lowest. Two dictionary words scores average. A dictionary word fragment and a plural noun is disqualified. Ridiculous.
Feel free to file bugs on it. I suspect the random one is due to it being short as well as all lower case and containing no numbers.
I'll have to change my throw away instance test password from 'abc123' to something like 'tacosyum99' Shrug.
You fail to understand the can of worms opened up by this. My trust in Fedora is diminished because of the theatrics and indiscriminately shifting this burden onto all users. The arguments in favor thus far are demonstrably specious, so there must be some other explanation for why the change is being made.
I think most people think it's not such a big deal and cannot see why you are so stridently affected by it.
kevin
On Fri, Jan 30, 2015 at 01:13:47PM -0700, Kevin Fenzi wrote:
Just FYI, this will likely be my last post to this thread.
I think most people think it's not such a big deal and cannot see why you are so stridently affected by it.
With all due respect, I think that several others, including myself, have also spoken against it.
Interestingly, on Fedora Forum, it got no comment. I suspect if it hits RHEL, like several other Fedora-isms that get in, it will finally aggravate people, but by then it will be too late.
It does nothing but aggravate people. Is it something we'll deal with, along with several other bad (IM less than HO) decisions? Yeah, probably.
Does anyone REALLY think this is going to protect one single computer?
Is there a place to file a protest against it?
On Friday, January 30, 2015 04:08:19 PM Scott Robbins wrote:
On Fri, Jan 30, 2015 at 01:13:47PM -0700, Kevin Fenzi wrote:
Just FYI, this will likely be my last post to this thread.
I think most people think it's not such a big deal and cannot see why you are so stridently affected by it.
With all due respect, I think that several others, including myself, have also spoken against it.
Interestingly, on Fedora Forum, it got no comment. I suspect if it hits RHEL, like several other Fedora-isms that get in, it will finally aggravate people, but by then it will be too late.
It does nothing but aggravate people. Is it something we'll deal with, along with several other bad (IM less than HO) decisions? Yeah, probably.
Does anyone REALLY think this is going to protect one single computer?
Is there a place to file a protest against it?
By helping reform/scrap FESco so it properly represents Fedora Users and Developers alike.
That's the only way.
Thanks, Shawn
On Fri, 2015-01-30 at 16:08 -0500, Scott Robbins wrote:
On Fri, Jan 30, 2015 at 01:13:47PM -0700, Kevin Fenzi wrote:
Just FYI, this will likely be my last post to this thread.
I think most people think it's not such a big deal and cannot see why you are so stridently affected by it.
With all due respect, I think that several others, including myself, have also spoken against it.
Interestingly, on Fedora Forum, it got no comment. I suspect if it hits RHEL, like several other Fedora-isms that get in, it will finally aggravate people, but by then it will be too late.
It's not really a Fedora-ism. The anaconda developers develop anaconda as the installer for Fedora and RHEL; if they want a change to be specific to one or the other, they'd write it that way. By committing this it's already implicitly part of RHEL 8 or whatever.
It does nothing but aggravate people. Is it something we'll deal with, along with several other bad (IM less than HO) decisions? Yeah, probably.
Does anyone REALLY think this is going to protect one single computer?
Presumably yes, or they wouldn't have made the change. Why would you make the change if you don't think it's going to achieve anything? So, at least the person who wrote the change and the person who reviewed it.
Is there a place to file a protest against it?
That's what you're doing, isn't it? This is a place, and you're certainly protesting.
On Fri, 2015-01-30 at 13:13 -0700, Kevin Fenzi wrote:
Because you cannot just say "This is some decision, I know whatever I do will have good and bad tradeoffs, therefore, I will just not decide and expose all the possible choices to the user". Thats just not tenable.
That is exactly what should happen. If you know that any decision will be wrong in some circumstances you try to leave it flexible to the extent possible by other limits such as developer time.
The system requires a root password. Ok, the pure UNIX way would be to simply prompt for one. Because a typo here (especially since passwords don't echo) tradition calls for requiring it be entered twice as a basic sanity check. And that is all. This is also what the RedHat/Fedora installers actually did for many successful releases. If additional developer resources are available it is perfectly acceptable to add more sanity checking and inform / warn about unsafe passwords. Fedora has also used this policy, and again with success and no complaints. The second the developer takes the step of requiring their preferred password policy is when they have left The UNIX Way and adopted the attitude (endemic in every other computing culture) that the developers are superior to the users / admins.
While perfectly normal everywhere else, that is a totally alien mindset for UNIX folk and is why the instantly negative reaction is occurring, a reaction that is probably more harsh than the actual case at hand would justify. I realize Fedora is no longer UNIX, doesn't even want to be a UNIX, but many users do still follow The UNIX Way and we haven't all been driven out yet.
On Fri, Jan 30, 2015 at 1:13 PM, Kevin Fenzi kevin@scrye.com wrote:
Just FYI, this will likely be my last post to this thread.
On Fri, 30 Jan 2015 12:59:12 -0700 Chris Murphy lists@colorremedies.com wrote:
User who want or need more secure passwords can always opt in without affect anyone else. Why is the project's installer not merely questioning the user's veracity and competency, but disallowing them, by force, from doing what they think is in their best interest?
Because you cannot just say "This is some decision, I know whatever I do will have good and bad tradeoffs, therefore, I will just not decide and expose all the possible choices to the user". Thats just not tenable.
Except we do exactly that with custom partitioning on UEFI systems, by making users responsible for things they've never previously been responsible for, and the same developers defend this UI with "users are expected to know what they're doing" in that UI.
And at the same time, tenable has been, we haven't had a password requirement up until now, the same as every other major distro and OS on the planet. Can anyone name another OS that has a minimum quality password enforcement by default for device login access? I can't think of any.
I'll have to change my throw away instance test password from 'abc123' to something like 'tacosyum99' Shrug.
You fail to understand the can of worms opened up by this. My trust in Fedora is diminished because of the theatrics and indiscriminately shifting this burden onto all users. The arguments in favor thus far are demonstrably specious, so there must be some other explanation for why the change is being made.
I think most people think it's not such a big deal and cannot see why you are so stridently affected by it.
Its affect on me personally is moot. I am a user advocate, and as such I trust the overwhelming majority of users to set an appropriate password for their use case, rather than this condescending baby sitting nonsense that impacts security almost nil, and impacts usability significantly and disproportionately.
I think users should be educated and incentivized to make the right choices for their use case. By making this involuntary the project is absolutely saying "we do not trust the user to make this decision voluntarily, which is why have to force them into making better passwords regardless of the context and use case."
When you stop trusting me. I stop trusting you. And that's a huge problem, and thus far the engineering types are looking at this with narrow vision, it's 2 more key presses. They aren't looking at this at all from the perspective of its connotation.
Not even Windows, that rat trap of security problems, requires this of me. What's wrong with Fedora that I am *required* to have a stronger password here than on any of my other devices?
On Fri, 2015-01-30 at 12:59 -0700, Chris Murphy wrote:
What's the actual, real world, non-imaginary impetus behind the change?
It's exactly what all the list posts I pointed you to say it is. I don't know how to stop the conspiracy virus which causes people to leap to the conclusion that there's some shadowy secret motive behind every change they don't like, but there *isn't*. PJP posted about his change proposal to anaconda-devel . bcl said 'that doesn't sound like a good idea, but we take your point about possible brute force attacks against services enabled ootb, and an easy way to mitigate that is to require strong passwords'. anaconda already *has* a password strength checker, so it probably took him all of five minutes to make it mandatory instead of optional. Then he dropped a mail here as a courtesy heads-up. that's the entirety of what happened.
On 01/30/2015 12:21 PM, Adam Williamson wrote:
On Fri, 2015-01-30 at 12:59 -0700, Chris Murphy wrote:
What's the actual, real world, non-imaginary impetus behind the change?
It's exactly what all the list posts I pointed you to say it is. I don't know how to stop the conspiracy virus which causes people to leap to the conclusion that there's some shadowy secret motive behind every change they don't like, but there *isn't*. PJP posted about his change proposal to anaconda-devel . bcl said 'that doesn't sound like a good idea, but we take your point about possible brute force attacks against services enabled ootb, and an easy way to mitigate that is to require strong passwords'. anaconda already *has* a password strength checker, so it probably took him all of five minutes to make it mandatory instead of optional. Then he dropped a mail here as a
^^^^^^^^^
courtesy heads-up. that's the entirety of what happened.
That's what's setting people off--making it mandatory unilaterally.
I have no issue with the system nattering at me that the password is (in the installer's opinion) inadequate, but do NOT stop me from using it. I probably have a damned good reason to use it. After all, I put in my "weak" password twice (and note the second time was AFTER the system bitched about its perceived weakness). I obviously want it set to what I entered.
If I wanted to be led by the nose, restricted in what I can do and nannied constantly, I'd use Windows or a freaking Mac. Sheesh! ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - BASIC is the Computer Science version of `Scientific Creationism' - ----------------------------------------------------------------------
On Fri, Jan 30, 2015 at 12:54:22PM -0800, Rick Stevens wrote:
If I wanted to be led by the nose, restricted in what I can do and nannied constantly, I'd use Windows or a freaking Mac. Sheesh!
Errm, no, they let you choose the password.
Heh, could be a new advertising slogan. YOU choose the password.
If you like your password you can keep it. Period.
Otherwise write it down as in "War Games"........
On Fri, Jan 30, 2015 at 1:21 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Fri, 2015-01-30 at 12:59 -0700, Chris Murphy wrote:
What's the actual, real world, non-imaginary impetus behind the change?
It's exactly what all the list posts I pointed you to say it is.
Please go find quotes because I just went through them all and I found:
"Better security is always a plus."
"Instead I propose that we increase our minimum password..."
"In principle I don't disagree with it; But IMO it can not be a replacement to stronger defaults."
And that's it. No actual reasons, let alone any data to back it up. And all three of those statements have flaws which I've already addressed.
I don't know how to stop the conspiracy virus which causes people to leap to the conclusion that there's some shadowy secret motive behind every change they don't like, but there *isn't*.
I don't know how to stop your conspiracy virus from leaping to the conclusion I was thinking there's a secret motive. I'm actually, literally asking the question, what is the *real world* impetus behind the change? That is not rhetorical. I want facts. I want data. Not hand waivy opinions like "better security is a plus" I want to know exactly what the attack vector is being mitigated here and how common it is. Otherwise it is exactly as I've stated, it's a solution in search of a problem, a problem that by the way the $18 billion target on its back doesn't seem to think is such a big problem seeing as its devices without passwords are regularly used on public encrypted wifi and the world is not ending.
What conspiracy are we avoiding with this password change? Where's the threat? Why is voluntary compliance inadequate? Have we done our absolute best to achieve voluntary compliance with stronger passwords? Why do we distrust user's ability to choose their own passwords for their own use case?
I just don't see any consideration here except specious statements like better security is always a plus. That was the summary extent of the entire decision making process.
On Fri, Jan 30, 2015 at 2:49 PM, Chris Murphy lists@colorremedies.com wrote:
its devices without passwords are regularly used on public encrypted wifi and the world is not ending.
Oops, that should be non-encrypted.
On Fri, 2015-01-30 at 14:49 -0700, Chris Murphy wrote:
I just don't see any consideration here except specious statements like better security is always a plus. That was the summary extent of the entire decision making process.
Well, no, AFAICS there isn't anything like that. It was a fairly lightly considered change. The threat it's primarily addressing is that sshd with password login is enabled out of the box in at least some of the configurations anaconda deploys, and is therefore vulnerable to brute force attacks. Secondarily it's about local user accounts.
I think the main point is the one nirik made; I don't think the devs agree with your assessment of how significant this is. It's a minor inconvenience; you just have to come up with a password that passes the check, or use a kickstart. So I don't think they agree that it needs a full-blown security audit and FESCo review or whatever, because they don't think it's really that huge of a change in behaviour.
On Fri, Jan 30, 2015 at 3:03 PM, Adam Williamson adamwill@fedoraproject.org wrote:
On Fri, 2015-01-30 at 14:49 -0700, Chris Murphy wrote:
I just don't see any consideration here except specious statements like better security is always a plus. That was the summary extent of the entire decision making process.
Well, no, AFAICS there isn't anything like that. It was a fairly lightly considered change. The threat it's primarily addressing is that sshd with password login is enabled out of the box in at least some of the configurations anaconda deploys, and is therefore vulnerable to brute force attacks. Secondarily it's about local user accounts.
I'm amused because Fedora Server WG was so dead set against the original change proposal, they were willing to consider overriding it with a per-product config. I wonder if the Server SG would like to consider a per-product config for stronger passwords to mitigate sshd being enabled by default? Or reconsider it being enabled by default seeing as it apparently comes with the baggage of collective punishment.
What is this about local user accounts? Workstation doesn't put users in wheel by default. OS X and Windows both do and yet it allows any password to be set.
I think the main point is the one nirik made; I don't think the devs agree with your assessment of how significant this is.
I thought you wanted to wait for them to respond before assuming what they think?
They didn't agree with my or other people's assessments with the last password change in the installer, which likewise was considered a light change by the devs, and was done without any meaningful discussion. Calm inquiry and criticism was discarded, then as now. And it took a devel@ shit show to get it reverted, that's how well they anticipated that debacle.
Does anyone think Google, Microsoft, Apple, have not considered mandatory strong passwords with their products? Why do you think they haven't done it?
Recapitiulation:
A security problem was recognized because the ssh daemon is enabled by default on Fedora systems: with a weak root password, a remote attacker might easily obtain unlimited access.
The direct solution would seem to be a change to the ssh daemon to prohibit root login in its default configuration, but allow post-installation change to sshd to permit this where it is desirable.
An indirect solution was implemented to require a strong root password during Fedora installation. This avoids the default vulnerability, but upset people (especially testers who frequently install Fedora) that consider it makes additional work necessary to configure a system the way they want it.
Ultimately, this indirect solution is weak. Users are likely to supply an acceptable root password during installation, then change it to what they desire after installation. This could re-open the vulnerability, which was not understood by a casual user.
On Sat, Jan 31, 2015 at 09:21:45PM -0500, Richard Ryniker wrote:
Recapitiulation:
A security problem was recognized because the ssh daemon is enabled by default on Fedora systems: with a weak root password, a remote attacker might easily obtain unlimited access.
The direct solution would seem to be a change to the ssh daemon to prohibit root login in its default configuration, but allow post-installation change to sshd to permit this where it is desirable.
Coming from a FreeBSD background, where that is the default, that makes more sense to me, admittedly, just one person's opinion. It's actually more likely to stop this theoretical newcomer from leaving their system open.
On Sat, 2015-01-31 at 21:21 -0500, Richard Ryniker wrote:
Recapitiulation:
A security problem was recognized because the ssh daemon is enabled by default on Fedora systems: with a weak root password, a remote attacker might easily obtain unlimited access.
This is not quite correct; it should say 'some Fedora systems'.
The direct solution would seem to be a change to the ssh daemon to prohibit root login in its default configuration, but allow post- installation change to sshd to permit this where it is desirable.
The reason we didn't do this - which was the initial Change proposal - is that we don't have a solid mechanism for deploying any *other* ssh authentication mechanism (i.e. a gpg key) at install time. The 'ssh up with password login enabled' configuration exists because _people use it_ - they deploy systems in remote locations which they then need to log in to, and 'ssh to it with a password' is really the only way we offer to do this OOTB (unless you have AD/FreeIPA management set up).
Ultimately, this indirect solution is weak. Users are likely to supply an acceptable root password during installation, then change it to what they desire after installation.
Well, that's a possibility, but I don't think I've seen any evidence of it (as cmurf has pointed out we also have no data about the prevalence of weak passwords or attacks on default-configured Fedora systems, though).
we also have no data about the prevalence of weak passwords or attacks on default-configured Fedora systems
On my firewall system, /var/log/secure is larger than 300 megabytes (less than one month of data), most of it reports of failed login attempts to root. I am very careful about passwords on this machine.
Some of the security companies operate "honeypot" machines, and may have interesting numbers about ssh attacks. Red Hat probably also has data about unwelcome attempts to access its systems.
Like some other security issues, it is as much about psychology as it is about code. However elegant the software technology may be, its value is small if users pretermit its use.
Aside from the usual problems with strong passwords, the problem I see is that the user who changes the root password does not think about ssh attacks. If some ssh configuration change is needed to permit root login, at least we have some reason to believe the risk has been evaluated.
On Fri, 2015-01-30 at 14:03 -0800, Adam Williamson wrote:
I think the main point is the one nirik made; I don't think the devs agree with your assessment of how significant this is. It's a minor inconvenience; you just have to come up with a password that passes the check, or use a kickstart. So I don't think they agree that it needs a full-blown security audit and FESCo review or whatever, because they don't think it's really that huge of a change in behaviour.
Having to come up with a password that passes the check is not 'a minor inconvenience'. Given how capricious libpwquality is about scoring (there have been some examples in this thread, there are more in gnome-initial-setup bugs), it is next to impossible.
This discussion has been pretty heated, but I agree with there being some aspect of 'collective punishment' here: just because _some_ systems get installed with sshd enabled, all users who install the Workstation have to spend a couple of frustrating minutes trying to find a password that gets them past this hurdle.
If this change stays, I anticipate the Workstation WG asking for a way to the workstation installer not enforce this. I know the anaconda folks are not eager to add variations like this, but that is exactly what we need: If you want to enforce product-specific policy in the installer, it needs to be a product-specific installer.
On Sun, Feb 01, 2015 at 09:53:05PM -0500, Matthias Clasen wrote:
On Fri, 2015-01-30 at 14:03 -0800, Adam Williamson wrote:
I think the main point is the one nirik made; I don't think the devs agree with your assessment of how significant this is. It's a minor inconvenience; you just have to come up with a password that passes the check, or use a kickstart. So I don't think they agree that it needs a full-blown security audit and FESCo review or whatever, because they don't think it's really that huge of a change in behaviour.
Having to come up with a password that passes the check is not 'a minor inconvenience'. Given how capricious libpwquality is about scoring (there have been some examples in this thread, there are more in gnome-initial-setup bugs), it is next to impossible.
This discussion has been pretty heated, but I agree with there being some aspect of 'collective punishment' here: just because _some_ systems get installed with sshd enabled, all users who install the Workstation have to spend a couple of frustrating minutes trying to find a password that gets them past this hurdle.
If this change stays, I anticipate the Workstation WG asking for a way to the workstation installer not enforce this. I know the anaconda folks are not eager to add variations like this, but that is exactly what we need: If you want to enforce product-specific policy in the installer, it needs to be a product-specific installer.
You're assuming before asking. With the structure of the installer now, we can look at changes like taking the password aspect and making it product-specific controllable by a number of different methods. Our historic aim to end variant specifics in the installer was because the old code (and variants) lacked a way to assign owners to those product specifics, which meant that requests of the installer to be product specific meant we were asked to be the owners of those specifics.
On Mon, 2015-02-02 at 18:38 -0500, David Cantrell wrote:
On Sun, Feb 01, 2015 at 09:53:05PM -0500, Matthias Clasen wrote:
On Fri, 2015-01-30 at 14:03 -0800, Adam Williamson wrote:
I think the main point is the one nirik made; I don't think the devs agree with your assessment of how significant this is. It's a minor inconvenience; you just have to come up with a password that passes the check, or use a kickstart. So I don't think they agree that it needs a full-blown security audit and FESCo review or whatever, because they don't think it's really that huge of a change in behaviour.
Having to come up with a password that passes the check is not 'a minor inconvenience'. Given how capricious libpwquality is about scoring (there have been some examples in this thread, there are more in gnome-initial-setup bugs), it is next to impossible.
This discussion has been pretty heated, but I agree with there being some aspect of 'collective punishment' here: just because _some_ systems get installed with sshd enabled, all users who install the Workstation have to spend a couple of frustrating minutes trying to find a password that gets them past this hurdle.
If this change stays, I anticipate the Workstation WG asking for a way to the workstation installer not enforce this. I know the anaconda folks are not eager to add variations like this, but that is exactly what we need: If you want to enforce product-specific policy in the installer, it needs to be a product-specific installer.
You're assuming before asking. With the structure of the installer now, we can look at changes like taking the password aspect and making it product-specific controllable by a number of different methods. Our historic aim to end variant specifics in the installer was because the old code (and variants) lacked a way to assign owners to those product specifics, which meant that requests of the installer to be product specific meant we were asked to be the owners of those specifics.
Let me ask now, then: can we make the change to reject 'weak' passwords specific to only those products that enable sshd by default, please ?
Matthias Clasen <mclasen <at> redhat.com> writes:
Let me ask now, then: can we make the change to reject 'weak' passwords specific to only those products that enable sshd by default, please ?
If the only concern is remote attacks, I'd like to see someone answer the earlier question about whether Fedora has password rate and retry limits to allow a weak password to be adequately secure, and if not, why not fix that instead of requiring a strong password?
On Thu, Feb 05, 2015 at 09:38:52AM +0000, Andre Robatino wrote:
Matthias Clasen <mclasen <at> redhat.com> writes:
Let me ask now, then: can we make the change to reject 'weak' passwords specific to only those products that enable sshd by default, please ?
If the only concern is remote attacks, I'd like to see someone answer the earlier question about whether Fedora has password rate and retry limits to allow a weak password to be adequately secure, and if not, why not fix that instead of requiring a strong password?
As someone said on the CentOS list, where, like most places, it's generally being received unfavorably, this is similar to the security theatre we have here in the US, where the TSA inconveniences anyone, at will, with little real effect, but it makes a nice show.
In my admittedly biased opinion, that's the best description I've seen. Will it stop one or two events? Probably. Is it effective? No. Will it inconvenience the vast majority? Yes.
Are Fedora users so inexperienced and stupid that it's necessary? I don't think so.
On Thu, Feb 05, 2015 at 09:53:30AM +0100, Matthias Clasen wrote:
On Mon, 2015-02-02 at 18:38 -0500, David Cantrell wrote:
On Sun, Feb 01, 2015 at 09:53:05PM -0500, Matthias Clasen wrote:
On Fri, 2015-01-30 at 14:03 -0800, Adam Williamson wrote:
I think the main point is the one nirik made; I don't think the devs agree with your assessment of how significant this is. It's a minor inconvenience; you just have to come up with a password that passes the check, or use a kickstart. So I don't think they agree that it needs a full-blown security audit and FESCo review or whatever, because they don't think it's really that huge of a change in behaviour.
Having to come up with a password that passes the check is not 'a minor inconvenience'. Given how capricious libpwquality is about scoring (there have been some examples in this thread, there are more in gnome-initial-setup bugs), it is next to impossible.
This discussion has been pretty heated, but I agree with there being some aspect of 'collective punishment' here: just because _some_ systems get installed with sshd enabled, all users who install the Workstation have to spend a couple of frustrating minutes trying to find a password that gets them past this hurdle.
If this change stays, I anticipate the Workstation WG asking for a way to the workstation installer not enforce this. I know the anaconda folks are not eager to add variations like this, but that is exactly what we need: If you want to enforce product-specific policy in the installer, it needs to be a product-specific installer.
You're assuming before asking. With the structure of the installer now, we can look at changes like taking the password aspect and making it product-specific controllable by a number of different methods. Our historic aim to end variant specifics in the installer was because the old code (and variants) lacked a way to assign owners to those product specifics, which meant that requests of the installer to be product specific meant we were asked to be the owners of those specifics.
Let me ask now, then: can we make the change to reject 'weak' passwords specific to only those products that enable sshd by default, please ?
[adding anaconda-devel-list to CC]
From a technical standpoint, I see this being possible. Conditionalize it
on sshd being enabled or not. That's not really variant-specific and just a system condition we could work around.
I'm putting this on anaconda-devel-list for further discussion. bcl, others? What are your thoughts on this request?
On Thu, Feb 05, 2015 at 10:47:44AM -0500, David Cantrell wrote:
On Thu, Feb 05, 2015 at 09:53:30AM +0100, Matthias Clasen wrote:
On Mon, 2015-02-02 at 18:38 -0500, David Cantrell wrote:
On Sun, Feb 01, 2015 at 09:53:05PM -0500, Matthias Clasen wrote:
On Fri, 2015-01-30 at 14:03 -0800, Adam Williamson wrote:
I think the main point is the one nirik made; I don't think the devs agree with your assessment of how significant this is. It's a minor inconvenience; you just have to come up with a password that passes the check, or use a kickstart. So I don't think they agree that it needs a full-blown security audit and FESCo review or whatever, because they don't think it's really that huge of a change in behaviour.
Having to come up with a password that passes the check is not 'a minor inconvenience'. Given how capricious libpwquality is about scoring (there have been some examples in this thread, there are more in gnome-initial-setup bugs), it is next to impossible.
Next to impossible? Really? I've find it easy to come up with passwords that work. We even report libpwquality's reason for any failures.
This discussion has been pretty heated, but I agree with there being some aspect of 'collective punishment' here: just because _some_ systems get installed with sshd enabled, all users who install the Workstation have to spend a couple of frustrating minutes trying to find a password that gets them past this hurdle.
If this change stays, I anticipate the Workstation WG asking for a way to the workstation installer not enforce this. I know the anaconda folks are not eager to add variations like this, but that is exactly what we need: If you want to enforce product-specific policy in the installer, it needs to be a product-specific installer.
You're assuming before asking. With the structure of the installer now, we can look at changes like taking the password aspect and making it product-specific controllable by a number of different methods. Our historic aim to end variant specifics in the installer was because the old code (and variants) lacked a way to assign owners to those product specifics, which meant that requests of the installer to be product specific meant we were asked to be the owners of those specifics.
Let me ask now, then: can we make the change to reject 'weak' passwords specific to only those products that enable sshd by default, please ?
[adding anaconda-devel-list to CC]
From a technical standpoint, I see this being possible. Conditionalize it
on sshd being enabled or not. That's not really variant-specific and just a system condition we could work around.
I'm putting this on anaconda-devel-list for further discussion. bcl, others? What are your thoughts on this request?
I don't think we should make it act differently. While the change request for sshd setup was the initial reason I wrote the changes, I think that ALL passwords on the system need to be strong these days.
I don't find any of the arguments against the change to be compelling. The most valid one is repeated installs of throw-away VMs, and I addressed that in my original post. Just make up a password that passes and write it down.
If we do make this conditional, either based on sshd being active, or per-product then where do we stop? Most decisions the installer makes about the system could be called 'enforcing', so do we now have to have a vote on every change?
Passwords are the gateway to people's private data. We should be encouraging them to choose stronger passwords and we should remember that we're not the only people running Fedora.
Brian C. Lane composed on 2015-02-05 09:36 (UTC-0800):
We should be encouraging them to choose stronger passwords and we should remember that we're not the only people running Fedora.
BIG difference between encouraging, and paternalistic forcing. Forcing is what happens to slaves and prisoners. Encouragment is better at leading to acceptance than brutality.
On Thu, 2015-02-05 at 13:59 -0500, Felix Miata wrote:
Brian C. Lane composed on 2015-02-05 09:36 (UTC-0800):
We should be encouraging them to choose stronger passwords and we should remember that we're not the only people running Fedora.
BIG difference between encouraging, and paternalistic forcing. Forcing is what happens to slaves and prisoners. Encouragment is better at leading to acceptance than brutality.
OK, seriously, I did warn you. Likening the behaviour of other contributors to slavery, prison and brutality is a flagrant violation of the Fedora code of conduct. I'm placing your messages on moderation for the next week or two at least.
On Thu, Feb 5, 2015 at 10:36 AM, Brian C. Lane bcl@redhat.com wrote:
Next to impossible? Really? I've find it easy to come up with passwords that work.
You think this is easy. Other's don't. It's a condescending, pointless, and unwinnable argument, and it needs to stop.
I tried anaconda 22.17. I failed to produce an acceptable 8 character password, and tolerated a 10 character one to appease the installer, which was promptly forgotten 1/2 an hour later. While humorous, it also pissed me off. That's not a good UX by definition but I know you tend to discard negative UX whenever you disagree with the actions of the user.
I don't think we should make it act differently. While the change request for sshd setup was the initial reason I wrote the changes, I think that ALL passwords on the system need to be strong these days.
You keep trying to frame this as weak vs strong passwords, and that's simply wrong. It's a very weak vs weak password difference, yet it comes with a disproportionate burden on the user. Every single device I own, and even ATMs I don't own, have better security and a truly easy UX than this policy proposes.
I don't find any of the arguments against the change to be compelling.
I also notice how many times you defend this policy change with "I". You find it easy, you think it's needed, you find others' arguments uncompelling. It's just more of the same casting aside of user opinions that you merely disagree with. And disagreement with the opinions of others isn't a defense that withstands scrutiny.
Do you find it conspicuous that in a ~70 email thread that no one except you has posted in favor of the change? The strongest statement in favor of it that I've read, other than yours, is from sgallagh, in the Server WG meeting minutes. [1]
16:34:28 <sgallagh> A more reasonable approach would be to just enforce a better root password (not more complex, just longer)
Adamw's hyperbole notwithstanding, his sentiment in that same meeting is compatible with mine: quit job, and buy a yak farm instead of typing long passwords a dozen fking times a day.
I surmise the Server WG would reject the current behavior in 22.17 also due to the (capricious) complexity required, and if so there wouldn't be a misalignment requiring separate behavior between Server and Workstation.
We should be encouraging them to choose stronger passwords and we should remember that we're not the only people running Fedora.
Encourage: - give support and advice to (someone) so that they will do or continue to do something Coerce: - persuade (an unwilling person) to do something by using force or threats
22.17 forces me to use a weak instead of very weak password, or I'm disallowed from installing. That behavior meets the definition of coercion, not encouragement.
[1] http://meetbot.fedoraproject.org/fedora-meeting-1/2015-01-13/fedora-meeting-...
On Thu, Feb 05, 2015 at 12:53:45PM -0700, Chris Murphy wrote:
On Thu, Feb 5, 2015 at 10:36 AM, Brian C. Lane bcl@redhat.com wrote:
Next to impossible? Really? I've find it easy to come up with passwords that work.
You think this is easy. Other's don't. It's a condescending, pointless, and unwinnable argument, and it needs to stop.
You might also look at the CentOS list, which has a high percentage of people who, y'know, actually use this stuff to make a living. You'll find that it's overwhelmingly against this.
I don't find any of the arguments against the change to be compelling.
Well, I don't find any of the arguments for a change, that will probably violate POLA (principle of least astonishment) at all compelling. You're making the change, it is up to you to justify.
This reminds me of the time when they wanted packagekit to allow any user to upgrade any package--even now, any user can upgrade any installed, signed package--and they were going to go through with it till it made the front page of slashdot.
We should be encouraging them to choose stronger passwords and we should remember that we're not the only people running Fedora.
Yes, but most running Fedora aren't totally inexperienced. Nor for that matter, are people running Mint or Ubuntu--most have at least some knowledge of computers, otherwise, they run Windows or OSX.
On 02/05/2015 01:27 PM, Scott Robbins wrote:
On Thu, Feb 05, 2015 at 12:53:45PM -0700, Chris Murphy wrote:
On Thu, Feb 5, 2015 at 10:36 AM, Brian C. Lane bcl@redhat.com wrote:
Next to impossible? Really? I've find it easy to come up with passwords that work.
You think this is easy. Other's don't. It's a condescending, pointless, and unwinnable argument, and it needs to stop.
You might also look at the CentOS list, which has a high percentage of people who, y'know, actually use this stuff to make a living. You'll find that it's overwhelmingly against this.
I don't find any of the arguments against the change to be compelling.
Well, I don't find any of the arguments for a change, that will probably violate POLA (principle of least astonishment) at all compelling. You're making the change, it is up to you to justify.
This reminds me of the time when they wanted packagekit to allow any user to upgrade any package--even now, any user can upgrade any installed, signed package--and they were going to go through with it till it made the front page of slashdot.
I have to agree with Chris. I have absolutely no issue with the installer _warning_ me that the password I chose is (in the INSTALLER's opinion) weak. The installer should ABSOLUTELY NOT force me to use some arbitrarily obscure password to satisfy its criteria. I have very good reasons for using the passwords I choose.
One example: We often have accounts that log in to collect data (e.g. nagios or rancid) for monitoring purposes or config change deltas. If the installer suddenly changes the password requirements, then the existing systems all have to be changed to match, and the monitoring software also has to be reconfigured. That is truly invasive. I manage well over 400 systems spread around in three data centers and I have to change everything because some self-righteous coder thinks my passwords are inadequate?
All the installer should do is install a functional system. If something comes up that may be odd, then fine, warn the user about it but do what the user tells you to do. Leave it up to the system admins to harden the system if they need to.
We should be encouraging them to choose stronger passwords and we should remember that we're not the only people running Fedora.
Yes, but most running Fedora aren't totally inexperienced. Nor for that matter, are people running Mint or Ubuntu--most have at least some knowledge of computers, otherwise, they run Windows or OSX.
<soap> Encouraging is one hell of a lot different than beating them over the head and not letting them configure the system THE WAY THEY WANT IT CONFIGURED! </soap> ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@alldigital.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - "You think that's tough? Try herding cats!" - ----------------------------------------------------------------------
On Thu, Feb 05, 2015 at 03:03:50PM -0800, Rick Stevens wrote:
I have to agree with Chris. I have absolutely no issue with the installer _warning_ me that the password I chose is (in the INSTALLER's opinion) weak. The installer should ABSOLUTELY NOT force me to use some arbitrarily obscure password to satisfy its criteria. I have very good reasons for using the passwords I choose.
Agreed (again). IMHO installing a system is a first step, *after* that follow configuring subsystems, adding users and setting passwords.
A default of not accepting root logins via ssh is already a bit annoying, but adding another user at install time is an acceptable workaround.
An installer should be good at what it should do, installing, not configuring.
Unfortunately, using Red Hat Linux versions since 1996, having installed hundreds of systems, probably 1000+ (ok, mostly with kickstart), the installer has become extremely difficult to use the last years, because it tries to be "smart" and makes life for people that know what they want (like using preformatted partition tables etc.) extremely difficult.
Hi
On Wed, Jan 28, 2015 at 11:53 AM, Brian C. Lane wrote:
This Friday's build of Anaconda will no longer allow you to use weak passwords and click done twice. In order to promote more secureish default systems I have increased the password length required to 8 characters and removed allowing weak (as defined by libpwquality) passwords.
Please revert this change. I have to routinely create images for testing that don't need this additional burden and no, I am not going to write down passwords to appease the installer. It is perfectly ok to strongly encourage users to choose good password but an enforcement is unnecessary. If you feel strongly, file a ticket with FESCo and let them vote on it. Thanks
Rahul
-
Adam Williamson -
Amita -
Andre Robatino -
Bob Lightfoot -
Brian C. Lane -
Bruno Wolff III -
Chris Adams -
Chris Murphy -
Chuck Forsberg WA7KGX -
David Cantrell -
David Lehman -
drago01 -
Ed Greshko -
Felix Miata -
John Morris -
Jos Vos -
Kevin Fenzi -
Matthias Clasen -
Rahul Sundaram -
Rejy M Cyriac -
Richard Ryniker -
Rick Stevens -
Samuel Sieb -
Scott Robbins -
Shawn Starr -
Sudhir Khanger -
Sérgio Basto