Re: sftp module cant connect to new hosts

[Mattias Eriksson <snaggen acc umu se>]

Well what do you suggest? My imagination can only come up with three
options:
1. We accept all connections - this is NOT the solution since we then
would use SSH in a insecure way.
2. We deny all connections and tell the user about it - the user then
has to run ssh/sftp from the command line. This (and I think we agree
here) is not the best way of doing things from a usability point of
view.
3. Let the user decide what to do - this is really the only choise we
have since we cannot decide if the server is actually the server that
the user wants to connect to. 

I guess the message might be improved to inform the user what is
happening and how the user may validate the host key, but I have to
narrow imagination to see how this may be automated.

//Snaggen, not so good a UIs and with a small imagination

ons 2004-03-10 klockan 00.03 skrev Seth Nickell:
> UI wise I'm not sure popping up a dialog to "accept" the host key really
> adds security.
> 
> -Seth
> 
> On Mon, 2004-03-08 at 05:25, Alexander Larsson wrote:
> > On Sun, 2004-03-07 at 14:59, Mattias Eriksson wrote:
> > > Hi, I was looking at the sftp module because I had some trouble
> > > connecting to a host. I then connected manually and realized I have
> > > never connected to that host before so I had to accept the host-key.
> > > When I looked at the code to fix the problem I can't find a easy way to
> > > do it. I have looked at the callback mechanisms, but the standard
> > > callbacks are for authentication and status from what I can see. If I
> > > define a new callback I have to patch nautilus to handle that. 
> > > But before I go through to much trouble I want to hear if the callback
> > > mechanism might be used as I think for general ask-user dialogs. I guess
> > > the pointer to the in-argument can point to a struct that contains the
> > > message and the options, then in return in the out-argument you just get
> > > which argument the user selected.
> > > Another thing if I patch gnome-vfs to create a new standard callback,
> > > where should the general code to handle this in gnome be? libgnomeui?
> > > 
> > > So is this a possible solution or am I running in the wrong direction?
> > 
> > Its probably right. We don't want a bazillion different callbacks in
> > gnome-vfs, but in this case its probably right. It should be a generic
> > callback that can be used by other backends with similar issues though.
> > 
> > The default gnome implementation goes in libgnomeui with the other auth
> > callback dialogs.
> > 
> > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> >  Alexander Larsson                                            Red Hat, Inc 
> >                    alexl redhat com    alla lysator liu se 
> > He's a notorious devious filmmaker gone bad. She's a transdimensional 
> > out-of-work pearl diver prone to fits of savage, blood-crazed rage. They fight 
> > crime! 
> > 
> > _______________________________________________
> > gnome-vfs-list mailing list
> > gnome-vfs-list gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-vfs-list