...
| Wiki Markup |
|---|
Signing code, however, has its own problems. According to Schneier \[[Schneier 2000|AA. Java References#Schneier 00]\]: |
First, users have no idea how to decide if a particular signer is trusted or not. Second, just because a component is signed doesn't mean that it is safe. Third, just because two components are individually signed does not mean that using them together is safe; lots of accidental harmful interactions can be exploited. Fourth, "safe" is not an all-or-nothing thing; there are degrees of safety. And fifth, the fact that the evidence of attack (the signature on the code) is stored on the computer under attack is mostly useless: The attacker could delete or modify the signature during the attack, or simply reformat the drive where the signature is stored."
...
An organization that signs its code must not vouch for code acquired from a third party without carefully auditing it. When signing privileged code, ensure that the code is confined to the same package (See guideline ENV01-J. Place all privileged code in a single package and seal the package for more information.) . Likewise, any code that is called from the privileged code must also be bundled in the same package. Non-privileged code can be left unsigned, restricting it to the sandbox. Additionally, any code that is incomprehensible or unaudited must not be signed. (See guideline SEC17-J. Create and sign a SignedObject before creating a SealedObject.) .
It follows that unprivileged code is not required to be digitally signed and consequently should not be. This conviction adequately respects the guideline SEC00-J. Follow the principle of least privilege. For instance, unsigned applets and JNLP applications are granted the minimum set of privileges and are restricted to the sandbox.
...