On 2014/10/14 13:48, Ross Altman wrote:
Hi Martin,
Thank you, I'll definitely look into that. It's unfortunate that there
isn't a simpler way to do this... oh well.
Let me bud in here since I encounter this question a lot in other matters. There typically are three reasons one would like to
protect the data in a file from end-users' meddling:
- You need to protect idiot users against themselves,
- You need the data to remain clean and untarnished to make some other system
depending on it function correctly, or
- The data itself is important for legal reasons or you have some kind of
liability towards data accuracy.
If it is the first case, then you are stuffed and Richard's byte-change is the
closest to a solution you can come.
If the second case, then make the other system check the file, add table with encrypted values that has meaning only to the other
system, or even use file encryption for the entire database - this is common and can be had commercially from
http://www.hwaci.com/sw/sqlite/see.html
For the latter I suggest recording the file hash (sha512+) whenever you update it and store that in a data list marking release
dates. That way if someone claims that they have data gotten from you that says x while you claim it says y... then simply whip out
the hash list and compare to their file, any changes will be evident immediately.
You probably need to then also keep a register history of DBs that correspond to those hashes, else you cannot prove the data from
that file to correspond to any specific hash. Also it is safer to upload such hashes to a blog or something that is not under your
control, where any edits will be marked and timestamped, then it is impossible for yourself to meddle with the files after release
and a public record exists of the file version hashes. Pretty solid in legal terms.
Whichever way, good luck!
Ryan
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
