In test mode, dynamically load libraries in well known locations that can
allow to override the libfprint behavior.
It would still be possible to potentially inject code by replicating the
distro build directory and adding a library there, but if one is able to
access there, they would already be able to access any path.
Plus the env variable check is still there, so again they would need to
be able to change the fprintd environment
Add support for the SecuGen Hamster Pro 20 (1162:2200), a 500 DPI
press-type optical scanner built around the SIDO020A sensor.
The protocol was reverse-engineered from USB packet captures. The
sensor is configured over I2C-tunneled vendor control transfers and
streams 956x688 raw frames over the bulk endpoint, read in 64KB
chunks so the standard pcap-based test tooling can record full
frames (the kernel usbmon interface truncates single URBs at
ring_size/5). Frames are processed with band compensation, an
edge-aware unsharp mask, a fixed-point bilinear downsample to
300x400, flat-field blending and directional sharpening, driven by
per-device factory calibration data read from the device firmware.
The fixed-point pipeline keeps the output bit-identical across
compilers and architectures for the image comparison test.
The sensor has no proximity hardware and its GET_STATUS request
always returns zeros, so finger presence is detected by polling
preview frames and comparing the mean brightness of the central
region against a calibration background frame.
Includes a umockdev capture/replay test with a reference image.
Closes: https://gitlab.freedesktop.org/libfprint/libfprint/-/work_items/353
When memory sanitizers are set, tests may fail because we are indirectly
LD_PRELOAD'ing (through umockdev). While we could ensure that sanitizer
libraries are loaded first, it's just something we don't care because we
don't want to test the launcher wrappers themselves.
So, let's just ignore the link order and live with it
Drop usage of NSS library now that openssl >= 3.0 has not anymore any
license incompatibility.
OpenSSL will provide us a better ground for further developments and
it's also the preferred crypto library by most distros these days
Doesn't build on other operating systems.
With auto-detection we don't have to manually select all other drivers.
Signed-off-by: Daniel Schaefer <dhs@frame.work>
GLib 2.68 is now more than 3 years old, so we can definitely start
using it without thinking too much.
This allows us to drop lots of compat code that we had around.
And like the previous commit tells us, it will also help us to have
more correct code around.
Having this should at least give us a slightly better idea about the
version that the user has installed. Obviously it is still not very
accurate (maybe a git hash would be good if available?), but it should
still be helpful overall.
