Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
184.108.40.206 DB bug report code keeps original FileLookup Path intact (privacy regression) #3790
The DB bug report has long scrubbed sensitive information such as source pathnames. Various forum posts and documentation describe this. 220.127.116.11 canary code for the new path storage scheme (maybe inadvertently) leaves the FileLookup table intact including its Path. This could not be seen until 18.104.22.168 canary fixed "Create bug report ..." results in syntax error #3725. I'm not sure which tables are most helpful. The new code creates one it calls FixedFile, and drops others. Should it drop or fix FileLookup?
Steps to reproduce
Feature/fix path storage2 #3468 might be the pull request. There are some side issues we could get into, such as the future of DB bug reports. People haven't been very willing to post them (although some have), and this makes it hard to dig into field failures for the problems that developers can't reproduce themselves. Regarding deletion, a VACUUM would be more thorough, otherwise deleted information remains. Tools can dig data out.
Rather than open a different issue on VACUUM (which is probably an issue dating back to the earliest code):
Re: [sqlite] Parsing sqlitedb file. describes the problem, and the SQLite leader's advice, which is linked below:
PRAGMA schema.secure_delete; which says VACUUM should work too. That fits the bug report usage better.
Although web search can find many tools that claim to recover deleted data, the sqlite mailing list discussion (and other resources) claim a proper recovery is iffy. From a privacy point of view though, the scrubbing that Duplicati does leaves things like pathnames behind, easily seen by looking into the file, e.g. with a hex editor.
22.214.171.124 does expand the privacy leak to be obvious with the tools one normally uses, e.g. an SQLite browser.