Hi guys! Got two questions concerning v 2.20.1:
When I open a lot (≈70) of entries one by one by double-clicking on it's name (or pressing "Enter") and then close "Edit Entry" window, KeePass's memory consumption grows dramatically. When launched it consumes something about 22 MB according to the Task Manager (Windows 7 Ultimate x64), and after I do what is described above — 100 MB and even more. Right now it is 55MB, after I've open for editing ≈ 20 entries. Maybe it is a security measure, something dealing with in-memory protection?
The changelog for v 2.20.1 says:
Improved behavior when the user deletes the system temporary directory.
On Unix-like systems, KeePass now stores most of its temporary files in a private temporary directory (preferably in $XDG_RUNTIME_DIR).
I would like to ask what are KeePass's temporary files? I was sure it never uses system temporary directories. Is it safe?
And one more question. KeePass Data Viewer has an option to show content of the attached file in "Web Browser" mode. It seems to use Internet Explorer engine (it's just my guess). If so, is there a possibility of the confidential information leak through browser's cache?
Thanks for your reply Paul!
Anything concerning two other questions? Unfortunately I'm not a programmer at all, so reading source code is equivalent reading Confucius in the original in my case:)
2) KeePass 2.x uses the temporary directory during the following operations:
- Importing and exporting to the old KDB file format of KeePass 1.x.
- Compiling of PLGX plugins.
- Output of the --get-urloverride command line option.
- Global mutex and IPC broadcast files on Unix-like systems (on Windows systems all of these are in-memory).
In all of these cases, the data is either encrypted or not confidential. Even if someone would read your temporary files, no security issue arises. Furthermore, KeePass deletes most temporary files as soon as possible.
3) The 'Web Browser' view in the internal data viewer on Windows indeed uses the Internet Explorer engine to render the document. The document is in-memory and is not cached.
Thanks a lot, Dominic!
On 1.: I've now optimized the code to free some image lists immediately, which reduces the memory consumption.
Here's the latest development snapshot for testing:
Thanks and best regards