- 19 Dec, 2020 1 commit
-
-
Marco Trevisan authored
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
-
- 17 Dec, 2020 1 commit
-
-
Marco Trevisan authored
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.
-
- 16 Dec, 2020 2 commits
-
-
Benjamin Berg authored
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.
-
Benjamin Berg authored
-
- 14 Dec, 2020 1 commit
-
-
Benjamin Berg authored
We need at least the GFlagsClass autoptr, but just pull in most of the definitions from libfprint.
-
- 11 Dec, 2020 8 commits
-
-
Benjamin Berg authored
-
Benjamin Berg authored
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.
-
Marco Trevisan authored
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
-
-
-
Dudemanguy authored
The systemd dependency is only used to install some systemd service files. This can easily be made optional.
-
Benjamin Berg authored
This really should never ever happen. If it does, don't continue but stop instead.
-
Benjamin Berg authored
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
-
- 09 Dec, 2020 1 commit
-
-
Benjamin Berg authored
-
- 08 Dec, 2020 2 commits
-
-
Marco Trevisan authored
-
Marco Trevisan authored
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
-
- 07 Dec, 2020 24 commits
-
-
Marco Trevisan authored
-
Marco Trevisan authored
-
Marco Trevisan authored
-
Marco Trevisan authored
-
Marco Trevisan authored
We follow libfprint here, using GNOME format
-
Marco Trevisan authored
Just continue earlier instead of using a long if check
-
Benjamin Berg authored
-
Marco Trevisan authored
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.
-
Benjamin Berg authored
Otherwise the PAM module will crash trying to send an info message about the selected print.
-
Marco Trevisan authored
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.
-
Marco Trevisan authored
-
Benjamin Berg authored
-
Benjamin Berg authored
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
-
Benjamin Berg authored
-
Marco Trevisan authored
-
Marco Trevisan authored
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.
-
Marco Trevisan authored
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
-
Marco Trevisan authored
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
-
Marco Trevisan authored
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>
-
Benjamin Berg authored
It may be useful, just let it go to stdout/stderr.
-
Benjamin Berg authored
This can only happen if fprintd is not adhering to the protocol.
-
Benjamin Berg authored
-
Benjamin Berg authored
This allows properly reading the output only to the point where we can ensure that verification has started.
-
Benjamin Berg authored
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.
-