Seems ironic their cert doesnt match and I get a browser warning. What happened to Debian? Is Security something they have only heard about in folklore terms?
What about it? That's the URL for the Debian mailing list and not where packages are downloaded from.
In fact, you download packages from Debian mirrors and most of these are over HTTP and not HTTPS. How do you know you're not downloading a compromised APT? Checksums you say? Don't forget you downloaded the package footprints via HTTP too!
The MITM for APT is the elephant in the room here.
No, the nightmare is still there. Most Debian mirrors only serve HTTP and you most likely installed Debian from an ISO that you downloaded over HTTP. And when you did an md5 of the downloaded ISO you probably compared it to a fingerprint hosted on a website served via HTTP (at the same time forgetting that md5sum could have been compromised itself since you downloaded it via HTTP). Then when using APT to install packages, they too are being installed via HTTP.
Packages are signed using GPG keys from the package maintainers. The private keys are in an ideal world never even near the machine that serves the package to you.
I often recompile packages from testing or unstable on stable, to get newer versions, or because I need to patch something. This is usually more productive than installing from upstream source. (Exceptions are packages with a big tree of dependencies, where chances are high that something won't build.)
More often than not, I'm checking the source package signautures (gpg) myself, though, because in the past doing it automatically wouldn't work or so. I wonder whether those signatures are concerned in this bug. I've tried to get at the source repo, but no luck (stable has a bzr repo that redirects to a 404, another url nearby does not contain recent changes; sid is in Git, but doesn't appear to have changes related to the bug). In the end I diffed the source of the apt package against its former version, I've put the diff here:
I haven't studied it enough to get the answer (yet).
Edit: it seems this really concerns repository signatures only, not package signatures; assuming that you're verifying that the package signature (the one in the *.dsc file) is correct and the hash sums match the package files, the only possible attack will be to refuse access to the correct/latest version of the package.
Edit 2: but as the bug report points out, the .dsc signature check can't be relied on automatically (even if the check fails, apt returns success, you have to read the stdout/stderr instead).
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749795
So the only way to have been safe was to check every apt-source'd package individually, with manual eyeing or running of gpg.
And, this bit (from the bug report) may be most worrysome: "(..) all debian build systems which probably rely on secure APT." (i.e. the binary packages may have been built automatically based on source that was fetched without protection).
16 comments
[ 3.2 ms ] story [ 44.1 ms ] threadI don't think debian is any less secure than other OSs.
In fact, you download packages from Debian mirrors and most of these are over HTTP and not HTTPS. How do you know you're not downloading a compromised APT? Checksums you say? Don't forget you downloaded the package footprints via HTTP too!
The MITM for APT is the elephant in the room here.
(Usually when I want the source it's because I'm compiling a package from source, and I get the tarball from the project's website)
It's also more likely to work out of the box without having to hunt for build dependencies.
This is mostly useful when you care about contributing bugfixes to the distro patches, or you can't get the upstream source to build easily.
More often than not, I'm checking the source package signautures (gpg) myself, though, because in the past doing it automatically wouldn't work or so. I wonder whether those signatures are concerned in this bug. I've tried to get at the source repo, but no luck (stable has a bzr repo that redirects to a 404, another url nearby does not contain recent changes; sid is in Git, but doesn't appear to have changes related to the bug). In the end I diffed the source of the apt package against its former version, I've put the diff here:
http://christianjaeger.ch/scratch/apt-0.9.7.9+deb7u1_apt-0.9...
I haven't studied it enough to get the answer (yet).
Edit: it seems this really concerns repository signatures only, not package signatures; assuming that you're verifying that the package signature (the one in the *.dsc file) is correct and the hash sums match the package files, the only possible attack will be to refuse access to the correct/latest version of the package.
Edit 2: but as the bug report points out, the .dsc signature check can't be relied on automatically (even if the check fails, apt returns success, you have to read the stdout/stderr instead). https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749795
So the only way to have been safe was to check every apt-source'd package individually, with manual eyeing or running of gpg.
And, this bit (from the bug report) may be most worrysome: "(..) all debian build systems which probably rely on secure APT." (i.e. the binary packages may have been built automatically based on source that was fetched without protection).