On 10/29/15, Warren Young <[email protected]> wrote: > > Oh, I see what you mean. You’re making the same point Ron W did: If you > replace the file blob data in the tip of a branch, you don’t get a timeline > entry for that change. > > I assume the Fossil sync algorithm won’t allow a remote Fossil to replace an > existing artifact.
Correct > If so, that attack only works if you have control of the > server hosting a Fossil repo that others sync from. > > This would bypass the problem of not being able to spoof those who already > have an existing clone of the repo, since the evil file hashes to the same > value as the one they already have. > > But by the same token, I don’t see how to get those with existing copies of > that file to download the new one. The sync protocol should skip the > “unchanged” file, since the client already has an artifact with that ID. Correct. The first instance of a hash to get into the system suppresses all others. -- D. Richard Hipp [email protected] _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
