Implemented in trunk, r7991:

 curl -s http://192.168.0.115/extended/3.1.1rc2/OOo_3.1.1rc2_20090820_Win32Intel_langpack_sw-TZ.exe.sha256  
b8ac00bedff1e85fae9b3ca1af8ed616d1d177010156a97d1275d8b6035959d6  OOo_3.1.1rc2_20090820_Win32Intel_langpack_sw-TZ.exe

 curl -s http://192.168.0.115/extended/3.1.1rc2/OOo_3.1.1rc2_20090820_Win32Intel_langpack_sw-TZ.exe.sha1
0e1aefc1df0ba4c147fb36d3c62d000441e6b945  OOo_3.1.1rc2_20090820_Win32Intel_langpack_sw-TZ.exe

 curl -s http://192.168.0.115/extended/3.1.1rc2/OOo_3.1.1rc2_20090820_Win32Intel_langpack_sw-TZ.exe.md5   
c7feb5365c2e9ce205ba212c6fa19aa0  OOo_3.1.1rc2_20090820_Win32Intel_langpack_sw-TZ.exe

Serving the hashes by appending the corresponding file suffix, like .md5, could 
shadow existing .md5 files; likewise for sha1 files. But I think it would still be 
worthwhile and it wouldn't matter at all.

MirrorBrain could become a "hash server": Whenever a suffix like ".md5" or 
"sha256" is appended to an URL, MirrorBrain could return the corresponding hash. 
Would be really cool.

Easy to implement, once issue 40 is done.