11 ms·

I guess I can copy over a comment I made when this previously made rounds: I have a few problems with this. The short summary of these claims is “APT checks si

by hannob 8y ago

I guess I can copy over a comment I made when this previously made rounds: I have a few problems with this. The short summary of these claims is “APT checks signatures, therefore downloads for APT don’t need to be HTTPS”. The whole argument relies on the idea that APT is the only client that will ever download content from these hosts. This is however not true. Packages can be manually downloaded from packages.debian.org and they reference the same insecure mirrors. At the very least Debian should make sure that there are a few HTTPS mirrors that they use for the direct download links. 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. Finally the chapter about CAs and TLS is - sorry - baseless fearmongering. Yeah, there are problems with CAs, but deducing from that that “HTTPS provides little-to-no protection against a targeted attack on your distribution’s mirror network” is, to put it mildly, nonsense. Compromising a CA is not trivial and due to CT it’s almost certain that such an attempt will be uncovered later. The CA ecosystem has improved a lot in recent years, please update your views accordingly.

xcaaa 8y ago
How is it not trivial if rogue organizations like "Staat der Nederlanden" have default certificates in the browser? Hint: The Netherlands is world leader in surveillance of its own citizens and inhabitants.
- vegardx 8y ago
  Because they would be caught doing it very quickly. There are so many ways to detect this.
  - shittyadmin 8y ago
    And ultimately none of those ways to detect this aren't useful against a sufficiently targeted attack with direct access to the signing key. It's one thing if you sign a bad key for Google.com, publish it in CT logs and then put it up on the public internet - it's quite another if you sign a bad key for midsizecompany.com, keep it out of the CT system and use it only in a targeted attack against non-technical individuals who are unlikely to examine a certificate or use things like Certificate Watch. With that said, I still believe serving it over HTTPS would be a substantial improvement. Perhaps pin the cert or at least the CA out of the box to prevent such attacks.
    - Boulth 8y ago
      CT monitors are primarily for site operators not end users. When site operators spot a rouge cert issuance they can clarify that and ultimately get the cert revoked.
      - shittyadmin 8y ago
        Precisely my point - it's not something an end user would notice. And if it doesn't even appear in CT logs or for the end user it would likely go completely unnoticed. There really aren't "so many ways to detect this" - there's about 3: the user examines the certificate, CT logs catch it later and detection in browsers of major changes on the most high profile sites. Anything falling outside of those will almost certainly go unnoticed.
        tialaramex 8y ago
        When you (a CA, but also just anybody who finds a new one) log a new certificate or a "pre-certificate" (which is essentially a signed document equivalent to the final certificate but not usable as a certificate) the log gives you a receipt, a Signed Certificate Timestamp, saying it commits to publish a consistent log containing this certificate within a period of time (today 24 hours). The SCT proves that this particular log saw a signed document with these specific contents, at this specific moment. Chrome (for a long while now), Safari (announced for early 2019) and Firefox (announced but a bit vague on when) check SCTs for publicly trusted certificates. The browser can look at the SCT and verify that: * It was signed by a log this browser trusts * It matches the contents of the leaf certificate (DNS names, dates, keys, etcetera: Distinguished Encoding means there is only one correct way to write any certificate so there can't be any ambiguity) * It has an acceptable timestamp (not too old, in some cases not too new) It can also contemplate the set of SCTs and decide if they meet further criteria e.g. Google requires at least one Google log and at least one non-Google log. If any of these is wrong, the site doesn't work and an appropriate error message occurs, no user effort is needed or useful here. We know this works because Google managed to do it to themselves by accident once already, blocking Chrome access to a new Google site for - I think it was several hours - because their dedicated in-house certificate group screwed up and didn't log a new certificate. There is more to do to defend the system completely: 1. You could compel a log operator to emit an SCT, but then not actually log your certificate. Certificate Transparency can detect this, a browser would need to remember SCTs it has seen and periodically ask a log for a proof which allows it to verify that the log really has included this certificate. 2. You could go further and compel the log to bifurcate, showing some clients a history with your certificate in, and others a parallel history without that certificate. This can only be detected using what is called "gossip" in which observers of the log have a way to discuss their knowledge of the log state and find out systematically if there are inconsistencies. Once both these things are in place, there's basically no way around just admitting what do you did. Which of course doesn't mean any negative consequences for you, but it does make _deniability_ (much desired by outfits like the NSA and Mossad) hard to achieve if that's something you care about.
- kstrauser 8y ago
  TLS instead of GPG signatures might be a bad idea, but adding TLS to the transport of signed packages can't make the pipeline less secure.
  - admax88q 8y ago
    Unless it misleads people in to thinking they don't have to check signatures because they fetched it over HTTPS which is "secure"
    - bigiain 8y ago
      Also, as the article posts out - it's not exactly trivial to deploy https across their global mirror network or to make it work with local caching proxies. That's an easy thing if you've got a handful of servers or a few load balancers, but not so easy or practical for their use case. (Also, remember most of the apt development had already happened way before free ssl certs became a thing. While saying "Why don't then just use certbot/LetEncrypt is an easy criticism, give them credit for having actually build a GPG sig secured distributed software delivery system years before LetEncrypt existed...)
hacknat 8y ago
Also, their claim that HTTPS doesn’t hide the hosts that you are visiting is about to not be true. Encrypted SNI is now part of the TLS 1.3 RFC, so HTTPS will actually hide one’s internet browsing habits quite well. The only holes in privacy left on the web’s stack are in DNS.
- zamadatix 8y ago
  I bet DoHTTPS/DoTLS has more penetration than ESNI. Neither are widely implemented though, which is the important part.
  - da_chicken 8y ago
    Yeah, but not being implemented now doesn't mean that they never will be. Migrating/implementing now will mean that the mirrors will automatically support it once the features are in place and the clients and servers can agree on the improved privacy feature sets.
- ec109685 8y ago
  For sni to be effective, you need to be hitting hosts that serve more than one domain. Otherwise, you can just reverse map the ip.
  - y4mi 8y ago
    Most of my severs don't report the actual service dns back on a reverse lookup. It's generally nodeXX.some.fqdn or clusterXX or lbXX
    - jedberg 8y ago
      Yes but if I want to specifically look for traffic to the Debian mirrors, I can use DNS to build a list of the IPs and then see if you're connecting to one of them.
    - shittyadmin 8y ago
      Doesn't really matter either way - there's a bunch of crawlers and scanners out there such that you can pretty much Google any IP and find a list of sites that are hosted on it.
jdamato 8y ago
Thanks for commenting this! I've seen this website before and it's really unfortunate how much attention it gets. APT's use of plain text HTTP (even with GPG) is vulnerable to several attacks outlined in this paper: https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.pdf https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.p.... Yes, this paper is old, but APT is still vulnerable to most of these attacks. I would advise anyone wanting to use APT to do so only with TLS.
- loeg 8y ago
  The criticisms in that paper either do not apply to Apt as described in TFA or amount to DoS attacks. HTTPS does not and can not solve DoS.
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.
emilfihlman 8y ago
>Compromising a CA is not trivial and due to CT it’s almost certain that such an attempt will be uncovered later. The CA ecosystem has improved a lot in recent years, please update your views accordingly. This is simply not true. Governments can simply compel your CA to do as they want. Not to mention that "uncovered later" is pretty damn worthless. That said, I do agree that there should be HTTPS mirrors.
- electrum 8y ago
  > Not to mention that "uncovered later" is pretty damn worthless. It is not worthless as a deterrent to the CA. Proof of a fraudulently issued certificate are grounds to permanently distrust the CA. So, yes, they can do it, but hopefully only once.
NicoJuicy 8y ago
Here is why Videolan (VLC) doesn't do it: https://www.beauzee.fr/2017/07/04/videolan-and-https/ https://www.beauzee.fr/2017/07/04/videolan-and-https/ There were some topics about it yesterday. Eg. https://news.ycombinator.com/item?id=18948195 https://news.ycombinator.com/item?id=18948195 Some arguments of the blog post are also valid here
notyourday 8y ago
The justifications for why APT does not use HTTPS ( by default, it is possible to add https transport ) are just mind blowing. It is however not at all surprising considering how broken Debians secure package distribution methodology is -- I'm saying it as someone who had to implement workarounds for it for a company that was willing to spend significant amount of resources on making it work. Here's are some low level gems: 1. I have installed package X. I want to validate that the files that are listed in a manifest for package X have not changed on a host. APT answer: Handwave! This is not a valid question. If you are asking this question you already lost. 2. I want to have more than one version of a package in a distribution. APT answer: Handwave! You don't need it. You can just have multiple distributions! It is because of how we sign things - we sign collections! 3. I want to have a complicated policy where some packages are signed, some are not signed, and some are signed with specific keys. APT answer: Handwave! You should have all or nothing policy! Nothing policy, actually, because we mostly just sign collections, rather than the individual packages https://wiki.debian.org/SecureApt https://wiki.debian.org/SecureApt
- geezerjay 8y ago
  > 2. I want to have more than one version of a package in a distribution. > APT answer: Handwave! You don't need it. You can just have multiple distributions! It is because of how we sign things - we sign collections! This is not true at all. If you need to distribute multiple versions of the same package then all you need to do is provide multiple versions of the same package. Just get your act straight, learn how to package software, create your packages so that you can deploy them simultaneously without breaking downstream software, and you're set.
  - drdaeman 8y ago
    AFAIK, dpkg doesn't allow to have multiple versions of the same package installed at the same time. This is not apt's limitation, though.
    - UncleEntity 8y ago
      Too lazy to get up from my comfy easy chair to boot my debian running NAS but 99.9% sure there's more than one version of python on that thing.
pbhjpbhj 8y ago
Can't Debian devs just hookup their own server as a CA? No need to trust anyone outside the Debian universe. In fact, is the FOSS community running it's own trust network still, it used to be a thing at LUGs.
omarforgotpwd 8y ago
The other big problem is that people can see what you're downloading. Might not be a big deal but consider: 1. You're in China and you download some VPN software over APT. A seemingly innocuous call to package server is now a clear violation of Chinese law. 2. Even in the US, can leak all kinds of information about your work habits, what you're working on, etc. 3. If it's running on a server, it could leak what vulnerable software you have installed or what versions of various packages you're running to make exploiting known vulnerabilities easier
- omarforgotpwd 8y ago
  Oh, another thing I just thought of: It could leak what vulnerable software you have installed / what version you're running to make exploits easier.
- jlarocco 8y ago
  Even with HTTPS, it's easy enough to figure out which package is being downloaded based on the download size, as explained in TFA. Every time this comes up, it's always the same handful of incorrect arguments made in favor of HTTPS. The cargo-cult mentality that HTTPS == security really does more damage than it does good.
  - zaptheimpaler 8y ago
    I mean deducing the package from download size is way harder than just seeing the name in the open.. security is rarely perfect and more like an arms race, making things more difficult is a big deal. This kind of "you can hack Y too" argument doesn't make any sense if its way harder to hack Y than X.
    - jlarocco 8y ago
      I would agree with you IF it were actually "way harder", but realistically it's no more difficult than checking the file name or the md5 checksum.
    - gtsteve 8y ago
Spooky23 8y ago
For a mirror based system like apt it is incredibly trivial. The integrity of a package depends on dozens of organizations and their practices. When I was a 19 year old idiot, I was responsible for a mirror server. As a bad actor, I could easily get access to a valid organizational cert.
- sanxiyn 8y ago
  > When I was a 19 year old idiot, I was responsible for a mirror server. Me too! It was even ftp.kr.debian.org! It still is! Seriously, people, who do you think has root of official Debian mirror servers hosted by universities? University students. Who are 19 years old. This is literally true.
  - Ayesh 8y ago
    In my country, the ccTLD registry is run by a university. While the professors have done an excellent job, the NIC itself was hacked a few times back, there is no admin UI (call a 19 year old kid and set your nameservers with NATA phonetics), and they still have some non functional root nameservers.

by hannob 8y ago

xcaaa 8y ago

How is it not trivial if rogue organizations like "Staat der Nederlanden" have default certificates in the browser? Hint: The Netherlands is world leader in surveillance of its own citizens and inhabitants.

vegardx 8y ago
Because they would be caught doing it very quickly. There are so many ways to detect this.
- shittyadmin 8y ago
  And ultimately none of those ways to detect this aren't useful against a sufficiently targeted attack with direct access to the signing key. It's one thing if you sign a bad key for Google.com, publish it in CT logs and then put it up on the public internet - it's quite another if you sign a bad key for midsizecompany.com, keep it out of the CT system and use it only in a targeted attack against non-technical individuals who are unlikely to examine a certificate or use things like Certificate Watch. With that said, I still believe serving it over HTTPS would be a substantial improvement. Perhaps pin the cert or at least the CA out of the box to prevent such attacks.
  - Boulth 8y ago
    CT monitors are primarily for site operators not end users. When site operators spot a rouge cert issuance they can clarify that and ultimately get the cert revoked.
    - shittyadmin 8y ago
      Precisely my point - it's not something an end user would notice. And if it doesn't even appear in CT logs or for the end user it would likely go completely unnoticed. There really aren't "so many ways to detect this" - there's about 3: the user examines the certificate, CT logs catch it later and detection in browsers of major changes on the most high profile sites. Anything falling outside of those will almost certainly go unnoticed.
      - tialaramex 8y ago
        When you (a CA, but also just anybody who finds a new one) log a new certificate or a "pre-certificate" (which is essentially a signed document equivalent to the final certificate but not usable as a certificate) the log gives you a receipt, a Signed Certificate Timestamp, saying it commits to publish a consistent log containing this certificate within a period of time (today 24 hours). The SCT proves that this particular log saw a signed document with these specific contents, at this specific moment. Chrome (for a long while now), Safari (announced for early 2019) and Firefox (announced but a bit vague on when) check SCTs for publicly trusted certificates. The browser can look at the SCT and verify that: * It was signed by a log this browser trusts * It matches the contents of the leaf certificate (DNS names, dates, keys, etcetera: Distinguished Encoding means there is only one correct way to write any certificate so there can't be any ambiguity) * It has an acceptable timestamp (not too old, in some cases not too new) It can also contemplate the set of SCTs and decide if they meet further criteria e.g. Google requires at least one Google log and at least one non-Google log. If any of these is wrong, the site doesn't work and an appropriate error message occurs, no user effort is needed or useful here. We know this works because Google managed to do it to themselves by accident once already, blocking Chrome access to a new Google site for - I think it was several hours - because their dedicated in-house certificate group screwed up and didn't log a new certificate. There is more to do to defend the system completely: 1. You could compel a log operator to emit an SCT, but then not actually log your certificate. Certificate Transparency can detect this, a browser would need to remember SCTs it has seen and periodically ask a log for a proof which allows it to verify that the log really has included this certificate. 2. You could go further and compel the log to bifurcate, showing some clients a history with your certificate in, and others a parallel history without that certificate. This can only be detected using what is called "gossip" in which observers of the log have a way to discuss their knowledge of the log state and find out systematically if there are inconsistencies. Once both these things are in place, there's basically no way around just admitting what do you did. Which of course doesn't mean any negative consequences for you, but it does make _deniability_ (much desired by outfits like the NSA and Mossad) hard to achieve if that's something you care about.
kstrauser 8y ago
TLS instead of GPG signatures might be a bad idea, but adding TLS to the transport of signed packages can't make the pipeline less secure.
- admax88q 8y ago
  Unless it misleads people in to thinking they don't have to check signatures because they fetched it over HTTPS which is "secure"
  - bigiain 8y ago
    Also, as the article posts out - it's not exactly trivial to deploy https across their global mirror network or to make it work with local caching proxies. That's an easy thing if you've got a handful of servers or a few load balancers, but not so easy or practical for their use case. (Also, remember most of the apt development had already happened way before free ssl certs became a thing. While saying "Why don't then just use certbot/LetEncrypt is an easy criticism, give them credit for having actually build a GPG sig secured distributed software delivery system years before LetEncrypt existed...)

hacknat 8y ago

Also, their claim that HTTPS doesn’t hide the hosts that you are visiting is about to not be true. Encrypted SNI is now part of the TLS 1.3 RFC, so HTTPS will actually hide one’s internet browsing habits quite well. The only holes in privacy left on the web’s stack are in DNS.

zamadatix 8y ago
I bet DoHTTPS/DoTLS has more penetration than ESNI. Neither are widely implemented though, which is the important part.
- da_chicken 8y ago
  Yeah, but not being implemented now doesn't mean that they never will be. Migrating/implementing now will mean that the mirrors will automatically support it once the features are in place and the clients and servers can agree on the improved privacy feature sets.
ec109685 8y ago
For sni to be effective, you need to be hitting hosts that serve more than one domain. Otherwise, you can just reverse map the ip.
- y4mi 8y ago
  Most of my severs don't report the actual service dns back on a reverse lookup. It's generally nodeXX.some.fqdn or clusterXX or lbXX
  - jedberg 8y ago
    Yes but if I want to specifically look for traffic to the Debian mirrors, I can use DNS to build a list of the IPs and then see if you're connecting to one of them.
  - shittyadmin 8y ago
    Doesn't really matter either way - there's a bunch of crawlers and scanners out there such that you can pretty much Google any IP and find a list of sites that are hosted on it.

jdamato 8y ago

Thanks for commenting this! I've seen this website before and it's really unfortunate how much attention it gets. APT's use of plain text HTTP (even with GPG) is vulnerable to several attacks outlined in this paper: https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.pdf https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.p.... Yes, this paper is old, but APT is still vulnerable to most of these attacks. I would advise anyone wanting to use APT to do so only with TLS.

loeg 8y ago
The criticisms in that paper either do not apply to Apt as described in TFA or amount to DoS attacks. HTTPS does not and can not solve DoS.

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.

emilfihlman 8y ago

>Compromising a CA is not trivial and due to CT it’s almost certain that such an attempt will be uncovered later. The CA ecosystem has improved a lot in recent years, please update your views accordingly. This is simply not true. Governments can simply compel your CA to do as they want. Not to mention that "uncovered later" is pretty damn worthless. That said, I do agree that there should be HTTPS mirrors.

electrum 8y ago
> Not to mention that "uncovered later" is pretty damn worthless. It is not worthless as a deterrent to the CA. Proof of a fraudulently issued certificate are grounds to permanently distrust the CA. So, yes, they can do it, but hopefully only once.

NicoJuicy 8y ago

Here is why Videolan (VLC) doesn't do it: https://www.beauzee.fr/2017/07/04/videolan-and-https/ https://www.beauzee.fr/2017/07/04/videolan-and-https/ There were some topics about it yesterday. Eg. https://news.ycombinator.com/item?id=18948195 https://news.ycombinator.com/item?id=18948195 Some arguments of the blog post are also valid here

notyourday 8y ago

The justifications for why APT does not use HTTPS ( by default, it is possible to add https transport ) are just mind blowing. It is however not at all surprising considering how broken Debians secure package distribution methodology is -- I'm saying it as someone who had to implement workarounds for it for a company that was willing to spend significant amount of resources on making it work. Here's are some low level gems: 1. I have installed package X. I want to validate that the files that are listed in a manifest for package X have not changed on a host. APT answer: Handwave! This is not a valid question. If you are asking this question you already lost. 2. I want to have more than one version of a package in a distribution. APT answer: Handwave! You don't need it. You can just have multiple distributions! It is because of how we sign things - we sign collections! 3. I want to have a complicated policy where some packages are signed, some are not signed, and some are signed with specific keys. APT answer: Handwave! You should have all or nothing policy! Nothing policy, actually, because we mostly just sign collections, rather than the individual packages https://wiki.debian.org/SecureApt https://wiki.debian.org/SecureApt

geezerjay 8y ago
> 2. I want to have more than one version of a package in a distribution. > APT answer: Handwave! You don't need it. You can just have multiple distributions! It is because of how we sign things - we sign collections! This is not true at all. If you need to distribute multiple versions of the same package then all you need to do is provide multiple versions of the same package. Just get your act straight, learn how to package software, create your packages so that you can deploy them simultaneously without breaking downstream software, and you're set.
- drdaeman 8y ago
  AFAIK, dpkg doesn't allow to have multiple versions of the same package installed at the same time. This is not apt's limitation, though.
  - UncleEntity 8y ago
    Too lazy to get up from my comfy easy chair to boot my debian running NAS but 99.9% sure there's more than one version of python on that thing.

pbhjpbhj 8y ago

Can't Debian devs just hookup their own server as a CA? No need to trust anyone outside the Debian universe. In fact, is the FOSS community running it's own trust network still, it used to be a thing at LUGs.

omarforgotpwd 8y ago

The other big problem is that people can see what you're downloading. Might not be a big deal but consider: 1. You're in China and you download some VPN software over APT. A seemingly innocuous call to package server is now a clear violation of Chinese law. 2. Even in the US, can leak all kinds of information about your work habits, what you're working on, etc. 3. If it's running on a server, it could leak what vulnerable software you have installed or what versions of various packages you're running to make exploiting known vulnerabilities easier

omarforgotpwd 8y ago
Oh, another thing I just thought of: It could leak what vulnerable software you have installed / what version you're running to make exploits easier.
jlarocco 8y ago
Even with HTTPS, it's easy enough to figure out which package is being downloaded based on the download size, as explained in TFA. Every time this comes up, it's always the same handful of incorrect arguments made in favor of HTTPS. The cargo-cult mentality that HTTPS == security really does more damage than it does good.
- zaptheimpaler 8y ago
  I mean deducing the package from download size is way harder than just seeing the name in the open.. security is rarely perfect and more like an arms race, making things more difficult is a big deal. This kind of "you can hack Y too" argument doesn't make any sense if its way harder to hack Y than X.
  - jlarocco 8y ago
    I would agree with you IF it were actually "way harder", but realistically it's no more difficult than checking the file name or the md5 checksum.
  - gtsteve 8y ago

Spooky23 8y ago

For a mirror based system like apt it is incredibly trivial. The integrity of a package depends on dozens of organizations and their practices. When I was a 19 year old idiot, I was responsible for a mirror server. As a bad actor, I could easily get access to a valid organizational cert.

sanxiyn 8y ago
> When I was a 19 year old idiot, I was responsible for a mirror server. Me too! It was even ftp.kr.debian.org! It still is! Seriously, people, who do you think has root of official Debian mirror servers hosted by universities? University students. Who are 19 years old. This is literally true.
- Ayesh 8y ago
  In my country, the ccTLD registry is run by a university. While the professors have done an excellent job, the NIC itself was hacked a few times back, there is no admin UI (call a 19 year old kid and set your nameservers with NATA phonetics), and they still have some non functional root nameservers.