| At line 24 changed one line |
| The signing makes development unnecessaryly difficult. |
| The signing makes development unnecessarily difficult. |
| At line 26 changed one line |
| This is not a bug, because code-signing is needed to support certain deployment scenarios. This is perhaps a slight impediment to development, but I think we've done the best we can to make code-signing easy. The Ant scripts will auto-generate a key for you (with sensible defaults) whenever you build JSPWiki from scratch. |
| This is not a bug, because code-signing is needed to support certain deployment scenarios. This is perhaps a slight impediment to development, but I think we've done the best we can to make code-signing easy. The Ant scripts will auto-generate a key for you (with sensible defaults) whenever you build JSPWiki from scratch. So I think the comment "unnecessarily difficult" is a little harsh. |
| At line 30 changed one line |
| Here's an excerpt from the definitive book, ''Inside Java 2 Platform Security, 2nd Edition'', by Li Gong: |
| Here's an excerpt from the definitive book, ''Inside Java 2 Platform Security, 2nd Edition'', by Li Gong, that explains why this is so: |
| At line 34 changed one line |
| However, [[it is possible that] when the {{Policy}} object is constructed, the code that implenents a particular {{Permission}} class has yet to be loaded or is not available for loading. For example, a referenced {{Permission}} class might be in a JAR file that will eventually be downloaded. In this case, the {{Permission}} has yet to be defined within the Java runtime environment. For such a class, an {{UnresolvedPermission}} object is instantiated instead, as a placeholder that contains information about the permission... Unresolved permissions of a particular type must be resolved before an access control decision can be made about a permission of the actual type... To resolve an {{UnresolvedPermission}}, the policy decision point must locate and instantiate the appropriate permission class type... |
| However, [[it is possible that] when the {{Policy}} object is constructed, the code that implements a particular {{Permission}} class has yet to be loaded or is not available for loading. For example, a referenced {{Permission}} class might be in a JAR file that will eventually be downloaded. In this case, the {{Permission}} has yet to be defined within the Java runtime environment. For such a class, an {{UnresolvedPermission}} object is instantiated instead, as a placeholder that contains information about the permission... Unresolved permissions of a particular type must be resolved before an access control decision can be made about a permission of the actual type... To resolve an {{UnresolvedPermission}}, the policy decision point must locate and instantiate the appropriate permission class type... |
| At line 51 changed one line |
| ''However'', it is not safe to assume that all environments work this way. In some (mine, for instance), the admin will wish to set the policy file manually. In this case, the JSPWiki Permission classes will ''not'' be available to the Java Policy object at JVM startup. Thus, they are instantiated initially as {{UnresolvedPermission}} instances. ''Therefore, we must have our JAR signed in order for them to become unresolved.'' |
| ''However'', it is not safe to assume that all environments work this way. In some (mine, for instance), the admin will wish to set the policy file manually. In this case, the JSPWiki Permission classes will ''not'' be available to the Java Policy object at JVM startup. Thus, they are instantiated initially as {{UnresolvedPermission}} instances. ''Therefore, we must have our JAR signed in order for them to become "resolved."'' |
| At line 56 added 6 lines |
|
| ---- |
|
| As of 2.5.68, code signing is no longer necessary, unless you wish to use a global policy. |
|
| -- JanneJalkanen |
