Keepassxc: Store/Read additional attributes as JSON when exporting/importing to CSV

Created on 8 Aug 2017  ·  9Comments  ·  Source: keepassxreboot/keepassxc

When testing keypass features I added an additional entry on a key entry under the advanced tab. When exporting to csv to test this functionality the additional entry was nowhere to be found.

Expected Behavior

I would expect additional entries to be present on the csv file.

Current Behavior

Additional entries for saved keys are not exported.

Possible Solution

Note: I am not sure what is the intended function here from a developers standpoint.

If additional entries are intended to be exported then they 'd need to be implemented on a later release.

If it is not intended for those entries to be exported it would be good if it is documented somewhere. From a new user's perspective it would be even better if a dialogue box opened (after clicking export to csv) saying which parts of the database are not exported (with an option to never show again).

Steps to Reproduce (for bugs)

I am including two screen-shots of adding a new key and the resulting csv text below

db1-1b

db1-2b

When exporting the data to a scv I get the following result:

"Group","Title","Username","Password","URL","Notes"
"Root","key1","key1","key1","",""

Note: I have clicked ok to save the new additional entries before attempting to export.

Context

I am testing keepassxc features to make sure any information I add to the database can be exported to a printable format (for non-digital backup purposes).

Debug Info

```{bash}
$ snap info keepassxc
name: keepassxc
summary: "community driven port of the windows application “Keepass Password Safe”"
publisher: keepassxreboot
contact: https://github.com/keepassxreboot/keepassxc
description: |
KeePassXC is an application for people with extremly high demands on secure
personal data management. It has a light interface, is cross platform and
published under the terms of the GNU General Public License.

commands:

  • keepassxc
    tracking: stable
    installed: 2.2.0 (23) 79MB -
    refreshed: 2017-06-25 23:25:35 +0100 BST
    channels:
    stable: 2.2.0 (23) 79MB -
    candidate: ↑
    beta: ↑
    edge: 2.1.3 (21) 73MB -
    $ lsb_release -a
    No LSB modules are available.
    Distributor ID: Ubuntu
    Description: Ubuntu 16.04.3 LTS
    Release: 16.04
    Codename: xenial
    $ uname -a
    Linux shade 4.10.0-30-generic #34~16.04.1-Ubuntu SMP Wed Aug 2 02:13:56 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
    ```

Enabled extensions:

  • None, just using the default snap settings.
CSV new feature

Most helpful comment

Because TOTP codes are stored under additional attributes, the lack of their export in CSV (and the lack of a more structured export, such as XML), causes a bit of a lock-in problem. I cannot move to another service easily as I will have to go through _each_ entry and double check their attributes. This is an issue.

All 9 comments

We call those additional attributes. Either way, exporting N number of attributes into CSV is problematic. You wouldn't want to add another row since each row represents an entry. You also cannot just add another column since CSV is pretty strict on columns. Lets say 1 entry has 100 attributes, then every exported row will have 90 commas with only one row having that data filled in.

To shorten this up, the intention of CSV export is not to replicate the database in a CSV file, its to export the primary fields for transport to another service. Your request would be better served in an XML export (for example).

Because TOTP codes are stored under additional attributes, the lack of their export in CSV (and the lack of a more structured export, such as XML), causes a bit of a lock-in problem. I cannot move to another service easily as I will have to go through _each_ entry and double check their attributes. This is an issue.

I've personally had to implement CSVs with n additional fields per record, even additional nested rows, and it's a horrible mess that many CSV readers will parse incorrectly.

CSV is a great format for exporting simple data structures, in an efficient way, but the need for something more versatile (like XML for example) is apparent. Currently the only _real_ way to get a complete export of a database is to open it in keepass and export to XML from there, something which is less than ideal, but does work very well as a temporary solution, as KeePassXC doesn't have an XML export. For now?

It would be useful to export plugin specific attributes (totp, http, etc) and would limit the scope (ie, columns). @andschwa if you think this would be a good feature please open a new issue. Creating an XML export feature would be rather trivial to do as well since the db is an encrypted xml export.

Note: cli interface can already export XML.

I think it's not complete, though. For KDBX4 it needs to inline attachments, which it isn't doing AFAIK.

Thanks @RealOrangeOne for the suggestion to use KeePass (the original) for exporting. Funnily, doing so showed another problem with exporting additional attributes. While KeePass exported to XML just fine, the other software failed to import it because some of my fields were too huge (1000+ character limit apparently on import).

This is a sorely missed feature. I agree that having a CSV with an arbitrarily large number of columns is problematic. However, I don't think you need to add as many columns as there are attributes. Instead, how about just having one column perhaps called "additional_attributes" and store a serialized form of the attributes as maybe JSON? Then when importing you can simply read the entire column and deserialize it.

That's not a bad idea

Was this page helpful?
0 / 5 - 0 ratings