3 ms·

Also, no-one still mentioned the fact that not doing it over HTTPS with a client that checks certificates (you would be surprised at how many tools get this wro

Also, no-one still mentioned the fact that not doing it over HTTPS with a client that checks certificates (you would be surprised at how many tools get this wrong, sometimes or always) is a complete code execution MitM vulnerability. It is like giving away all the security built everywhere else and yelling "YOLO".

plorkyeran 13y ago
It's almost as insecure as running a binary installer downloaded over HTTP, which of course is something no one would ever do.
- FiloSottile 13y ago
  It's exactly as insecure as running an unsigned binary installer downloaded over HTTP (without checking checksums), which no one should ever do. (Because the authors should offer it over HTTPS, sign it, provide some checksum or ship it through some package manager that knows better, if they can't secure the process themselves)
  - joeshevland 13y ago
    But really? It'll get pretty onerous to check every checksum and guard every entry point. I think we should fix the real problem.
    - mpyne 13y ago
      Well yes, that's the problem. Proper security is onerous, there's no use crying about it. Either do it right or accept that you're insecure. :P Fix all the problems you can, of course, defense in depth is always a good idea. But hackers managing to alter a mirrored file without getting access to the website itself happens more often than you'd like to admit, and even hackers getting access to both a website and a tarball can be mitigated by signing tarballs instead of just listing sha sums. If you trust your website won't be hacked to serve malicious code then you might do away with signing and cryptographic checksums, but then that only makes using TLS that much more important to avoid having your tarball zoinked by a MitM during transit.
    - toomuchtodo 13y ago
      Is there a standard yet where the SHA hash of an object can be stored as part of its HREF? And therefore the HTTP client can verify the hash easily?

plorkyeran 13y ago

It's almost as insecure as running a binary installer downloaded over HTTP, which of course is something no one would ever do.

FiloSottile 13y ago
It's exactly as insecure as running an unsigned binary installer downloaded over HTTP (without checking checksums), which no one should ever do. (Because the authors should offer it over HTTPS, sign it, provide some checksum or ship it through some package manager that knows better, if they can't secure the process themselves)
- joeshevland 13y ago
  But really? It'll get pretty onerous to check every checksum and guard every entry point. I think we should fix the real problem.
  - mpyne 13y ago
    Well yes, that's the problem. Proper security is onerous, there's no use crying about it. Either do it right or accept that you're insecure. :P Fix all the problems you can, of course, defense in depth is always a good idea. But hackers managing to alter a mirrored file without getting access to the website itself happens more often than you'd like to admit, and even hackers getting access to both a website and a tarball can be mitigated by signing tarballs instead of just listing sha sums. If you trust your website won't be hacked to serve malicious code then you might do away with signing and cryptographic checksums, but then that only makes using TLS that much more important to avoid having your tarball zoinked by a MitM during transit.
  - toomuchtodo 13y ago
    Is there a standard yet where the SHA hash of an object can be stored as part of its HREF? And therefore the HTTP client can verify the hash easily?