Hacker News Reader

Comment by CapacitorSet | Hacker News Reader

This isn't any different from many download procedures. Consider that even a general-purpose package manager like Pacman uses HTTP, because there's little point in using transport-level security when the payload is cryptographically signed and there's a solid root of trust.

The only reasonable problem I see with this approach is that a MITM can make clients download an older version that is known to have critical bugs.

View on HN

> This isn't any different from many download procedures. Consider that even a general-purpose package manager like Pacman uses HTTP, because there's little point in using transport-level security when the payload is cryptographically signed and there's a solid root of trust.

This IS different.

If the VLC update is signed with a key not known to VLC, VLC will then go fetch the new key from the update server over HTTP, and not verify the key in any other way.

This renders the cryptographic signing of the updated binary a complete no-op. Anybody in a position to tamper with the HTTP download of the signed binary can equally change the HTTP downloaded, unverified key VLC retrieves to verify the signing. It is effectively unsigned, and the root of trust is as solid as mist.

No, this is not the case, as many other people in the thread said.

Thant's an interesting observation, possibly can be solved with a signed version file, which is released daily. Signing of (datetime, version, package_image_hash) can be done with CI daily or hourly and probably way faster than encrypting the whole traffic.

Reply on news.ycombinator.com