Binding the touchIdEnabled Buttons state directly to the userdefaults
value.
Fixed bug that disabled the TouchIdEnabled button on an unsucessfull
TouchId unlock
Renamed touchIdEnabled outlet to touchIdEnabledButton in preparation
to bind a variable to the state value.
Used SecKeyCreateRandomKey instead of SecKeyGeneratePair as suggested
by the headers.
The fileURL for the current document does no longer have to be passed
in as a parameter but instead is retreived by accessing the windowControllers
document that hosts the MPPasswordInputController.
_touchIdHandleUnlockAttempt got renamed to _touchIdUpdateKeyForCurrentDocument
to better state its actual purpose and should no longer be called
on unsuccessfull unlock attempts. It also now removes stored keys if the
state of the TouchIdEnabled button has changed.
The key, that is derived from the document, is now the same whether it is
used to store it in the transient dictionary or the userdefaults
This is a good feature for security and stability. It gives users
the option to prevent TouchID unlock for any previously unlocked
database and it is also helpful in cases where only one part of the
keypair is in the macOS keychain.
While originally not intended, this changeset enables MacPass to
unlock a database with TouchID even after the process is completly
wiped.
It does this by introducing multiple modes of operation.
First: TouchId can be completly disabled. The TouchID checkbox is off
and MacPass works like the TouchID feature had never been added.
Second: The TouchID checkbox gets put into the mixed state. MacPass will now
remember the database key in memory as long as the process remains
alive and the database can be unlocked with TouchID until the
applications terminates.
Third: The TouchID checkbox is checked and MacPass will store the encrypted
database key on a successfull unlock attempt in the standard
userdefaults. TouchID unlock works now even after MacPass is completly
terminated and restarted.
