Re: xscreensaver, any plan do drop it !!

[William Jon McCann <mccannwj pha jhu edu>]

Hello John,

John (J5) Palmieri wrote:
> Some people had some problems with it becoming a replacement.  Not sure
> what they were and I haven't investigated it myself.

I encourage you and others to actually look at how I've been trying to 
design gnome-screensaver.  I am eager to receive specific feedback.

> Has it been vetted
> yet for security issues?  The biggest problem with xscreensaver type
> locking is that if xscreensaver crashes your session is unlocked.  This
> is why the author didn't want to link against external libraries if it
> could be avoided (and why we get ugly dialog).  Replacing it with
> something else doesn't really solve any problems other than making it
> look better.  I think we need to get GDM to start doing the locking.
> That way if it crashes the session exits.  If we do that then we can use
> anything for a screensaver app.

I'll agree with you in principle that failing closed is better than 
failing open.  However, failing closed with data-loss and disruption not 
an ideal solution (except for security experts and TSA employees).  Talk 
to angry users who have been logged out and lost work.  Of course, this 
argument applies equally to xscreensaver and gnome-screensaver.

It is not true that using a toolkit for the lock dialog requires linking 
to toolkit libraries.  I think I've solved this problem adequately by 
running the authentication checking and lock dialog code in a separate 
process that is embedded in the window using XEMBED.  I decided to use 
GtkSocket for this, on the daemon side.  It should be possible to do 
exactly the same thing using only Xlib.  I have chosen not to duplicate 
code and also acknowledge that most likely I could not do it better than 
GTK+ does.  Obviously, a trade-off.

Using a separate process for the input processing, authentication, and 
non-trivial widgetry is a big win in terms of security.

Replacing the input dialog is only one of the many goals of 
gnome-screensaver and not one of the most important ones.  It is more 
important that gnome-screensaver allows a system administrator to set 
mandatory policy for screensaver themes and locking.  It is difficult to 
talk about system security when any any user can disable the screensaver 
altogether or use a theme that displays porn and the system 
administrator can't do anything about it.  On the other hand, some 
systems require that the screen never be locked.  Setting this kind of 
policy is impossible to do with xscreensaver.

Currently, gnome-screensaver uses GConf for settings and policy.  At the 
moment this requires it to link to the GConf libraries.  The use of 
GConf is an implementation detail to gnome-screensaver.  It is hidden 
within the GSPrefs object.  I think it should be possible to use some 
kind of proxy object via DBus to get these settings and changes.  I am 
not familiar enough with DBus to know how one can up a trust 
relationship between two objects.  Since it is important that the 
settings come unaltered from GConf I have decided (for now) to link 
directly to the GConf libraries.

gnome-screensaver is about a lot more than "making it look better." 
Let's try to move the conversation past that point.

I've tried to put some information in the Wiki:
http://live.gnome.org/GnomeScreensaver

I'll be happy to try to answer any specific questions and criticism.

Thanks,
Jon