Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #6627 > unrolled thread

Unsealing a jar file at runtime

Back to article view | Back to comp.lang.java.programmer

Contents

  Unsealing a jar file at runtime "raphfrk@gmail.com" <raphfrk@gmail.com> - 2011-07-28 02:36 -0700
    Re: Unsealing a jar file at runtime Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-07-28 11:21 +0000
      Re: Unsealing a jar file at runtime lewbloch <lewbloch@gmail.com> - 2011-07-29 13:42 -0700
      Re: Unsealing a jar file at runtime "raphfrk@gmail.com" <raphfrk@gmail.com> - 2011-08-01 14:48 -0700
        Re: Unsealing a jar file at runtime Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-08-01 21:22 -0400
        Re: Unsealing a jar file at runtime Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-08-02 13:41 +0000

#6627 — Unsealing a jar file at runtime

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.

[toc] | [next] | [standalone]

#6632

raphfrk@gmail.com <raphfrk@gmail.com> wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#6665

On Jul 28, 4:21 am, Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at>
wrote:
> raph...@gmail.com <raph...@gmail.com> wrote:
> > 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.

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.

--
Lew

[toc] | [prev] | [next] | [standalone]

#6715

On Jul 28, 12:21 pm, Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at>
wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#6727

On 8/1/2011 5:48 PM, raphfrk@gmail.com wrote:
> On Jul 28, 12:21 pm, Andreas Leitgeb<a...@gamma.logic.tuwien.ac.at>
> wrote:
>> 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.

     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.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#6740

raphfrk@gmail.com <raphfrk@gmail.com> wrote:
> On Jul 28, 12:21 pm, Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at>
> wrote:
>> 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.

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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web