Forgot to prune it in previous commit.

We live in a modern society where phones look like
something from Inspector Gadget and signal marshalling
is no longer something to waste goo credits on.

The greeter needs not to know the saved session after the user
settings are loaded successfully. Sending back the saved session
name could potentially form an infinite loop between the daemon
and the greeter.

https://bugzilla.gnome.org/show_bug.cgi?id=569039

This makes PAM not set it to a proper value later.

https://bugzilla.gnome.org/show_bug.cgi?id=649413

This commit updates the docs to mention the new
split authentication feature recently added.

This commit adds a plugin to initiate a conversation when
smartcards are inserted.

This commit adds a plugin to initiate a conversation for
fingerprint scans.

This allows extensions to drive which PAM conversations
get run and potentially augment the login window UI.
This commit adds one builtin extension that
does the traditional unified authentication thing, and
a plugin for password-only based authentication.

By default we use the builtin extension, but enable
the plugin with --enable-split-authentication

Subsequent commits will add support for fingerprint and smartcard
plugins.

If pam_start() fails, that suggests the configured service
stack is failing independent of the user account.

This commit exposes that failure as "service unavailable"
instead of "authentication failed".

We keep multiple conversations in the session now, keyed off of
which PAM service is at the other end.  Much of the guts still
only operate on the first conversation added though.

Now the greeter (and also the autologin code) has to say what
PAM stack it wants the slave to run.  When that stack is ready,
we emit the Ready signal as before, but now the Ready signal
carries a string argument saying which service is ready to
converse.

When we support multiple PAM stacks, the greeter will call
StartConversation for each stack, and will keep the UI
associated with each stack disabled until the Ready signals
come back one-by-one.

This way when we're running multiple PAM conversations at once
it will be obvious which worker is managing which conversation.

We want to eventually support having multiple
simultaneous PAM conversations in one login
screen (so, e.g., username/password, smart card, and
fingerprint all work at the same time).

This commit refactors the session code to be in terms
of a conversation object.  With this change, it should
be easier later to have multiple conversation objects.

The conversation is named by the pam service the login
screen is talking to.

It's pretty old code that was designed to prevent
proceeding until the user had a chance to pick language,
etc.  I don't think it's really relevant anymore, and it
adds some complexity to the code I'd rather not have.

GTK widgets must at all times report a size they can handle. So it is
not allowed to return 0 when not realized, because then size allocations
break when GTK uses this size for its widget.
In this case, GTK uses the pre-realize size to determine the size it
should request when creating the greeter window - chicken and egg so to
say.

This patch just uses the default monitor (I guess the root window's
monitor is the default monitor?) for determining the login window size.

One thing this patch doesn't do is add a call to gtk_widget_queue_resize()
from the realize callback or from monitor-changing signals, though
that's probably technically necessary.

https://bugzilla.gnome.org/show_bug.cgi?id=646498

This gets around filename length limitations.

Don't rename .xsession-errors to .xsession-errors.old if the file is not a
regular file.  The later code will truncate the file to zero anyway, so even in
that case the file won't grow indefinitely.

This is handy when the home directory is on NFS and you want to avoid network
contention when there are buggy programs which spam .xsession-errors.

Also drop the second check that .xsession-errors is a regular file even if the
opening succeeded. With that, we'd open a temporary .xsession-errors.XXXXXX
even if ~/.xsession-errors was perfectly writable (such as being a symlink to
/dev/null).

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=639527
Bug-Ubuntu: https://launchpad.net/bugs/771661

If we don't set this, it will use the default which can
cause weird behavior when building in a logged in session.

This reverts commit 2108fbb0.

It was wrong.  dconf uses both XDG_CACHE_HOME and XDG_CONFIG_HOME.
They both need to exist and be distinct.

We now install some noop mime uri handlers, so this
commit makes sure they get uninstalled at uninstall
time as well.

Later versions of dconf seem to stuff it there now.

Starting with glib 2.28, we don't use gconf to find out which handler
should be used for a URI scheme, and we need to provide a custom MIME
configuration for the gdm user to ensure no default URI scheme handler
is used.

CVE-2011-1709

This makes things a little easier for debugging problems.

We were forcing the minimum height of the scrollable widget
to be the minimum height of the tree view.  This meant the
scrollable widget would never "clamp" the tree view to a
reasonable size.

Downstream report here:

https://bugzilla.redhat.com/show_bug.cgi?id=703243

https://bugzilla.gnome.org/show_bug.cgi?id=647336

It's left over from an era past; before two was
superceded by three; when black wasn't yet the new
black; when questions were asked more frequently than
they needed to be.

If the user can't jump to an existing login screen, we should fail
instead of firing up a new one.

This way we don't get a stream of login screens from ssh users or
whatever.

This will save master.gnome.org work when posting new releases.

Earlier versions have some bugs that make GDM
crash, so probably better to just force this version.