Closed tisp00n closed 1 year ago
Any idea what is going on?
Yes, my first thought is that the synchronization simply went wrong. It is possible that the save file stream is interrupted during a transfer, the probability of this happening during a synchronization is higher simply because the database is bigger. And since it's up to the synchronization application to handle this problem, it can't be solved from KeePassDX.
Pretty bad for a tool where you are supposed to keep your access data safe.
I don't think Google drive had this goal in mind when they created their application. ;) If you think the problem is with KeePassDX, try to reproduce the problem with a database that exclusively uses the phone's default DocumentsUI application with a local file.
Bypass solution under study: https://github.com/Kunzisoft/FileSync
Edit : more explanation in the wiki page https://github.com/Kunzisoft/KeePassDX/wiki/File-Manager-and-Sync
Please fill in the bug template correctly in order to have as much information as possible to understand where the problem comes from
Any idea what is going on?
Yes, my first thought is that the synchronization simply went wrong. It is possible that the save file stream is interrupted during a transfer, the probability of this happening during a synchronization is higher simply because the database is bigger. And since it's up to the synchronization application to handle this problem, it can't be solved from KeePassDX.
Hi, thanks for your feedback. In case of a file stream corruption on Google Drive layer, wouldn't this have broken the entire kdbx file making it unreadable? In all the cases this issue occurred, only the attachments were broken, never the remaining data.
Pretty bad for a tool where you are supposed to keep your access data safe.
I don't think Google drive had this goal in mind when they created their application. ;) If you think the problem is with KeePassDX, try to reproduce the problem with a database that exclusively uses the phone's default DocumentsUI application with a local file.
I have tried downloading the kdbx file on the phone (in local storage, not the Google Drive cache) and made some changes, but the attachments remained in place and in shape. I have not made tons of tests though...
I have attached the kdbx file and left one corrupted entry: ConnectionData.zip Password is "password". Maybe this can help to understand what happened?
Bypass solution under study: https://github.com/Kunzisoft/FileSync
Edit : more explanation in the wiki page https://github.com/Kunzisoft/KeePassDX/wiki/File-Manager-and-Sync
Please fill in the bug template correctly in order to have as much information as possible to understand where the problem comes from
Hi, thanks for your feedback. In case of a file stream corruption on Google Drive layer, wouldn't this have broken the entire kdbx file making it unreadable? In all the cases this issue occurred, only the attachments were broken, never the remaining data.
Good suggestion. For me it is possible that header file data is corrupted during a transfer, so only affects encrypted blobs (here data related to attachments). But I'm not sure of anything at all without having reproduced the problem.
I have attached the kdbx file and left one corrupted entry: ConnectionData.zip Password is "password". Maybe this can help to understand what happened?
Maybe, I will study the format of the data in this database.
I also experience this issue using Nextcloud as a sync provider. And just like @tisp00n says, only attachments are broken, all other data (passwords, notes, even KPRPC JSON) are fine. Also, my whole database is 942 KB so I would exclude a sync issue
There seems to be a correlation between the database and/or an item size and this bug occurring. I'm currently trying to reproduce the error but I cannot do that consistently:
Using my Nextcloud setup
Everything works well in this scenario
But if the entry contain a KPRPC header (used in Kee), it doesn't:
{"version":1,"formFieldList":[{"name":"","displayName":"KeePass password","value":"{PASSWORD}","type":"FFTpassword","id":"mydkt-defaut-Password","page":-1,"placeholderHandling":"Default"},{"name":"searchedText","displayName":"searchedText","value":"","type":"FFTtext","id":"menuSearchInput","page":-1,"placeholderHandling":"Default"},{"name":"","displayName":"KeePass username","value":"{USERNAME}","type":"FFTusername","id":"mydkt-defaut-Email","page":-1,"placeholderHandling":"Default"},{"name":"","displayName":"","value":"KEEFOX_CHECKED_FLAG_TRUE","type":"FFTcheckbox","id":"gwt-uid-1","page":-1,"placeholderHandling":"Default"}],"alwaysAutoFill":false,"neverAutoFill":false,"alwaysAutoSubmit":false,"neverAutoSubmit":false,"priority":0,"altURLs":["example.com"],"hide":false,"blockedURLs":[],"regExBlockedURLs":[],"regExURLs":[],"blockHostnameOnlyMatch":false,"blockDomainOnlyMatch":false}
And using the above provided database and adding a KPRPC JSON field, it just works 🤔
Also, you asked for the issue template to be filled so here is it:
Describe the bug
Every attachments are "broken" after saving an edited KeePass database using KeePassDX
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Save all attachments without modifications, so they can be opened later.
KeePass Database
content://
URI): content://org.nextcloud.documents/...
KeePassDX:
Android:
Additional context
Add any other context about the problem here.
Thank you @Chouffy for your detailed feedback, it is much appreciated and will allow to go much faster in the analysis of this issue. My first guess now: Maybe there is a conflict with the protected data in memory in the XML formatting.
Sorry guys but I still can't reproduce the problem. I create the file well with KeePass (2.51.1), add an image, then send the file to KeePassDX (3.4.5), modify the entry and save but I have no error. I am able to reopen the image after opening the database again.
Can you try to reproduce the problem on your side by doing a manual file transfer from PC to Android to see if the problem is still reproducible?
Kee requires registration and endless reading of Terms of Service so I haven't tested it.
I've tried to reproduce the issue from a new database. Here's my test log, but unfortunately I wasn't able to reproduce it either... At the moment I implemented a "workaround": all previous attachments are now files somewhere else, and the KeePass database doesn't contains them anymore. So it'll be difficult for me to check if this bug reoccurs or not in the near future.
--- Test log below ---
KeePass 2.51.1 on Windows x64 KeePassDX 3.4.5 on Android Files that I've generated:
On PC:
On Android:
On PC:
On Android:
... still working as expected 😕🤔
Thanks for the feedback. I have improved the save routine in version 3.5.0, so if the problem was in an error in formatting attachments during save it will be implicitly solved in the next version.
I can't reproduce the problem, so I leave the issue open. You will tell me if it happens again in version 3.5.0, if I have no feedback on this version I will consider the issue solved.
Hi, I have been using KeepassDX for many years and, for the 2nd time, I realize that most of my attachments (text files, PNG with QR codes ...) are unreadable. I'm also using Keepass(.info) on my Windows PC and the KDBX is stored in my Google Drive account to be synced accross my devices: Android & Windows. Pretty bad for a tool where you are supposed to keep your access data safe. I mostly add entries on my Windows PC, but also sometimes on KeepassDX. Any idea what is going on? Thanks