Brion Vibber wrote:
Tim Starling wrote:
Brion Vibber wrote:
Looks like Tim forgot to update the GPG signature files when he re-issued the release; we'll make sure they get re-done. The file checksums match, so we're good for now. :)
It takes about 10 minutes to upload all the files for a release. I didn't want to wait that long, so I generated them on zwinger instead, where I don't have a GPG key.
Maybe we could just serve the uploads via HTTPS and quit this mucking around with hashes and GPG. Hardly anyone checks them anyway.
Hashes and keys are nice for confirming that: a) the file wasn't corrupted in download or on a mirror b) the file didn't get corrupted on the master download server c) the file didn't get surreptitiously replaced by an attacker
HTTPS helps with none of these.
HTTPS has cryptographic block hashes, so the file would be protected against corruption during download.
Additionally, we could host hashes on the HTTPS server instead of sending them out by email. That way we could update the tarball without sending out a new release announcement, and reduce the amount of technical clutter in the email.
Since uploading the files to storage2 requires root access, I think the scenario of foul play on the server side falls into the "screwed anyway" category. An attacker could just wait for someone to log in with key forwarding enabled, and then edit the source files in SVN. As for inadvertent corruption during upload, it's done by ssh so there's a cryptographic block hash during transport, and there's the gzip checksum as well.
All of this misses the most common source of file corruption, which is the FTP upload from a user's computer to their shared hosting account, post-unpack. We often get reports on IRC of files missing or truncated. We had one just today (RingtailedFox). I'd like to have a file integrity check in the installer.
-- Tim Starling