Add new attachment

Only authorized users are allowed to upload new attachments.

This page (revision-13) was last changed on 29-May-2007 23:13 by JanneJalkanen  

This page was created on 25-Feb-2006 01:04 by

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version and

At line 7 changed one line
|[Bug status]|OpenBug
|[Bug status]|NotReallyBug
At line 25 added 29 lines
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.
As for why we need to do code-signing, it's NOT necessary in the default case where you drop a WAR into a servlet container and use JSPWiki as a single, stand-alone wiki. But for multi-wiki deployments in the same container, or for those cases where the implementer wishes to specify an external security policy file, then we need our code to be signed. Specifically, it has to do with the way Permission classes are loaded and evaluated by the Java access control classes. JSPWiki makes extensive use of custom Permission types (PagePermission, WikiPermission and AllPermission).
Here's an excerpt from the definitive book, ''Inside Java 2 Platform Security, 2nd Edition'', by Li Gong:
''Many {{Permission}} classes referenced by the policy configuration exist locally. That is, those classes can be discovered by the {{Policy}} provider's defining class loader or another loader it delegates to, such as the bootstrap class loader. Objects for such permissions can be instantiated during {Policy}} initialization. For example, it is always possible to instantiate a {{}}, as the {{FilePermission}} class is bound on the bootstrap class path.
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...
A few methods... in the {{UnresolvedPermission}} class are
{{{public UnresolvedPermission(String type, String name,
String actions, certs[]);
public boolean implies(Permission p);
public boolean equals(Object obj); }}}
Note that the constructor takes an array of certificates, which can be used to verify the signatures on the permission class. Remember that {{UnresolvedPermission}}s enable the deferred loading of permission classes so that a given permission class need not be defined until necessary. __The very nature of such permission classes suggests that a more rigorous mechanism is required to ensure their authenticity. By signing a given permission class and specifying the signing requirement in the security policy, we have a foundation that can be used to assure us that the permission class respects the intentions of the root class {{}} and that the implementation is not malicious.__ Of course, this assurance depends on the trust conveyed by the signature keys used to sign the class. However, without this mechanism, it would be up to the application to make this trust decision, which would be difficult, if not impossible, for the application to do.''
Thus -- the logic works like this...
If the classes containing our custom permissions are all loaded before the Policy is set, then we don't need to sign them. For stand-alone, out-of-the-box JSPWiki implementations that ''do not also specify an external policy file'' via the {{}} system property at startup, all classes will be loaded before JSPWiki sets its custom policy.
''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.''
-- Andrew Jaquith, 29 March 2006
Version Date Modified Size Author Changes ... Change note
13 29-May-2007 23:13 5.571 kB JanneJalkanen to previous
12 17-Jul-2006 21:51 5.449 kB Janne Jalkanen to previous | to last
11 17-Jul-2006 11:30 18.999 kB to previous | to last
10 29-Mar-2006 10:18 5.449 kB to previous | to last
9 29-Mar-2006 10:13 5.382 kB to previous | to last
8 29-Mar-2006 10:13 5.352 kB to previous | to last
7 29-Mar-2006 10:13 5.335 kB to previous | to last
6 29-Mar-2006 10:11 5.121 kB to previous | to last
5 29-Mar-2006 10:10 5.119 kB to previous | to last
4 29-Mar-2006 10:09 5.118 kB to previous | to last
3 29-Mar-2006 10:09 5.116 kB to previous | to last
2 27-Feb-2006 07:28 0.667 kB to previous | to last
1 25-Feb-2006 01:04 0.666 kB to last
« This page (revision-13) was last changed on 29-May-2007 23:13 by JanneJalkanen