Re: tls-ftp and GConf

[Andy Hanton <andyhanton comcast net>]

On Mon, 2003-09-08 at 07:15, Alexander Larsson wrote:
> Since vfs modules are very hidden, very "automatic" pieces of code, with
> no user interface or visible user-model these kinds of settings just
> don't work that well. Unless they are really honest-to-god preferences,
> ie. do you prefer it this way or that way, everything still works
> whatever you decide.

I think that they should have a ui.  No sane person is going to connect
to an ftp server over ssl by typing ftp://user:password somesite com/
into the location bar.  They will use a password prompt dialog instead. 
On MacOS X there is an options button in that dialog that pops up a
dialog with checkboxes for things like tunneling over ssh and allowing
cleartext passwords. Those settings can be changed for the current
connection or saved.  It also has a button for changing the password.  I
think that this setting would fit in perfectly in a dialog like this. 
Of course this would require gnome-vfs or some other library to provide
the dialog instead of forcing each application to handle the
authentication callback and provide their own dialog, but I think this
is required for decent handling of the differences between protocols. 
For example, the smb password dialog really should include a separate
text box for the domain.  I would assume that in the future some
protocol will support  certificates and only a passkey would be
required.  

The Appletalk options dialog
http://home.comcast.net/~andyhanton/temp/osx-afp-options.png

The password dialogs from OS X
http://home.comcast.net/~andyhanton/temp/osx-afp.png
http://home.comcast.net/~andyhanton/temp/osx-smb.png

I think apple has not done a good job keeping the dialogs consistent,
but it does show the usefulness of allowing each protocol to at least
add widgets to the authentication dialog.    

> A better way of handling this problem could be trying to detect when the
> firewall problem will happen, and reauth not using tls. I don't know how
> feasible this is, but we should at least look into it. At the very least
> if we chose to go with the gconf key route we need to handle timeouts in
> the ftp method so that we don't hang forever. (This is also needed in
> the http method btw. I looked at it once, and it didn't look that hard
> to add. Wasn't in time for 2.4 though.)

Silently falling back to cleartext sounded like a good idea at first,
but is that what the user would want?  If an advanced user knows that
the site supports secure connections and that gnome supports them, they
will expect to connect securely.  I think that even less knowledgeable
users would want to know if their password would be sent securely
because they have become accustomed to it from the little lock icon in
web browsers.  It would be cool if we could have an icon in the lower
left corner of the password dialog indicating whether the password would
be encrypted or not.  We could even steal the icon from epiphany.  

MacOS 7, 8, 9 had a similar feature where the password dialog had a
label at the bottom that said 'clear text' or 'two way scrambled' for
the challenge-response authentication.  In OSX it only warns if you are
about to use cleartext.  I guess they figured all modern afp and smb
servers support encryption so it wasn't worth keeping in their dialog. 
Since we support protocols like http and ftp that have been
traditionally unencrypted I don't think that reasoning applies to us.  
  
The password dialog from MacOS 7
http://home.comcast.net/~andyhanton/temp/os7-afp.png

I am having difficulty thinking up a proper solution to the problem with
firewalls that doesn't address these larger issues.  I could pop up a
dialog telling the user that the secure connection to the server failed
and asking if the user wants to retry without tls, but this dialog could
get really annoying for people behind firewalls.  I could add a checkbox
to the dialog for 'always use cleartext authentication for ftp', but
then there would be no way for an end user to change their mind later
unless the preference is added to the UI somewhere else. I agree that
the timeout handler should prevent the application from hanging, but
without some UI I don't see how it can do much more.  

Should I file RFEs for these ideas?  Do you have any suggestions for how
to fix this problem with firewalls in the short term? Do you think it is
acceptable to fall back to cleartext authentication without telling the
user?

-- 
Andy Hanton <andyhanton comcast net>