[chrissnell]

More importantly, what good is a code-signed executable when that executable can simply download a payload from the internet like this Dropbox installer does? Code signing seems like a feel-good mechanism for users. Yeah, we guarantee that the executable that you downloaded was signed by a legitimate entity but once you run it, good luck. This type of "meta installer" seems ripe for exploitation. Unscrupulous entities create a legit signed app that later downloads a malicious payload; legitimate distributors might also find themselves to be the target of attackers who want to alter that downloadable payload.

[timbre]

I think the point of code signing is to ensure that the program was really written by Dropbox, so _if_ you trust Dropbox you should trust the program. That trust should definitely include both Dropbox's good intentions and their competency to prevent their payload system from being subverted.

[deciplex]

>That trust should definitely include both Dropbox's good intentions and their competency to prevent their payload system from being subverted.

Only a fool would, after their actions of the past year, still believe this company has good intentions or that their payload system hasn't already been totally compromised (with their cooperation, no less).

[mike_hearn]

Signing doesn't imply you are "legit", at least not much - it requires ID verification but in the absence of any hard rules about what's acceptable that's only useful in the most egregious cases, and anyway you can still run unsigned binaries.

Signing is mostly useful to help reduce anti-virus false positives. AV systems learn binary reputations just like spam filters do. It doesn't matter if the app goes off and downloads another program for this purpose - that's an implementation detail that doesn't impact whether the app is malicious or not.