FileList overwritten by old one

[weiszg]

Entities stored by CSC are usually indexed by their content hashes. However file lists (stored per user) are indexed by public keys. Their authenticity is protected by a signature. During stabilisation, different versions of these file lists have to be identified as they will have the same index (public key doesn't change). Currently a file list is determined to be newer if the peer advertising it advertises a different fileHash from what we have. This means that if an old peer comes back alive, it can overwrite the new file lists with its old ones. At least this is a race condition.

[weiszg]

Proposed solution: include version number with the file list. We would actually have two version numbers, one attached to the end of the filelist upload call and the other one embedded in the filelist data, signed by the public key. This is because peers not in the possession of the public key will still have to be able to determine which one of two filelists is the newer one. Malicious peers may report wrong numbers, even replay old messages with higher numbers, however when this filelist is read by someone else (assuming it is not the malicious peer that is responsible for storing the filelist), the reported version number will mismatch with the one embedded in the replayed data hence the operation will fail. This is consistent with our goal of allowing malicious peers to corrupt the data as long as we always can tell if the data is not authentic.

[weiszg]

solution implemented in commit c467877