Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!newsfeed.utanet.at!newscore.univie.ac.at!aconews-feed.univie.ac.at!aconews.univie.ac.at!not-for-mail Newsgroups: comp.lang.java.programmer From: Andreas Leitgeb Subject: Re: Unsealing a jar file at runtime References: <375b1210-8410-4f56-a2a9-69d63678bd8f@dc3g2000vbb.googlegroups.com> Reply-To: avl@logic.at User-Agent: slrn/pre0.9.9-111 (Linux) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Message-ID: Date: 02 Aug 2011 13:41:16 GMT Lines: 27 NNTP-Posting-Host: gamma.logic.tuwien.ac.at X-Trace: 1312292476 tunews.univie.ac.at 71616 128.130.175.3 X-Complaints-To: abuse@tuwien.ac.at Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:6740 raphfrk@gmail.com wrote: > On Jul 28, 12:21 pm, Andreas Leitgeb > 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.