GitLab

As per new GLib in CI image fprintd doesn't build anymore, since
g_once_init_enter now warns about using a volatile value, as this has
never been supposed to be the case, despite its signature [1].

Related to: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1719

[1] https://gitlab.gnome.org/GNOME/glib/-/issues/600

This is useful in the functions where we have to unset the device's
current action but we may use early-return to handle multiple conditions
such as in open, close and delete functions.
The latest also currently is a bit buggy as it won't reset the state on
some failures.

In the usual test we cancel the operation immediately by calling
VerifyStop. This (often) tests the case where we don't end up restarting
the Verify operation internally.

We can easily force fprintd to have restarted already internally, so add
a test that does so by sleeping a bit. This should give us a slightly
higher branch coverage in the verify_cb/identify_cb tests.

We need at least the GFlagsClass autoptr, but just pull in most of the
definitions from libfprint.

It seems that GLib may process multiple DBus signals in one mainloop
iteration. This could cause messages to be re-ordered, which in turn
caused a race condition in the CI that could trigger random failures.

Given we're going to use an object manager it can just stay at the root
of the project, while it will be just used to manage the devices

The systemd dependency is only used to install some systemd service
files. This can easily be made optional.

This really should never ever happen. If it does, don't continue but
stop instead.

We must ignore NameOwnerChanged that happen due to automatic startup.
The easy way to do so is to just register it only when we get to the
point that a name owner change has security implications.

While add it, change it to always log at a warning level.

Fixes: #94

It's not smart as g_strdup, so need to ensure we don't use it for NULL
strings.

This is a regression caused by commit bf223662

We follow libfprint here, using GNOME format

Just continue earlier instead of using a long if check

We already use FpFinger for storage operations and prints management,
but internally we keep still using the old finger number, that uses
different values for invalid data.

Let's be consistent, and always use FpFinger everywhere.

Otherwise the PAM module will crash trying to send an info message about
the selected print.

Implement simple auto-pointers for the types we use in pam_fprintd with
a basic implementation based on GLib one so that we can have the same
features without having neither an header-dependency on it.

If fprintd disappears or is replaced, then we might be getting signals
from another daemon/verifcation session.

As such we must give up at that point.

Related: #47

We had a race that was causing the events to be handled even if we were
not ready to accept them, causing a potential non-authentication.

So simulate this case, by sending a 'verify-match' event before we
started the verification and ensure that we ignore it.

In case fprintd is emitting a verify signal for another request that is
still going on while we're about to start a new verification, we'd just
accept such signal, so potentially allowing a log-in because another
concurrent request succeeded.

To avoid this, use async call to VerifyStart and open a verify window
(during which we accept the verification related signals) that is kept
open just once the VerifyStart call has been completed and before
stopping the verification again. As that's the only moment in which we
can be sure that we've control of the daemon events for such device.

Thanks to Benjamin to find out the race.

Fixes: #47

This is both in case in we start the authentication and in the absurd
but (hey, testing!) situation in which prints gets deleted in between
the device claiming and the verification start.

To handle this second scenario we need to instruct fprintd mock to raise
an error on some special command

This now allows:
 * Sending signals before and after method return
 * Exiting the daemon
 * Emulating NoEnrolledPrints DBus method error
Co-authored-by: Benjamin Berg <bberg@redhat.com>

It may be useful, just let it go to stdout/stderr.

This can only happen if fprintd is not adhering to the protocol.

This allows properly reading the output only to the point where we can
ensure that verification has started.

The verify script would start an async routine. However, this blocks the
dbus return, which really is needed.

Also, we should only return one item of the script for each VerifyStart
run. So, fix things by pop'ing the first item and putting it on the bus
from a GLib.add_timeout handler.