Biopass: a face and fingerprint login for Linux desktops

Linux never got the Windows Hello experience, so Biopass supplies one

The README states the gap directly. While Windows Hello provides a smooth multi-modal biometric experience with face, fingerprint and PIN on Windows 11, Linux has historically lacked a modern, unified equivalent. Biopass was developed by two named contributors to fill that gap, and the project describes itself as modern multi-modal biometric login for Linux, face and fingerprint, with GUI management.

The multi-modal part is the interesting design decision, and it is what the comparison table with Howdy is built around. Howdy offers face only, a command-line interface only, manual configuration, and IR camera anti-spoofing. Biopass offers face plus fingerprint, a modern GUI for management, GUI-based configuration, and anti-spoofing with both an IR camera and an embedded AI model.

So the pitch is not that Biopass is a better face recognizer than Howdy. It is that Biopass covers two modalities, exposes them through a graphical interface, and layers an AI model on top of the hardware check for anti-spoofing.

For a person whose laptop has a fingerprint reader but a mediocre webcam, that combination is the whole argument. For a person who only has face, the comparison narrows to the GUI and the AI model, and the answer to whether that is enough depends on how much you value a graphical enrollment flow over a command line one.

The user is a Linux desktop user who wants passwordless login and does not mind installing a PAM module and a system service. This is not a server-side or headless tool, and it is not a container story.

Two sub-projects: a PAM module and a Tauri app

The repository layout and the root Makefile together describe the architecture, and the Makefile header is explicit about it. It is the root build orchestrator, driving both sub-projects from the repository root: `auth/` is a C++ CMake PAM module with face, fingerprint and voice libraries, and `app/` is a Tauri desktop application.

That split is the design. The part that actually authenticates you has to be a native shared library that the PAM stack can load, so it is C++ and CMake. The part that lets you enroll a face, manage models and change settings is a desktop application, so it is a Tauri app with a web frontend.

The Makefile coordinates the two. The aliases are compact:

all: build

build: build-auth build-app

package: package-app

and the auth build target configures CMake against the `auth` source directory into a build directory, with the build type, deprecation warnings turned off, and the project version passed in:

build-auth:
	@echo "==> [auth] Configuring CMake (BUILD_TYPE=$(BUILD_TYPE))…"
	cmake -S auth -B $(AUTH_BUILD) \
	      -Wno-deprecated \
	      -DCMAKE_BUILD_TYPE=$(BUILD_TYPE) \
	      -DCMAKE_WARN_DEPRECATED=OFF \
	      -DCMAKE_ERROR_DEPRECATED=OFF \
	      -DPROJECT_VERSION=$(VERSION)
	@echo "==> [auth] Building…"
	cmake --build $(AUTH_BUILD) --config $(BUILD_TYPE) --parallel

The version is derived from git rather than hardcoded, with `git describe --tags --always` and a fallback of 0.1.0, so the version stamped into the build follows the tag history.

The prerequisite list in the Makefile comment is worth reading before you start, because it is a substantial list. The auth side needs cmake, ninja or make, `libpam0g-dev`, `libcli11-dev` and `libturbojpeg0-dev`, and libcamera is built from source and pinned, which needs meson, ninja-build, `python3-jinja2`, `python3-yaml`, `python3-ply` and `libudev-dev`. The app side needs bun, rustup or cargo, tauri-cli v2, webkit2gtk and `libssl-dev`.

Face recognition runs on EdgeFace and YOLO-Face

The model choices are named in the References section, and they are specific enough to plan around. Face Recognition uses EdgeFace, and Face Detection uses YOLO-Face.

That pairing maps onto the pipeline. Detection has to happen before recognition, since a recognition model expects a cropped face, and the detector supplies the crop. The anti-spoofing path is separate and uses hardware, an IR camera, rather than the recognition model.

The repository topics name antispoofing, face-authentication, fingerprint-authentication, pam and tauri, which is a fair summary of the scope.

There is one feature on the list that is explicitly not finished. The Features section has a checklist, and the unchecked item is Local AI model management, where the user can download, update and delete AI models for supported authentication methods. Every other listed item is checked, including registration of multiple biometrics for a user, running authentication methods in parallel or sequentially, face recognition, face anti-spoofing both with the AI model and with the IR camera, and fingerprint.

The gap is worth understanding because it determines how you install and update. Without local model management, the models ship with the package rather than being fetched and versioned by the app, so a model update arrives when the package updates, and an administrator cannot install an alternative model from within the GUI.

Installation is a package, plus PAM and polkit work that has to be done

There are three distribution channels, and the README links each to a release artifact rather than describing a build.

The Debian and RPM packages are on the GitHub releases page, and there is an AUR package for Arch. So for a mainstream distribution you are installing a binary package, and for Arch you are using the AUR.

The parts that the packages do not do for you are the system integrations, and the README points at three separate documents for them.

System sign-in setup uses distro-managed PAM configuration when available, for example `pam-auth-update` on Debian and Ubuntu, with the details in `docs/PAM.md`. Interactive polkit authentication setup is covered in `docs/Polkit.md`, which matters for GUI applications that need to ask for authentication. And there is an IR camera setup guide at `docs/IR camera.md`.

That last one is the requirement most likely to block an evaluation. The anti-spoofing feature depends on an IR camera, and a built-in laptop webcam generally does not have one. A desktop with an external IR camera can use that path; a laptop with an ordinary camera is relying on the AI model for anti-spoofing, and the README does not describe how the two paths interact when one is unavailable.

The practical sequence is therefore: install the package, set up PAM for sign-in, set up polkit for interactive authentication, and set up the IR camera if you have one and want the hardware check.

The two integration points that decide whether it works

Authentication on Linux happens at two different layers, and Biopass has to plug into both of them, which is why there are two setup documents.

PAM, the Pluggable Authentication Modules framework, is what the login screen consults. When you enter a password at the graphical login or over SSH, PAM is what decides whether it is accepted. A biometric stack that does not register a PAM module is invisible to the login screen, and that is what `docs/PAM.md` is about. The README notes the use of distro-managed configuration where available, which on Debian and Ubuntu means `pam-auth-update` presents a list and you select the entry.

polkit, the PolicyKit, is the authorization layer for actions that need privileges, and it is what lets an application ask a user to authenticate for a privileged operation without being root. A desktop application that needs to trigger a biometric check runs into polkit rather than PAM, which is why `docs/Polkit.md` is a separate document and is described as interactive polkit authentication setup.

Getting only one of these right produces a confusing result. The application can prompt for a fingerprint through the GUI, while the login screen still asks for a password, and it is easy to conclude the installation failed when in fact only one path was configured.

The build side has the same two-part structure. The `auth` directory is the C++ CMake PAM module, and the `app` directory is the Tauri application, and the root Makefile's `build` target runs both, with `package` handling the app side.

Compared with Howdy and with keeping a password

Howdy is the comparison the README itself draws, and the differences are the ones to weigh.

Howdy is face only, configured by hand from a command line, with anti-spoofing that relies on the IR camera. Biopass adds fingerprint as a second modality, replaces the command line with a GUI for management and configuration, and adds an AI model to the anti-spoofing path.

The difference in approach is really about breadth versus focus. A face-only system has one camera to support, one matching threshold to tune, and one failure mode to reason about. A two-modality system has to present two choices at the login screen, decide whether they can run in parallel or in sequence, and handle the case where one hardware path is unavailable on a given machine. The Features section says authentication methods can be executed in parallel or sequentially, which is the right level of choice to expose, but it is still a decision you have to make and then live with.

The second alternative is keeping a password, or using a hardware security key, or using the fingerprint reader that many Linux distributions already wire up through fprintd. For a single-user machine with a working fingerprint reader, the distribution's own support is often less work than installing a biometric stack, and it has none of the PAM and polkit integration surface. Biopass is worth the integration cost when you want face as well, or when you want the management GUI, or when you want the hardware IR check for anti-spoofing.

A word on the model supply chain. The face recognition and detection models are third-party projects, EdgeFace and YOLO-Face, which means the accuracy and the licensing of what you run come from them, and Biopass's own contribution is the integration, the PAM module and the application around them.

Active release cadence, and an unusual licence question

The maintenance situation looks healthy on the release side. The listed releases are 1.4.1 on 2026-07-12, 1.4.0 on 2026-07-11 and 1.4.0-rc3 on 2026-07-11, so a release candidate and two final versions within a day, and the last push was on 2026-10-20 with the repository not archived. The presence of a release candidate alongside the finals is normal practice and suggests the maintainers version carefully around the 1.4 line.

The repository has a `CONTRIBUTING.md` at the root, a `lefthook.yml` for git hooks, a `Makefile`, an `app/` directory, an `auth/` directory and a `docs/` directory, which is a conventional layout for a project with a native component and a desktop app.

The licence is MIT, and the LICENSE file is at the repository root. The interesting part is not the licence but the scope of what you are licensing. A PAM module is loaded into the authentication path of the system, and the face models come from separate projects, so the pieces that touch your machine and your camera come from different places with different terms. This is not legal advice, and it is worth reading the model projects' licences if the deployment is anything other than your own laptop.

One limitation to plan around is stated in the Features list itself. Local AI model management is not implemented, so models ship with the package and are updated when the package is updated, which means model updates are tied to release cadence rather than being something you control at runtime.

Editorial conclusion

Adopt Biopass if you want Windows Hello style multi-modal login on a Linux desktop and you are willing to wire PAM and polkit yourself, following the docs in the repository. Do not adopt it if you need a single modality done well, since supporting two modalities doubles the hardware and integration surface, and skip it if a graphics-free terminal login matters to you. Verify first that your camera has the IR capability the anti-spoofing path depends on, and that the packaged versions match your distribution, because the Debian, RPM and AUR packages are separate artifacts with separate maintenance.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. TickLabVN/biopass on GitHub