Built in viewer/editor for popular attachment formats

[CodeCracker-oss]

Adding support for a built in viewer/editor for file attachment types like jpg, png, txt would be nice to avoid the decryption and storage of attachments in tmp directory as I am not sure if its even securely deleted or just regulary deleted which may be a security concern, if this was implemented in a way similar to KeePass, that would be nice.

I find myself very often reviewing documents in my database like drivers license, credit card ... but having KeePassXC store in /tmp and open it with photo viewer most likely is insecure for a lot of people, eg. my default photo viewer creates cached data of images (like thumbnails) into a different directory in .cache, sometimes even in .config for some reason which is just another trace of that sensitive data on my computer. I do have my hard drive encrypted via luks but even then, if my computer is on its in a decrypted state, if I use my database on a friend/family members computer, it may have traces of my personal data left over depending on his/her os, used software... (I do not however, open it on public/untrusted computers, even with this feature as i consider them very insecure for this purpose).

It could be implemented where its viewing/editing within memory instead of extraction/decryption to disk, I myself mainly focus on just viewing, i rarely fined myself editing attachments within KeePass(XC) but it would maybe be useful for others though.

[0xpr03]

Just as a side note, when you have multiple documents to store it may be worth looking into https://github.com/veracrypt/VeraCrypt

[michaelk83]

(based on discussion in #6300)

Since the feature set for this can quickly spiral out of control, it would be best to place this in a separate repository within the KPXC ecosystem, similar to the browser extension, so that it wouldn't pollute the main KPXC code. But it doesn't need to be fancy to be useful.

For text attachments, the MVP is:

• A large, resizable text area (separate window from KPXC).
• Launch from an open entry in KPXC, so it doesn't need its own entry browser and so forth (Attachments → Open button).
• Save to the same attachment in the existing entry.
• Most importantly, the same memory- and other applicable protections as KPXC itself. Ideally, the data should be securely transferred in memory, without creating any temporary files.

A text search would also be useful (#4864), but goes beyond the MVP. Anything fancier can primarily come from PRs (or defer to an external editor, so the user choice is between security guarantees vs advanced edit features).

For images, the MVP is a non-editable preview panel.

[droidmonkey]

We won't be implementing this. If you have simple text files, just use the entry notes. Attachments were overhauled in 2.7.0 to allow for file watching and automatic change detection and storage.

[LoganDark]

If you have simple text files, just use the entry notes

I want to store records of PGP-encrypted messages I've sent to others, since I can't decrypt those in the future, but adding each one as an attachment sounds way more attractive than pasting them all into the notes section.

After a while—hundreds or even thousands of records—it'll take forever for me to find any of them because I have to store all the contents in a single contiguous note. to find anything maybe I would even have to paste it into an external application to use Ctrl+F...

The problem is adding an attachment requires creating an actual text file on my computer for KeePassXC to "open". But this should never be an actual text file on my computer. I should be able to at least create and edit plaintext attachments without having to use the real filesystem since I don't want this stuff to touch my disk.

Even a button to create an attachment from the current clipboard contents, would allow me to just type something up and add it as an attachment without using a real file. Or paste directly from my terminal's scrollback buffer which is where I type my messages (in gpg interactive mode).

Plaintext messages like this seem like a great use case for the attachments feature, since you obviously sent those messages using a particular service, they are individual communications which would warrant being separated into their own separate attachments, and it doesn't make sense to have to create real files just to import them.

I'm afraid to create a new issue for this because there are so many issues about attachments and I really don't have the attention span to sort through 7 pages of search results for "attachment file" so if this argument holds any merit whatsoever I would trust you to know what to do with it better than me.

thank you for everything you've done by the way <3

[LoganDark]

@droidmonkey could you elaborate on the reasons for not offering a built-in text editor for creating/modifying attachments without having to create real files on the real filesystem?

the notes feature only offers a single textarea, which makes it difficult to organize the data that I've put in it. for example if I want to store SSH private keys or PGP encrypted messages I would want to store them as separate attachments, not just concatenate them all together into a single note. in a single note, it becomes a chore to locate the data I want later because I have to scroll past all the data I don't want.

the flow of "here's an easily-skimmable list of filenames -> here's the contents of that attachment" is something that notes can't emulate. unless you did something ridiculous and overhauled notes to turn it into ... the attachments system that you already have.

sure, I could download third-party software (of unknown quality) to create a ramdisk, then use an external text editor to create a file, then have keepassxc load that file into an attachment.

but why do attachments have to be real files in the first place though. why can't I manage attachments at all without round-tripping through real files. why can't I view or edit the contents of an attachment securely, without involving real files and other programs on my computer.

attachments shouldn't only be for storing real files that have really existed. I should be able to use attachments to attach any data I want, including things that I don't want to be (or have never been) real files on my filesystem. things in my clipboard for example, like a message encrypted using GPG in interactive mode (where files never existed). importing and exporting to files should be for convenience but shouldn't be the only way.

[0xpr03]

I want to store records of PGP-encrypted messages I've sent to others

I would strongly recommend using veracrypt. That way you can use the editor of your choice, with the encoding and features of your choice while having all files stored securely and cross OS compatible. Which also allows you to index, search or otherwise use them with your normal programs. - I am not the person you asked, but this should already give you an insight into the bottomless pit this "simple editor" feature can create.

That said I do support the idea of create file attachements from content in the clipboard.

[KeinR]

Even if we have built-in editors, you still have to trust the architecture of your OS to not be writing stuff to swap, as well as the robustness of the KeePassXC developer team to not have a single data leak in the entire behemoth of a featureset that built in editors would result in (with all due respect, however people have their limitations). Furthermore, you have to trust QT and their massively bloated codebase (and the same with every other widget toolkit out there).

It sounds what is really being asked for is forensic immunity, and for that just boot up an air gaped VM with disk encryption (or should I say, with networking disabled). Perhaps Whonix without the gateway? This way you have access to any tool you could dream of, without risking your important data; it's probably even more secure, since it wouldn't have network access. Security updates wouldn't happen, but without network access, how will you get malware, except from the host?

[LoganDark]

I would strongly recommend using veracrypt.

I already use veracrypt. I don't want to store them as files. The keepass database is easy to sync and access across computers and the veracrypt volume is not. Because the veracrypt volume is 25gb and my keepass database is less than a megabyte.

you still have to trust the architecture of your OS to not be writing stuff to swap

I don't care about this. I'm not asking for total security.

It sounds what is really being asked for is forensic immunity

No, I'm asking for convenience without having to juggle real files on my filesystem.

[CodeCracker-oss]

@KeinR Personally, I have swap disabled as I have plenty of RAM and no need for swap. Even if I needed it, I would encrypt it.

Software and its developers will always have its flaws, thats just how its always been. This could even be as an extension to the software, similar to how official keepass software works with extensions.

Not asking for forensic security. Official keepass already includes this feature as well as sensitive data encrypted in RAM, which keepassxc don't offer.

Making it more conveinient and secure should be looked at as a good thing, not a bad thing.

[LoganDark]

Making it more conveinient and secure should be looked at as a good thing, not a bad thing.

Yeah, it's not like the entire database isn't stored in RAM while it's open anyway. If stuff being in swap was an issue, it's always been an issue.

[droidmonkey]

There is a big difference between a viewer and an editor. We could support viewing attachments (text, image) within keepassxc. Editing plain text is not a big deal as long as we keep it same as notes, no frills.

[FlorinAndrei]

On macOS 14.6.1, one thing that helped was to explicitly configure the file type to be always opened with my favorite text editor (Sublime Text), which is something I should have done anyway. After that, the Open button in KeePassXC works for that file type. For reference, these are files with the .local extension.

Would be nice to have some kind of less manual solution in KeePassXC.