- # It is easy to see that this protocol is prone to race conditions because the remote file can be modified
- # between read operations which might result in the client obtaining a damaged file. To combat this,
- # application designers are recommended to adhere to the following convention. Let every file whose integrity
- # is of interest have a hash or a digital signature, which is stored in an adjacent file under the same name
- # suffixed with the appropriate extension according to the type of hash or digital signature used.
- # For example, let there be file "image.bin", integrity of which shall be ensured by the client upon downloading.
- # Suppose that the file is hashed using SHA-256, so the appropriate file extension for the hash would be
- # ".sha256". Following this convention, the hash of "image.bin" would be stored in "image.bin.sha256".
- # After downloading the file, the client would read the hash (being small, the hash can be read in a single
- # request) and check it against a locally computed value. Some servers may opt to generate such hash files
- # automatically as necessary; for example, if such file is requested but it does not exist, the server would
- # compute the necessary signature or hash (the type of hash/signature can be deduced from the requested file
- # extension) and return it as if the file existed. Obviously, this would be impractical for very large files;
- # in that case, hash/signature should be pre-computed and stored in a real file. If this approach is followed,
- # implementers are advised to use only SHA-256 for hashing, in order to reduce the number of fielded
- # incompatible implementations.
