*** Please type your report below this line ***
When typing from a shell in a terminal ssh foo@bar, don't fire up a GUI dialog.
It is quite disruptive.

Alternatively, provide a way of de-installing the package without de-installing half of Gnome.

Le vendredi 10 octobre 2008 à 19:07 +0200, tomas@tuxteam.de a écrit :

I don’t think it is disruptive, as long as the dialog gets the focus.

Feel free to open a bug report upstream if you are willing to nitpick on
that preference.

You can disable the SSH agent functionality by setting
the /apps/gnome-keyring/daemon-components/ssh GConf key to false.

Cheers,

That's how tastes differ. For me, it's like a popup in a web page (even
worse -- I'm typing at a text console).

That fixes it for me -- at least partially. Will the "classical"
ssh-agent take over this job then?

Thanks
-- tomás

Le samedi 11 octobre 2008 à 06:19 +0200, tomas@tuxteam.de a écrit :

You’re going to have to type your passphrase anyway, so this is at worst
surprising the first time.

Yes.

Cheers,

On Mon, Oct 13, 2008 at 10:37:20AM +0200, Josselin Mouette wrote:

[...]

Hey -- I don't intend to get into an argument about this here (unless
you want to, of course). I understand perfectly now that this is a matter
of taste and am far from dictating your (or Gnome's) taste.

Thanks for the information. For now, it's XFCE for me anyway (Gnome is
diverging too much from what I feel comfortable with).

I suppose this closes the bug (not a bug, intentional behaviour)

Thanks again
-- tomás

"I don’t think it is disruptive, as long as the dialog gets the focus."

Sometimes the dialog does not get the focus, resulting in the password
being displayed in the terminal window (I use gnome-terminal).

Choose and configure some non-mainstream window manager, forgoing
the niceties of a "desktop environment" and figuring out why lots
of things don't "just work".  In other words; back to the 90s.
I can't afford to "get with the program", as I know it will get
me screwed.

But that's just me.
I shall consider the rest of the users from now on...

Modal dialogs that take focus away from _another_ application
are disruptive, and they can lead sensitive data to the wrong
place by accident.  We need less of them, not more.

Users will not accept responsibility for their actions if the
OS trips them in ways like this.  Just look at the rampant
denial permeating the user base of that other OS that you seem
to be emulating here.

Many users may have wished for those features, but this
may be a good place to say "no you don't want that!"

I'm disappointed, too...

I can accept that the GNOME community wants this.
But Debian?  Do you really, really, really think this is

- a good idea?
- good hygiene?
- good design?
- usable?
- safe?
- enforcing good habits?
- protecting the user's credentials well?

GUIs are supposed to be user _friendly_.  That does not
just mean easy and convenient, but safe.  Especially when
it comes to private keys and passphrases.  If they turn
out to be _less_ safe against user error, they fail to
maintain the GUI comfort zone, their raison d'être!

Considering "does it work out of the box?" and "is it
easy?" is only half the story.  The rest reveals itself
much later, when we discover permutations of user error
and bugs that was rather hard to foresee.

However, some issues are not hard to foresee, as they
have already been seen in that other OS.  Those issues
tend to be labeled "expected behaviour".  Well, not to
me, who has not used that OS since 1995...

Sadly, when a soft point in the user-system combination
is "by design", it will only be fixed if is exploited
rampantly.  And that is rather disingenious, since in the
GUI realm, the user is an integral component of the system.

Increased exposure to abuse, deceit, theft and fraud should
not be dressed up as empowerment and useability.
Bosses expect their most trusted underlings to cover their
butts.  Users expect their most trusted software to cover
their butts, not just the OS's or the developer's.

Le dimanche 08 mars 2009 à 16:00 +0100, Herman Robak a écrit :

Modal dialogs that take the focus to go directly into the workflow
you’re currently in (like, asking your SSH passphrase when you are
connecting by SSH to a host) are not only harmless, they are *desired*.

I have seen what happens when they don’t steal the focus, and believe
me, you don’t want that. That, being typing your passphrase in the wrong
window.

Please come up with a better argumentation than “DO NOT WANT”. We are
not on a troll forum.

I wonder what drugs you are on. The focus is stolen *precisely* for
safety reasons. Typing something else in place of your passphrase is, at
worse, annoying. Typing your passphrase in the wrong window can be a
loss of sensitive data.

Unless you can propose a better behavior to manage SSH keys based on
real use cases and sensible analysis, please refrain from such
misinformed rants.

 I agree that if a dialog pops up for this purpose, it needs to grab
focus.  I did not mention focus.  My beef is with the dialog.

 Simple solution: No dialog.  After all, ssh manages to present a
prompt in the shell, where it is expected.

When the user has just typed ssh name@host <enter> into the shell,
the line below that will be the user's locul of attention.

 Please.  I am trying to present a rational argument that this
feature, is not an improvement, but rather fraught with new risks.
If you think it was too verbose, feel free to say that.

 As I said, the focus grabbing is not the main point.

 Simple: Leave it to the shell, which the user already interacts with.

This dialog establishes a norm in the user's mind.  The first time
the user is surprised, but eventually it is expected.  When a password
is needed, a dialog pops up.  It pops up in its own X window.

What is the problem with that?  People have confirmation bias.  If
more things happen surprisingly and out of context, they accept that
as they get used to it.  That makes both malicious spoofing and
accidential misfiling more likely.


To summarise:
1) Redundant, the shell can present the prompt
2) Detracts from the context, see 1)
3) Part of a more general problem of "floating" nags
4) Lowers contrast between expected/surprising benign/anomalous

Ordinary novice users are hurt by this, too.  But they may
already be conditioned, so they are not annoyed much, even
if they are more exposed or disrupted.

I guess only old farts like me and some security pundits know
right away that this UI is fraught with danger, and should not
be there if it is redundant.


I'm sorry if you found my style grating.  I know very well that
pissing people off is not the best way to convince them.

Oh, but I did mention the focus. *sigh*
"Modal dialogs that take focus away from _another_ application
are disruptive"

I have to admit that I do have a beef with those.  But as I wrote,
focus is not the concern here.  The redundant alien window is.

<weasel>If you take "focus" to mean the _user's_ focus,
not the keyboard input focus, it will make more sense.</weasel>

I apologise for my inconsistence here.

Le dimanche 08 mars 2009 à 19:52 +0100, Herman Robak a écrit :

And this doesn’t cope at all with the case where the SSH connection is
not initiated from the shell. If it is initiated by gvfs because the
user opened a nautilus window or a file on a remote share, there is no
shell to display the prompt in.

Doing it in the shell only when started from the shell would bring two
other issues:
     1. Inconsistency. The prompting of a SSH key is always done the
        same with the gnome-keyring interface, whatever started the
        connection.
     2. Fragility. If you want the daemon to display something in the
        SSH’s tty, you need to hijack it and put text in it, which is
        prone to breakage.

I’d say quite the contrary, since the dialog is always the same.
Previously, you’d have different prompts depending on where the
connection was initiated (e.g. the shell, nautilus, or seahorse).

Anyway, if you really want to discuss it further, I think you should do
it with upstream. I don’t think we have a good reason here to diverge
with upstream on such a disruptive scale.

If you have suggestions on how to *really* improve the interface from a
security standpoint, please bring them to upstream and I’m sure they
will be welcome. But simply removing what we have would actually be a
big regression, in both terms of security and usability.

Otherwise, if you don’t like gnome-keyring, it’s simple: don’t use it.

Cheers,

To be fair, that is the developer's problem, not the user's problem.

 That sounds like a compelling argument if you think that users
use OSes, rather than applications.  But users are application
minded.
"Alternatively, provide a way of de-installing
the package without de-installing half of Gnome."

The real message is "if you don't like gnome-keyring, don't use GNOME."
That was the consequence understood by the reporter.  He left it at that.

I would not have bothered you if I just disliked it.  I commented because
this is the default desktop install on Debian, and I have doubts that the
new feature is as secure even to those who don't dislike it.

Since key management and passwords are all about security, the priority
has to be saving the user's butt in the very long run.  I don't find it
reassuring that GNOME employs an anti-pattern like the floating parent-
less popup dialog to prompt the user for the magic word.  Making it a
consistent anti-pattern just compounds the adverse effects.  Such prompts
should be firmly attached to the gizmo/program that triggered them, and
the user should be taught to expect _that_.

Honestly, I have little hopes to duke this out with the GNOMEs, so I'll
ask whom it may concern in Debian, just for the record:

Are you concerned?

Le dimanche 08 mars 2009 à 21:37 +0100, Herman Robak a écrit :

No, this is clearly the user’s problem. The user initiates a SSH
connection one way or another, there is an increasing number of possible
ways to initiate it, and he needs to be provided with authentication in
all these cases.

The whole point of having an integrated desktop environment is to let go
of this obsolete way of thinking. With Debian, we ship a desktop that is
ready to use, and that works as a whole, not as a group of applications.
And if you really want just a collection of applications, there is the
LXDE CD.

/usr/share/doc/gnome-keyring/README.Debian

Another person doesn’t like metacity because the keyboard shortcuts are
different from those in fvwm, and another doesn’t like totem because the
playlist doesn’t have the same color as the XMMS one. Should we change
the colors and the keyboard shortcuts because of that?

Again, if you have serious concerns about security, I’m ready to hear
about them. Currently the only reasoning I’m seeing is: “I don’t like
this dialog, so there HAS to be something insecure about it.”

I’m not so sure about this being an anti-pattern. The tendency in
security systems is to cleanly separate authentication and
authorization, and this means the user will be asked for authentication
from always the same service. This is conceptually what Kerberos does,
for example.

Anyway, this problem is far from being as simple as attaching a window
to another one. Maybe you should know that making the user aware of what
exactly is requiring a keyring unlock is one of upstream’s concerns, and
they would probably be thrilled to see someone propose new approaches.

I am very concerned about providing good defaults for GNOME in Debian,
and I do not hesitate to go against upstream’s opinion sometimes. I
can’t talk for the other team members, but you really can’t say that
Debian has the reputation on jumping on all new technologies upstream
likes to explore without reflexion.

It’s just that I think you are picking up a wrong fight.

I apologize for barging in on this bug. However, I believe some very
important points are not being addressed.

Following the instructions in [1] has no effect. Although, I suppose
that is an entirely different bug. As far as I can tell, the only way to
disable the functionality is to move the executable out of the way. This
is inelegant.

There is a large nuisance as well. When the program tries to emulate an
agent, it tries to be clever and attempts to unlock every key in the
.ssh directory until it finds one that works. This leads to either the
user being forced to move his or her keys, having to click deny
every time, or accepting ssh keys into the login keyring.

There is a very real security issue here that is being brushed aside.
The layout of the dialog and the fact that it pops up everytime in an
obtrusive manner encourages the user to load SSH keys into the login
keyring. This poses a very strong security risk for users who are not
used to locking their screens when they walk away from their computer.
Given the large number of new users in the Linux community, this is a
concern. Having to enter a passphrase in order to unlock a key is a good
habit. It reminds the user that there *is* a key that *is* being
unlocked. If this is done automatically, it _nearly_ defeats the purpose
of having a passphrase in the first place.

Le mardi 24 mars 2009 à 23:36 -0700, Yury Arkady Sobolev a écrit :

Yes, this is another issue, caused by the GConf move to D-Bus, and it
will be fixed soon.

I’ve never noticed this behavior. The keyring only unlocks the keys it
actually needs. There is only one exception to this rule: the first time
it unlocks a key, it will have to try all keys since it doesn’t have
metadata on them. This issue is also fixed in 2.26 by using better
heuristics.

I agree that the “unlock this key on login” checkbox is annoying and
there should be a better way. It’s been on my mind for a while, but I’ve
just opened a report upstream about it:
http://bugzilla.gnome.org/show_bug.cgi?id=576676

Cheers,

I suppose this is because I have not unlocked a key, so it keeps asking
about it. I would expect that once it has found a key that works, it
would try that first. I will see if this improves in the next version.

Thank you for taking the time to consider my points and respond.

it.

/usr/share/doc/gnome-keyring/README.Debian

No remedy for not starting gnome-keyring-daemon is included in that file.
Removing gnome-keyring-daemon from 'Startup Applications' only changes
the desktop file to 'hidden' in $HOME/.config/autostart.  I've removed
the desktop files from '/usr/share/gnome/autostart', '$HOME/.config/autostart'
and '/etc/xdg/autostart', yet gnome-keyring-daemon persists in starting.
Please tell me how to keep it from starting.

Afaik gnome-keyring-daemon is started from PAM. So if you really want to
stop it from starting carefully comment out its lines from /etc/pam.d/.

On the other hand disabling the SSH agent functionality described at
http://live.gnome.org/GnomeKeyring/Ssh works pretty well.

Greetings,
  gw