10:53 a.m.
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 :)
--
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)
2:55 p.m.
On Wed, Jan 28, 2015 at 08:53:42 -0800,
"Brian C. Lane" <bcl(a)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.
3:36 p.m.
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.
4:06 p.m.
On Wed, Jan 28, 2015 at 5:53 PM, Brian C. Lane <bcl(a)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).
4:20 p.m.
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?
4:54 p.m.
On Wed, Jan 28, 2015 at 22:20:54 +0000,
Andre Robatino <robatino(a)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.
5:05 p.m.
On Wed, Jan 28, 2015 at 9:53 AM, Brian C. Lane <bcl(a)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.
--
Chris Murphy
5:08 p.m.
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...
5:17 p.m.
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(a)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
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
5:41 p.m.
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?
--
If you can't laugh at yourself, others will gladly oblige.
5:46 p.m.
On Wed, Jan 28, 2015 at 4:17 PM, Adam Williamson
<adamwill(a)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
5:54 p.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
6:06 p.m.
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.
+ + + + +
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
6:29 p.m.
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)?
6:33 p.m.
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?
6:56 p.m.
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(a)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
--
Sérgio M. B.
7:07 p.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
7:23 p.m.
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.
7:32 p.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
7:34 p.m.
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(a)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.
--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
6:29 a.m.
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?
--
Regards,
Sudhir Khanger,
sudhirkhanger.com,
github.com/donniezazen,
5577 8CDB A059 085D 1D60 807F 8C00 45D9 F5EF C394.
6:34 a.m.
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?
6:37 a.m.
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...
--
-- Jos Vos <jos(a)xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
7 a.m.
On Thu, Jan 29, 2015 at 01:37:39PM +0100, Jos Vos wrote:
--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
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
7:18 a.m.
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
1:30 p.m.
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.
3:01 p.m.
On Wed, Jan 28, 2015 at 5:33 PM, Samuel Sieb <samuel(a)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.
--
Chris Murphy
3:23 p.m.
On Thu, 2015-01-29 at 14:01 -0700, Chris Murphy wrote:
On Wed, Jan 28, 2015 at 5:33 PM, Samuel Sieb <samuel(a)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...
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
4:09 p.m.
On Thu, Jan 29, 2015 at 2:23 PM, Adam Williamson
<adamwill(a)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...
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.
--
Chris Murphy
4:18 p.m.
On Thu, 2015-01-29 at 15:09 -0700, Chris Murphy wrote:
On Thu, Jan 29, 2015 at 2:23 PM, Adam Williamson <
adamwill(a)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...
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...
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
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
5:24 p.m.
On Thu, Jan 29, 2015 at 3:18 PM, Adam Williamson
<adamwill(a)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(a)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...
>
> 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...
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.
https://fedoraproject.org/wiki/Changes/Policy
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.
--
Chris Murphy
5:32 p.m.
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...
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
http://fedoraproject.org/wiki/Features/Policy/Definitions
that whole thing is obsolete, the Change process replaced the Feature
process. Nothing with 'Feature' in its URL is current any more.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
5:53 p.m.
On Thu, Jan 29, 2015 at 4:32 PM, Adam Williamson
<adamwill(a)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...
>
> 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
>
> http://fedoraproject.org/wiki/Features/Policy/Definitions
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?
--
Chris Murphy
7:27 p.m.
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.)
7:55 p.m.
Once upon a time, Adam Williamson <adamwill(a)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?
--
Chris Adams <linux(a)cmadams.net>
8:23 p.m.
On Thu, 2015-01-29 at 19:55 -0600, Chris Adams wrote:
Once upon a time, Adam Williamson <adamwill(a)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
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8:52 p.m.
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.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
9:07 p.m.
On Thu, Jan 29, 2015 at 7:23 PM, Adam Williamson
<adamwill(a)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.
--
Chris Murphy
10:04 p.m.
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.
--
Regards,
Rejy M Cyriac (rmc)
10:36 p.m.
-----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}
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBAgAGBQJUywpEAAoJEKqgpLIhfz3X9ZoH/0OVaD1ZBFMD2J6UQb5Y0nX+
fLJSPXsbCZUWYAzlQH2Gaiv0hPiljQNK3o8W36M3mD3Mo2DoGCB8lsGKZ25DhbEi
ao+hHyV3HcLBNoX3AqvquNm/rLDzquoEkW2HCLnyhGj/Uoc1BSGGHSJq6uv7SARs
sCDVLWuk7Ma8XI4ofklErG/Lb5UKfhHr5TpsWGUlouhDgn8iJTul7RA6mWfFQsYJ
D3gbRA40+oTq6crFQ03STSTUDqGriA9I+y8k3iy0ZmWGksM0Vxx6WLPvd0hTWi4m
wleeV7XIX1thxvWkbOtpCH9H3U/SnmO7+kMBS/HaPNr4seyWZlT61eJ6UdtZeKE=
=lYn3
-----END PGP SIGNATURE-----
12:54 a.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
8:05 a.m.
Once upon a time, Adam Williamson <adamwill(a)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.
--
Chris Adams <linux(a)cmadams.net>
10:41 a.m.
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.
--
Regards,
Sudhir Khanger,
sudhirkhanger.com,
github.com/donniezazen,
5577 8CDB A059 085D 1D60 807F 8C00 45D9 F5EF C394.
10:54 a.m.
On Fri, 30 Jan 2015 22:11:12 +0530
Sudhir Khanger <ml(a)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
11:38 a.m.
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.
--
Regards,
Sudhir Khanger,
sudhirkhanger.com,
github.com/donniezazen,
5577 8CDB A059 085D 1D60 807F 8C00 45D9 F5EF C394.
1:59 p.m.
On Fri, Jan 30, 2015 at 9:54 AM, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Fri, 30 Jan 2015 22:11:12 +0530
Sudhir Khanger <ml(a)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.
--
Chris Murphy
2:10 p.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2:13 p.m.
Just FYI, this will likely be my last post to this thread.
On Fri, 30 Jan 2015 12:59:12 -0700
Chris Murphy <lists(a)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
2:21 p.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2:54 p.m.
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(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- BASIC is the Computer Science version of `Scientific Creationism' -
----------------------------------------------------------------------
3:08 p.m.
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?
--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
3:13 p.m.
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
3:14 p.m.
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.
--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
3:32 p.m.
If you like your password you can keep it. Period.
Otherwise write it down as in "War Games"........
--
Chuck Forsberg WA7KGX caf(a)omen.com www.omen.com
Developer of Industrial ZMODEM(Tm) for Embedded Applications
Omen Technology Inc "The High Reliability Software"
10255 NW Old Cornelius Pass Portland OR 97231 503-614-0430
3:33 p.m.
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.
3:34 p.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
3:40 p.m.
On Fri, Jan 30, 2015 at 1:13 PM, Kevin Fenzi <kevin(a)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(a)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?
--
Chris Murphy
3:49 p.m.
On Fri, Jan 30, 2015 at 1:21 PM, Adam Williamson
<adamwill(a)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.
--
Chris Murphy
4:03 p.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
7:19 p.m.
On Fri, Jan 30, 2015 at 3:03 PM, Adam Williamson
<adamwill(a)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?
--
Chris Murphy
8:21 p.m.
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.
8:57 p.m.
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.
--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
10:35 a.m.
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).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2:59 p.m.
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.
8:53 p.m.
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.
5:38 p.m.
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.
--
David Cantrell <dcantrell(a)redhat.com>
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
2:53 a.m.
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 ?
3:38 a.m.
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?
4:49 a.m.
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.
--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
9:47 a.m.
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?
--
David Cantrell <dcantrell(a)redhat.com>
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
11:36 a.m.
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 | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)
12:59 p.m.
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.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
1:53 p.m.
On Thu, Feb 5, 2015 at 10:36 AM, Brian C. Lane <bcl(a)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-meeti...
--
Chris Murphy
3:27 p.m.
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(a)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.
--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
5:03 p.m.
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(a)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(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- "You think that's tough? Try herding cats!" -
----------------------------------------------------------------------
5:12 p.m.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2:39 a.m.
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.
--
-- Jos Vos <jos(a)xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
8:41 p.m.
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
10:37 a.m.
A ticket has been opened with FESCo.
https://fedorahosted.org/fesco/ticket/1412
--
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
3362
days inactive
3374
days old
79 comments
27 participants
participants (27)
-
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