Unsealing a jar file at runtime

[raphfrk]

I don't suppose that this is possible, perhaps with reflection?

The idea is for a plugin to extend a class, but the class is not a
public class, so can only be extended from within the same package.

If the jar file was unsealed, then a class could be created within the
plugin that is in the same package, is public and extends the non-
public class.

 

[Andreas Leitgeb]

I don't suppose that this is possible, perhaps with reflection?
The idea is for a plugin to extend a class, but the class is not a
public class, so can only be extended from within the same package.
If the jar file was unsealed, then a class could be created within the
plugin that is in the same package, is public and extends the non-
public class.

Breaking open a seal is typically easily done.
Reinstating someone else's seal on the changed
content is "believed" to be much harder. I also
believe that it is, but I'm no crypto-expert.

 

[lewbloch]

Breaking open a seal is typically easily done.
Reinstating someone else's seal on the changed
content is "believed" to be much harder. I also
believe that it is, but I'm no crypto-expert.

Even were you to succeed in extending the package-private class and
making it public, there are gotchas. The parent class (the one
already in the JAR) could make assumptions of package-private
visibility that a public subclass would break, e.g., exposure of
package-private methods or attributes for use by its putative friends.

 

[raphfrk]

Breaking open a seal is typically easily done.
Reinstating someone else's seal on the changed
content is "believed" to be much harder. I also
believe that it is, but I'm no crypto-expert.

I don't want to break/remake, just wanted to extend a private class.

Anyway, I guess if it was possible it would be a major hole in the
security system.

 

[Eric Sosman]

I don't want to break/remake, just wanted to extend a private class.

Anyway, I guess if it was possible it would be a major hole in the
security system.

Yes. Also, it's well not to think of security solely in the form
of "denial," as in "That so-and-so won't let me get at his private
class!" Think for a moment of the so-and-so (who might as well be
you), saying "I'm sure there's a better way to do this, but I don't
have time to research/develop/debug it right now. I'll just put the
adequate-but-not-great solution in a private class, and in Version 2.0
I'll replace it with something better. The replacement will be nothing
like the original, but that won't hurt anybody because it's a private
class so only my own code will need to adjust."

In other words, the security you chafe at also protects YOU.

 

[Andreas Leitgeb]

I don't want to break/remake, just wanted to extend a private class.

Who is going to run the resulting code?

You, yourself? Fine! Remove the seal by changing the library's MANIFEST
removing the seal. Then run your code that places that one class into
the library's package and it will work - on your machine.

You want someone else, who got that library from a site he trusts,
to execute your code (injecting that class into the library's package)?
No go. That's what the seal protects the customer against.

The seal is not about the jar-file, it is about the packages inside the
jar-file, that are "protected" by the seal against other jar-files that
would attempt to inject their classes into foreign packages.

If the customer of your package trusts you well enough, you could
persuade him into accepting and using a seal-removed version of that
library, though.