Re: [Jython-users] "bad" jars

[Nick C. <ni...@sr...>]

Java  provides an API for dealing  with jar files in the java.util.jar
package. Perhaps using this API would allow you to accompilsh what you
are trying to do. They are only part java 1.2 though.

Nick

On Wed, Apr 11, 2001 at 07:11:42PM -0400, D-Man wrote:
> On Wed, Apr 11, 2001 at 03:04:51PM -0700, Daniel Lord wrote:
> | Maybe I am missing somethign here and I certainly don't know the details of
> | what you are doing nor what your are trying to accomplish, but I thiink
> | circumventing the security model for Jython/Java is an ugly, uncreative, and
> | dangerous way to do anything. You should rethink the security mechanism
> | implementation to somehow include the key in the pre-jar code and then jar
> | it up so the check sum is correct. Or use another type of file in the
> | CLASSPATH since the JVM doesn't need to read it and it's just a key why are
> | you jaring it at all?
> 
> The product consists of an SDK and a runtime.  For "Trial" versions
> the user will enter a key provided by the sales team into the SDK.
> The SDK needs to save the key somehow.  Normal jar creation doesn't
> work because (at least on windows) renaming the new temp jar to the
> proper name fails -- the VM is using the file already.  My solution is
> to look through the CLASSPATH to find the proper jar (the path to it)
> and open it as a RandomAccessFile.  Then I walk through the jar until
> I find the spot I want and read/write the key as binary data.  The
> idea is to have the key stored in the (runtime) jar file so the
> potential customer can try out the runtime.  I already tried putting
> it in a file in the user's home directory, but that didn't work --
> some potential customers are using windows and each vm has it's own
> idea of what the "home" directory is ; some other users were on Unix
> and used one account in the lab for development and a different one
> for deployment.
> 
> The VM doesn't need that particular file, but putting it anywhere but
> in the jar seems pretty messy.
> 
> The security that this mechanism is supposed to provide is simply to
> prevent people from stealing the product without purchasing a license.
> Of course, any really determined person will step through the
> execution and hack around it.
> 
> I hope this clears up what I was looking for.
> 
> -D
> 
> 
> 
> _______________________________________________
> Jython-users mailing list
> Jyt...@li...
> http://lists.sourceforge.net/lists/listinfo/jython-users

-- 
Nick Collier
Social Science Research Computing
University of Chicago
http://repast.sourceforge.net