tails-greeter vs. Wheezy
Originally created by Tails on #5553 (Redmine)
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.
- Spend 2 days trying to convert tails-greeter to Wheezy’s GDM (Alan and intrigeri, late June)
- At the end of these 2 days, decide about GDM vs. lightdm.
- If GDM is chosen, then finish the migration to Wheezy’s GDM (Alan and intrigeri, before mid/late July).
- 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 (#5464 (closed)) 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.
- migrate tails-greeter to Python 3 (#5701 (closed))?
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
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
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 --debugstarts a greeter in a window inside your existing session, as an unprivileged user (and logs to
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.
We’ve given up the idea of writing our greeter as a web interface. Here’s some initial archived research in this area:
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.hashto the small Python adapter that received in through the
navigation-requestedsignal — 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
- Arbitrary data can be passed from the pywebkit greeter as arguments
to JS functions, once serialized in JSON, using the WebKit
apt-get install gdm3 gtk2-engines dpkg -i --force-all tails-greeter*.deb ln -s /bin/true /usr/local/sbin/live-persist
- Keep in sync’ with the Squeeze version.
Feature Branch: feature/wheezy
Parent Task: #6015 (closed)