If a device with storage memory fails during deletion phase, we just ignore
it silently from the dbus-client POV, while we should instead propagate the
error to the client.
When using Delete() method with a device with storage, we need to claim it,
however in case of failure we never return a DBus error, but instead we
ignore from the client point of view.
Use error messages to be consistent, and avoid checking for a returned
value when dbus-glib function to fetch it returned false, as it's
implicit that we had a failure.
Otherwise if didn't fail we are sure that we got the requested value.
fprintd supports "any" finger parameter for the VerifyStart call, and it's
up to the daemon to pick the first known if the device doesn't support
identification.
So remove the check to verify utility and add a test to verify this is
respected.
This avoids addCleanup ordering errors and also errors when we may try to
print an invalid stdout pipe (like when we have processed it all), as python
might fail with something like:
======================================================================
ERROR: test_fprintd_multiple_verify_fails (__main__.TestFprintdUtilsVerify)
----------------------------------------------------------------------
Traceback (most recent call last):
File "~/GNOME/fprintd/tests/test_fprintd_utils.py", line 102, in <lambda>
self.addCleanup(lambda: print(process.stdout.read()))
File "/usr/lib/python3.8/codecs.py", line 321, in decode
data = self.buffer + input
TypeError: can't concat NoneType to bytes
unittest addCleanup calls are called in reverse order, so we need to reverse
the order of the calls as well, otherwise we won't correctly terminate the
subprocess children
No need to repeat the action in every unit test, but move the tests to a
different class to easily allow adding another class with tests with no
such initialization
An assertion that is raised within a callback will not be swallowed by
the C code that called the function. To ensure that errors will be
noticable, pass the result back to the surrounding scope and check it
there.
This excercises the path where we early-report a result and the
VerifyStop call must wait for the operation to complete intenernally.
Note that this test cannot fail right now due to the FpImageDevice
internal code still trying to hide the deactivation delay internally.
See libfprint!174
libfprint 1.90.1 supports early match result report which allows to inform
the clients as soon as the driver detected a match/no-match without having
to wait the whole device driver deactivation.
Use this feature in fprintd, by emitting the "VerifyStatus" signal as soon
as we've an usable result we can inform the client about.
As per this, ignore any possible error we may get afterwards, due to device
issues or late user cancellation, as the point of the verification action
(i.e. getting a match/no-match) can be considered accomplished.
Fixes https://gitlab.freedesktop.org/libfprint/fprintd/issues/35
If a client vanishes while we are opening or closing then fprintd would
uncoditionally try to close the device immediately. This should not be
done, it instead needs to wait for the open/close to complete.
Add open/close to the current action enum and keep track of the fact
that they are ongoing. Also check, whether the device has been closed in
the meantime (after the nested mainloop is done).
Fixes: #65
The data->result was free'ed both in the loop (before breaking) and
afterwards. As the first case did not set the pointer to NULL, this
could result in a double free.
Fix this by simply removing the free that is in the loop and relying on
the cleanup later on.
We were saving the state of a disconnected device because we used a
workaround to figure it out, but now libfprint would provide us a proper
GError in such case, and so we'd handle it without the need of saving the
state, given it's never used anyways.
An application terminating because of a signal like SIGSEGV, SIGABRT and
friends, will exit with a signal number that is 128 + $SIGNAL_NUMBER, so
let's ensure that the daemon has not been terminated because of a such error
This makes even more sense with address sanitizer builds, as the daemon
would exit with abort.
Make possible to run tests with address sanitizer to quickly check for
memory errors, although we have to disable the error exit code in case of
leaks because we have some which are due to something else down in the stack
(and LSAN suppression files doesn't allow to define the stack to ignore
as we can in valgrind).
However, we'd abort in case of memory errors anyways, so this still helps
to prevent major problems, while still logging the leaks.
In order to run pam module tests with ASAN we need to manually pass the
library to LD_PRELOAD, as we do for the wrapper.
In order to run pam module tests we need to pass the libraries via
LD_PRELOAD, this supports a list of library paths, so use the compiler in
order to find their full paths (with soname) and check their presence.
In order to support linker scripts we need to introduce a workaround.
See meson issue https://github.com/mesonbuild/meson/issues/6880
Meson supports checking for default arguments natively without having to
do this for each one, so just use this feature.
Not doing this will become a warning as per meson 0.52.0 [1].
[1] https://github.com/mesonbuild/meson/pull/5627
The test doesn't need any assertion because we're calling DeleteEnrolledFingers
and in case it fails a net.reactivated.Fprint.Error.PermissionDenied error
would be thrown, and thus an exception would be raised at python level, making
the test to fail.
As per systemd's documentation:
If multiple directories are set, then in the environment variable the
paths are concatenated with colon (":").
Handle that case by splitting the paths if there's a ":" in the
variable.
Closes: #50
test_claim_from_other_client_is_released_when_vanished would fail on
the CI but work on a local system because we wouldn't want long enough
for the "vanished" code path to be taken into account. Add a small
timeout to make sure it works on the CI as well.
