Keepassxc: Keeshare: imported database is missing entries

[jeyca]

I import a second kdbx file using keeshare:

I created a new folder, put in a name, chose keeshare, chose type: import, chose the path to the kdbx (I had to switch to show all files) and put in the password. It seems to work, but some entries are just missing. I opened the file as a new database and it works, it is the same file that is imported and is opened as new database, but some files in the imported folder are just missing.

I tried to find out what is the difference between the entries that are shown and the missing ones, but could not find any yet.

Operating system: Xubuntu 18.04
Keepassxc: 2.5.2

Enabled extensions:

• no extensions enabled

[droidmonkey]

Are these databases related in any way? Do they share the same exact Entry

[jeyca]

no not related, in what way they could be related except the keeshare?

Do they share the same exact Entry

what exactly do you mean?

[droidmonkey]

KeeShare works at the entry level, if two entries in different databases have the same UUID then they will merge with each other no matter what folder they are in.

[jeyca]

ok. But when I search for the title of a missing entry, I cannot find anything in the first database. But it might be possible that I "copied" these entries some time before. That means, because I was not able to copy entries from one database to another, I copied the file, opened it as new database and then deleted all entries except one folder. But I also deleted all entries from that folder in the original database (you could say that I did a cut and paste operation). There is also nothing left in the rescycle bin of these old entries.

[jeyca]

ok I could solve it by cloning the missing entry in the second database, then it shows up. But because I have to this with a lot of entries, I wonder if there is a better solution for all entries at once of that second database? I thought about export/import, but then it looks like I would lose all the autotype settings..

[jeyca]

There's really something fishy about the keeshare function, I don't recommend using that, it keeps deleting arbitrary entries in my primary database. I am lucky that I had good secondary backups, because it also removed the passwords of my encrypted backup hard disks...

I don't think this is connected to the old "cut and paste operation" when I copied the file and deleted everything except one folder. I created completely new database files which I synced with a folder in my primary database.

What happens: I have synced a secondary database file using keeshare type sync. Then, all entries from folder "harddisks" (and others, which are completely unrelated to the synced folder) are removed. If I merge in a backup file of my primary database, I can see how the entries come back, then the green export/import banner shows up (I guess thats the sync operation) and the entries are removed again.

The same happens when I choose "import" instead of "sync" type, but then only after closing and reopening the primary database file.

[jeyca]

opposed to what was said in #4198 I found that the keeshare feature is documented here:

https://github.com/keepassxreboot/keepassxc/blob/develop/docs/QUICKSTART.md#using-sharing

and it is also stated that even the entries outside of a shared group are affected.

Please note, that the import currently is not restricted to the configured group. Every entry which was imported and moved outside the import group will be updated regardless of it's location!

That is unfortunate, but it might explain why it is even possible that entries get lost. But it still does not explain why these specific unrelated entries are removed. Is it possible to look up any kind of logging to see what actually happens here?

[droidmonkey]

If you can setup a simple example we can replicate while debugging. I have found KeeShare to do some surprising operations as well.

[ckieschnick]

@jeyca Are you using a "normal" database as import container for KeeShare? If you cloned your database before - and started to remove single entries, those entries are entered into a deleted entries list. This list - especially when using a real database as container - will be used by KeeShare to delete obsolete entries from the target database. For the intended setup, this list contains only entries which originated from the source database and contains only entries which the user of the source database doesn't want to share anymore. When you are using a standard database - especially a clone, this means that KeeShare will try to replicate all "newer" changes from the source database - aka your real source - into the target database.

That's why we didn't recommend to use real database for import/synchronization.

Another important point is - if you are using a real database as sharing container in sync it may get replaced when you are changing the target database since sync means to copy changes back - it doesn't sync those two databases. This is a separate feature which has nothing to do with KeeShare!

[mstarke]

I think we should consider making it non-obvious that keeshare uses a standard database as exchange container. Maybe by just adding a different file extension or something similarly simple. Even more so, we should add a special marker in the database that allows keeshare to show a prominent warning that there is something unexpected going to happen if that marke is missing.

[droidmonkey]

I am not against that, KeeShare should always use its own generated container. It was my mistake to assume how KeeShare worked before knowing so and allowing the kdbx unsigned version. We could universally use the .share extension and just detect if it is a zip file or not. There are options here, perhaps on another issue ticket for discussion.

[mstarke]

Maybe we can just come up with a PR that switches to using .share with autodetection on the format and include the marker as well as the warning signs.

[droidmonkey]

We would also want to prompt a user to "upgrade" their .kdbx share container to .share on load.