karagog
Segmentation fault when dragging entry unto it's parent
I see Gryptonite isn't really maintained at the moment, but just in case anyone picks up maintenance, I guess it doesn't hurt to report a bug.
I noticed Gryptonite crashes when I try to drag an entry onto it's parent, but only when it is at the moment the last child of the parent. If there are other children below it, dragging onto the parent will move it to the end of the list. But if it is already at the end of the list (e.g. when it's the only child), dropping it will cause a crash to desktop with the following error (if run from command line):
/usr/local/bin/gryptonite: line 3: 7578 Segmentation fault /usr/local/lib/gryptonite/gryptonite $@
By the way, I encountered it when trying to merge two versions of my database - I usually keep my key databases synchronized between my desktop and laptop, but for some reason they got out of sync and I had to do a manual merge... is there a smarter/more-secure way to do it than using the export-to-xml + diff?
Thanks for the detailed bug report. It's been a couple years since I've looked at the code, but based on your description I'm fairly certain I know the nature of the bug. As you noted, Gryptonite is not currently being maintained, so it's not likely to be fixed any time soon. However, it sounds like it's not a critical bug, as it should seldom affect users (dropping an item onto its own parent seems like a niche use-case). As a workaround, if you wanted to move the item to the end of the list, instead of dropping on the same parent, does it still work to drop it at the end of the list?
On another note, I'm glad to hear your user story about how you're using the XML export feature to keep databases in sync. Originally I intended that feature to (in theory) support interop with other password managers (e.g. to give people an easy way to get their data in/out of Gryptonite without requiring the other password managers to implement/integrate with Gryptonite's encryption layer). It sounds like you found another use for it, which further convinces me that the effort was worth it :)
Personally, I store my database on a network drive, so it's always in sync between multiple devices. You could use Google Drive for this, unless you're paranoid about storing the database in the cloud (in which case perhaps your only real option is to maintain your own Network File Server, and possibly a VPN server to access it safely from remote locations - this is what I used to do, until migrating to Google Drive). Gryptonite protects the database from update collisions by only allowing one process to write the data at a given time (subsequent processes will get read-only access), so that is considered a supported use case.
For whoever eventually investigates this bug more thoroughly, here are my initial thoughts on the cause of this bug:
The way drag and drop is implemented by the internal data structures, it is treated as a remove-and-add operation. If you're dropping on the same parent, normally the destination row is adjusted after the removal of the item to be moved (i.e. the # of children of the parent has decreased by one after removal, so the destination row needs to be adjusted to compensate for this). When you drop on the parent, the destination row is actually -1, due to Qt's implementation of the TreeView. My guess is that somehow this is causing a segfault by indexing the child array out of bounds (e.g. either one past the end of the array, or a negative index of the array).
Without spending time to actually look at the code, this is the best I can come up with off the top of my head, but it seems like the most plausible explanation. Your mileage may vary ;)
There's no need for a workaround, since the crash only happens when the item is already at the bottom of the list.
As for syncing, I actually used Dropbox to keep my databases synchronized. They got out of sync probably either because sometimes I have no internet connection (although it's unlikely I'd need passwords then), or because dropbox daemon sometimes fails to start properly - which seems more likely to be the reason here. In any case I ended up with two versions of the database that diverged slightly. (i.e. I only used the export to XML + diff this one time, it's the first time I had this happen)
Although as of now, I'm switching from Dropbox to Syncthing, to have better control over my data.
As for the collision protection, I often get the message that the database is locked when I open it... which seems to be caused by Dropbox syncing the lock file, then when I close the computer it seems if dropbox closes before gryptonite, then the lockfile stays in the cloud even after the computer is closed, causing all other devices to have the lockfile synchronized even after the computer that created the lockfile is closed. Which obviously makes me just tell Gryptonite to ignore the lockfile when I open the database on another computer ;)