5 ms·
Interesting paper. Thoughts about tradeoff: 1. What if the update breaks some user code / extension and causes loss of productivity? 2. What if the update serv
by khandekars 17y ago
Interesting paper. Thoughts about tradeoff:
1. What if the update breaks some user code / extension and causes loss of productivity? 2. What if the update server gets hacked (though highly unlikely)?
On the whole, silent updates are useful when: a. attack surface is greater, b. they are geared towards security fixes than enhancements.
- deno 17y agoAD1: Possible solution might be signing updates. Microsoft already provides way to sign assembly files. Ohama (Google update tool) uses HTTPS, but I doubt they are signing files they download.
- eru 17y agoUbuntu also signs updates. And I guess they did not invent it, but took the process from Debian.
- deno 17y agoStill, if private key is compromised you can inject evil updates. And it might be the case for teams that lacks necessary security policies, e.g. private key is on same server as download server or is accessible from one. Maybe requiring signing by several developers (so that if one key is compromised it's still not a threat)? But that might be a little paranoid.
- khandekars 17y agoSigning by several developers is a good idea. Also, the scheme might still fall to man-in-the-middle attack. One possible solution could be to have multiple update servers with the policy that, download update from one and signatures from the other, subsequently verifying the integrity.
- eru 17y agoThe man-in-the-middle attack is not such a big problem in defending against a short-lived attack. Ubuntu establishes the identity with the keys that you get at installation.