What security systems and processes are in place to prevent malicious third parties from hacking/compromising the security of code in the Debian mirrors, or to verify that the packages we get are in fact the ones the maintainers think they are?
The contents of the mirrors are signed using PGP keys, directly or indirectly. Starting at the "root" of a Debian distribution:
Release, signed with a detached signature in
Release.gpg, contains the hashes (MD5, SHA1, SHA256) of all the package indices and installer hashes (
InReleasenow combines the two);
- the package indices (e.g.,
binary-amd64) contain the hashes (MD5 and SHA256) of the packages.
The hashes and signatures are checked by tools such as
apt-get using PGP keys stored on the system (managed by
apt-key). So as long as the receiving system is sound, by default no package can be installed from the Debian archives if it hasn't been signed (indirectly) by the archive PGP key. Any intruders on the mirrors wouldn't be able to replace binaries if they didn't also have control of the relevant PGP key.
Controlling the mirrors
This means that compromising the archive isn't sufficient to actually compromise end-user systems; you'd also need to compromise a PGP key which those systems already trust. (A corollary of this is that adding a key to a Debian system isn't something to be taken lightly.) That addresses your first question to some extent, since the security of the archive doesn't matter quite so much. Nevertheless, the critical systems (where signing happens) are strictly monitored and supervised, and very few people have access to them.
Ensuring that the packages are "in fact the ones the maintainers think they are" is a little more involved. This is the path taken by a package:
- the package is prepared by a maintainer, and signed with a key in the Debian keyring (i.e. a key belonging to an uploading Debian Developer, or a Debian Maintainer, uploaded to the Debian keyring server and merged by the keyring maintenance team);
- the signed package is uploaded to the archive, where it is verified (amongst other things, the keys used must be in the current keyring and must not have expired, the signatures must be valid, and if the package was signed by a DM, that DM must have the relevant permissions for the package);
- any uploaded binaries are pushed to the final archive as-is (I'm simplifying a little here, but that's the effect);
- any missing binaries are built by a buildd and signed by the buildd's PGP key, and pushed to the final archive (which knows what buildd keys are valid, and verifies files against those);
- all these updates are eventually pushed out to the mirror network, with the appropriate index updates (which are signed as described above).
If the maintainer uploads binaries along with the package source, these are the files which end up being served (for the time being). Since uploading binaries is now optional, it's more and more common to skip them, and eventually uploaded binaries will be dropped. (This has always been the case in Ubuntu.) Whether the other binaries match the maintainer's expectations depends on the buildd network; so buildds are also critical systems, under close supervision and with little human access. Since all the artifacts are signed, it is always possible to verify the integrity of the files: first against the maintainer's key, then against the buildds' keys, and finally against the archive's key.
As pointed out by plugwash, the original signatures aren't available on the mirrors, and any DD can upload a missing binary. Original signatures can be retrieved from the debian-devel-changes archives.
In summary, while the current system isn't perfect, it does provide traceability for all the files you can download from the mirrors. There are a number of efforts to improve the situation: reproducible builds (which will allow independent verification of binaries' correspondence to the published source), dropping maintainer-provided binaries...