Repository navigation
Provide easy way to export and import attachments #10475
Description
Overview
Attachment are empty files after import from XML file
Steps to Reproduce
Using the CLI
- Create a keepass (cli db-create)
- Add an entry with an attachment (cli add)
- Export the keepass as an xml file (cli export)
- Create a second keepass by importing the previous xml (cli import)
Expected Behavior
In the new keepass, I expect that the attachment has data
Actual Behavior
The attachment has a size of zero bytes in the new keepass
Context
I would like to add autotype with the cli
As it seems to be not implemented, I export the database as XML, I modify the XML and then I import the XML
Even if I don't modify the xml by hand, the attachments are empty after the import
Version
KeePassXC - Version 2.7.7
Revision: 68e2dd8
Qt 5.12.8
Debugging mode is disabled.
Operating system: Ubuntu 20.04.6 LTS
CPU architecture: x86_64
Kernel: linux 5.15.0-101-generic
Enabled extensions:
- Auto-Type
- Browser Integration
- Passkeys
- SSH Agent
- KeeShare
- YubiKey
- Secret Service Integration
Cryptographic libraries: - Botan 2.12.1
Operating System: Linux
Desktop Env: Gnome
Windowing System: X11/Wayland
Activity
droidmonkey commentedon Mar 19, 2024
Attachments are not exported to xml, they are "outside" the xml. You will have to save attachments manually and re add them.
[-]2.7.6 or 2.7.7 Empty attachment after import from XML[/-][+]Provide easy way to export and import attachments[/+]guenther-brunthaler commentedon Jul 22, 2024
This is not generally true.
I have found out that it depends on the Keepass Database Format.
Unless certain features of KeePassXC are used which are only supported by the newer 4.0 format, KeepassXC allows to select the storage Format of the kdbx file, defaulting to KDBX 4 but still supporting the older KDBX 3.1 format.
I was able to export the full contents of my KeePassXC database, including attachments such as SSH keys and OTP secrets, to an XML file after converting the database to 3.1 format first.
When I then re-imported the XML file into a new kdbx database, all previous information (i.e. also the attachments) was still present and complete (i.e. not just empty files).
I wanted to export the database to XML for various reasons.
Firstly, I wanted to put the XML files under version control.
Secondly, I wanted to remove KeePassXC's internal version history before committing the XML files, because version control inside version control is inefficient (resulting in huge deltas by the external version control software).
Finally, removing the trashcan and the internal version history can significantly reduce the size of the XML file. It also gives smaller *.kdbx files after re-importing the XML files into new ones.
Such removal is easy be filtering the XML file, but hard to do manually in the KeePassXC GUI because there is no way to globally purge all version history and "trashcan" items (which I also wanted to exclude from the external version control using git).
This approach works unless KXBX 4.0 specific features are used within the KDBX file.
Remember that only exporting the 3.1 format to XML retains all features such as attachments.
In addition, the XML format must be chosen for the export, and the keepassxc-cli tool must be used to perform the import/export.
droidmonkey commentedon Jul 22, 2024
Just disable history for the database in database settings, press ok. All history will be gone.
Empty recycle bin to remove "trash" items.
For awareness, kdbx 4 standard moved the attachments outside the XML which is why they are not exported to kdbx 4 compliant xml.
guenther-brunthaler commentedon Jul 23, 2024
This was in fact invaluable advice! Thank you.
I did not get the connection between the trashcan, the history, the max. history entries setting, and the enabled-status of the latter setting.
My mistake was that I thought disabling the "max. history entries" setting would also disable the history, while it actually did the exact opposite.
Now I do the following to minimize the size of a database snapshot before archiving it externally:
Fortunately, I do not need the XML file any longer due to the above procedure.
I only used it to minimize the database snapshots for archiving.
On a more general level, however, an export format which is unable to preserve all the data is of questionable benefit.
In fact, I did lose several SSH keys in the past before I realized the attachment were present but empty files after re-importing, because I assumed the export to be lossless.
It was easy enough to deploy new SSH keys in my case, so it was only a minor annoyance.
Of course it was my mistake, I should have read the manual more carefully. But who does nowadays.
mvasin commentedon Sep 29, 2026
@droidmonkey, thanks for the direction on draft PR #13725 following the design question. I understand that KDBX 4's attachment separation should remain unchanged and that a lossless export should be a ZIP containing the database XML and attachment files.
Before I revise the implementation, is there an existing ZIP layout or attachment naming convention that the export should follow, or should the PR propose one?
droidmonkey commentedon Sep 29, 2026
Are you an AI?
mvasin commentedon Sep 29, 2026
Not entirely :) AI-assisted. This message is by me personally.
mvasin commentedon Sep 29, 2026
(another human message 😉) I keep a KeePassXC database in Git and need to compare revisions to understand changes, i.e. when resolving merge conflicts. My comparison tool uses XML exports, but KDBX4 exports omit attachment contents. That prevents a complete comparison, including detecting changes to attachments stored in entry history.
droidmonkey commentedon Sep 29, 2026
Might i recommend a more direct approach using
keepassxc-cli merge old.kdbx new.kdbx -s --dry-runmvasin commentedon Sep 30, 2026
It does detect an ordinary attachment change, so it helps with inspecting changes without exporting. The remaining gap is comparing exact snapshots. If
new.kdbxhas a history record removed but the current entry is unchanged, the suggested command reports no change. That makes sense for a merge, which retains the old history, but my comparison needs to detect that removal. > I’ll handle that stricter comparison in my own tool.