Similar to KeePass2 most elements are checked for a
Protected="True"
attribute. Previously, files KDBX 3.1 files with protected Binary
entries, as seen in the wild, could not be read (mangled passwords and
file attachments).
Building with -flto caught the fact that we were ignoring the return
value of readMagicNumbers(), which potentially left the value of 'sig2'
uninitialized.
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
Introduce missing CustomData-attributes of KDBX4 format to allow
storing of plugin data for groups and entries - adopt Metadata to use
the same storage mechanism
Add simple view for CustomData as part of EditWidgetProperties
Tracking of CustomData-Modification using SIGNAL-SLOT update-mechanism
Write duplicate attachments to the binary inner header only once and
skip duplicate entries when reading a KDBX4 file.
This fixes a an attachment mapping problem when an attachment appears
more than once in a database (which occurs frequently when editing attachment
entries and history is turned on)
* Adds KDBX4 reader/writer interfaces
* Adds KDBX4 XML reader/write interfaces
* Implements test cases for KDBX4
* Fully compatible with KeePass2
* Corrects minor issues with Argon2 KDF
Note: This implementation is not yet connected to the
database itself and will corrupt existing kdbx3 db's.
* Implemented memory and parallelism parameters for Argon2Kdf
* Using libargon2; libsodium does not support Argon2d algorithm
* Moved basic rounds parameter into Kdf class
* Reimplemented benchmark algorithm; previous was utterly broken
* Add SHA512 support to CryptoHash
* Add ChaCha20 support
* Add HMAC support
* Add new HmacBlockStream, used in KDBX 4
* Add support for ChaCha20 protected stream
Fixed 2 memory leaks in production code and a few in testcases. As a
result leak_check_at_exit ASAN option does not need to turned off for
non-gui tests.
Smart pointers should be used elsewhere for consistency, but the sooner
this fixes are delivered, the lesser memory leaks are introduced.
The rule for ellipsis is simple:
If the described action requires interruption (typically by a dialog)
which requires user input, then ellipsis should be used to indicate
that triggering the menu will not immediately trigger the desired action.
Examples:
"Save" does not need an ellipsis in general (when the file name is known)
"Open..." needs an ellipsis, as one must select a file to open.
"Save as..." needs an ellipsis, as in order to save the file as something,
one must select a file name.
"About" does not need an ellipsis, while it may open a dialog, that dialog
is the desired result.
