3 ms·

Oracle's practiced the same policy with VirtualBox distributions and that's been fine because they signed packages. VideoLAN signs their packages too. It seems

by Eli_P 8y ago

Oracle's practiced the same policy with VirtualBox distributions and that's been fine because they signed packages. VideoLAN signs their packages too. It seems to be a common practice for a highly loaded services to outsource as many cryptography to clients as possible. I think for the same reasons Google dropped CSRF tokens for their api in favor of different security measures.

hansen 8y ago
I always thought it's more about caching
CapacitorSet 8y ago
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.
- msbarnett 8y ago
  > 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.
  - theamk 8y ago
    No, this is not the case, as many other people in the thread said.
- Eli_P 8y ago
  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.

by Eli_P 8y ago

hansen 8y ago

I always thought it's more about caching

CapacitorSet 8y ago

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.

msbarnett 8y ago
> 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.
- theamk 8y ago
  No, this is not the case, as many other people in the thread said.
Eli_P 8y ago
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.