Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Vsftpd backdoor discovered in source code (The H)
Posted Jul 5, 2011 7:48 UTC (Tue) by danieldk (guest, #27876)
Posted Jul 5, 2011 8:06 UTC (Tue) by hpro (subscriber, #74751)
Shouldn't one download the source from more than one "reliable" sources and make sure they match (each other, and the checksum)?
Posted Jul 5, 2011 8:10 UTC (Tue) by farnz (guest, #17727)
That's why you want digitally signed signatures (GPG can create such things). If the maintainer is dealing with the same upstream for a while, the change of signing key is a major event, and worth cross-checking by other routes (e-mail, IRC). Even better - if upstream can get involved in the PGP Web of Trust, a change of key to an attacker's key that aims to look like upstream's key will change from a key you trust to an untrusted key, giving you a chance to intervene.
Posted Jul 5, 2011 8:23 UTC (Tue) by hpro (subscriber, #74751)
But then again, in the end you might just be downloading a program that is malicious to begin with, and no checksums can help you with that. (E.g., Android Market)
Posted Jul 5, 2011 9:37 UTC (Tue) by tialaramex (subscriber, #21167)
This seems like it's worth building into package building automation. "Download new source" should be "Download, verify as authentic and refuse to continue if not" for every package that provides detached signatures. This would require explicit intervention if the author (or rather signer) changes, but that is a significant event of which the maintainer certainly should be aware.
Posted Jul 5, 2011 13:04 UTC (Tue) by drag (subscriber, #31333)
You don't want one server compromise allow the attacker to not only upload his own package, but sign it also.
Putting the signature in URL would force them to break links
Posted Jul 5, 2011 11:48 UTC (Tue) by gmatht (guest, #58961)
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.
Posted Jul 6, 2011 20:19 UTC (Wed) by zooko (subscriber, #2589)
Posted Jul 6, 2011 21:06 UTC (Wed) by Tov (guest, #61080)
I would rather sacrifice a bit longer filenames for robustness and human readability (when comparing hashes).
Posted Jul 6, 2011 21:41 UTC (Wed) by zooko (subscriber, #2589)
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.:
rationale for zbase32 versus RFC 4648:
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds