{{toc}}

Rationale

GDM was rewritten between Debian Squeeze and Wheezy in ways that entirely break our custom greeter. So, we have to either adapt our greeter to the new GDM (if possible at all), or switch to another display manager and port our greeter to it.

Roadmap

1. Spend 2 days trying to convert tails-greeter to Wheezy’s GDM (Alan and intrigeri, late June)
2. At the end of these 2 days, decide about GDM vs. lightdm.
3. If GDM is chosen, then finish the migration to Wheezy’s GDM (Alan and intrigeri, before mid/late July).
4. If GDM is chosen, then spend 2 days improving the UI/UX (Alan, Tchou and intrigeri, late July / early August); we probably won’t do the full UI revamp (Feature #5464) we’ve been dreaming of, but if that’s cheap and good enough, moving to the best of Alan’s proposed mockups + tchou’s proposed improvements could be a wonderful first step.
5. migrate tails-greeter to Python 3 (Feature #5701)?

Candidates

GDM

Summary: GDM nowadays looks not very inviting (not to say hostile…) to us custom greeter developers.

Wheezy’s GDM removes features such as setting the keyboard layout.

It’s not clear if the rest of the GdmGreeterService interface changes, and I was not able to find any developer documentation on this.

The way the greeter component is started seems to have changed (e.g. I had to rename tails-greeter.desktop to gdm-simple-greeter.desktop to have it started at all, and the result displays no window at all). I was not able to find any documentation on this. Nor did I find any existing custom greeter for GDM 3.x.

Update: the gdm3 (3.4.1-7) debian/changelog entry reads:

* debian/patches/40_add_start_dir.patch:
  + Call gnome-session with --start /usr/share/gdm/greeter/autostart.
    .desktop files in that directory will be autostarted (if the
    condition to do so is true) in the gdm session.

… so perhaps that would be all that’s needed to have our greeter started? Incidentally, this last-minute patch for Wheezy gets accessibility back.

Also see the Custom greeter thread on tails-dev (early April 2013); quoting Ray Strode there:

Here’s the commit where the fallback greeter got ported to the new api: https://git.gnome.org/browse/gdm/commit/gui/simple-greeter?id=1ec0665b631965b8c73277374dddde8b1d8b6d1e

lightdm

Summary: lightdm looks very promising, but it may be lacking in some areas (accessibility).

lightdm has made huge progress since the time we considered it in the early pre-tails-greeter days:

• it’s now used by default in Ubuntu: unity-greeter, but also lightdm-gtk-greeter for Xubuntu and Lubuntu, KDE Greeter for Kubuntu
• a design goal is to be cross-desktop, and to separate the backend from the GUI; in practice, there are at least 4 greeters in active development, and a few more example ones, so one may think upstream won’t silently break the well-documented interface without caring about downstreams
• upstream find it important enough to have various greeters to blog about it and give an overview of how to do it
• it knows how to set the language and keyboard layout
• one may write a greeter in any language that supports GObject introspection (examples exist at least in C, Vala and Python)
• acceptable security: wasn’t that good in the beginning IIRC, but only one CVE filed (and it was in 2011), so should be good enough. Ubuntu ships an AppArmor profile for lightdm, no idea how restrictive it is though.
• for development purposes, a VM is a must for full scale testing, but lightdm --test-mode --debug starts a greeter in a window inside your existing session, as an unprivileged user (and logs to ~/.cache/lightdm/log/x-*-greeter.log)

One should have a look at possible drawbacks, though:

• accessibility features, or lack thereof?
  • Unity Greeter has some accessibility support: at least it knows how to run the Orca screen reader and the onboard onscreen keyboard, and it knows how to set a high-contrast GTK theme. Not running a full GNOME session, window manager included (contrary to GDM), forces them to manage a few things by hand, but it still does not look that crazy.
• Wheezy’s (1.2.3-1) lightdm does not build GObject introspection data, but sid’s (1.6.0-2 and later) does — this is needed to enable us to write greeters in something else than C.

Archive: webkit

We’ve given up the idea of writing our greeter as a web interface. Here’s some initial archived research in this area:

• lightdm-webkit-greeter and lightdm-pywebkit-greeter allow writing greeters in HTML/CSS + JavaScript… in case we want a Web-like look’n’feel, and possibly make it easier for people who are more into design to contribute to our greeter.
• JavaScript can’t run arbitrary commands nor create files, so a WebKit greeter could not work exactly the same way as current tails-greeter does (worst case: at least with pywebkit-greeter, the JS code passes back messages encoded in a URL using document.location.hash to the small Python adapter that received in through the navigation-requested signal — this way, the Python adapter can take care of the side effects; the jQuery serialize method allows to pass a set of form elements this way; the webkit-greeter more elaborately builds a JS lightdm class so that the JavaScript code can call outside, but this is written in C and thus harder to build upon)
• Arbitrary data can be passed from the pywebkit greeter as arguments to JS functions, once serialized in JSON, using the WebKit execute_script method.

GDM migration

Setup

apt-get install gdm3 gtk2-engines
dpkg -i --force-all tails-greeter*.deb
ln -s /bin/true /usr/local/sbin/live-persist

TODO

• Keep in sync’ with the Squeeze version.