Hi,
In the latest Fedora 19 Beta TC2 install after I got through the initial steps of the install I started to setup my root password.
To my surprise my password was shown in plain text instead of bullets.
I believe that this is a major security risk and that this is a new UI change going forward and this is not a bug.
Do you think this is a good idea?
What if you are installing and someone is looking over your shoulder and you don't know about this new "UI improvement"?
Someone would see a password that you may or may not often use whether it's secure or not.
Even if someone watched you type the password or recorded it with a camera, that would be harder to decrypt than just showing it in plain text while you type it in to anaconda.
In addition, it was stated that this is becoming a "popular" UI enhancement but there was no documentation provided as to where this is popular. In my experience you would click on an icon next to the dialog box if you wanted to see the password. This is what is becoming popular. Not showing it as plain text while you type.
Thoughts?
Dan
I think that the previous behaviour was better. (covering the password with bullets).
At least the phones only show one character at a time, not the whole password.
Cheers.
On Fri, May 3, 2013 at 5:04 PM, Dan Mashal dan.mashal@gmail.com wrote:
Hi,
In the latest Fedora 19 Beta TC2 install after I got through the initial steps of the install I started to setup my root password.
To my surprise my password was shown in plain text instead of bullets.
I believe that this is a major security risk and that this is a new UI change going forward and this is not a bug.
Do you think this is a good idea?
What if you are installing and someone is looking over your shoulder and you don't know about this new "UI improvement"?
Someone would see a password that you may or may not often use whether it's secure or not.
Even if someone watched you type the password or recorded it with a camera, that would be harder to decrypt than just showing it in plain text while you type it in to anaconda.
In addition, it was stated that this is becoming a "popular" UI enhancement but there was no documentation provided as to where this is popular. In my experience you would click on an icon next to the dialog box if you wanted to see the password. This is what is becoming popular. Not showing it as plain text while you type.
Thoughts?
Dan
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 05/03/2013 03:08 PM, Reartes Guillermo wrote:
I think that the previous behaviour was better. (covering the password with bullets).
At least the phones only show one character at a time, not the whole password.
GTK shows everything or nothing with visibility being a boolean setting. GTK would need to gain the ability to do this most likely through a new property for a GtkEntry widget.
On 04.05.2013 07:26, Michael Cronenworth wrote:
On 05/03/2013 03:08 PM, Reartes Guillermo wrote:
I think that the previous behaviour was better. (covering the password with bullets).
At least the phones only show one character at a time, not the whole password.
GTK shows everything or nothing with visibility being a boolean setting. GTK would need to gain the ability to do this most likely through a new property for a GtkEntry widget.
There's already this exact phoneish password hint capability in GTK+ with the 'gtk-entry-password-hint-timeout' setting. Turn it on in $XDG_CONFIG_HOME/gtk-3.0/settings.ini, or use gtk_settings_set_string_property()
Cheers,
Stef
H
On Sat, May 4, 2013 at 3:29 AM, Stef Walter stefw@redhat.com wrote:
There's already this exact phoneish password hint capability in GTK+ with the 'gtk-entry-password-hint-timeout' setting. Turn it on in $XDG_CONFIG_HOME/gtk-3.0/settings.ini, or use gtk_settings_set_string_property()
This sounds pretty neat but I am unable to get this to work. I have tried "gtk-entry-password-hint-timeout"=600 and without the quotes as well.
Rahul
Hi
On Sat, May 4, 2013 at 4:06 AM, Rahul Sundaram wrote:
This sounds pretty neat but I am unable to get this to work. I have tried "gtk-entry-password-hint-timeout"=600 and without the quotes as well.
Never mind. For anyone else looking, just use the format in /etc/gtk-3.0/settings.ini
Rahul
On 05/04/2013 02:29 AM, Stef Walter wrote:
There's already this exact phoneish password hint capability in GTK+ with the 'gtk-entry-password-hint-timeout' setting. Turn it on in $XDG_CONFIG_HOME/gtk-3.0/settings.ini, or use gtk_settings_set_string_property()
I forgot about that setting. It works just like it should. Thanks.
On Sat, 2013-05-04 at 00:26 -0500, Michael Cronenworth wrote:
On 05/03/2013 03:08 PM, Reartes Guillermo wrote:
I think that the previous behaviour was better. (covering the password with bullets).
At least the phones only show one character at a time, not the whole password.
GTK shows everything or nothing with visibility being a boolean setting. GTK would need to gain the ability to do this most likely through a new property for a GtkEntry widget.
GTK+ has been able to do for a very long time. See
https://developer.gnome.org/gtk3/3.8/GtkSettings.html#GtkSettings--gtk-entry...
On Mon, 2013-05-06 at 12:48 -0400, Matthias Clasen wrote:
On Sat, 2013-05-04 at 00:26 -0500, Michael Cronenworth wrote:
On 05/03/2013 03:08 PM, Reartes Guillermo wrote:
I think that the previous behaviour was better. (covering the password with bullets).
At least the phones only show one character at a time, not the whole password.
GTK shows everything or nothing with visibility being a boolean setting. GTK would need to gain the ability to do this most likely through a new property for a GtkEntry widget.
GTK+ has been able to do for a very long time. See
https://developer.gnome.org/gtk3/3.8/GtkSettings.html#GtkSettings--gtk-entry...
Is there a standard GTK+ widget for the apparently-fairly-popular compromise of 'hidden with a confirmation box by default, with a button that shows the password and greys out the confirmation box'?
On Mon, 2013-05-06 at 11:01 -0700, Adam Williamson wrote:
On Mon, 2013-05-06 at 12:48 -0400, Matthias Clasen wrote:
On Sat, 2013-05-04 at 00:26 -0500, Michael Cronenworth wrote:
On 05/03/2013 03:08 PM, Reartes Guillermo wrote:
I think that the previous behaviour was better. (covering the password with bullets).
At least the phones only show one character at a time, not the whole password.
GTK shows everything or nothing with visibility being a boolean setting. GTK would need to gain the ability to do this most likely through a new property for a GtkEntry widget.
GTK+ has been able to do for a very long time. See
https://developer.gnome.org/gtk3/3.8/GtkSettings.html#GtkSettings--gtk-entry...
Is there a standard GTK+ widget for the apparently-fairly-popular compromise of 'hidden with a confirmation box by default, with a button that shows the password and greys out the confirmation box'?
No, and I don't think it is a very likely candidate for a widget to add to GTK. I could see adding a password entry widget that adds the peekabo eye thingie.
what if the password IS 12 bullet characters :)
Three UI elements:
* two password fields that do not echo the password by default or covers it with bullets or asterisks. * one check-box that shows the password if the user wishes so.
It is the most flexible scheme. If one doubts the typed password and re-typing it is not desirable or enough (if one suspects the keyboard) having a check-box that shows the password covers that usage case. And the user will make sure when to enable the check-box (and when not to).
When one installs fedora, who is near to you when you install fedora, who is looking at you when you install fedora and the size of the password one will use for fedora, should not make uncomfortable the act of installing fedora. Ultimately, it is the responsibility of the user to not to get its password 'seen' (by any means), but i think the mentioned scheme is more convenient.
Cheers.
On Mon, May 6, 2013 at 9:41 AM, Przemek Klosowski < przemek.klosowski@nist.gov> wrote:
On 05/03/2013 04:08 PM, Reartes Guillermo wrote:
I think that the previous behaviour was better. (covering the password with bullets).
what if the password IS 12 bullet characters :)
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel
On May 3, 2013, at 2:04 PM, Dan Mashal dan.mashal@gmail.com wrote:
I believe that this is a major security risk and that this is a new UI change going forward and this is not a bug.
Do you think this is a good idea?
No. I think it's a bug, and a bug should be filed on it.
Chris Murphy
On Fri, May 3, 2013 at 2:17 PM, Chris Murphy lists@colorremedies.com wrote:
On May 3, 2013, at 2:04 PM, Dan Mashal dan.mashal@gmail.com wrote:
I believe that this is a major security risk and that this is a new UI change going forward and this is not a bug.
Do you think this is a good idea?
No. I think it's a bug, and a bug should be filed on it.
Chris Murphy
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
It was.
And closed as NOTABUG.
https://bugzilla.redhat.com/show_bug.cgi?id=959541 https://bugzilla.redhat.com/show_bug.cgi?id=958608
So I just wanted to email other intelligent people and see if I was crazy or stupid.
Dan
On 3 May 2013 15:26, Dan Mashal dan.mashal@gmail.com wrote:
On Fri, May 3, 2013 at 2:17 PM, Chris Murphy lists@colorremedies.com wrote:
On May 3, 2013, at 2:04 PM, Dan Mashal dan.mashal@gmail.com wrote:
I believe that this is a major security risk and that this is a new UI change going forward and this is not a bug.
Do you think this is a good idea?
No. I think it's a bug, and a bug should be filed on it.
Chris Murphy
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
It was.
And closed as NOTABUG.
https://bugzilla.redhat.com/show_bug.cgi?id=959541 https://bugzilla.redhat.com/show_bug.cgi?id=958608
So I just wanted to email other intelligent people and see if I was crazy or stupid.
I would have to say that this would be considered a security bug in certain environments as the security controls assume that the password is not visible and can't be made visible if the person typing in gets distracted (intentionally or unintentionally) and removed from the desk for a short time.
Dan
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On May 3, 2013, at 3:26 PM, Dan Mashal dan.mashal@gmail.com wrote:
So I just wanted to email other intelligent people and see if I was crazy or stupid.
Seems specious to me. I haven't seen an implementation like this. It's sorta like flipping off your parents to their faces, then 2 seconds later covering your hand, rather than flipping them off behind their back. In the former case you have a virtual 100% chance of getting caught. In the latter case, you have a decent chance of not being caught.
Oh wait, except, right after you cover your hand, you immediately do the same exact thing a 2nd time. To their faces. Yeah. I think it's about 100% if anyone's remotely paying attention.
The password entry paradigm is in the realm of ridiculous to asinine. But the proposed method exposes more of the user password entry than previously. If the idea is that it therefore makes the user nervous enough that they become more aware of their surroundings, than the false sense of security of immediately obscuring password entry, I might buy that this ends up being more effective on average. (Most users don't have enemies who can afford to deploy robot flies on walls to capture their password entry.)
Chris Murphy
On Fri, 2013-05-03 at 14:26 -0700, Dan Mashal wrote:
So I just wanted to email other intelligent people and see if I was crazy or stupid.
Dan
I don't ever want my password visible onscreen when I am typing it. I'm not worried about people staring at my keyboard when I'm typing my password; unless people are actually out to get you, that's paranoid. I just reasonably don't want them to see it if they're looking at my screen when I'm typing it....
I don't see the point in Anaconda implementing this while GNOME is bulleting out passwords (and I hope GNOME doesn't change that; there would be an uproar).
On Friday 03 May 2013 14:26:22 Dan Mashal wrote:
... And closed as NOTABUG.
https://bugzilla.redhat.com/show_bug.cgi?id=959541 https://bugzilla.redhat.com/show_bug.cgi?id=958608
I've read through it and didn't know if I should lough or cry.
Before referring the subject matter: Are security-related decisions taken without speaking with security-people first? (Dan Walsh? Any other?)
But I'll try to analyze few of the points raised in the BR...
Hiding the password as you type doesn't actually do anything for security, as anyone watching your monitor could just watch your keyboard instead.
Not really: * The keyboard is much closer to the body and someone has to be *really close to me* to see it (even then it may be partly obscured).
* On the other hand, a password on a monitor may be visible even to someone passing by for a split second (even by mistake) -- the exposure is orders of magnitude higher.
Not if you're a fast typer.
Okay, I'll record your typing with my phone and play it back slower later. Typing speed has nothing to do with anything.
Again: * Someone can easily record my screen from across the room (zoom) * How much of my keyboard they'd see from such a distance? Considering my back, elbows, palms (yes I type with 10 fingers) -- not much.
And here comes the best part...
There's quite a few papers about this right now.... ... and in a way that does not require yet another widget which needs layout, translation, and all that kind of stuff.
Passwords are really bad security mechanism (and you can find lot's of papers describing their drawbacks). By this line of thought, maybe we can get rid of the whole root password thingie...
This would save us at least 3 widgets (two text fields and a "done" button), with all their layout, translation and all that kind of stuff.
OK, so that last one was a bad joke, just like exposing typed passwords...
On 05/03/2013 05:26 PM, Dan Mashal wrote:
And closed as NOTABUG. https://bugzilla.redhat.com/show_bug.cgi?id=959541 https://bugzilla.redhat.com/show_bug.cgi?id=958608 So I just wanted to email other intelligent people and see if I was crazy or stupid.
I have reopened this. Clearly, this is a unprecedented decision and it should be reconsidered.
Rahul
On Fri, May 03, 2013 at 07:42:12PM -0400, Rahul Sundaram wrote:
On 05/03/2013 05:26 PM, Dan Mashal wrote:
And closed as NOTABUG. https://bugzilla.redhat.com/show_bug.cgi?id=959541 https://bugzilla.redhat.com/show_bug.cgi?id=958608 So I just wanted to email other intelligent people and see if I was crazy or stupid.
I have reopened this. Clearly, this is a unprecedented decision and it should be reconsidered.
It's unprecedented for maintainers to make UI decisions about the software they develop and maintain?
On Fri, May 03, 2013 at 10:36:51PM -0400, Rahul Sundaram wrote:
On 05/03/2013 10:31 PM, Matthew Garrett wrote:
It's unprecedented for maintainers to make UI decisions about the software they develop and maintain?
Is that a rhetorical question? I was referring to the decision to show the password in full when the user is typing it.
Many UI decisions are unprecedented. That doesn't justify reopening bugs that the maintainer has closed. If you want to have a discussion about whether or not this is a reasonable UI decision, do so somewhere other than Bugzilla.
On 05/03/2013 10:59 PM, Matthew Garrett wrote:
Many UI decisions are unprecedented. That doesn't justify reopening bugs that the maintainer has closed. If you want to have a discussion about whether or not this is a reasonable UI decision, do so somewhere other than Bugzilla
This isn't a minor UI change but that one that has fairly serious security and privacy concerns. I feel more than justified in reopening the bug.
Rahul
On Fri, May 03, 2013 at 23:11:56 -0400, Rahul Sundaram metherid@gmail.com wrote:
On 05/03/2013 10:59 PM, Matthew Garrett wrote:
Many UI decisions are unprecedented. That doesn't justify reopening bugs that the maintainer has closed. If you want to have a discussion about whether or not this is a reasonable UI decision, do so somewhere other than Bugzilla
This isn't a minor UI change but that one that has fairly serious security and privacy concerns. I feel more than justified in reopening the bug.
It's not like the people entering the password don't know it is visible. I expect people to take reasonable precautions when entering it given that information. Actually being able to see a password you are creating can help with memory and this could conceivably encourage people to choose more complex passwords.
On Fri, May 03, 2013 at 23:26:51 -0400, Rahul Sundaram metherid@gmail.com wrote:
On 05/03/2013 11:22 PM, Bruno Wolff III wrote:
It's not like the people entering the password don't know it is visible.
On the contrary, it is entirely unexpected that the UI will not hide it.
Are you refering to someone ther than the person who is looking at the screen while typing in their password? Surely the person doing that will know it is visible and not enter it while someone is obviously looking at their screen.
I didn't notice this the last time I did an install. But yes, it's a *problem* if it does that. I'll upvote or whatever if someone re-opens; I do so many installs in coffee shops that I would flat out not use a distro that did this!
On Fri, May 3, 2013 at 8:28 PM, Bruno Wolff III bruno@wolff.to wrote:
On Fri, May 03, 2013 at 23:26:51 -0400, Rahul Sundaram metherid@gmail.com wrote:
On 05/03/2013 11:22 PM, Bruno Wolff III wrote:
It's not like the people entering the password don't know it is visible.
On the contrary, it is entirely unexpected that the UI will not hide it.
Are you refering to someone ther than the person who is looking at the screen while typing in their password? Surely the person doing that will know it is visible and not enter it while someone is obviously looking at their screen.
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel
On Fri, May 3, 2013 at 8:40 PM, M. Edward (Ed) Borasky znmeb@znmeb.net wrote:
I didn't notice this the last time I did an install. But yes, it's a *problem* if it does that. I'll upvote or whatever if someone re-opens; I do so many installs in coffee shops that I would flat out not use a distro that did this!
I observed this while installing with BETA TC2
Link:
https://dl.fedoraproject.org/pub/alt/stage/19-Beta-TC2/Fedora/x86_64/iso/Fed...
I see a TC3 but no x86_64 ISO yet.
Dan
On Fri, May 3, 2013 at 9:40 PM, M. Edward (Ed) Borasky znmeb@znmeb.netwrote:
I didn't notice this the last time I did an install. But yes, it's a *problem* if it does that. I'll upvote or whatever if someone re-opens; I do so many installs in coffee shops that I would flat out not use a distro that did this!
Regardless of the arguments for either position, whether for ease of use and pseudosecurity or for peace of mind and tradition, I think the above will be the reaction from the world at large. There may be valid and convincing reasons to cease obfuscating passwords, but doing so would put Fedora supporters in the position of presenting those justifications regularly.
Personally, I think it presents a false sense of security, and any valid concerns can easily be rectified by changing the password after installation. However, users **expect** that security, and the result of removing it will be calamitous. We'll get lambasted by the tech press, flamed on user forums, and dejected head-shaking in server rooms. Opportunities to provide a righteous counterargument will be few and readily dismissed.
I'll make a small concession here. The demographic most affected by the propaganda I'm describing are casual or inexperienced users, and not part of Fedora's traditional user base. Keep in mind that these users are also prospective Fedora users, and have the potential to gain experience, become proficient, and perhaps even become active contributors.
People **will** bitch about being able to read the password as they type it. "Any Press is Good Press" is a bromide that Fedora shouldn't test.
- Pete Travis - Fedora Docs Project Leader - 'randomuser' on freenode - immanetize@fedoraproject.org
On 05/03/2013 11:28 PM, Bruno Wolff III wrote:
Are you refering to someone ther than the person who is looking at the screen while typing in their password? Surely the person doing that will know it is visible and not enter it while someone is obviously looking at their screen.
It may not be obvious at all. While you don't have necessarily have anyone sitting right next to you, it would be visible in the screen. A password shown in the screen is far more visible compared to someone having to overlook the keyboard. Users don't expect any UI to show the entire password and this UI change would come as a unpleasant surprise especially if they are looking at the keyboard while typing which many users do. Well, sure, once they realize it, they can retype a new password in private but why would we make them go through that pain unnecessarily? That is pretty awful for usability.
It is *very* useful to be able to see the password you are typing at times when there is no such privacy concern but this is precisely why some password fields have a "show password" checkbox but not as the default behavior.
Rahul
On Saturday, May 04, 2013 11:28 AM, Bruno Wolff III wrote:
On Fri, May 03, 2013 at 23:26:51 -0400, Rahul Sundaram metherid@gmail.com wrote:
On 05/03/2013 11:22 PM, Bruno Wolff III wrote:
It's not like the people entering the password don't know it is visible.
On the contrary, it is entirely unexpected that the UI will not hide it.
Are you refering to someone ther than the person who is looking at the screen while typing in their password?
Many people look at the keyboard when they type.
They would realize that the password is visible only ahen they have finished typing it.
Once upon a time, Bruno Wolff III bruno@wolff.to said:
It's not like the people entering the password don't know it is visible.
Actually, yes it is. The vast majority of other software that accepts passwords for any reason hides the passwords as they are typed, so the general expectation is that passwords are not displayed on the screen. Many people look down at the keyboard to type and would not necessarily look up as they are typing the password. So, they probably won't know the password is displayed in the clear on their screen until they are done.
On Fri, May 3, 2013 at 10:45 PM, Chris Adams cmadams@hiwaay.net wrote:
Once upon a time, Bruno Wolff III bruno@wolff.to said:
It's not like the people entering the password don't know it is visible.
Actually, yes it is. The vast majority of other software that accepts passwords for any reason hides the passwords as they are typed, so the general expectation is that passwords are not displayed on the screen. Many people look down at the keyboard to type and would not necessarily look up as they are typing the password. So, they probably won't know the password is displayed in the clear on their screen until they are done.
It gets worse. Say you dont use the mouse. Keyboard only. Type a weak password, which is shown in plaintext, TWICE. Now you tab over to done and your password is shown YET AGAIN for a THIRD time in plain text. This occurs during root password and user/administrator password creation.
Dan
On Fri, May 3, 2013 at 10:45 PM, Chris Adams cmadams@hiwaay.net wrote:
The vast majority of other software that accepts passwords for any reason hides the passwords as they are typed, so the general expectation is that passwords are not displayed on the screen.
More to the point, the vast majority of the other software *in Fedora* that accepts passwords for any reason hides the passwords as they are typed. If this is really broken (and who knows; neither side has really produced much in the way of science), it needs to be fixed in GTK (and Qt, and `passwd`, and a bunch of other places), not papered over in anaconda.
I think it's reasonable to expect the Fedora installer to handle passwords in a manner consistent with the rest of the operating system.
-T.C.
On Sat, May 4, 2013 at 11:06 AM, T.C. Hollingsworth tchollingsworth@gmail.com wrote:
More to the point, the vast majority of the other software *in Fedora* that accepts passwords for any reason hides the passwords as they are typed. If this is really broken (and who knows; neither side has really produced much in the way of science), it needs to be fixed in GTK (and Qt, and `passwd`, and a bunch of other places), not papered over in anaconda.
Without intending to express any support for the change, I do think it's important to point out that anaconda is not the same as most of these other cases because there is substantial potential for keyboard mapping error. Most of the other contexts you've named are on an already running system where its harder to notice that your keyboard mapping is screwy.
(OTOH, the stakes for a keyboard-remap-password-loss incident couldn't be lower than during install— at worst you're confused as a result and have to reinstall, but you don't lose data)
On Sat, May 4, 2013 at 10:27 PM, Gregory Maxwell gmaxwell@gmail.com wrote:
On Sat, May 4, 2013 at 11:06 AM, T.C. Hollingsworth tchollingsworth@gmail.com wrote:
More to the point, the vast majority of the other software *in Fedora* that accepts passwords for any reason hides the passwords as they are typed. If this is really broken (and who knows; neither side has really produced much in the way of science), it needs to be fixed in GTK (and Qt, and `passwd`, and a bunch of other places), not papered over in anaconda.
Without intending to express any support for the change, I do think it's important to point out that anaconda is not the same as most of these other cases because there is substantial potential for keyboard mapping error. Most of the other contexts you've named are on an already running system where its harder to notice that your keyboard mapping is screwy.
(OTOH, the stakes for a keyboard-remap-password-loss incident couldn't be lower than during install— at worst you're confused as a result and have to reinstall, but you don't lose data)
Well at the time I wrote that, the only issue that had been raised was that password masking might not be as secure if everyone thought it was. If that's what's broken, my point still stands—anaconda is not the right place to fix it.
But if our keyboard mapping selection is also broken, the root password entry is also not the right place to fix it. By the time you're entering the root password in the new UI, you've already started installation and it's too late to go back and change your keyboard mapping. Only letting our users know something is broken *after* it's too late to fix it is just cruel. (That being said, there are some suggestions in this thread to fix that problem too, by providing a keyboard indicator or such.)
IMHO the root password selection screen should be hidden away as a button on the user creation screen. That way the username and real name fields on that screen would be the obvious "my keyboard layout is wrong" indicators (sidestepping the whole password masking issue) and we deemphasize selecting a root password, which most normal users shouldn't need to deal with. (Right now, user creation and root password selection kind of look equally important sitting next to each other on the "configure stuff while installing" hub.)
-T.C.
On Friday 03 May 2013 22:22:47 Bruno Wolff III wrote:
It's not like the people entering the password don't know it is visible.
I for one, will finish typing the password *way before* realizing it's visible: * Touch typing is fast * With passwords it's even faster: - Because it's very common. - Because I don't want by-standers to be able to grasp it from looking at my fingers. * You never expect the Spanish Inquisition will make such a UI change ;-)
On Fri, May 03, 2013 at 11:11:56PM -0400, Rahul Sundaram wrote:
On 05/03/2013 10:59 PM, Matthew Garrett wrote:
Many UI decisions are unprecedented. That doesn't justify reopening bugs that the maintainer has closed. If you want to have a discussion about whether or not this is a reasonable UI decision, do so somewhere other than Bugzilla
This isn't a minor UI change but that one that has fairly serious security and privacy concerns. I feel more than justified in reopening the bug.
And if the maintainers feel more than justified in closing it again? Bugzilla isn't a discussion forum. If disagree with a deliberate policy decision, discuss it on an appropriate mailing list.
On Fri, May 3, 2013 at 8:51 PM, Matthew Garrett mjg59@srcf.ucam.org wrote:
On Fri, May 03, 2013 at 11:11:56PM -0400, Rahul Sundaram wrote:
On 05/03/2013 10:59 PM, Matthew Garrett wrote:
Many UI decisions are unprecedented. That doesn't justify reopening bugs that the maintainer has closed. If you want to have a discussion about whether or not this is a reasonable UI decision, do so somewhere other than Bugzilla
This isn't a minor UI change but that one that has fairly serious security and privacy concerns. I feel more than justified in reopening the bug.
And if the maintainers feel more than justified in closing it again? Bugzilla isn't a discussion forum. If disagree with a deliberate policy decision, discuss it on an appropriate mailing list.
-- Matthew Garrett | mjg59@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Isn't that what we're doing? That's exactly the point of this email thread.
Dan
On Fri, May 03, 2013 at 08:52:25PM -0700, Dan Mashal wrote:
On Fri, May 3, 2013 at 8:51 PM, Matthew Garrett mjg59@srcf.ucam.org wrote:
And if the maintainers feel more than justified in closing it again? Bugzilla isn't a discussion forum. If disagree with a deliberate policy decision, discuss it on an appropriate mailing list.
Isn't that what we're doing? That's exactly the point of this email thread.
No, this isn't the most appropriate mailing list for the discussion - anaconda-devel-list is a better choice if you want to interact with the people who actually work on that code. In any case, I was disagreeing with Rahul's assertion that he was justified in re-opening a bug merely because he disagreed with a design choice.
(Please trim the emails you're replying to. It's a pain to have to cut out my own signature just to make the mail coherent in isolation)
On Fri, May 3, 2013 at 8:58 PM, Matthew Garrett mjg59@srcf.ucam.org wrote:
On Fri, May 03, 2013 at 08:52:25PM -0700, Dan Mashal wrote:
On Fri, May 3, 2013 at 8:51 PM, Matthew Garrett mjg59@srcf.ucam.org wrote:
And if the maintainers feel more than justified in closing it again? Bugzilla isn't a discussion forum. If disagree with a deliberate policy decision, discuss it on an appropriate mailing list.
Isn't that what we're doing? That's exactly the point of this email thread.
No, this isn't the most appropriate mailing list for the discussion - anaconda-devel-list is a better choice if you want to interact with the people who actually work on that code. In any case, I was disagreeing with Rahul's assertion that he was justified in re-opening a bug merely because he disagreed with a design choice.
(Please trim the emails you're replying to. It's a pain to have to cut out my own signature just to make the mail coherent in isolation) -- Matthew Garrett | mjg59@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
This is a wider audience. I believe this was a better group of people to ask.
Dan
On Fri, May 03, 2013 at 08:59:11PM -0700, Dan Mashal wrote:
On Fri, May 3, 2013 at 8:58 PM, Matthew Garrett mjg59@srcf.ucam.org wrote:
No, this isn't the most appropriate mailing list for the discussion anaconda-devel-list is a better choice if you want to interact with the people who actually work on that code. In any case, I was disagreeing with Rahul's assertion that he was justified in re-opening a bug merely because he disagreed with a design choice.
This is a wider audience. I believe this was a better group of people to ask.
The people you need to convince are the Anaconda developers. The place to discuss things with them is the Anaconda mailing list.
(Please trim the emails you're replying to. It's a pain to have to cut out my own signature just to make the mail coherent in isolation) -- Matthew Garrett | mjg59@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Seriously. Learn to trim or I'm never reading email from you again.
On Fri, May 3, 2013 at 9:03 PM, Matthew Garrett mjg59@srcf.ucam.org wrote:
Seriously. Learn to trim or I'm never reading email from you again.
Is this better? Quite frankly I could care less whether you read my email or not.
Dan
On 2013-05-04 04:58 (GMT+0100) Matthew Garrett composed:
this isn't the most appropriate mailing list for the discussion - anaconda-devel-list is a better choice if you want to interact with the people who actually work on that code.
I strongly disagree. The policy implication of this violation of tradition and expectation goes beyond Anaconda.
On Sat, May 04, 2013 at 12:11:21AM -0400, Felix Miata wrote:
On 2013-05-04 04:58 (GMT+0100) Matthew Garrett composed:
this isn't the most appropriate mailing list for the discussion - anaconda-devel-list is a better choice if you want to interact with the people who actually work on that code.
I strongly disagree. The policy implication of this violation of tradition and expectation goes beyond Anaconda.
If you want to change a decision, it helps if you're discussing it in a forum that's read by the people who made that decision.
On Fri, May 3, 2013 at 9:32 PM, Matthew Garrett mjg59@srcf.ucam.org wrote:
If you want to change a decision, it helps if you're discussing it in a forum that's read by the people who made that decision.
Anaconda developers don't read the developer list? That's terrible!
On Fri, May 3, 2013 at 9:35 PM, Matthew Garrett mjg59@srcf.ucam.org wrote:
Bugzilla's a dreadful place to have discussions. The lack of threading means unpopular decisions tend to just result in large numbers of contentless comments which make meaningful discussion impossible - it's a nightmare to find appropriate context. If a project doesn't have a mailing list then Bugzilla may be the least worst choice, but where it does then make use of it.
Thanks. Can you stop littering this thread now? We got your point.
Le vendredi 03 mai 2013 à 21:41 -0700, Dan Mashal a écrit :
On Fri, May 3, 2013 at 9:32 PM, Matthew Garrett mjg59@srcf.ucam.org wrote:
If you want to change a decision, it helps if you're discussing it in a forum that's read by the people who made that decision.
Anaconda developers don't read the developer list? That's terrible!
That's the whole point of having a separate list in the first place, so people are not forced to read a high volume list like fedora-devel.
On Fri, May 03, 2013 at 09:41:39PM -0700, Dan Mashal wrote:
On Fri, May 3, 2013 at 9:32 PM, Matthew Garrett mjg59@srcf.ucam.org wrote:
If you want to change a decision, it helps if you're discussing it in a forum that's read by the people who made that decision.
Anaconda developers don't read the developer list? That's terrible!
Many Fedora developers don't read the developer list.
On Sat, 4 May 2013 05:32:18 +0100 Matthew Garrett mjg59@srcf.ucam.org wrote:
I strongly disagree. The policy implication of this violation of tradition and expectation goes beyond Anaconda.
If you want to change a decision, it helps if you're discussing it in a forum that's read by the people who made that decision.
This is a perfectly appropriate forum where their authority for making this decision is to be discussed before it's revoked if necessary.
-- Pete
On Fri, May 3, 2013 at 9:53 PM, Pete Zaitcev zaitcev@redhat.com wrote:
This is a perfectly appropriate forum where their authority for making this decision is to be discussed before it's revoked if necessary.
Hi Pete. Thanks for your very helpful reply. You mentioned something VERY important, so now I have a very important question.
What would be the process for "revoking" the privilege of these crazy decisions from the design / anaconda development team and giving them back to the community where they belong? Making the process more open so we can avoid these ridiculous discussions, flame wars, regressions, security holes, and over all unhappiness for all parties involved?
I would like to stress that this is not the first, nor will it be the last time since the complete redesign of the installer since Fedora 18 that flame wars and absolutely atrocious design decisions without community approval have been made and this needs to stop.
Thanks, Dan
On Fri, May 03, 2013 at 10:53:35PM -0600, Pete Zaitcev wrote:
On Sat, 4 May 2013 05:32:18 +0100 Matthew Garrett mjg59@srcf.ucam.org wrote:
If you want to change a decision, it helps if you're discussing it in a forum that's read by the people who made that decision.
This is a perfectly appropriate forum where their authority for making this decision is to be discussed before it's revoked if necessary.
The authority for making this decision is, as always, in the hands of the individuals who write the code. We do have a process for overruling that authority, but that's a last resort - people should assume that maintainers are acting in good faith and engage in a discussion *with the maintainers* before thinking about ways of forcing them to revert.
On 5/3/13 10:58 PM, Matthew Garrett wrote:
On Fri, May 03, 2013 at 08:52:25PM -0700, Dan Mashal wrote:
On Fri, May 3, 2013 at 8:51 PM, Matthew Garrett mjg59@srcf.ucam.org wrote:
And if the maintainers feel more than justified in closing it again? Bugzilla isn't a discussion forum. If disagree with a deliberate policy decision, discuss it on an appropriate mailing list.
Isn't that what we're doing? That's exactly the point of this email thread.
No, this isn't the most appropriate mailing list for the discussion - anaconda-devel-list is a better choice if you want to interact with the people who actually work on that code. In any case, I was disagreeing with Rahul's assertion that he was justified in re-opening a bug merely because he disagreed with a design choice.
Matthew, with all due respect the tone of the bug doesn't make me think that there is a lot of interest in discussion from the developers.
Whether or not bugzilla was the right place to start it, the early discussion went something like this, mostly paraphrased.
Q: This seems to be a bug. My password is visible while I type it. I'm surprised. Is this a bug?
A: It's not a bug. It's intentional. "There's quite a few papers about this right now."
Q: Link?
A: Google it.
At this point things may have turned a bit south. If there is active research or new thinking on this aspect of security, it should be part of the discussion. If there's precedent, it's worth noting specifically. That's the transparent, open approach. This isn't about the placement of a widget; this is about someone's password in clear text. It's worth having a broader discussion about the implications.
If this had been on the anaconda list, most impacted parties would not have seen it. Speaking for myself, I'm glad it was brought up here.
The principal of least surprise is a good one. I think this change breaks it.
What is the downside to defaulting to a hidden PW, with an opt-in mechanism to display the password as it's typed? The downsides of defaulting to cleartext have been noted, and to me are quite self-explanatory.
On the other hand, if it's the right thing to do, then it needs to be done for GUI password change dialogs and the passwd command should be updated as well, for consistency, no?
-Eric
On Fri, May 03, 2013 at 11:24:01PM -0500, Eric Sandeen wrote:
On 5/3/13 10:58 PM, Matthew Garrett wrote:
No, this isn't the most appropriate mailing list for the discussion - anaconda-devel-list is a better choice if you want to interact with the people who actually work on that code. In any case, I was disagreeing with Rahul's assertion that he was justified in re-opening a bug merely because he disagreed with a design choice.
Matthew, with all due respect the tone of the bug doesn't make me think that there is a lot of interest in discussion from the developers.
Reopening bugs is generally a good way of ensuring that there's even less interest in discussion from the developers, and posting to mailing lists that most of the developers concerned don't read has pretty obvious problems in terms of changing their minds.
If this had been on the anaconda list, most impacted parties would not have seen it. Speaking for myself, I'm glad it was brought up here.
I think making people aware of it on devel was a perfectly reasonable thing to do, but most of the rest of the thread has been pretty pointless. We don't make technical decisions by majority vote - most get left up to the maintainers of the project in question.
On 5/3/13 11:30 PM, Matthew Garrett wrote:
On Fri, May 03, 2013 at 11:24:01PM -0500, Eric Sandeen wrote:
On 5/3/13 10:58 PM, Matthew Garrett wrote:
No, this isn't the most appropriate mailing list for the discussion - anaconda-devel-list is a better choice if you want to interact with the people who actually work on that code. In any case, I was disagreeing with Rahul's assertion that he was justified in re-opening a bug merely because he disagreed with a design choice.
Matthew, with all due respect the tone of the bug doesn't make me think that there is a lot of interest in discussion from the developers.
Reopening bugs is generally a good way of ensuring that there's even less interest in discussion from the developers, and posting to mailing lists that most of the developers concerned don't read has pretty obvious problems in terms of changing their minds.
Fair enough, I hadn't looked closely at the timeline on the bug history.
If this had been on the anaconda list, most impacted parties would not have seen it. Speaking for myself, I'm glad it was brought up here.
I think making people aware of it on devel was a perfectly reasonable thing to do, but most of the rest of the thread has been pretty pointless. We don't make technical decisions by majority vote - most get left up to the maintainers of the project in question.
Well, that bears some scrutiny, IMHO.
Anaconda has a pretty special place in this project. It is the uber-administrator of every new Fedora install. We would do better as a community to hash out major changes before they're made, and try to reach some agreement before we implement them.
For example, the choice of the default fs ultimately is implemented in Anaconda, but I'm pretty sure the change wouldn't be made without wider discussion.
Maybe the question is this: How much of the Anaconda team's job is it to set Fedora OS policies and behaviors, vs. to implement them?
-Eric
On Sat, May 04, 2013 at 12:03:39AM -0500, Eric Sandeen wrote:
Anaconda has a pretty special place in this project. It is the uber-administrator of every new Fedora install. We would do better as a community to hash out major changes before they're made, and try to reach some agreement before we implement them.
I've been reading loads and loads of blogs about the Anaconda redesign. That was a pretty major change. Something like showing a password is terribly minor change when developing.
There was a pretty huge outcry about the Anaconda redesign, despite all the blogs. Now there is some small change, and there is a call that "major changes need to be hashed out".
Seems like nothing they'd do would ever be good enough. Getting consensus before most commits sounds like a good way to scare away developers.
On Wed, May 08, 2013 at 10:00:50AM +0200, Olav Vitters wrote:
On Sat, May 04, 2013 at 12:03:39AM -0500, Eric Sandeen wrote:
Anaconda has a pretty special place in this project. It is the uber-administrator of every new Fedora install. We would do better as a community to hash out major changes before they're made, and try to reach some agreement before we implement them.
I've been reading loads and loads of blogs about the Anaconda redesign. That was a pretty major change. Something like showing a password is terribly minor change when developing.
There was a pretty huge outcry about the Anaconda redesign, despite all the blogs. Now there is some small change, and there is a call that "major changes need to be hashed out".
Seems like nothing they'd do would ever be good enough. Getting consensus before most commits sounds like a good way to scare away developers.
If they were coding a music player for their own needs, then you would be right. However Anaconda is something completely different. I am very sorry to say it however Anaconda developers are not doing it for their fun. You can not simply opt out it if you don't like it (unless you try different distribution/OS, I hope this not a goal of this project), there's no alternative to use. And that's the difference. Anaconda as well as any other core component of distribution/OS has to be developed really carefully.
On 05/04/2013 12:30 AM, Matthew Garrett wrote:
On Fri, May 03, 2013 at 11:24:01PM -0500, Eric Sandeen wrote:
Matthew, with all due respect the tone of the bug doesn't make me think that there is a lot of interest in discussion from the developers.
Reopening bugs is generally a good way of ensuring that there's even less interest in discussion from the developers, and posting to mailing lists that most of the developers concerned don't read has pretty obvious problems in terms of changing their minds.
From the process point of view, it does look a little obstructionist: "No, we won't discuss it in Bugzilla"; "No we won't discuss it in fedora-devel either". Reminds me of the joke: "Lunch on Tuesday? Sorry, can't do it on Tuesday---how about Never? is Never good for you?". I understand your point that the concerned Anaconda developers may simply not see the traffic, but they do know about the Bugzilla entry and this discussion on the devel list, so I hope that they could find it in their heart to put out their argument in the forum with the largest possible audience which at the moment seems to be here.
Big changes deserve more explanation and outreach from the developers, not just dropping them in everyone's lap.
On Mon, May 06, 2013 at 09:51:22AM -0400, Przemek Klosowski wrote:
On 05/04/2013 12:30 AM, Matthew Garrett wrote:
On Fri, May 03, 2013 at 11:24:01PM -0500, Eric Sandeen wrote:
Matthew, with all due respect the tone of the bug doesn't make me think that there is a lot of interest in discussion from the developers.
Reopening bugs is generally a good way of ensuring that there's even less interest in discussion from the developers, and posting to mailing lists that most of the developers concerned don't read has pretty obvious problems in terms of changing their minds.
From the process point of view, it does look a little obstructionist: "No, we won't discuss it in Bugzilla"; "No we won't discuss it in fedora-devel either". Reminds me of the joke: "Lunch on Tuesday? Sorry, can't do it on Tuesday---how about Never? is Never good for you?". I understand your point that the concerned Anaconda developers may simply not see the traffic, but they do know about the Bugzilla entry and this discussion on the devel list, so I hope that they could find it in their heart to put out their argument in the forum with the largest possible audience which at the moment seems to be here.
The simple explanation is: - Bugzilla is awful to have a discussion. It is to solve bugs and focus on how to solve a particular bug - If you want a discussion, hold it with the developers Meaning anaconda-developers
Big changes deserve more explanation and outreach from the developers, not just dropping them in everyone's lap.
Define "big". To any developer, this change is minor. Usually "big" or "invasive" is explained as "I have an issue with it", no matter how small.
On 05/04/2013 12:24 AM, Eric Sandeen wrote:
On the other hand, if it's the right thing to do, then it needs to be done for GUI password change dialogs and the passwd command should be updated as well, for consistency, no?
On a related note, Anaconda, GNOME, KDE etc seems to be relying on different rules about what an acceptable password is. We really need to settle on one library and provide a consistent way to tweak it.
Rahul
On Sat, May 4, 2013 at 6:31 AM, Rahul Sundaram metherid@gmail.com wrote:
On 05/04/2013 12:24 AM, Eric Sandeen wrote:
On the other hand, if it's the right thing to do, then it needs to be done for GUI password change dialogs and the passwd command should be updated as well, for consistency, no?
On a related note, Anaconda, GNOME, KDE etc seems to be relying on different rules about what an acceptable password is. We really need to settle on one library and provide a consistent way to tweak it.
"Everything" (certainly Anaconda and GNOME, not sure about KDE) is supposed to use libpwquality. Is that not so? Mirek
On 05/06/2013 10:48 AM, Miloslav Trmač wrote:
On Sat, May 4, 2013 at 6:31 AM, Rahul Sundaram wrote:
On 05/04/2013 12:24 AM, Eric Sandeen wrote: On the other hand, if it's the right thing to do, then it needs to be done for GUI password change dialogs and the passwd command should be updated as well, for consistency, no? On a related note, Anaconda, GNOME, KDE etc seems to be relying on different rules about what an acceptable password is. We really need to settle on one library and provide a consistent way to tweak it."Everything" (certainly Anaconda and GNOME, not sure about KDE) is supposed to use libpwquality. Is that not so?
They are definitely not enforcing the same rules.
Rahul
On Mon, 2013-05-06 at 11:43 -0400, Rahul Sundaram wrote:
On 05/06/2013 10:48 AM, Miloslav Trmač wrote:
On Sat, May 4, 2013 at 6:31 AM, Rahul Sundaram wrote: On 05/04/2013 12:24 AM, Eric Sandeen wrote: On the other hand, if it's the right thing to do, then it needs to be done for GUI password change dialogs and the passwd command should be updated as well, for consistency, no?
On a related note, Anaconda, GNOME, KDE etc seems to be relying on different rules about what an acceptable password is. We really need to settle on one library and provide a consistent way to tweak it."Everything" (certainly Anaconda and GNOME, not sure about KDE) is supposed to use libpwquality. Is that not so?
They are definitely not enforcing the same rules.
One obvious area of inconsistency is that some of the tools _warn_ on weak passwords, and some _block_ on weak passwords. We should standardize on one or the other of those.
On 06.05.2013 18:38, Adam Williamson wrote:
On Mon, 2013-05-06 at 11:43 -0400, Rahul Sundaram wrote:
On 05/06/2013 10:48 AM, Miloslav Trmač wrote:
On Sat, May 4, 2013 at 6:31 AM, Rahul Sundaram wrote: On 05/04/2013 12:24 AM, Eric Sandeen wrote: On the other hand, if it's the right thing to do, then it needs to be done for GUI password change dialogs and the passwd command should be updated as well, for consistency, no?
On a related note, Anaconda, GNOME, KDE etc seems to be relying on different rules about what an acceptable password is. We really need to settle on one library and provide a consistent way to tweak it."Everything" (certainly Anaconda and GNOME, not sure about KDE) is supposed to use libpwquality. Is that not so?
They are definitely not enforcing the same rules.
One obvious area of inconsistency is that some of the tools _warn_ on weak passwords, and some _block_ on weak passwords. We should standardize on one or the other of those.
Not really. It makes complete sense to allow overriding the rules in certain contexts. For example when root is setting another user's password.
Cheers,
Stef
On Mon, 2013-05-06 at 21:37 +0200, Stef Walter wrote:
On 06.05.2013 18:38, Adam Williamson wrote:
On Mon, 2013-05-06 at 11:43 -0400, Rahul Sundaram wrote:
On 05/06/2013 10:48 AM, Miloslav Trmač wrote:
On Sat, May 4, 2013 at 6:31 AM, Rahul Sundaram wrote: On 05/04/2013 12:24 AM, Eric Sandeen wrote: On the other hand, if it's the right thing to do, then it needs to be done for GUI password change dialogs and the passwd command should be updated as well, for consistency, no?
On a related note, Anaconda, GNOME, KDE etc seems to be relying on different rules about what an acceptable password is. We really need to settle on one library and provide a consistent way to tweak it."Everything" (certainly Anaconda and GNOME, not sure about KDE) is supposed to use libpwquality. Is that not so?
They are definitely not enforcing the same rules.
One obvious area of inconsistency is that some of the tools _warn_ on weak passwords, and some _block_ on weak passwords. We should standardize on one or the other of those.
Not really. It makes complete sense to allow overriding the rules in certain contexts. For example when root is setting another user's password.
But they have different behaviours for the same operation. For e.g., initial-setup and g-i-s have different behaviours for setting the password for the first user account.
On 06.05.2013 21:51, Adam Williamson wrote:
On Mon, 2013-05-06 at 21:37 +0200, Stef Walter wrote:
On 06.05.2013 18:38, Adam Williamson wrote:
On Mon, 2013-05-06 at 11:43 -0400, Rahul Sundaram wrote:
On 05/06/2013 10:48 AM, Miloslav Trmač wrote:
On Sat, May 4, 2013 at 6:31 AM, Rahul Sundaram wrote: On 05/04/2013 12:24 AM, Eric Sandeen wrote: On the other hand, if it's the right thing to do, then it needs to be done for GUI password change dialogs and the passwd command should be updated as well, for consistency, no?
On a related note, Anaconda, GNOME, KDE etc seems to be relying on different rules about what an acceptable password is. We really need to settle on one library and provide a consistent way to tweak it."Everything" (certainly Anaconda and GNOME, not sure about KDE) is supposed to use libpwquality. Is that not so?
They are definitely not enforcing the same rules.
One obvious area of inconsistency is that some of the tools _warn_ on weak passwords, and some _block_ on weak passwords. We should standardize on one or the other of those.
Not really. It makes complete sense to allow overriding the rules in certain contexts. For example when root is setting another user's password.
But they have different behaviours for the same operation. For e.g., initial-setup and g-i-s have different behaviours for setting the password for the first user account.
True.
It's on my list of things to do to make AccountsService be able to use PAM to set the password, which then puts it through libpwquality. How that interacts with the password complexity requirements in g-i-s and g-c-c would need to be solved.
Cheers,
Stef
On Wed, 2013-05-08 at 07:04 +0200, Stef Walter wrote:
On 06.05.2013 21:51, Adam Williamson wrote:
On Mon, 2013-05-06 at 21:37 +0200, Stef Walter wrote:
On 06.05.2013 18:38, Adam Williamson wrote:
On Mon, 2013-05-06 at 11:43 -0400, Rahul Sundaram wrote:
On 05/06/2013 10:48 AM, Miloslav Trmač wrote:
On Sat, May 4, 2013 at 6:31 AM, Rahul Sundaram wrote: On 05/04/2013 12:24 AM, Eric Sandeen wrote: On the other hand, if it's the right thing to do, then it needs to be done for GUI password change dialogs and the passwd command should be updated as well, for consistency, no?
On a related note, Anaconda, GNOME, KDE etc seems to be relying on different rules about what an acceptable password is. We really need to settle on one library and provide a consistent way to tweak it."Everything" (certainly Anaconda and GNOME, not sure about KDE) is supposed to use libpwquality. Is that not so?
They are definitely not enforcing the same rules.
One obvious area of inconsistency is that some of the tools _warn_ on weak passwords, and some _block_ on weak passwords. We should standardize on one or the other of those.
Not really. It makes complete sense to allow overriding the rules in certain contexts. For example when root is setting another user's password.
But they have different behaviours for the same operation. For e.g., initial-setup and g-i-s have different behaviours for setting the password for the first user account.
True.
It's on my list of things to do to make AccountsService be able to use PAM to set the password, which then puts it through libpwquality. How that interacts with the password complexity requirements in g-i-s and g-c-c would need to be solved.
Actually it would be much easier to use libpwquality directly and that also allows to use the scoring functionality for passwords that pass the basic checks.
Le vendredi 03 mai 2013 à 23:24 -0500, Eric Sandeen a écrit :
What is the downside to defaulting to a hidden PW, with an opt-in mechanism to display the password as it's typed? The downsides of defaulting to cleartext have been noted, and to me are quite self-explanatory.
First, we need to see why the input default to visible.
The discussion about it have been going since a few years in usability circles when Jakob Nielsen proposed it : http://www.nngroup.com/articles/stop-password-masking/ http://uxmovement.com/forms/why-password-masking-can-hurt-your-sign-up-form/
and I think that even Bruce Schneier have gave his opinion in favor of the proposal : http://www.schneier.com/blog/archives/2009/06/the_problem_wit_2.html http://www.schneier.com/blog/archives/2009/07/the_pros_and_co.html
I can add to that that I have seen more than once people setting a password which was not the one they believed due to : - keyboard layout ( ie, qwerty vs azerty in France ) - small usage difference with Windows way, again on azerty keyboard ( people using capslock on french keyboard to type numbers while they should use shift, as capslock just type capital letter like À or É and not 0 or 2, and if you do not understand, just look on the web to compare how different it is from qwerty-based keyboard )
Or I could also speak of the small non standard keyboard such as macbook one where ~ or | are not printed and where using the wrong keyboard could result in wrong characters if you are unaware of the problem.
Or what about the people where the ASCII ( or ASCII related ) chars are not the norm, and people are forced to use it for the password despite sometime being less familiar with it ( ie, china, japanese, india ) ?
I think we can agree there is a few problems to solve here, and showing the password ( I think ) help to solve them ( or at least minimize the time spent on figuring what is wrong ).
But the discussion is not about that, even if I think the rational around the defaults. Showing by default will help people who are less familiar, hidden by default will satisfy people who think that's a security issue.
Hidden by default and showing it on demand is likely to still be a hindrance to people who may not know they type their password wrong ( because I think most assume that it will work fine, we are not to a point where people assume by default this will fail ).
So what about hiding on demand, and having it visible by default ? This way, people who prefer to have it hidden will be happy, and we are still friendly to non technical users.
( and then the discussion is around the mechanism to hide the password, between "reduce visual clutter" and "have a explicit checkbox" )
Hi
On Sat, May 4, 2013 at 5:37 AM, Michael Scherer wrote:
and I think that even Bruce Schneier have gave his opinion in favor of the proposal : http://www.schneier.com/blog/archives/2009/06/the_problem_wit_2.html http://www.schneier.com/blog/archives/2009/07/the_pros_and_co.html
Not anymore
http://www.out-law.com/page-10152.
Rahul
On Sat, May 04, 2013 at 05:51:02AM -0400, Rahul Sundaram wrote:
Hi
On Sat, May 4, 2013 at 5:37 AM, Michael Scherer wrote:
and I think that even Bruce Schneier have gave his opinion in favor of the proposal : http://www.schneier.com/blog/archives/2009/06/the_problem_wit_2.html http://www.schneier.com/blog/archives/2009/07/the_pros_and_co.html
Not anymore
To be honest it would be a lot more convincing if someone had done a study and published the results of it, rather than just linking to opinions. I was rather hopeful that Neilsen-Norman would have done a study, but they don't publish their results (or rather, you have to pay lots of $$$ to read them).
Science. It works. Appeal to Authority ... more suspect.
Rich.
Richard W.M. Jones <rjones <at> redhat.com> writes:
To be honest it would be a lot more convincing if someone had done a study and published the results of it, rather than just linking to opinions. I was rather hopeful that Neilsen-Norman would have done a study, but they don't publish their results (or rather, you have to pay lots of $$$ to read them).
The Fedora installer is unusual in that's it's used rarely - normally no more often than once every 6 months (except for testers), and for many users it's the first time. Even if there was a study, it would probably be on frequently-used applications and the results might not apply, since it would assume that the user knew in advance exactly how the application behaves. There's no way an average user using the F19 installer for the first time will know in advance that the entire password will be visible, before typing it.
Another opinion.
It is possible to study such things, and even give caveats and error bounds to show uncertainty.
Rich.
On Sat, 2013-05-04 at 19:23 +0100, Richard W.M. Jones wrote:
Another opinion.
It is possible to study such things, and even give caveats and error bounds to show uncertainty.
I went looking, but as T.C. Hollingsworth said, it doesn't appear that either side has produced anything much in the way of empirical research to support its view. Given that, it would seem most prudent to continue with what we've done in the past; the onus would seem to be on the 'don't mask passwords' side to make a convincing case for change. I haven't found anything much beyond the initial pretty small study (62 participants) cited (and conducted) by Nielsen, and that didn't seem to be widely accepted at the time. It was a study of mobile users, and we don't design anaconda for cellphones (someone has noted that there's a significant difference between cellphone and 'regular PC' text entry). It was also tightly focused on web use, and Nielsen seems to have been thinkign about the case where you enter an existing password for authentication, rather than the case where you initially set the password. So it seems dubious to consider it applicable to the case of anaconda.
I'm also not sure that it's easy to design a study that takes into account all the factors here. We can easily measure the usability of various masking approaches, but I think everyone would accept that in *usability* terms, unmasked passwords are best: I think it's generally accepted that this is a case of a usability versus security trade-off, and the questions are a) exactly how much security does masking provide and b) once we have agreed on the terms (exactly how much more usable are unmasked passwords? exactly how much more secure are masked passwords?) where do we decide Fedora should fall?
Measuring the *security* consequences of each approach seems much more difficult; it'd certainly need to be some kind of large-scale experiment, if only to make sure the many other factors that affect password security were evened out. It doesn't seem to be something you can easily test in a day just by sitting 30 people down in a usability lab, at least, because the practical risk of shoulder-surfing is a 'real world' thing you'd have to try and measure somehow. So far as I can tell, no-one's really tried this yet, all the debate seems to be just people citing their wild-ass guesses as to how big of a problem shoulder surfing might be as if they were gospel. And then there's the argument that, if shoulder surfing isn't much of a problem in the real world at present, that's *because passwords are usually masked*, which complicates the question even further.
b) is not something you can measure at all, it's a judgement call. There will inevitably be an element of subjectivity in any decision made on this topic, even if we can perfectly measure the usability and security of each approach under consideration. If we find that, say, one-character-at-a-time masking is almost as usable as unmasked and almost as secure as masked, the subjective decision might be an easy one, but it'd still be subjective.
Nielsen seems to have updated his pages and links over time, so the dates don't really add up, but I'm _pretty_ sure that http://www.nngroup.com/articles/mobile-usability-first-findings/ is the write-up of the actual study he mentions in passing in http://www.nngroup.com/articles/stop-password-masking/ (the note that started all the fuss; it seems to have been updated in places). That write-up does not mention password security at all, so it doesn't seem to have been the focus of the study. Really, his password masking piece seems to be mostly just opinion; he doesn't cite references for most of it, and a lot of it seems like if it was based on actual data at all, it was heavily extrapolated.
To throw some more very inconclusive data on the pile, I'll note that - IIRC - Android's 'pattern lock' feature initially did not have the option to disable the display of the pattern as you enter it. This was added in a later update. It would be interesting to know if that was in response to user demand, or some kind of empirical data, or just some coder's arbitrary decision. (Correct me if I'm wrong there, though...)
On Sat, May 04, 2013 at 12:52:00PM -0700, Adam Williamson wrote:
I haven't found anything much beyond the initial pretty small study (62 participants) cited (and conducted) by Nielsen,
Do you have a link to this one? This is the one I was originally looking for, but I still can't find the actual study.
Rich.
On Sat, 2013-05-04 at 21:06 +0100, Richard W.M. Jones wrote:
On Sat, May 04, 2013 at 12:52:00PM -0700, Adam Williamson wrote:
I haven't found anything much beyond the initial pretty small study (62 participants) cited (and conducted) by Nielsen,
Do you have a link to this one? This is the one I was originally looking for, but I still can't find the actual study.
Nope, me either. That write-up I linked later in the post is the closest I can find, and I'm only 90% sure that's even the study he was talking about.
On Sat, 2013-05-04 at 21:06 +0100, Richard W.M. Jones wrote:
On Sat, May 04, 2013 at 12:52:00PM -0700, Adam Williamson wrote:
I haven't found anything much beyond the initial pretty small study (62 participants) cited (and conducted) by Nielsen,
Do you have a link to this one? This is the one I was originally looking for, but I still can't find the actual study.
Ah. http://www.nngroup.com/reports/mobile-website-and-application-usability/ looks like it might be the actual report, but I'm not about to drop $300 to find out. Even that looks like it's mainly a set of guidelines aimed at web developers extrapolated from the research, and the actual _foundational research_ looks to be skipped over in only 11 pages, according to the table of contents (there's an excerpt freely available which includes the contents). It's also not the original 2009 report, but a 2011 update, though presumably the short write-up of the studies includes the 2009 ones.
Again, Nielsen's actual piece on masking only mentions any study at all very briefly, in passing:
"Password masking has proven to be a particularly nasty usability problem in our testing of mobile devices [hyperlink to http://www.nngroup.com/articles/mobile-usability-update], where typing is difficult and typos are common. But the problem exists for desktop users as well."
That's it. So far as I can see, that's the sole reference to any actual identifiable study. And again, so far as I can see, the entire 2009 debate spiraled out from that single post, with lots of 'experts' adding their subjective $0.02 on either side (mostly against), but no-one actually adding any kind of useful empirical research.
On Sat, 2013-05-04 at 13:20 -0700, Adam Williamson wrote:
That's it. So far as I can see, that's the sole reference to any actual identifiable study. And again, so far as I can see, the entire 2009 debate spiraled out from that single post, with lots of 'experts' adding their subjective $0.02 on either side (mostly against), but no-one actually adding any kind of useful empirical research.
The other link I've seen cited in favour of the change - http://uxmovement.com/forms/why-password-masking-can-hurt-your-sign-up-form/ - again appears to be solely opinion stated as fact. It's all phrased very categorically, but there is no reference I can find to any kind of actual evidential backing.
On Sat, May 4, 2013 at 10:27 PM, Adam Williamson awilliam@redhat.com wrote:
On Sat, 2013-05-04 at 13:20 -0700, Adam Williamson wrote:
That's it. So far as I can see, that's the sole reference to any actual identifiable study. And again, so far as I can see, the entire 2009 debate spiraled out from that single post, with lots of 'experts' adding their subjective $0.02 on either side (mostly against), but no-one actually adding any kind of useful empirical research.
The other link I've seen cited in favour of the change - http://uxmovement.com/forms/why-password-masking-can-hurt-your-sign-up-form/ - again appears to be solely opinion stated as fact. It's all phrased very categorically, but there is no reference I can find to any kind of actual evidential backing.
I wanted to stay out of this discussion but if we want to go this route there you go:
http://dl.acm.org/citation.cfm?doid=2406367.2406384 http://dl.acm.org/citation.cfm?doid=1280680.1280683 http://dl.acm.org/citation.cfm?doid=1968613.1968647 http://dl.acm.org/citation.cfm?doid=1030083.1030116 ....
The change to display the password as plain text is just wrong (see studies / papers above ... you can find a lot more of them).
Seriously this changes just papers over another bug "we suck at keyboard layout selection" ... "fixing" it by showing the password like that is just wrong.
On 05.05.2013 10:54, drago01 wrote:
Seriously this changes just papers over another bug "we suck at keyboard layout selection" ... "fixing" it by showing the password like that is just wrong.
Thank you for writing this here! Password entry box is not a place for testing keyboard layout. Maybe this obvious remark should be forwarded to Anaconda developers?
Pleas don't break unrelated things in UI just to say that some other bugs are fixed by this change. I really don't like to say it but after this whole Anaconda rewrite it's still not as usable as it was in F17 and now this "plain password" issue which fixes nothing occurred!
Mateusz Marzantowicz
Le Sam 4 mai 2013 21:52, Adam Williamson a écrit :
I think it's generally accepted that this is a case of a usability versus security trade-off, and the questions are a) exactly how much security does masking provide and b) once we have agreed on the terms (exactly how much more usable are unmasked passwords? exactly how much more secure are masked passwords?) where do we decide Fedora should fall?
c. how reliable is our input stack?
Let's be honest, non-masking in smartphones does not stem from any security hinsight but from the cheer lack of reliability of virtual keyboards.
(the worse case I know of is trying to type a 63-char wifi key on a virtual keybord with non-familiar layout and masked input field)
On 4 May 2013 19:23, Richard W.M. Jones rjones@redhat.com wrote:
Another opinion.
It is possible to study such things, and even give caveats and error bounds to show uncertainty.
Yes and no. It's possible it a tightly defined setting with specified outcomes. Since a crucial factors here include how likely someone is to either intentionally attempt to steal a password (and how much effort they will go to) or to opportunistically use a casually spotted password and what the consequences of that happening are versus the risk of a potentially wrongly set password it's likely any genuine research is going to be hard to transfer.
Le samedi 04 mai 2013 à 05:51 -0400, Rahul Sundaram a écrit :
Hi
On Sat, May 4, 2013 at 5:37 AM, Michael Scherer wrote:
and I think that even Bruce Schneier have gave his opinion in favor of the proposal : http://www.schneier.com/blog/archives/2009/06/the_problem_wit_2.html http://www.schneier.com/blog/archives/2009/07/the_pros_and_co.htmlNot anymore
This page cite the 2nd link I already gave earlier...
And the way I read it, he explain that for him, the risk of should surfing are overrated. He also say that for a public terminal and a pin code, password should be masked, but for a person on a private computer, that's likely not a problem.
Now of course, the issue is that a installer of a linux distribution is not a web site, so part of the discussion doesn't apply at all.
And being at the moment in a install party ( which is as the most public way of installing a linux system ), I see quite often people writing their passwords on a paper ( and not only during install party ). And if most people have already trouble to keep up their passwords, I think most people will have more problem with passwords of others.
The "show password as we type" proposal is good for a mobile as you likely have accuracy issues with it, but I am not sure that help solving the problems that showing password is (IMHO) meant to solve ( but again, I just speculate on the reason, I trust the designers to make educated choices but I am not mind reading ).
Michael Scherer wrote:
So what about hiding on demand, and having it visible by default ? This way, people who prefer to have it hidden will be happy, and we are still friendly to non technical users.
That might be acceptable but only if there were a big, eye-catching warning that users would notice *before* they start typing.
Björn Persson
On May 4, 2013, at 3:37 AM, Michael Scherer misc@zarb.org wrote:
Or I could also speak of the small non standard keyboard such as macbook one where ~ or | are not printed and where using the wrong keyboard could result in wrong characters if you are unaware of the problem.
I don't know what this means. On my MBP these characters are printed in all applications including in anaconda's plaintext password field. I've yet to experience the behavior you describe on any Mac.
Chris Murphy
Le samedi 04 mai 2013 à 17:06 -0600, Chris Murphy a écrit :
On May 4, 2013, at 3:37 AM, Michael Scherer misc@zarb.org wrote:
Or I could also speak of the small non standard keyboard such as macbook one where ~ or | are not printed and where using the wrong keyboard could result in wrong characters if you are unaware of the problem.
I don't know what this means. On my MBP these characters are printed in all applications including in anaconda's plaintext password field. I've yet to experience the behavior you describe on any Mac.
Indeed, that was not clear ( or it was clear, but in my head only ). I meant "not printed on the keys themself".
And I checked, the issue is not present on qwerty models ( it seems ) , but on azerty layout, the ~ and | are not visible on the keyboard ( at least, on the keyboard I have on my old macbook 2.2 ).
See for example : http://bblfish.net/tmp/2004_09_29/titanium_azerty_keyboard.jpg ( old power book ) http://users.telenet.be/depot/screenshots/mb%20azerty.jpg
and others on google images.
And last time I used it, the mapping was not the same between os x and linux on uc details ( ie, using ctrl vs apple key, if I am not wrong ), but I do not boot on os x any more, so maybe things are better now.
On 05/04/2013 05:37 AM, Michael Scherer wrote:
Or I could also speak of the small non standard keyboard such as macbook one where ~ or | are not printed and where using the wrong keyboard could result in wrong characters if you are unaware of the problem.
Reminds me of the famous case when someone could login while sitting down but not when they were standing up. The reason turned out to be that their keyboard layout was slightly non-standard and the keycodes didn't agree with keycaps. When they were sitting, they touch-typed and hit the correct keys, but when they were standing, they hunt-and-pecked and got the wrong keys.
On Saturday 04 May 2013 04:58:13 Matthew Garrett wrote:
No, this isn't the most appropriate mailing list for the discussion - anaconda-devel-list is a better choice if you want to interact with the people who actually work on that code.
What separate a Linux distro from a random batch of software is *policy* and what happened here is a radical policy change without any *prior* discussion.
Why only installation? By the same token we should apply this logic to any other password entry -- should this go according to each packager taste?
IMO, this kind of change belongs first to fedora-devel and *than* to Fesco.
(and I'm still repeating my previous question in this thread -- are any security related people involved? Or do we assume their opinion on the subject matter isn't relevant)
On Sat, May 04, 2013 at 10:37:04AM +0300, Oron Peled wrote:
What separate a Linux distro from a random batch of software is *policy* and what happened here is a radical policy change without any *prior* discussion.
What happened here was a change in the UI of a single (albeit important) application. It's not a change in the overall policy of the distribution. There's a worthwhile discussion as to whether or not it's something that *should* be overall distribution policy, but when worrying about a single application it makes sense to discuss it with the developers of that application.
On Sat, 2013-05-04 at 04:58 +0100, Matthew Garrett wrote:
On Fri, May 03, 2013 at 08:52:25PM -0700, Dan Mashal wrote:
On Fri, May 3, 2013 at 8:51 PM, Matthew Garrett mjg59@srcf.ucam.org wrote:
And if the maintainers feel more than justified in closing it again? Bugzilla isn't a discussion forum. If disagree with a deliberate policy decision, discuss it on an appropriate mailing list.
Isn't that what we're doing? That's exactly the point of this email thread.
No, this isn't the most appropriate mailing list for the discussion - anaconda-devel-list is a better choice if you want to interact with the people who actually work on that code.
That is not actually what Dan wanted to do, though. If you read his mail, his intent was to bring this decision to the awareness of a wider audience that might have a stake in it. For that purpose, his choice of this list was entirely appropriate; few people besides anaconda developers read anaconda-devel-list, so choosing that list would not have achieved his purpose.
On Sat, May 04, 2013 at 09:42:22AM -0700, Adam Williamson wrote:
On Sat, 2013-05-04 at 04:58 +0100, Matthew Garrett wrote:
No, this isn't the most appropriate mailing list for the discussion - anaconda-devel-list is a better choice if you want to interact with the people who actually work on that code.
That is not actually what Dan wanted to do, though. If you read his mail, his intent was to bring this decision to the awareness of a wider audience that might have a stake in it. For that purpose, his choice of this list was entirely appropriate; few people besides anaconda developers read anaconda-devel-list, so choosing that list would not have achieved his purpose.
The context was me replying to Rahul, who appeared to think that the best way to cause the decision to be reconsidered was to re-open the bug. Raising awareness on devel is a perfectly reasonable thing to do, but further discussion here is not likely to actually change anything in itself.
On 05/03/2013 11:51 PM, Matthew Garrett wrote:
And if the maintainers feel more than justified in closing it again?
Hopefully, they will reconsider their decision before doing that. You seem to be claiming that once the maintainer has a bug report as a deliberate UI change, it should never be reopened no matter what. I don't agree with your opinion in that case.
Rahul
On Fri, May 03, 2013 at 11:55:24PM -0400, Rahul Sundaram wrote:
On 05/03/2013 11:51 PM, Matthew Garrett wrote:
And if the maintainers feel more than justified in closing it again?
Hopefully, they will reconsider their decision before doing that. You seem to be claiming that once the maintainer has a bug report as a deliberate UI change, it should never be reopened no matter what. I don't agree with your opinion in that case.
I'm saying that if a bug report has been closed due to the change being a deliberate design decision, reopening the bug isn't going to change the fact that it was a deliberate design decision. The appropriate place to discuss deliberate design decisions is a forum where said decisions are made, ie not Bugzilla.
On Fri, May 3, 2013 at 9:01 PM, Matthew Garrett mjg59@srcf.ucam.org wrote:
On Fri, May 03, 2013 at 11:55:24PM -0400, Rahul Sundaram wrote:
On 05/03/2013 11:51 PM, Matthew Garrett wrote:
And if the maintainers feel more than justified in closing it again?
Hopefully, they will reconsider their decision before doing that. You seem to be claiming that once the maintainer has a bug report as a deliberate UI change, it should never be reopened no matter what. I don't agree with your opinion in that case.
I'm saying that if a bug report has been closed due to the change being a deliberate design decision, reopening the bug isn't going to change the fact that it was a deliberate design decision. The appropriate place to discuss deliberate design decisions is a forum where said decisions are made, ie not Bugzilla.
-- Matthew Garrett | mjg59@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Let's be realistic here. The precedence they have recently set is they make decisions and if you don't like it "too bad".
Dan
On Wed, 2013-05-08 at 10:10 +0200, Olav Vitters wrote:
On Fri, May 03, 2013 at 09:03:02PM -0700, Dan Mashal wrote:
Let's be realistic here. The precedence they have recently set is they make decisions and if you don't like it "too bad".
Even if that is true, what is your point?
That you are replying to a 4 days old email on a thread that is no longer active?
Pierre
On Wednesday, May 8, 2013, Pierre-Yves Chibon wrote:
On Wed, 2013-05-08 at 10:10 +0200, Olav Vitters wrote:
On Fri, May 03, 2013 at 09:03:02PM -0700, Dan Mashal wrote:
Let's be realistic here. The precedence they have recently set is they make decisions and if you don't like it "too bad".
Even if that is true, what is your point?
That you are replying to a 4 days old email on a thread that is no longer active?
+1
Kevin,
Please close this thread. Mission accomplished as your great wisdom predicted.
Dan
On Wed, 08 May 2013 10:09:13 +0200 Pierre-Yves Chibon pingou@pingoured.fr wrote:
On Wed, 2013-05-08 at 10:10 +0200, Olav Vitters wrote:
On Fri, May 03, 2013 at 09:03:02PM -0700, Dan Mashal wrote:
Let's be realistic here. The precedence they have recently set is they make decisions and if you don't like it "too bad".
Even if that is true, what is your point?
That you are replying to a 4 days old email on a thread that is no longer active?
FOUR DAYS is "no longer active" for you? Seriously? You want to STFU those who disagree _this hard_?
-- Pete
On Wed, 2013-05-08 at 19:59 -0600, Pete Zaitcev wrote:
FOUR DAYS is "no longer active" for you? Seriously? You want to STFU those who disagree _this hard_?
Pete,
There is no constructive discussion going on here any more. 4 days is certainly enough time for a mailing list thread to go inactive. Please mind your language. You are not being excellent towards the rest of the community. Use of such language in the future will get you moderated. We'd really like to avoid that scenario. It's easy enough: please re-read your mail before you send it to ensure it's polite, irrespective of the situation.
I insist that you please stop posting to this thread.
On 2013-05-08 10:09 (GMT+0200) Pierre-Yves Chibon composed:
you are replying to a 4 days old email on a thread that is no longer active?
A: The thread was started on a Friday night.
B: Some people don't get to read mail every day, or more than a few or less times a week.
A + B = perfectly justified timing of reply.
On Wed, 2013-05-08 at 22:36 -0400, Felix Miata wrote:
On 2013-05-08 10:09 (GMT+0200) Pierre-Yves Chibon composed:
you are replying to a 4 days old email on a thread that is no longer active?
A: The thread was started on a Friday night.
B: Some people don't get to read mail every day, or more than a few or less times a week.
A + B = perfectly justified timing of reply.
C: the debate was taken to every place it could possibly go, and the commit was reverted.
So what's the point of reviving it? Sometimes, if you don't get your $0.02 posted in time, it's best to just sit on it.
On 2013-05-09 00:02 (GMT-0400) Adam Williamson composed:
On Wed, 2013-05-08 at 22:36 -0400, Felix Miata wrote:
On 2013-05-08 10:09 (GMT+0200) Pierre-Yves Chibon composed:
you are replying to a 4 days old email on a thread that is no longer active?
A: The thread was started on a Friday night.
B: Some people don't get to read mail every day, or more than a few or less times a week.
A + B = perfectly justified timing of reply.
C: the debate was taken to every place it could possibly go, and the commit was reverted.
So what's the point of reviving it? Sometimes, if you don't get your $0.02 posted in time, it's best to just sit on it.
So everyone who cannot maintain currency has to catch up 100% prior to writing a response coming to mind while reading, lest he be publicly chastised by temporal relevance police? Likely "revival" was not the primary objective of the late writer. The late arrival would much better have been left ignored than have the already too long thread be further extended by OT police commentary.
On Thu, 2013-05-09 at 00:44 -0400, Felix Miata wrote:
On 2013-05-09 00:02 (GMT-0400) Adam Williamson composed:
On Wed, 2013-05-08 at 22:36 -0400, Felix Miata wrote:
On 2013-05-08 10:09 (GMT+0200) Pierre-Yves Chibon composed:
you are replying to a 4 days old email on a thread that is no longer active?
A: The thread was started on a Friday night.
B: Some people don't get to read mail every day, or more than a few or less times a week.
A + B = perfectly justified timing of reply.
C: the debate was taken to every place it could possibly go, and the commit was reverted.
So what's the point of reviving it? Sometimes, if you don't get your $0.02 posted in time, it's best to just sit on it.
So everyone who cannot maintain currency has to catch up 100% prior to writing a response coming to mind while reading, lest he be publicly chastised by temporal relevance police? Likely "revival" was not the primary objective of the late writer. The late arrival would much better have been left ignored than have the already too long thread be further extended by OT police commentary.
If I get behind on reading devel@, what I do is read through the backlog, writing replies as I read, but *don't send any of them*. I just leave them open. If it turns out someone else already said what I wanted to say already, or the thread diverged into something else, or it became toxic and then died, or whatever, I just trash the message.
Once upon a time, Felix Miata mrmazda@earthlink.net said:
So everyone who cannot maintain currency has to catch up 100% prior to writing a response coming to mind while reading, lest he be publicly chastised by temporal relevance police?
Well, yes. That is common courtesy in any form of debate, especially on-line where it is easy to review the thread before posting.
On 2013-05-09 08:00 (GMT-0500) Chris Adams composed:
Felix Miata composed:
So everyone who cannot maintain currency has to catch up 100% prior to writing a response coming to mind while reading, lest he be publicly chastised by temporal relevance police?
Well, yes. That is common courtesy in any form of debate, especially on-line where it is easy to review the thread before posting.
Right. Participants of a list for developers, who as a group are notorious for imperfect work, must be perfect handling their email.
Yes, it's a good goal to strive for, but public chastising those who fall short, and extending OT content simply, is not necessary, or desirable.
From: Adam Williamson awilliam@redhat.com
On Wed, 2013-05-08 at 22:36 -0400, Felix Miata wrote:
On 2013-05-08 10:09 (GMT+0200) Pierre-Yves Chibon composed:
you are replying to a 4 days old email on a thread that is no longer active?
A: The thread was started on a Friday night.
B: Some people don't get to read mail every day, or more than a few or
less
times a week.
A + B = perfectly justified timing of reply.
C: the debate was taken to every place it could possibly go, and the commit was reverted.
D: read mail, have knee jerk reaction, send email, read remainder of unread mail and realize A, B and C have already occurred and then decided it's best to read all unread mail before allowing knee to jerk the send button.
So what's the point of reviving it? Sometimes, if you don't get your $0.02 posted in time, it's best to just sit on it.
Agreed.
-- John Florian
Hi
On Sat, May 4, 2013 at 12:01 AM, Matthew Garrett wrote:
I'm saying that if a bug report has been closed due to the change being a deliberate design decision, reopening the bug isn't going to change the fact that it was a deliberate design decision.
I understand your perspective just fine but I have had maintainers fix the bug after it was reopened and I have done that for users as a maintainer when I originally thought something wasn't a problem but changed my mind when presented with a coherent argument to reconsider. I don't see it as a hardline rule
Rahul
On Sat, May 04, 2013 at 12:07:30AM -0400, Rahul Sundaram wrote:
On Sat, May 4, 2013 at 12:01 AM, Matthew Garrett wrote:
I'm saying that if a bug report has been closed due to the change being a deliberate design decision, reopening the bug isn't going to change the fact that it was a deliberate design decision.
I understand your perspective just fine but I have had maintainers fix the bug after it was reopened and I have done that for users as a maintainer when I originally thought something wasn't a problem but changed my mind when presented with a coherent argument to reconsider. I don't see it as a hardline rule
Bugzilla's a dreadful place to have discussions. The lack of threading means unpopular decisions tend to just result in large numbers of contentless comments which make meaningful discussion impossible - it's a nightmare to find appropriate context. If a project doesn't have a mailing list then Bugzilla may be the least worst choice, but where it does then make use of it.
Hi
On Sat, May 4, 2013 at 12:35 AM, Matthew Garrett wrote:
Bugzilla's a dreadful place to have discussions. The lack of threading means unpopular decisions tend to just result in large numbers of contentless comments which make meaningful discussion impossible - it's a nightmare to find appropriate context. If a project doesn't have a mailing list then Bugzilla may be the least worst choice, but where it does then make use of it.
We are already having the discussion in a mailing list and I have already agreed that it is in general a good idea to bring broader discussions to a mailing list. So repeating that I should, several times serves no real purpose. Your real point of disagreement is that I should not have reopened the bug report and I am generally hesitant to do and I stand by my decision to reopen it in this case.
Rahul
On Sat, 2013-05-04 at 22:48 +0100, David Woodhouse wrote:
On Sat, 2013-05-04 at 05:01 +0100, Matthew Garrett wrote:
The appropriate place to discuss deliberate design decisions is a forum where said decisions are made, ie not Bugzilla.
Or a forum where said decisions can be overridden with a little more sanity, such as FESCo.
I don't think it helps to start calling people's sanity into question. You can debate the merits of the decision without going over the top.
On Sat, May 4, 2013 at 5:01 PM, Adam Williamson awilliam@redhat.com wrote:
On Sat, 2013-05-04 at 22:48 +0100, David Woodhouse wrote:
On Sat, 2013-05-04 at 05:01 +0100, Matthew Garrett wrote:
The appropriate place to discuss deliberate design decisions is a forum where said decisions are made, ie not Bugzilla.
Or a forum where said decisions can be overridden with a little more sanity, such as FESCo.
I don't think it helps to start calling people's sanity into question. You can debate the merits of the decision without going over the top.
I don't think he was calling anyone's sanity into question. Just saying FESCo would be a reasonable forum to discuss this if you are hoping to get the decision overridden. But I suppose the goal was really to get the developers to reconsider if there was enough push back in this "peer" forum.
John
On Sat, May 4, 2013 at 2:37 AM, Michael Scherer misc@zarb.org wrote:
and I think that even Bruce Schneier have gave his opinion in favor of the proposal : http://www.schneier.com/blog/archives/2009/06/the_problem_wit_2.html http://www.schneier.com/blog/archives/2009/07/the_pros_and_co.html
Which he later took back.
I can add to that that I have seen more than once people setting a password which was not the one they believed due to :
- keyboard layout ( ie, qwerty vs azerty in France )
- small usage difference with Windows way, again on azerty keyboard
( people using capslock on french keyboard to type numbers while they should use shift, as capslock just type capital letter like À or É and not 0 or 2, and if you do not understand, just look on the web to compare how different it is from qwerty-based keyboard )
The installer should detect the keyboard automatically. In fact you can even tell it what type of keyboard you have on the first screen.
Or I could also speak of the small non standard keyboard such as macbook one where ~ or | are not printed and where using the wrong keyboard could result in wrong characters if you are unaware of the problem.
I think people that have Macs have learned how to use their slightly different keybaords by now.
But the discussion is not about that, even if I think the rational around the defaults. Showing by default will help people who are less familiar, hidden by default will satisfy people who think that's a security issue.
Showing by default helps no one.
Hidden by default and showing it on demand is likely to still be a hindrance to people who may not know they type their password wrong ( because I think most assume that it will work fine, we are not to a point where people assume by default this will fail ).
Straw man argument.
So what about hiding on demand, and having it visible by default ? This way, people who prefer to have it hidden will be happy, and we are still friendly to non technical users.
Absolutely wrong.
On Sat, May 4, 2013 at 11:10 AM, Michael Cronenworth mike@cchtml.com wrote:
On 05/04/2013 02:29 AM, Stef Walter wrote:
There's already this exact phoneish password hint capability in GTK+ with the 'gtk-entry-password-hint-timeout' setting. Turn it on in $XDG_CONFIG_HOME/gtk-3.0/settings.ini, or use gtk_settings_set_string_property()
I guess this is somewhat of a reasonable compromise.. if I was installing Fedora on my phone/tablet.
On Sat, May 4, 2013 at 2:48 PM, David Woodhouse dwmw2@infradead.org wrote:
Or a forum where said decisions can be overridden with a little more sanity, such as FESCo.
Has it come to that? Do we really need a committee to decide "sanity" and how ridiculous this is?
On Sat, May 4, 2013 at 9:35 AM, Adam Williamson awilliam@redhat.com wrote:
http://it.slashdot.org/story/13/05/04/1248242/fedora-19-to-stop-masking-pass...
Well, that escalated quickly.
As it should have.
So where do we go from here? I think the vast majority of people here have agreed that this was wrong. I guess does this now go to FESCo and let a few people vote on it?
Why can't there be a wider community approval be able to vote on things like this? As I stated earlier there are a list of things that have changed without any real widespread community approval.
I kind of feel helpless, and powerless.
Great. I brought the attention to a wider audience and the general public and something may or may not get done about it, but what about the next UI change I think is ridiculous or the ones I think that already are?
I don't feel like if I filed a bug anything would get done about it besides a "too bad" response.
I'm really lost.
Dan
On Sat, 4 May 2013 15:22:01 -0700 Dan Mashal dan.mashal@gmail.com wrote:
...snip...
On Sat, May 4, 2013 at 9:35 AM, Adam Williamson awilliam@redhat.com wrote:
http://it.slashdot.org/story/13/05/04/1248242/fedora-19-to-stop-masking-pass...
Well, that escalated quickly.
As it should have.
So where do we go from here? I think the vast majority of people here have agreed that this was wrong. I guess does this now go to FESCo and let a few people vote on it?
IMHO, no.
You posted this on friday afternoon, Rauhl re-opened the bug friday night. I suspect many anaconda folks have not even seen this discussion or the bug reopening yet. Is there some massive hurry here?
Lets see what anaconda developers say based on the feedback and see if they would like to revisit the change or if they still wish to keep it. Or perhaps they wish more information or feedback. Or perhaps they will revisit it and solve it some other way. There's lots of options there.
If they do decide to keep the change, you could escalate it to FESCo. However, (speaking only for myself here) I would be VERY reluctant to override maintainers on their packages on something that is a design decision/judgement call. Where would we draw the line?
Why can't there be a wider community approval be able to vote on things like this? As I stated earlier there are a list of things that have changed without any real widespread community approval.
Fedora isn't a direct democracy, and I don't think such a model would work well at all. Especially when it comes to how maintainers or people doing the work spend their time. I think it's great to bring up things like this and ask they be reconsidered, but mob rule isn't a good model.
I kind of feel helpless, and powerless.
I'm sorry to hear it. You brought up discussion, have some patience?
Great. I brought the attention to a wider audience and the general public and something may or may not get done about it, but what about the next UI change I think is ridiculous or the ones I think that already are?
Perhaps engage with the folks making those changes and offer to help out or provide more direct feedback?
I don't feel like if I filed a bug anything would get done about it besides a "too bad" response.
I'm really lost.
Bugs can and do get things changed, but the ones that do are ones with well reasoned arguments or citations.
I'm sure it will work out in the end... :)
kevin
On Sat, May 4, 2013 at 3:42 PM, Kevin Fenzi kevin@scrye.com wrote:
You posted this on friday afternoon, Rauhl re-opened the bug friday night. I suspect many anaconda folks have not even seen this discussion or the bug reopening yet. Is there some massive hurry here?
No.
Lets see what anaconda developers say based on the feedback and see if they would like to revisit the change or if they still wish to keep it. Or perhaps they wish more information or feedback. Or perhaps they will revisit it and solve it some other way. There's lots of options there.
As I stated before the feeling I got from their response was "this is our decision based on this and that and too bad", and it's not the first time.
If they do decide to keep the change, you could escalate it to FESCo. However, (speaking only for myself here) I would be VERY reluctant to override maintainers on their packages on something that is a design decision/judgement call. Where would we draw the line?
I would rather have QA have move oversight on these things. As I only discovered this while doing QA.
Excuse my cynicism here but this would also require some change to the QA process itself and what are blockers and what are not and the "nice to have" process which should be renamed "we won't hold our breath".
So say I did bring this up as a blocker under new criterion like "This isn't broken but probably a bad idea criterion" that I think should be defined (with a better name) and it was -1'd by the whoever was around during the meeting because most of us have $dayjobs, only then would I feel it appropriate to bring up to FESCo and then possibly the board. Short of doing that, it's much easier to just bring it to the attention of this list and see what other people have to say about it. Again, still a bit lost.
Fedora isn't a direct democracy, and I don't think such a model would work well at all. Especially when it comes to how maintainers or people doing the work spend their time. I think it's great to bring up things like this and ask they be reconsidered, but mob rule isn't a good model.
I'm not saying it should be on everything. But changes to I guess "CRITPATH" packages (which anaconda is one of I think) should be vetted in the community not on the anaconda maintainer list first.
Perhaps engage with the folks making those changes and offer to help out or provide more direct feedback?
As stated earlier this is not the first time I have tried to do so.
I'm sure it will work out in the end... :)
I think that bringing it up here made a bit of difference. Thanks.
Dan
On Sat, May 04, 2013 at 15:58:03 -0700, Dan Mashal dan.mashal@gmail.com wrote:
I would rather have QA have move oversight on these things. As I only discovered this while doing QA.
QA isn't really the right place to make up policy. This particular case doesn't seem to be something that would merit any action by QA unless the Fedora community developed an over arching possibly on when passwords can and cannot be displayed.
Excuse my cynicism here but this would also require some change to the QA process itself and what are blockers and what are not and the "nice to have" process which should be renamed "we won't hold our breath".
The "Nice to Have" process has been renamed "Freeze Exception", which better describes what it does.
So say I did bring this up as a blocker under new criterion like "This isn't broken but probably a bad idea criterion" that I think should be defined (with a better name) and it was -1'd by the whoever was around during the meeting because most of us have $dayjobs, only then would I feel it appropriate to bring up to FESCo and then possibly the board.
I don't think this would fly as a QA criterion. QA aren't necessarily in the best position to decide on whether or not general things are good or bad ideas.
I'm not saying it should be on everything. But changes to I guess "CRITPATH" packages (which anaconda is one of I think) should be vetted in the community not on the anaconda maintainer list first.
I don't think critpath is the right description to use here. I think where you want to head is the long intended changes to the Feature process. Though I am not sure this subpart of the anconda UI change would really rate a Feature all on its own. The Anaconda rewrite is a Feature and they have been reaching out for feedback.
While I think feedback from the community is nice, I think the maintainers should generally be making the decisions (rather than voting) as the maintainers generally will know more about the problem than random community members.
I also think it is likely that if maintainers start getting overridden by community vote, we are going to start losing maintainers.
On Sat, 2013-05-04 at 15:58 -0700, Dan Mashal wrote:
If they do decide to keep the change, you could escalate it to FESCo. However, (speaking only for myself here) I would be VERY reluctant to override maintainers on their packages on something that is a design decision/judgement call. Where would we draw the line?
I would rather have QA have move oversight on these things. As I only discovered this while doing QA.
Excuse my cynicism here but this would also require some change to the QA process itself and what are blockers and what are not and the "nice to have" process which should be renamed "we won't hold our breath".
I don't really see any special place for QA in reviewing design decisions. I've said it before, but my opinion is that the job of QA is to determine whether things are working as intended, not to decide what the intentions should be.
As a practical matter, I don't think any of our test cases, release criteria, or anything else have anything to say on the topic of password masking; I don't think an unmasked password entry box violates any of our release requirements.
I don't immediately see any relevance to the 'freeze exception' process, which used to be called the 'nice to have' process but was renamed to make its purpose clearer. The 'freeze exception' process is a process which allows us to decide what changes we should allow as freeze exceptions. That's really it. I don't immediately see any relevance it has to this topic. The FE/NTH process is not and never was some kind of tool for QA or anyone else to force any developers to make any particular decisions; FE status does not mean 'we have decreed you must change this to how we think it must be'. The NTH name was very confusing and could have implied all kinds of things, hence the change to 'freeze exception', but the actual intent of the process has always been the same.
So say I did bring this up as a blocker under new criterion like "This isn't broken but probably a bad idea criterion"
Personally I think that would be a really terrible criterion. The release criteria are intended to define, as objectively as possible, a minimum baseline set of functionality that should be operational for any given Fedora release to go out. The release validation / blocker review process is not meant to be a talking shop (any more than it needs to be), a form of code review, or a 'I think this issue is important' list. It's a tightly focused process which is intended to ensure we reach a minimum level of functionality for each release point, and that's all it is. There are many issues that are potentially of extreme importance to at least _someone_ which, for various reasons, would not make any sense to consider in the context of the release validation process.
that I think should be defined (with a better name) and it was -1'd by the whoever was around during the meeting because most of us have $dayjobs, only then would I feel it appropriate to bring up to FESCo and then possibly the board. Short of doing that, it's much easier to just bring it to the attention of this list and see what other people have to say about it. Again, still a bit lost.
So this is turning into an open ended discussion, and I think Kevin gave you a great reply, but here's one thing I'd add: relax. You're working on a massive project that involves hundreds/thousands of people. It is not possible, however you organize such a project, for everyone to have a voice in everything. It is not possible to subject every decision to some kind of public review process. It is a statistical certainty that things you disagree with are going to happen. This is something you need to reconcile yourself to. Of course you can raise your voice on topics that concern you, and of course we can try to make our processes as open as possible, but however we do things, _stuff you don't like is going to happen_, and you've got to be comfortable with that, or you're going to get frustrated and burnt out very quickly. I find it helps to keep a sense of perspective, to be able to say 'okay, I think that's a really silly design, but it's just not the end of the world, it's a piece of software, the sun is still shining outside'. We need passionate people, and I love that you _really care a lot_, but it can be problematic if you get into the frame of mind that you care so much that you're convinced that every decision you disagree with, every thing that happens that you don't think should have happened, is a howling emergency or a personal failure on your part or someone else's part. It's not. It's just...the way things are.
I'm not saying it should be on everything. But changes to I guess "CRITPATH" packages (which anaconda is one of I think) should be vetted in the community not on the anaconda maintainer list first.
I don't think it hurts to have a process for review of really controversial changes, and of course in some circumstances it's a good thing for major changes to be proposed and discussed publicly rather than just being implemented. But it's not practically possible to 'vet' every single change to every critpath package; how would we ever get any work done? So there's a line there somewhere, and given the way a project like Fedora works, the maintainers of any component are going to have a lot of leeway in determining where that line is drawn, what changes they think they should propose as features or bring up for review in some other way and what changes they just go ahead and make. Someone would have to be drawing that line in a way that a large majority of people thought was completely wrong, for a long time, before it would be a good idea to start whacking them with a hammer of some kind. There are always trade-offs to be drawn, and the problem with 'the project' or 'management' or whatever keeping too tight a rein on development and demanding a week of discussion and formal review and whatever else for every change is that the developers just get frustrated and either do the minimum possible work, or just quit, neither of which is a good outcome.
Perhaps engage with the folks making those changes and offer to help out or provide more direct feedback?
As stated earlier this is not the first time I have tried to do so.
It helps to remember the times when things go well as well as when they go badly. I think I can think of the two or three things you're thinking about where you (and several others) and the anaconda team have/had a Major Difference Of Opinion. But I can also think of cases where you or I or one of many other people have brought up a concern to the anaconda team, and changes have been made in response. There have been major changes to newUI in F19, for instance, in response to feedback from you, me, the rest of the QA team, and others (on this list, in the forums, and so forth). There will be times when we're all just going to have to agree to disagree; as I said above, that's a thing that's just going to happen. But I think you might be being unfair on the anaconda team and getting needlessly frustrated if you're starting to think they are impervious to any form of outside input.
On Sun, May 5, 2013 at 1:28 AM, Adam Williamson awilliam@redhat.com wrote:
On Sat, 2013-05-04 at 15:58 -0700, Dan Mashal wrote:
If they do decide to keep the change, you could escalate it to FESCo. However, (speaking only for myself here) I would be VERY reluctant to override maintainers on their packages on something that is a design decision/judgement call. Where would we draw the line?
I would rather have QA have move oversight on these things. As I only discovered this while doing QA.
Excuse my cynicism here but this would also require some change to the QA process itself and what are blockers and what are not and the "nice to have" process which should be renamed "we won't hold our breath".
I don't really see any special place for QA in reviewing design decisions. I've said it before, but my opinion is that the job of QA is to determine whether things are working as intended, not to decide what the intentions should be.
No but if QA had adopted the "keyboard layouts must work" criterion that I have proposed multiple times the anaconda maintainers would have to spent their time on fixing the real issue rather than papering over it in such obscure ways.
On Sun, 2013-05-05 at 14:43 +0200, drago01 wrote:
Excuse my cynicism here but this would also require some change to the QA process itself and what are blockers and what are not and the "nice to have" process which should be renamed "we won't hold our breath".
I don't really see any special place for QA in reviewing design decisions. I've said it before, but my opinion is that the job of QA is to determine whether things are working as intended, not to decide what the intentions should be.
No but if QA had adopted the "keyboard layouts must work" criterion that I have proposed multiple times the anaconda maintainers would have to spent their time on fixing the real issue rather than papering over it in such obscure ways.
Nope. Current anaconda would pass any such criterion. It lets you pick a keyboard layout, and picking a keyboard layout works. I don't think a "there must be a keyboard layout indicator in anaconda" criterion would get accepted.
On 4 May 2013 23:42, Kevin Fenzi kevin@scrye.com wrote:
On Sat, 4 May 2013 15:22:01 -0700 Dan Mashal dan.mashal@gmail.com wrote:
On Sat, May 4, 2013 at 9:35 AM, Adam Williamson awilliam@redhat.com wrote:
http://it.slashdot.org/story/13/05/04/1248242/fedora-19-to-stop-masking-pass...
Well, that escalated quickly.
As it should have.
So where do we go from here? I think the vast majority of people here have agreed that this was wrong. I guess does this now go to FESCo and let a few people vote on it?
IMHO, no.
You posted this on friday afternoon, Rauhl re-opened the bug friday night. I suspect many anaconda folks have not even seen this discussion or the bug reopening yet. Is there some massive hurry here?
Of course another way to look at that is that it alerts them to the fact there's already quite a lot of discussion on this issue on the devel list and they may want to start getting involved in that.
On Sat, May 04, 2013 at 04:42:58PM -0600, Kevin Fenzi wrote:
If they do decide to keep the change, you could escalate it to FESCo. However, (speaking only for myself here) I would be VERY reluctant to override maintainers on their packages on something that is a design decision/judgement call. Where would we draw the line?
I think there is a line to be drawn somewhere. And unfortunately, in some packages, that line probably needs to get drawn further into what the package maintainer and software author might consider their territory than others.
I suppose for me security is probably one criteria for drawing the line. How many people the change affects is probably another one. This particular change seems to hit both those criteria. Criteria that could ameliorate those would be how easily users could use an alternative and whether the change is being announced at a volume to suit the amount of change it represents. (Security might still trump those... but as adamw said, it's likely to depend on how much less secure I might evaluate it to be compared to how much other benefit the feature seems to bring).
-Toshio
On Sat, 2013-05-04 at 16:42 -0600, Kevin Fenzi wrote:
If they do decide to keep the change, you could escalate it to FESCo. However, (speaking only for myself here) I would be VERY reluctant to override maintainers on their packages on something that is a design decision/judgement call. Where would we draw the line?
Surely that is part of what FESCo is *for*? To give "guidance" when a single package wants to do something that's inconsistent with what users expect and what every other package in the distribution does.
That was my understanding when I served as part of FESCo. Perhaps things have changed since then?
Le samedi 04 mai 2013 à 15:22 -0700, Dan Mashal a écrit :
On Sat, May 4, 2013 at 2:37 AM, Michael Scherer misc@zarb.org wrote:
and I think that even Bruce Schneier have gave his opinion in favor of the proposal : http://www.schneier.com/blog/archives/2009/06/the_problem_wit_2.html http://www.schneier.com/blog/archives/2009/07/the_pros_and_co.html
Which he later took back.
As said to Rahul, that's what he say in the 2nd link I gave. Do people read what I say before replying to me ?
I can add to that that I have seen more than once people setting a password which was not the one they believed due to :
- keyboard layout ( ie, qwerty vs azerty in France )
- small usage difference with Windows way, again on azerty keyboard
( people using capslock on french keyboard to type numbers while they should use shift, as capslock just type capital letter like À or É and not 0 or 2, and if you do not understand, just look on the web to compare how different it is from qwerty-based keyboard )
The installer should detect the keyboard automatically.
I have yet to see how the installer can detect the layout of a keyboard, because that would solve much issues we have a work with luks passwords and grub.
In fact you can even tell it what type of keyboard you have on the first screen.
And if you had to actually choose the keyboard ( as I assume you don't since that's good by default for you ), you would know that there is sometime several variants, up to sometime 3 or 5 variants per country ( see swiss or italian ones in gnome ).
I do not have issues with keyboard myself, but I can see why there is some case where some peoples may not know what to choose ( even if things greatly improved since last years when we had 8 unneeded keyboard variants for France )
And I am not sure that there isn't some country with more than 1 national layout ( depending how you interpret this map : http://en.wikipedia.org/wiki/File:Latin_keyboard_layouts_by_country_in_Europ... ).
Again, the situation may not be as simple as people believe for some users. How much, no idea. Should we care, I think we should but maybe not everybody agree. But I think we cannot say the issue do not exist, some people will type their passwords wrong.
Or I could also speak of the small non standard keyboard such as macbook one where ~ or | are not printed and where using the wrong keyboard could result in wrong characters if you are unaware of the problem.
I think people that have Macs have learned how to use their slightly different keybaords by now.
I guess then the guy I have seen today having this same exact issue on Ubuntu on his macbook didn't got the memo.
But the discussion is not about that, even if I think the rational around the defaults. Showing by default will help people who are less familiar, hidden by default will satisfy people who think that's a security issue.
Showing by default helps no one.
Then I think you are not doing enough support, or maybe you are more lucky than me with people you choose/have to help and support.
Hidden by default and showing it on demand is likely to still be a hindrance to people who may not know they type their password wrong ( because I think most assume that it will work fine, we are not to a point where people assume by default this will fail ).
Straw man argument.
So what about hiding on demand, and having it visible by default ? This way, people who prefer to have it hidden will be happy, and we are still friendly to non technical users.
Absolutely wrong.
What part is wrong, that people that prefer to have it hidden will not be happy, or that this will not make some less technical user happy ?
Cause I can find a few people that would be happy, just read the slashdot thread to find some of them ( so you cannot exactly say they do not exist ). Do not get me wrong, I would personally have been as surprised as you were if I did a installation of F19, and had no problem with the old way. But I can see people who would benefit from the change, and what the reasoning was.
Why can't there be a wider community approval be able to vote on things like this? As I stated earlier there are a list of things that have changed without any real widespread community approval.
Because we are Fedora, not reddit.
For 1, voting has some inherent issues like "who should be able to vote", and 2, who decide what can and should be set to be voted 3) who is volunteer to organize them ?
In fact, if you are so keen on having community approval, you should lead by example, install a voting application on openshift or anywhere, and start doing vote for your own work, so you will see if that work, if you feel more legitimate, etc, etc. Just follow https://github.com/openshift-quickstart/limesurvey-quickstart and that's it.
That would be fair to apply what you are preaching and to first see how it work on yourself before proposing the changes to others who didn't asked for it, no ?
On Sat, 2013-05-04 at 15:22 -0700, Dan Mashal wrote:
Hidden by default and showing it on demand is likely to still be a hindrance to people who may not know they type their password wrong ( because I think most assume that it will work fine, we are not to
a
point where people assume by default this will fail ).
Straw man argument.
So what about hiding on demand, and having it visible by default ?
This
way, people who prefer to have it hidden will be happy, and we are
still
friendly to non technical users.
Absolutely wrong.
Well constructed arguments, with very nice examples...
Michael proposes here a sort of middle ground, using the studies from different sources (referenced) and the apparent wish of the maintainer to go this way. It's not because it is different from your current behavior that it is by definition false. So if you disagree please provide *reasonable* arguments.
Pierre
On 05/05/13 08:40 AM, Pierre-Yves Chibon wrote:
On Sat, 2013-05-04 at 15:22 -0700, Dan Mashal wrote:
Hidden by default and showing it on demand is likely to still be a hindrance to people who may not know they type their password wrong ( because I think most assume that it will work fine, we are not to
a
point where people assume by default this will fail ).
Straw man argument.
So what about hiding on demand, and having it visible by default ?
This
way, people who prefer to have it hidden will be happy, and we are
still
friendly to non technical users.
Absolutely wrong.
Well constructed arguments, with very nice examples...
Michael proposes here a sort of middle ground, using the studies from different sources (referenced) and the apparent wish of the maintainer to go this way.
I would like to point out that, as Adam Williamson nicely written in his analysis of the references quoted earlier in this thread, it's hard to call any of the references as "studies" -- most of them are opinions and not widely accepted either.
On May 5, 2013, at 1:40 AM, Pierre-Yves Chibon pingou@pingoured.fr wrote:
So if you disagree please provide *reasonable* arguments.
Those who disagree have already done this ad nauseum. The summary:
The Neilsen-Norman article cited is an editorial piece. It is out of scope, out of context, not a study, and not a paper. It suggests there's a usability consequence for masked passwords, which is an observation in the realm of Thank You Captain Obvious, that doesn't really need a study. It should be ignored.
It's inappropriate for others to state the relative risk level of a user's situation, rather than deferring to the user's ability to self-assess their risk level.
The implemented change offers no alternatives, to account for elevated risk contexts.
There are at least two alternative behaviors:
a.) Mask by default with two fields, with an unmask option that would gray out the (now superfluous) second field.
b.) The entry method used on mobile platforms, delayed masking per character. I argued against this in my earlier email when I brought it up. This isn't a mobile platform. It's higher risk, and probably not as easy to employ as option a.) which is a common cross platform behavior.
Chris Murphy
Le dimanche 05 mai 2013 à 11:18 -0600, Chris Murphy a écrit :
On May 5, 2013, at 1:40 AM, Pierre-Yves Chibon pingou@pingoured.fr wrote:
So if you disagree please provide *reasonable* arguments.
Those who disagree have already done this ad nauseum.
The summary:
The Neilsen-Norman article cited is an editorial piece. It is out of scope, out of context, not a study, and not a paper.
As I said earlier, I cited the url to say "there is a discussion going on". And yes, this is as much useful as all others people stating their opinions in this thread. The fact that this is still being discussed ( as I found post/article/etc in 2010 and 2012 ) show that's indeed a complex question, and we can all agree on that.
We can also all agree that we have no conclusive data for anything. IE, we have no data on shoulder surfing ( ie, is it prevalent during os installation ? ), nor data to show how problematic is the password masking in term of user experience.
It suggests there's a usability consequence for masked passwords, which is an observation in the realm of Thank You Captain Obvious, that doesn't really need a study. It should be ignored.
It may seems obvious but not everybody seems to agree with that according to this thread. And so, if it doesn't need a study, then why dismiss it as "not a study" ?
Being obvious doesn't mean it should be ignored either.
It's inappropriate for others to state the relative risk level of a user's situation, rather than deferring to the user's ability to self-assess their risk level.
As a distribution project, we are doing this kind of choice almost daily. This one is just one among the million one that have already been done.
I would like also add that not everybody is able to correctly self-assess their risk level. In fact, I would even say that few people are able due to various psychological bias like loss aversion ( http://qje.oxfordjournals.org/content/112/2/647.abstract ), or some others bias related to risk like : http://en.wikipedia.org/wiki/Zero-risk_bias http://en.wikipedia.org/wiki/Subadditivity_effect ( and maybe others among the list http://en.wikipedia.org/wiki/List_of_cognitive_biases ).
The implemented change offers no alternatives, to account for elevated risk contexts.
There are at least two alternative behaviors:
a.) Mask by default with two fields, with an unmask option that would grayout the (now superfluous) second field.
b.) The entry method used on mobile platforms, delayed masking per character. Iargued against this in my earlier email when I brought it up. This isn't a mobile platform. It's higher risk, and probably not as easy to employ as option a.) which is a common cross platform behavior.
Yes, and is not solving the same issue. Again, on a mobile platform, there is much more accuracy issues than on a PC, thus needing some changes.
Now since the issue with the current change is "I am forced to type the password visible and I do not want to do it for some others reasons", yes, that's a problem ( at least to me, even if I think that's a rare problem, but still a problem ).
So what about this alternative proposal (made earlier, upon no one commented ) :
c.) unmask by default, with a explicit mask option.
That answer to the need of being able to mask if your environment requires it, so should at least satisfy part of the people who want that.
And this permit to people who are more likely to make a error to check without thinking about doing it.
That's the reverse of option A, because my hypothesis based on my own empirical users observations is that people who would need to use this option are not the ones that will think to do it. For example, I do use the unmask feature for long passwords given by someone else ( ie wifi ), since I cannot be sure I typed it correctly. But I would likely not use it for typing my own password for a account creation since I trust myself to type it right, like I think most people.
And if people want others ideas, there is some creative one like this one, adding decoy text : http://hcsl-web.clemson.edu/wp-content/uploads/2012/12/Evaluating-the-Usabil...
or adding decoy characters : http://lab.arc90.com/2009/07/08/halfmask-an-experiment-in-password-masking/ ( didn't work with firefox, only with epiphany )
( as a side note, I suspect that the whole idea come from this article : http://uxdesign.smashingmagazine.com/2012/10/26/password-masking-hurt-signup... )
Le Dim 5 mai 2013 00:22, Dan Mashal a écrit :
I think people that have Macs have learned how to use their slightly different keybaords by now.
OTOH there are slight variations between the windows, mac and linux layouts for the same locale (due to the fact that getting fixes in xkb is way easier than elsewhere), so I would expect anaconda to show proeminently the name of the currently active layout on all screens, and permit layout inspection, test and change on any click on this layout id.
If only to make new Linux users' life easier
Regards,
On 05/04/2013 06:22 PM, Dan Mashal wrote:
On Sat, May 4, 2013 at 2:37 AM, Michael Scherer misc@zarb.org wrote:
I can add to that that I have seen more than once people setting a password which was not the one they believed due to :
- keyboard layout ( ie, qwerty vs azerty in France )
- small usage difference with Windows way, again on azerty keyboard
( people using capslock on french keyboard to type numbers while they should use shift, as capslock just type capital letter like À or É and not 0 or 2, and if you do not understand, just look on the web to compare how different it is from qwerty-based keyboard )
The installer should detect the keyboard automatically. In fact you can even tell it what type of keyboard you have on the first screen.
On the screen where you can pick your keyboard, do we have a test area where the user can verify the keyboard layout? Or maybe if you select a different keyboard it should automatically pop up a verify keyboard screen?
On Mon, May 6, 2013 at 8:34 AM, Bill Peck bpeck@redhat.com wrote:
On 05/04/2013 06:22 PM, Dan Mashal wrote:
On Sat, May 4, 2013 at 2:37 AM, Michael Scherer misc@zarb.org wrote:
I can add to that that I have seen more than once people setting a password which was not the one they believed due to :
- keyboard layout ( ie, qwerty vs azerty in France )
- small usage difference with Windows way, again on azerty keyboard
( people using capslock on french keyboard to type numbers while they should use shift, as capslock just type capital letter like À or É and not 0 or 2, and if you do not understand, just look on the web to compare how different it is from qwerty-based keyboard )
The installer should detect the keyboard automatically. In fact you can even tell it what type of keyboard you have on the first screen.
On the screen where you can pick your keyboard, do we have a test area where the user can verify the keyboard layout? Or maybe if you select a different keyboard it should automatically pop up a verify keyboard screen?
No matter how smart the kernel or anaconda, this can be nightmarish when funneled through a virtualization console. The remapping between the user's operating system, through the VMware or VNC or other virtualization console access toolkit, can create..... some very odd remappings.
On 05/03/2013 10:59 PM, Matthew Garrett wrote:
On Fri, May 03, 2013 at 10:36:51PM -0400, Rahul Sundaram wrote:
I was referring to the decision to show the password in full when the user is typing it.
Many UI decisions are unprecedented. That doesn't justify reopening bugs that the maintainer has closed. If you want to have a discussion about whether or not this is a reasonable UI decision, do so somewhere other than Bugzilla.
In all seriousness, this is a substantial UI decision that requires a commensurate change in user behavior---it shouldn't be dismissed so easily as marking it NOTABUG.
Another example of such important change that recently appeared without recourse and much discussion is the lock screen: previously, the password unlock widget had focus so one could start typing the password, while the new behavior is that the focus is in the clock, and one needs to hit Esc or Enter. I understand the security tradeoffs: the former behavior is conditioning people to carelessly type passwords in the blind, so they are more vulnerable to fake authentication dialogs, while the new one almost uses the SAK (secure attention key) paradigm. Still, the user behavior change is significant and I keep making mistakes even though I understand and agree with the new scheme.
By the way, does Gnome have a SAK? I don't think Esc is a true SAK, but maybe I am wrong about it?
On Mon, May 6, 2013 at 3:21 PM, Przemek Klosowski przemek.klosowski@nist.gov wrote:
Another example of such important change that recently appeared without recourse and much discussion is the lock screen: previously, the password unlock widget had focus so one could start typing the password, while the new behavior is that the focus is in the clock, and one needs to hit Esc or Enter.
This is vastly off-topic of course, but this was actually a temporary limitation in GNOME 3.6 - since 3.8 (e.g. Fedora 19), you can just type in your password again.
On Mon, 2013-05-06 at 09:21 -0400, Przemek Klosowski wrote:
On 05/03/2013 10:59 PM, Matthew Garrett wrote:
On Fri, May 03, 2013 at 10:36:51PM -0400, Rahul Sundaram wrote:
I was referring to the decision to show the password in full when the user is typing it.
Many UI decisions are unprecedented. That doesn't justify reopening bugs that the maintainer has closed. If you want to have a discussion about whether or not this is a reasonable UI decision, do so somewhere other than Bugzilla.
In all seriousness, this is a substantial UI decision that requires a commensurate change in user behavior---it shouldn't be dismissed so easily as marking it NOTABUG.
Another example of such important change that recently appeared without recourse and much discussion is the lock screen: previously, the password unlock widget had focus so one could start typing the password, while the new behavior is that the focus is in the clock, and one needs to hit Esc or Enter. I understand the security tradeoffs: the former behavior is conditioning people to carelessly type passwords in the blind, so they are more vulnerable to fake authentication dialogs, while the new one almost uses the SAK (secure attention key) paradigm. Still, the user behavior change is significant and I keep making mistakes even though I understand and agree with the new scheme.
This was a temporary situation in GNOME 3.6, when the new lock screen was introduced. In GNOME 3.8 (F19), you can just type your password again.
By the way, does Gnome have a SAK? I don't think Esc is a true SAK, but maybe I am wrong about it?
You can't implement a true SAK without support from X and the kernel.
On 2013-05-03 14:26 (GMT-0700) Dan Mashal composed:
Chris Murphy wrote:
Dan Mashal wrote:
I believe that this is a major security risk and that this is a new UI change going forward and this is not a bug.
Do you think this is a good idea?
No. I think it's a bug, and a bug should be filed on it.
closed as NOTABUG.
https://bugzilla.redhat.com/show_bug.cgi?id=959541 https://bugzilla.redhat.com/show_bug.cgi?id=958608
So I just wanted to email other intelligent people and see if I was crazy or stupid.
Yet another case of trying to "fix" what isn't broken.
Are any of the several who closed the bug more than 20 years old?
Crazy is the unexpected behavior of echoing back typed password characters. Where else, if anywhere, is this happening? Never in 40 computing years can I remember ever seeing password characters echoed for viewing.
On Fri, May 3, 2013 at 8:48 PM, Felix Miata mrmazda@earthlink.net wrote:
Yet another case of trying to "fix" what isn't broken.
Are any of the several who closed the bug more than 20 years old?
Crazy is the unexpected behavior of echoing back typed password characters. Where else, if anywhere, is this happening? Never in 40 computing years can I remember ever seeing password characters echoed for viewing.
I don't want to make personal attacks on someone's maturity as much as I have been frustrated since the "new and improved anconda UI" introduced in Fedora 18.
Please try not to turn this in to a personal flame war.
Dan
On Fri, May 3, 2013 at 5:26 PM, Dan Mashal dan.mashal@gmail.com wrote:
On Fri, May 3, 2013 at 2:17 PM, Chris Murphy lists@colorremedies.com wrote:
On May 3, 2013, at 2:04 PM, Dan Mashal dan.mashal@gmail.com wrote:
I believe that this is a major security risk and that this is a new UI change going forward and this is not a bug.
Do you think this is a good idea?
No. I think it's a bug, and a bug should be filed on it.
Chris Murphy
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
It was.
And closed as NOTABUG.
https://bugzilla.redhat.com/show_bug.cgi?id=959541 https://bugzilla.redhat.com/show_bug.cgi?id=958608
So I just wanted to email other intelligent people and see if I was crazy or stupid.
Saving passwords in clear text, it makes certain operations easier, but makes numerous illicit operations more easy. The ability to, and value of, shoulder surfing a password is a very real issue in large shared environments with multiple people with visual access to your shoulder. The critical one iin my mind is remote electronic access through shared consoles in VMware environments and in other virtualizaiton environments. Anyone in the data center can shoulder surf you with a console to the virtualization *server*.
On Sat, 2013-05-04 at 23:42 -0400, Nico Kadel-Garcia wrote:
On Fri, May 3, 2013 at 5:26 PM, Dan Mashal dan.mashal@gmail.com wrote:
On Fri, May 3, 2013 at 2:17 PM, Chris Murphy lists@colorremedies.com wrote:
On May 3, 2013, at 2:04 PM, Dan Mashal dan.mashal@gmail.com wrote:
I believe that this is a major security risk and that this is a new UI change going forward and this is not a bug.
Do you think this is a good idea?
No. I think it's a bug, and a bug should be filed on it.
Chris Murphy
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
It was.
And closed as NOTABUG.
https://bugzilla.redhat.com/show_bug.cgi?id=959541 https://bugzilla.redhat.com/show_bug.cgi?id=958608
So I just wanted to email other intelligent people and see if I was crazy or stupid.
Saving passwords in clear text, it makes certain operations easier, but makes numerous illicit operations more easy.
Just to avoid any confusion - this is about *displaying* passwords as they are typed (or masking them). It is not about how they are stored, there is no change in that regard (we hash and salt them up the wazoo). The rest of your message shows that you actually understand this, I just didn't want anyone to read 'saving passwords in clear text' and get worried :)
Dan Mashal wrote:
In the latest Fedora 19 Beta TC2 install after I got through the initial steps of the install I started to setup my root password.
To my surprise my password was shown in plain text instead of bullets.
I believe that this is a major security risk and that this is a new UI change going forward and this is not a bug.
Do you think this is a good idea?
Very very bad idea.
What if you are installing and someone is looking over your shoulder and you don't know about this new "UI improvement"?
Precisely. This will be a very unpleasant surprise to the experienced admin who knows that passwords are always obscured in password entry fields.
I don't suppose there's a warning in big red letters? "BEWARE! YOUR ROOT PASSWORD WILL BE *VISIBLE*. MAKE SURE THAT NOBODY CAN SEE THE SCREEN!" The admin won't know about this misfeature until he looks up from the keyboard and sees the password being displayed in the clear, right?
Always close the door and the blinds when installing operating systems? That's easier said than done in an open plan office.
Björn Persson
On Fri, 2013-05-03 at 13:04 -0700, Dan Mashal wrote:
Hi,
In the latest Fedora 19 Beta TC2 install after I got through the initial steps of the install I started to setup my root password.
To my surprise my password was shown in plain text instead of bullets.
I believe that this is a major security risk and that this is a new UI change going forward and this is not a bug.
Do you think this is a good idea?
http://it.slashdot.org/story/13/05/04/1248242/fedora-19-to-stop-masking-pass...
Well, that escalated quickly.
On 05/04/2013 06:35 PM, Adam Williamson wrote:
http://it.slashdot.org/story/13/05/04/1248242/fedora-19-to-stop-masking-pass...
Well, that escalated quickly.
And in one of the replies:
http://it.slashdot.org/comments.pl?sid=3716785&cid=43628711
"I like the way Windows 8 addressed this problem. They added a button that looks like an eye on the right hand side of the password field to show the password as you've typed it. That seems like a better compromise than briefly showing the password characters."
I think Microsoft just succeeded in teaching Linux something about security practices. And this is not something to be proud of.
On Sun, 2013-05-05 at 15:50 +0200, Roberto Ragusa wrote:
On 05/04/2013 06:35 PM, Adam Williamson wrote:
http://it.slashdot.org/story/13/05/04/1248242/fedora-19-to-stop-masking-pass...
Well, that escalated quickly.
And in one of the replies:
http://it.slashdot.org/comments.pl?sid=3716785&cid=43628711
"I like the way Windows 8 addressed this problem. They added a button that looks like an eye on the right hand side of the password field to show the password as you've typed it. That seems like a better compromise than briefly showing the password characters."
I think Microsoft just succeeded in teaching Linux something about security practices. And this is not something to be proud of.
That seems to be needless hyperbole. The 'have a button to toggle the status' solution was proposed in the 2009 discussion already.
On Fri, May 3, 2013 at 4:04 PM, Dan Mashal wrote:
Hi,
In the latest Fedora 19 Beta TC2 install after I got through the initial steps of the install I started to setup my root password.
To my surprise my password was shown in plain text instead of bullets.
The obvious workaround is to use a temporary password during installation and on the first boot use passwd to change it (still leaves a small time window of vulnerability though). It is similar to removing pulseaudio upon installation to get the sound working. Surprisingly, Fedora keeps adding these "hidden" steps to complete a sane installation, yet adding a step to educate users about DE choices is still a taboo.
Best, Orcan
On Sun, 2013-05-05 at 14:07 -0400, Orcan Ogetbil wrote:
On Fri, May 3, 2013 at 4:04 PM, Dan Mashal wrote: Hi,
In the latest Fedora 19 Beta TC2 install after I got through the initial steps of the install I started to setup my root password. To my surprise my password was shown in plain text instead of bullets.The obvious workaround is to use a temporary password during installation and on the first boot use passwd to change it (still leaves a small time window of vulnerability though). It is similar to removing pulseaudio upon installation to get the sound working. Surprisingly, Fedora keeps adding these "hidden" steps to complete a sane installation, yet adding a step to educate users about DE choices is still a taboo.
Can we please keep this discussion productive? It really irritates me when people question other people's good faith for no valid reason.
Look, please remember: this change was committed to anaconda git master less than a month ago. It was reviewed only by the anaconda team. It has not yet made it to a single official Fedora (pre-)release; it has been present only in Beta TC1, TC2 and TC3, which are *validation test images*, they are not public pre-releases.
Whether you think the change was a good change or not, it is out of line to suggest that the idea was somehow "adding these "hidden" steps to complete a sane installation". The idea was to improve the usability of the password entry dialog, on the understanding that the practical security impact was minimal. Now we can argue with that assessment, and that's what we're doing, but it would be really nice if people would assume *good* faith on the part of other members of the project, not *bad* faith. The anaconda team are working hard to make things better, not worse, just like the rest of us.
It is ridiculous to suggest that "removing pulseaudio upon installation to get the sound working" is some kind of ""hidden" steps to complete a sane installation". In addition to all the objections above, it is factually incorrect: in the vast majority of installations, sound works better with PulseAudio than without it.
Look, please, by all means, calmly discuss the merits of the decision. Just don't bring into question the motivations of its introduction unless you have a damn strong factual basis for doing so.
On Sun, May 5, 2013 at 11:35 AM, Adam Williamson awilliam@redhat.com wrote:
[snip]
Look, please, by all means, calmly discuss the merits of the decision. Just don't bring into question the motivations of its introduction unless you have a damn strong factual basis for doing so.
I maintain an open source project for computational journalists. The intended deployment model is as virtual machines for people who might very well be working, as I often do, in coffee shops with unsecured WiFi and excellent pastries. There are plenty of risks involved already in that milieu, as noted here: http://mashable.com/2013/04/27/hacked-starbucks/
Passwords visible for a significant period of time will essentially render my main modus operandi - installing a virtual machine over the Internet - too risky in public settings. In the long run I need to build a better deployment model anyway, and I'm committed to Fedora going forward on this project for many other reasons. But if I have a vote, my vote is to eliminate password visibility entirely.
On Sun, May 5, 2013 at 2:35 PM, Adam Williamson wrote:
On Sun, 2013-05-05 at 14:07 -0400, Orcan Ogetbil wrote:
On Fri, May 3, 2013 at 4:04 PM, Dan Mashal wrote: Hi,
In the latest Fedora 19 Beta TC2 install after I got through the initial steps of the install I started to setup my root password. To my surprise my password was shown in plain text instead of bullets.The obvious workaround is to use a temporary password during installation and on the first boot use passwd to change it (still leaves a small time window of vulnerability though). It is similar to removing pulseaudio upon installation to get the sound working. Surprisingly, Fedora keeps adding these "hidden" steps to complete a sane installation, yet adding a step to educate users about DE choices is still a taboo.
Whether you think the change was a good change or not, it is out of line to suggest that the idea was somehow "adding these "hidden" steps to complete a sane installation". The idea was to improve the usability of the password entry dialog, on the understanding that the practical security impact was minimal. Now we can argue with that assessment, and that's what we're doing, but it would be really nice if people would assume *good* faith on the part of other members of the project, not *bad* faith. The anaconda team are working hard to make things better, not worse, just like the rest of us.
Sorry, I did not try to imply "*bad* faith" on any members of the project. I try to look at it as posing challenges to filter out the weak and let the fittest survive, which, I think, can be explained by "*good* faith". I admire certain developers' imagination.
Going off-topic:
It is ridiculous to suggest that "removing pulseaudio upon installation to get the sound working" is some kind of ""hidden" steps to complete a sane installation". In addition to all the objections above, it is factually incorrect: in the vast majority of installations, sound works better with PulseAudio than without it.
Well, unfortunately it did not work on a fresh F18 installation on a rare hardware (onboard Intel HD Audio) a couple of weeks back. I really did not want to spend time to figure out what was wrong. Just guess what I did to fix it (and it worked rightaway) ...
Look, please, by all means, calmly discuss the merits of the decision. Just don't bring into question the motivations of its introduction unless you have a damn strong factual basis for doing so.
I believe I do have a damn strong factual basis on everything I claimed. Sorry if I could not manage to convince.
Best, Orcan
On Mon, 2013-05-06 at 00:02 -0400, Orcan Ogetbil wrote:
Look, please, by all means, calmly discuss the merits of the decision. Just don't bring into question the motivations of its introduction unless you have a damn strong factual basis for doing so.
I believe I do have a damn strong factual basis on everything I claimed. Sorry if I could not manage to convince.
Here is the proposal and discussion of the change:
https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-April/003719....
where you can easily read the motivation:
"It'd be nice to have passwords readable when editing them, and then hidden when done editing."
Note: "it would be nice"! Not "it would contribute to our evil plans"!
https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-April/003756....
"Will and Mairin had some good links talking about the merits of doing this and how hiding passwords doesn't even do all that much to help (a determined person can always just watch your keyboard)."
"Why not use a checkbox? Well, why use a widget if we don't have to? Using a checkbox means now we have to work in another widget to the design, introducing potential padding and layout problems. It's another string that needs to be translated. It's another thing that needs a mnemonic widget. By doing the focus trick, we completely get rid of the keyboard layout problem because you can see what you're typing as you're typing it. It may also even allow us to get rid of the confirmation entries for the same reason."
Again, it's fine to disagree with this reasoning all you like. But the thread clearly demonstrates people thinking about ways to improve the installation experience. Unless you have clear evidence that this thread was just some sort of clever smoke screen to conceal their REAL intentions, I think you're out of line.
"Will and Mairin had some good links talking about the merits of doing this and how hiding passwords doesn't even do all that much to help (a determined person can always just watch your keyboard)."
This argument isn't very solid. I mean someone can just break your window to get in your house, so locking the door is waste of time, right? The bigger issue here is we should always have the mantra "secure by default". This is not secure by default.
"Why not use a checkbox? Well, why use a widget if we don't have to? Using a checkbox means now we have to work in another widget to the design, introducing potential padding and layout problems. It's another string that needs to be translated. It's another thing that needs a mnemonic widget. By doing the focus trick, we completely get rid of the keyboard layout problem because you can see what you're typing as you're typing it. It may also even allow us to get rid of the confirmation entries for the same reason."
A checkbox is probably the right way to handle this. While yes it's slightly more work, it does two very important things. It puts the user in control, and it is secure by default.
Security is hard, and many security decisions can often have unintended impacts. I suspect in this instance, a new Fedora user (and even some old ones) will see this behavior and think one of two things. 1) It's a bug. 2) These people know NOTHING about security! Neither is an ideal outcome.
Regardless of all the studies that say masking passwords doesn't help, we can't make this change quickly. We need to slowly ease people into such behavior. For now, the best solution is probably a checkbox, in a few releases we can revisit what the current accepted practice is. The current accepted practice is to mask the password, sometimes with a checkbox to unmask (but never unmask by default).
I think a discussion about the merits of password masking could be had, but I'd rather not start down that path. Perhaps the better question is what problem are we trying to solve. Has anyone ever complained about Anaconda masking passwords?
Thanks.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 05/06/2013 09:27 AM, Josh Bressers wrote:
"Will and Mairin had some good links talking about the merits of doing this and how hiding passwords doesn't even do all that much to help (a determined person can always just watch your keyboard)."
Sure, a person can watch your keyboard, but it's usually more obvious than someone glancing at your screen. Your body tends to be unconsciously huddled over the keyboard when typing a password, obscuring view.(Not to mention that unless you have a VERY high-precision camera pointed the right way (or you type about 5 wpm), most of the time a human won't be able to follow your keystrokes.
This argument isn't very solid. I mean someone can just break your window to get in your house, so locking the door is waste of time, right? The bigger issue here is we should always have the mantra "secure by default". This is not secure by default.
I agree strongly here. I have no problems with *permitting* the user to view the password unmasked, but doing so by default is just wrong.
"Why not use a checkbox? Well, why use a widget if we don't have to? Using a checkbox means now we have to work in another widget to the design, introducing potential padding and layout problems. It's another string that needs to be translated. It's another thing that needs a mnemonic widget. By doing the focus trick, we completely get rid of the keyboard layout problem because you can see what you're typing as you're typing it. It may also even allow us to get rid of the confirmation entries for the same reason."
A checkbox is probably the right way to handle this. While yes it's slightly more work, it does two very important things. It puts the user in control, and it is secure by default.
Agreed. Please add the widget. "It's more work" is not a valid answer. Yes I realize this means layout and translation changes. It also means that the installer is less prone to shoulder-surfing information leaks. The gains far outweigh the (perceived) costs.
Security is hard, and many security decisions can often have unintended impacts. I suspect in this instance, a new Fedora user (and even some old ones) will see this behavior and think one of two things. 1) It's a bug. 2) These people know NOTHING about security! Neither is an ideal outcome.
Yes, if nothing else, most users have been trained for many years that protecting their passwords is important. To have us suddenly displaying it for all to see (installer demos at conferences?) makes us look like we are intentionally ignoring "conventional wisdom". (I'm not going to make any statements about the research studies here. At the moment I'm only talking about perception). Users *will* report this as a bug, and I would not be surprised if some people refuse to install Fedora because of it. I certainly wouldn't use the installer in a public place (even in the office, where someone could walk by wearing a pair of Google Glasses).
Regardless of all the studies that say masking passwords doesn't help, we can't make this change quickly. We need to slowly ease people into such behavior. For now, the best solution is probably a checkbox, in a few releases we can revisit what the current accepted practice is. The current accepted practice is to mask the password, sometimes with a checkbox to unmask (but never unmask by default).
I think a discussion about the merits of password masking could be had, but I'd rather not start down that path. Perhaps the better question is what problem are we trying to solve. Has anyone ever complained about Anaconda masking passwords?
At the risk of sounding glib, when people have complaints about Anaconda, it's usually about more important things. Let's not try to solve a non-problem with a dubious solution, yes?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Mon, May 06, 2013 at 08:27:14AM -0500, Josh Bressers wrote:
A checkbox is probably the right way to handle this. While yes it's slightly more work, it does two very important things. It puts the user in control, and it is secure by default.
Secure by default is definitely where we need to be at all times. Now if we could just get SSH to be secure by default...
Regardless of all the studies that say masking passwords doesn't help, we can't make this change quickly. We need to slowly ease people into such behavior. For now, the best solution is probably a checkbox, in a few releases we can revisit what the current accepted practice is. The current accepted practice is to mask the password, sometimes with a checkbox to unmask (but never unmask by default).
I remember another discussion similar to this (not on this list) where passwords are shown one character at a time on Android. That added a risk but because the screens are generally smaller and partially covered by someone's hand it wasn't that big of a deal. That was a good compromise that made it easier for people to make sure their passwords (passphrases, right?) were being entered correctly.
I feel that not masking passwords isn't good. We can say that when we install Fedora in our homes that no one is around to see our passwords being entered. But we simply don't know where, physically, the user is when he is typing that password or what kind of surveilence is around at the time.
- -- Eric
- -------------------------------------------------- Eric "Sparks" Christensen Fedora Project - Red Hat
sparks@redhat.com - sparks@fedoraproject.org 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - --------------------------------------------------
On Mon, May 6, 2013 at 9:37 AM, Eric H. Christensen sparks@fedoraproject.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On Mon, May 06, 2013 at 08:27:14AM -0500, Josh Bressers wrote:
A checkbox is probably the right way to handle this. While yes it's slightly more work, it does two very important things. It puts the user in control, and it is secure by default.
Secure by default is definitely where we need to be at all times. Now if we could just get SSH to be secure by default...
That's a separate issue. But it's not gonna happen. I've raised some of the more obvious flaws on the developer's list, fhaws that existed back before OpenSSH even existed such as lack of hostkey experation, user key experiation, lack of tools to delete specific host keys from .ssh/known_hosts, lack of tools to manage authorized_keys, and the continuing support for the default use of unencrypted private keys.
The attitude from the core OpenBSD development community was "if you don't trust the machine you're on, you shouldn't be using it", and Theo de Raadt calling me four letter words.
On Fri, 2013-05-03 at 13:04 -0700, Dan Mashal wrote:
Hi,
In the latest Fedora 19 Beta TC2 install after I got through the initial steps of the install I started to setup my root password.
To my surprise my password was shown in plain text instead of bullets.
For the record:
commit da565b769979a031f318dbc727b9888e4f1fb37c Author: Chris Lumens clumens@redhat.com Date: Mon May 6 17:18:30 2013 -0400
Revert "Add signal handlers for controlling password entry visibility." (#958608).
This reverts commit 99464761dab4e43cfbf8caa059815c6ab67c6282.
Internet, you may stand down.
I don't know if the devs plan to look at the various 'compromise' solutions that were suggested, or if the plan is just to stick with regular old full-on masking. But right now, the status is that we're back to full-on masking.
On Mon, May 6, 2013 at 2:42 PM, Adam Williamson awilliam@redhat.com wrote:
For the record:
commit da565b769979a031f318dbc727b9888e4f1fb37c Author: Chris Lumens clumens@redhat.com Date: Mon May 6 17:18:30 2013 -0400
Revert "Add signal handlers for controlling password entryvisibility." (#958608).
This reverts commit 99464761dab4e43cfbf8caa059815c6ab67c6282.Internet, you may stand down.
Thank you.
Dan
On 06.05.2013 23:42, Adam Williamson wrote:
On Fri, 2013-05-03 at 13:04 -0700, Dan Mashal wrote:
Hi,
In the latest Fedora 19 Beta TC2 install after I got through the initial steps of the install I started to setup my root password.
To my surprise my password was shown in plain text instead of bullets.
For the record:
commit da565b769979a031f318dbc727b9888e4f1fb37c Author: Chris Lumens clumens@redhat.com Date: Mon May 6 17:18:30 2013 -0400
Revert "Add signal handlers for controlling password entryvisibility." (#958608).
This reverts commit 99464761dab4e43cfbf8caa059815c6ab67c6282.Internet, you may stand down.
I don't know if the devs plan to look at the various 'compromise' solutions that were suggested, or if the plan is just to stick with regular old full-on masking. But right now, the status is that we're back to full-on masking.
the classic style: http://goo.gl/NC3FI more modern style: https://addons.mozilla.org/En-us/firefox/addon/show-my-password/ wise style: hurry slowly :)
poma
-
Adam Williamson -
Andre Robatino -
Ankur Sinha -
Bill Peck -
Björn Persson -
Bruno Wolff III -
Chris Adams -
Chris Murphy -
Dan Mashal -
Dariusz J. Garbowski -
David Woodhouse -
drago01 -
Eric Christensen -
Eric Sandeen -
Felix Miata -
Florian Müllner -
Gregory Maxwell -
Ian Malone -
inode0 -
John.Florian＠dart.biz -
Josh Bressers -
Kevin Fenzi -
M. Edward (Ed) Borasky -
Marian Ganisin -
Mateusz Marzantowicz -
Mathieu Bridon -
Matthew Garrett -
Matthias Clasen -
Michael Catanzaro -
Michael Cronenworth -
Michael Scherer -
Miloslav Trmač -
Nico Kadel-Garcia -
Nicolas Mailhot -
Olav Vitters -
Orcan Ogetbil -
Oron Peled -
Pete Travis -
Pete Zaitcev -
Pierre-Yves Chibon -
poma -
Przemek Klosowski -
Rahul Sundaram -
Reartes Guillermo -
Richard W.M. Jones -
Roberto Ragusa -
Stef Walter -
Stephen Gallagher -
Stephen John Smoogen -
T.C. Hollingsworth -
Tomas Mraz -
Toshio Kuratomi