Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
AirDropping database can cause database corruption #1113
Given one setting choice, an AirDrop (a macOS feature), and a "no" choice, it's possible to corrupt a database.
Users should be free to AirDrop their database with any combinations of settings and not corrupt their database.
Given a setting choice and a prompt choice, AirDropping a database can result in a corruption.
Make the prompt described in step 5 below ("The database file has changed. Do you want to load the changes?") be more of a warning? I guess the AirDropping "modifies" the locked file somehow, so this could be a problem with AirDrop/macOS, but maybe there's some way of having AirDropping a database not modify it somehow?
Steps to Reproduce (for bugs)
Note: I have not been able to see if I can reproduce this bug by AirDropping a database file from one laptop to another laptop, but if I had to guess it would also happen in that case?
Screenshot of Settings Used While Reproducing
A user wishing to remain anonymous told me about this bug. (I successfully reproduced it following the steps listed above, with the settings and debug info listed here.) User was simply attempting to send his database to his or her iPhone without using a cloud service.
I can see a possible objection that unchecking the setting in step 1 and choosing "no" at step 6 is the "wrong" choice, but given how unexpected the dialogue prompt is (an AirDrop transfer doesn't feel like a file modification), and the (likely) catastrophic results of a corrupted database, I'd say this is a pretty gnarly bug. I'd hope that it would be harder (if not impossible) to corrupt a database using KeePassXC-- is that realistic?
KeePassXC - Version 2.2.2
Operating system: OS X Yosemite (10.10)
To be sure I follow correctly: the database is closed, but transferring it to an iPhone changes it? That shouldn't happen and first of all sounds like a bug in AirDrop. There is no reason why that should cause a file modification.
Can you please test what happens if you
Glad to see we've maybe caught one bug!
I was busy today but I got to try a few of the procedures @phoerious requested above.
Let's call my original procedure of steps described in my opening of this issue as "Procedure A"
Procedure B: Procedure A, but have the automatic reload setting on (checked)
Procedure C. Procedure B, but choose yes in step 6
Procedure D. Procedure A, but restart KeePassXC immediately following step 6
Procedure E. Procedure A, but don't lock the database in step 3. In other words: leave the DB open (unlocked) while AirDropping it .
These remaining three procedures I didn't have time to check tonight, but I'm assuming similar results to Procedure E.
Throughout my tests I was always able to open the test databases on my iPhone using MiniKeePass. However I admit I didn't test this after completing each procedure.
This is pretty bad. I was able to reproduce just with
I doesn't have to happen at the same time (autoreload and autosave). The save can happen after the reload and the problem will still occur. Also, both options can be disabled and there's still gonna be a way for a user to corrupt it's database. the problem is twofold
I think this is where the corruption comes from. We overwrite the database with an empty database that was created as a placeholder when locking