Repository navigation
Conversation
|
I have updated the description to account for KDBX 4 deliberately storing attachments outside XML. Would you accept an explicit lossless standalone export mode? If so, which representation would you prefer: The current patch changes the default. Its evidence only covers a round trip with the current KeePassXC development version; I am not claiming interoperability with other versions or implementations. I can adapt the implementation once the intended interface and representation are clear. |
|
Export attachments into a zip file that also includes the xml of the database. The point of exporting is not to reimport to another kdbx database, it's meant to move to another manager entirely. The current implementation of this PR is not going to be accepted at all. Do not muck with the XML writer/reader. |
|
Closing this PR. I’ll address the database-comparison requirement in my own tool, without changing KeePassXC’s XML export. |
Related to #10475.
KDBX 4 intentionally stores attachment binaries outside the XML, in the inner header. The current standalone XML export therefore writes attachment references without the corresponding binary pool. Importing that XML into current KeePassXC creates zero-byte attachments and reports unmapped keys.
This draft explores treating CLI XML output as a standalone, lossless export. When
KdbxWriter::extractDatabase()writes XML, it builds and writes an inline<Meta><Binaries>pool for every database version. Ordinary encrypted KDBX 4 saves continue to pass an explicit binary index map and keep attachment data in the inner header.The patch changes the default XML export behavior. The regression test proves a round trip with the current KeePassXC development version and covers a regular attachment, an empty attachment, entry history, and an attachment in a KeeShare group. It does not claim that this extended output is a KDBX 4-compliant XML representation or that KeePass, older KeePassXC versions, or other implementations can import it.
Before taking the implementation further, I would like maintainer direction on whether a lossless standalone export belongs in the XML command and, if so, whether it should be explicit rather than the default. An
--include-attachmentsmode could use the inline binary pool demonstrated here; a sidecar or archive format could preserve the KDBX 4 separation instead.Tests:
testcli testExportKdbx4Attachmentstestkdbx3testkdbx4This submission was predominantly generated using OpenAI Codex with GPT-6 Astra.