This commit allows users to put alternative wordlists in a `wordlists` subdirectory below their KeePassXC directory (e.g., under Linux, `~/.config/keepassxc/wordlists`). These wordlists will then appear in the dropdown menu in the *Password Generator* widget.
In order to differentiate between lists shipped with KeePassXC and user-provided lists, the former appears with a (SYSTEM) prefix.
Fixes#6942 and fixes#4443
- Return number of deleted entries
- Fix minor memory leak
- FdoSecrets: make all prompt truly async per spec and update tests
* the waited signal may already be emitted before calling spy.wait(),
causing the test to fail. This commit checks the count before waiting.
* check unlock result after waiting for signal
- FdoSecrets: implement unlockBeforeSearch option
- FdoSecrets: make search always work regardless of entry group searching settings, fixes#6942
- FdoSecrets: cleanup gracefully even if some test failed
- FdoSecrets: make it safe to call prompts concurrently
- FdoSecrets: make sure in unit test we click on the correct dialog
Note on the unit tests: objects are not deleted (due to deleteLater event not handled).
So there may be multiple AccessControlDialog. But only one of
it is visible and is the correctly one to click on.
Before this change, a random one may be clicked on, causing the
completed signal never be sent.
* Closes#6335
* Modify application settings presentation to allow for alternative saving strategies
* Transition Database::save calls to using flags to control saving behavior. Reduces boolean flags on function call.
* Made direct write save option a local setting to prevent unintentional carry over between platforms.
* Fixes#6459
Improves the overall handling of FdoSecrets showing client executable paths to the user. It does the following:
* Check executable file existence as described in [RFC] fdosecrets: add optional confirmation to secret access (#4733)
* Show application PID and dbus address in the client list
* When the executable file is inaccessible, depending on where the client name is shown:
* when shown inline, e.g. in notification text, where space is limited, clearly say that the path is invalid
* when shown in auth dialog, show warning and print detailed info about the client
* when shown in the client list, draw a warning icon
Co-authored-by: Jonathan White <support@dmapps.us>
* Support NFC readers for hardware tokens using PC/SC
This requires a new library dependency: PCSC.
The PCSC library provides methods to access smartcards. On Linux, the third-party pcsc-lite package is used. On Windows, the native Windows API (Winscard.dll) is used. On Mac OSX, the native OSX API (framework-PCSC) is used.
* Split hardware key access into multiple classes to handle different methods of communicating with the keys.
* Since the Yubikey can now be a wireless token as well, the verb "plug in" was replaced with a more
generic "interface with". This shall indicate that the user has to present their token to the reader, or plug it in via USB.
* Add PC/SC interface for YubiKey challenge-response
This new interface uses the PC/SC protocol and API
instead of the USB protocol via ykpers. Many YubiKeys expose their functionality as a CCID device, which can be interfaced with using PC/SC. This is especially useful for NFC-only or NFC-capable Yubikeys, when they are used together with a PC/SC compliant NFC reader device.
Although many (not all) Yubikeys expose their CCID functionality over their own USB connection as well, the HMAC-SHA1 functionality is often locked in this mode, as it requires eg. a touch on the gold button. When accessing the CCID functionality wirelessly via NFC (like this code can do using a reader), then the user interaction is to present the key to the reader.
This implementation has been tested on Linux using pcsc-lite, Windows using the native Winscard.dll library, and Mac OSX using the native PCSC-framework library.
* Remove PC/SC ATR whitelist, instead scan for AIDs
Before, a whitelist of ATR codes (answer to reset, hardware-specific)
was used to scan for compatible (Yubi)Keys.
Now, every connected smartcard is scanned for AIDs (applet identifier),
which are known to implement the HMAC-SHA1 protocol.
This enables the support of currently unknown or unreleased hardware.
Co-authored-by: Jonathan White <support@dmapps.us>
