Recent Features
| |||||||||||||
Putting the signature in URL would force them to break linksPutting the signature in URL would force them to break linksPosted Jul 5, 2011 11:48 UTC (Tue) by gmatht (guest, #58961)In reply to: Vsftpd backdoor discovered in source code (The H) by hpro Parent article: Vsftpd backdoor discovered in source code (The H)
I was thinking if you put the signature in the url it would create much lulz if people looked for the package by following an external link. :) It would be quite easy to create a file type .sha256chk, and associated utility that when given a file called X.Y.sha256chk renames it X if the file matches the sha256sum Y. This notation would also help when you are trying to chase down a broken link like http:.../README; a websearch would find thousands of unrelated README's but hopefully only one "README.0983e91e1f8a061385f41464e141c94892f0f3ccc8e0d5a5167f1841c0f123c4.sha256chk".
A variant could also be to let Y be a tinyurl like reference to a public key, and the whole filename stored in a public mirrored database linking filenames to signed sha256keys, so even the author cannot re-release a file with the same name.
(Log in to post comments)
Putting the signature in URL would force them to break links Posted Jul 6, 2011 20:19 UTC (Wed) by zooko (subscriber, #2589) [Link]
Hey that's a good idea. A base-62 encoding could make the results more compact, e.g. your example would then look like:
README.2FtSwvET66qZj2xqQjlAi6VFYW4ZQfCRhFgc3fwMglg.sha256chk
instead of:
README.0983e91e1f8a061385f41464e141c94892f0f3ccc8e0d5a5167f1841c0f123c4.sha256chk
Putting the signature in URL would force them to break links Posted Jul 6, 2011 21:06 UTC (Wed) by Tov (guest, #61080) [Link]
Wouldn't base62 encoding create problems in case-insensitive environments (e.g. when stored on a FAT filesystem)?
I would rather sacrifice a bit longer filenames for robustness and human readability (when comparing hashes).
Putting the signature in URL would force them to break links Posted Jul 6, 2011 21:41 UTC (Wed) by zooko (subscriber, #2589) [Link]
Yeah, you're partially right about case-insensitive filesystems like VFAT or NTFS. Actually nothing would go terribly wrong on such a filesystem except that the chance of collisions would be less astronomically unlikely. However, it still smells a bit icky to have only astronomical collision-resistance instead of super-duper-astronomical collision-resistance, depending on your local filesystem.
Also you're right that base-62 is harder to read aloud than other encoding (because you have to say "uppercase" and/or "lowercase" a lot). An alternative that addresses these two issues is base-32, e.g.:
http://pypi.python.org/pypi/zbase32/
rationale for zbase32 versus RFC 4648:
http://tahoe-lafs.org/trac/zbase32/browser/trunk/zbase32/...
On the other hand the more compact result of base-62 makes it a little easier to cut and paste, which is probably more common than reading aloud nowadays.
Here are the examples again.
base-16 (hex):
base-32 (zbase32):
base-62 (zbase62):
|
|||||||||||||