Delegate recycling causes a bug when removing an account and then adding
it back: the old, stale UI for the account is reused instead of a new one.
In combination with 'alive' guard property on the UI for account entries,
this results in the account entry becoming frozen in the old stale state.
(Incorrect helath indicators, tokens that do not update and buttons that no
longer respond anymore.)
After triggering the removal of an account from storage in the UI, it may
be possible for the UI not to fully reflect this change for a while yet.
During this short time window, it is possible for an operation to occur on
an already deleted account object which is a use-after-free bug.
In particular signals from animations and timers in the QML UI might still
trigger which causes a slot to be invoked that accesses the underlying
account object.
This change introduces a guard property called 'alive' which is flipped
when the account removal operation is triggered. Slots are updated to
check for the alive status of the UI before proceeding with other logic.
With this change the "Add" button in the "Add account" page is not enabled
until the entered account name and details are valid. Additionally, the UI
for entering the token secret now uses a password field with appropriate
hints for input methods.
This change fixes input validation for the following cases:
- Check that entered account names are still available
- Working validation for time steps (input mask was completely broken)
- Allow longer tokens: liboath is no longer used, Keysmith can handle it
Additionally the QML code is refactored significantly:
- Extracted the main accounts overview page
- Extracted the add an account page
- Completed the internal renaming of "Oath" to "Keysmith" for QML types
This change is a workaround for behaviour of QML controls: when fixup is
called during input validation, the `acceptableInput` property is not
updated correctly.
Provide a building block towards re-implementing the HOTP/TOTP
algorithms without using oath-toolkit: see issue #9.
The hmac::compute function trades simplicity (having to pre-allocate
a scratch buffer) for avoding accidental leaks of key material
(security).
This particular trade-off will help with resolving issue #6.
Provide a custom base32 implementation; relates to issues: #9 and #6.
In particular being able to control memory allocation prior to
decoding base32 will help with resolving issue #6 in a (more) secure
fashion.
Nicolas Fella
Johan Ouwerkerk
Volker Krause
l10n daemon script
Yuri Chornoivan
Bhushan Shah
Carl Schwan