Support using a fingerprint for keyring decryption at login #62
Description
I recently disabled this in 955cc22, since fingerprints cannot be used for decryption on their own, meaning GNOME keyring requires the password post-login to decrypt itself. This poses a UX problem, since most people use fingerprint login as an alternative to password login, and having to use the password again breaks that expectation.
This is somewhat a philosophical problem as well as a practical one. Login passwords have always been used for authenticating the user, but at some point, they also started to be used for decrypting keyrings. This was a decision of convenience, since most people used the same password for their keyring and didn't want to re-type it after login for the decryption. Due to this, the ideas of what a login password did started to intermingle in a bad way: people started to believe authentication was equivalent to decryption, creating the expectation today.
The solution to this problem is easy to explain and theorize, but hard to implement. After we authenticate with a fingerprint, we need to also obtain a secret key that can be used for the sake of decryption, and this needs to be done transparently so that the current UX is preserved. The easiest way (in my opinion) is to associate a secret with the fingerprint when it is first enrolled via fprintd-enroll. This secret should be unique and impossible to re-create, even if you delete and re-enroll the same finger (don't panic, this isn't a problem). Thus, we can say that this secret is unique, secure, and therefore suitable for decryption. When the fingerprint gets used for authenticating, any services that require a secret for decryption should be able to request it directly from fprintd and unlock themselves transparently.
You might be wondering why do this and not just use the fingerprint itself? The problem here is that fingerprint matching is fuzzy, meaning that each "capture" of a fingerprint is going to look slightly different. This is pretty normal if you think about it, we can't always put our finger down on the sensor in the exact same position and angle, so naturally we need to give some flexibility to the match whilst also ensuring that the fingerprint is correct. The complexity of how this occurs is beyond this scope but suffice it to say that each capture is different. Since the fingerprint scan will always appear to be different, it cannot be used for decryption because it would translate to a different sequence of bytes each time, and there isn't any way to extract something common out of them that would be usable (technically it could be possible, but it's computationally expensive and unnecessary to attempt).
From my limited understanding, this would need to be implemented as a PAM module. I have no experience in writing PAM modules, so I do not have any implementation ideas. Furthermore, I have no idea how I would interop this with fprintd itself, login daemons, keyrings, and other PAM services. Just as I said before, easy to theorize, hard to implement.
I'm sure someone more experienced than me has already developed a solution, and if they haven't, then hopefully they will soon. This is a feature that's very cool but completely beyond my current abilities, and I do not want to waste precious time churning down this route. Despite that, I want to document it because I truly believe this is a beneficial implementation not just for me, but for all users on Linux. So many other ecosystems already do this: Microsoft has "Windows Hello", Apple has "Face ID" and "Touch ID", Linux/Unix should have something similar.