3 ms·

>Packages can be manually downloaded from packages.debian.org and they reference the same insecure mirrors. That's a reasonable complaint. I think it would mak

by simias 8y ago

>Packages can be manually downloaded from packages.debian.org and they reference the same insecure mirrors. That's a reasonable complaint. I think it would make sense for the individual packages to be signed as well (and checked during install). This way you'd get a warning if you install an untrusted package regardless of the source. I'm not sure why it doesn't work that way. >Furthermore Debian also provides ISO downloads over the same HTTP mirrors, which are also not automatically checked. While they can theoretically be checked with PGP signatures it is wishful thinking to assume everyone will do that. I do do that. If you care about such an attack vector why wouldn't you? And if you don't, why should Debian care for you? There are plenty of mirrors for Debian installers, I often get the mine from bittorent, trusting a PGP sig makes much more sense than relying on HTTPS for that IMO. >Finally the chapter about CAs and TLS is - sorry - baseless fearmongering. I don't think it's baseless (we have a long list of shady CAs and I'm sure may government agencies can easily generate forged certificates) but it's rather off-topic. Their main argument is that the trust model of HTTPs doesn't make sense for APT, if that's true then whether or not HTTPS is potentially hackable is irrelevant.

oefrha 8y ago
> And if you don't, why should Debian care for you? Those who don’t go out of their way to defend themselves don’t deserve security — seriously, that’s your attitude? Then you don’t deserve to be in any position to make security decisions for other people.
- 0xdeadbeefbabe 8y ago
  Security isn't on or off. If you think it is then "you don't deserve [...]" It seems like reasonable trade off.
driverdan 8y ago
> If you care about such an attack vector why wouldn't you? And if you don't, why should Debian care for you? Security should be as automatic as possible. It should be assumed that any step that requires manual intervention will be skipped by most people.
- antris 8y ago
  >It should be assumed that any step that requires manual intervention will be skipped by most people. Indeed. 1. If you don't care about security, it still doesn't hurt to have HTTPS. Think of it as "extra" that you get for free. 2. If you care about security, you might still don't have the know-how to make sure everything is secure and don't have time to get into it as you're trying to get things done. 3. Even if you care about security AND have the know-how, you might still forget. Nobody's perfect. So it's good that the HTTPS is there.
  - wolco 8y ago
    Nothing is for free, https has additional costs over http. In many cases it makes sense to pay those costs but let's not forget about them.
- simias 8y ago
  But the point the page makes is that HTTPS wouldn't be good enough anyway. As such it's not a replacement for checking the PGP signature. I think it's consistent. If HTTPS could be used to replace PGP signature checks then I'd agree with you but it's not the case. So I go back to my initial point, if you worry about your image being tampered with HTTPS is not enough. If you don't care then you don't care either way. In a way not using HTTP is kind of an implicit disclaimer on Debian's part. "Don't trust what you get from this website". If they feel like they can't guarantee the security of whatever server is hosting the CD images adding HTTPS might actually be a bad thing because people who might otherwise have checked the signature may think "well, it's over HTTPS, it's good enough".
- bigiain 8y ago
  To be fair to the apt developers/maintainers - the security _is_ automatic when using their tool to talk to their repos. It's not their responsibility to automate security for people using their repos via different tools. If the solution was just "install certbot on the server and use a free https cert" then perhaps you could make an argument saying maybe they should just do it. But when the problem space includes aggressively using a global (largely volunteer) mirror network and supporting local caching proxies, I can completely understand why they'd say "Nope. Not our problem, not our responsibility to provide a solution. We've got other more productive ways to spend our and our mirror volunteers time and effort".
Conan_Kudo 8y ago
> I think it would make sense for the individual packages to be signed as well (and checked during install). This way you'd get a warning if you install an untrusted package regardless of the source. I'm not sure why it doesn't work that way. Actually, debs are not signed in Debian or Ubuntu. The accepted practice in Debian is that only repository metadata is signed. The argument is that the design of Debian packages (as in, the package format) makes it difficult to reproducibly validate a deb, add a signature, strip the signature, and validate it again. Personally, I'm not sure I buy it, as we don't have problems signing both RPMs and RPM repository metadata. Technically, yes, the RPM file format is structured differently to make this easier ('rpm' is a type of 'cpio' archive), but Debian packages are fundamentally 'ar' archives with tarballs inside, and those aren't hard to do similar things. For reproducible builds, Koji (Fedora's build system) and OBS (Open Build Service, openSUSE's build system) are able to strip and add signatures in a binary-predictable way for RPMs. Fedora goes the extra step of shipping checksums via metalink for the metadata files before they are fetched to ensure they weren't tampered before processing. But even with all that, RPMs _are_ signed so that they can be independently verified with purely the usage of 'rpm(8)'.

by simias 8y ago

oefrha 8y ago

> And if you don't, why should Debian care for you? Those who don’t go out of their way to defend themselves don’t deserve security — seriously, that’s your attitude? Then you don’t deserve to be in any position to make security decisions for other people.

0xdeadbeefbabe 8y ago
Security isn't on or off. If you think it is then "you don't deserve [...]" It seems like reasonable trade off.

driverdan 8y ago

> If you care about such an attack vector why wouldn't you? And if you don't, why should Debian care for you? Security should be as automatic as possible. It should be assumed that any step that requires manual intervention will be skipped by most people.

antris 8y ago
>It should be assumed that any step that requires manual intervention will be skipped by most people. Indeed. 1. If you don't care about security, it still doesn't hurt to have HTTPS. Think of it as "extra" that you get for free. 2. If you care about security, you might still don't have the know-how to make sure everything is secure and don't have time to get into it as you're trying to get things done. 3. Even if you care about security AND have the know-how, you might still forget. Nobody's perfect. So it's good that the HTTPS is there.
- wolco 8y ago
  Nothing is for free, https has additional costs over http. In many cases it makes sense to pay those costs but let's not forget about them.
simias 8y ago
But the point the page makes is that HTTPS wouldn't be good enough anyway. As such it's not a replacement for checking the PGP signature. I think it's consistent. If HTTPS could be used to replace PGP signature checks then I'd agree with you but it's not the case. So I go back to my initial point, if you worry about your image being tampered with HTTPS is not enough. If you don't care then you don't care either way. In a way not using HTTP is kind of an implicit disclaimer on Debian's part. "Don't trust what you get from this website". If they feel like they can't guarantee the security of whatever server is hosting the CD images adding HTTPS might actually be a bad thing because people who might otherwise have checked the signature may think "well, it's over HTTPS, it's good enough".
bigiain 8y ago
To be fair to the apt developers/maintainers - the security _is_ automatic when using their tool to talk to their repos. It's not their responsibility to automate security for people using their repos via different tools. If the solution was just "install certbot on the server and use a free https cert" then perhaps you could make an argument saying maybe they should just do it. But when the problem space includes aggressively using a global (largely volunteer) mirror network and supporting local caching proxies, I can completely understand why they'd say "Nope. Not our problem, not our responsibility to provide a solution. We've got other more productive ways to spend our and our mirror volunteers time and effort".

Conan_Kudo 8y ago

> I think it would make sense for the individual packages to be signed as well (and checked during install). This way you'd get a warning if you install an untrusted package regardless of the source. I'm not sure why it doesn't work that way. Actually, debs are not signed in Debian or Ubuntu. The accepted practice in Debian is that only repository metadata is signed. The argument is that the design of Debian packages (as in, the package format) makes it difficult to reproducibly validate a deb, add a signature, strip the signature, and validate it again. Personally, I'm not sure I buy it, as we don't have problems signing both RPMs and RPM repository metadata. Technically, yes, the RPM file format is structured differently to make this easier ('rpm' is a type of 'cpio' archive), but Debian packages are fundamentally 'ar' archives with tarballs inside, and those aren't hard to do similar things. For reproducible builds, Koji (Fedora's build system) and OBS (Open Build Service, openSUSE's build system) are able to strip and add signatures in a binary-predictable way for RPMs. Fedora goes the extra step of shipping checksums via metalink for the metadata files before they are fetched to ensure they weren't tampered before processing. But even with all that, RPMs _are_ signed so that they can be independently verified with purely the usage of 'rpm(8)'.