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