Nabble - Juice - Dev

Fwd: Incubator Quarterly Board Reporting Schedule

2006-06-14T23:32:51Z

FYI

---------- Forwarded message ----------
From: Noel J. Bergman <noel@...>
Date: Jun 15, 2006 12:31 AM
Subject: Incubator Quarterly Board Reporting Schedule
To: general@...

The reporting schedule is at
http://wiki.apache.org/incubator/ReportingSchedule, so that everyone knows
for which months their report is due. PLEASE NOTE: all new projects must
also report for the first three months of Incubation. This is not reflected
on the posted schedule.

Mentors: as new projects are adopted, I'd appreciate your help keeping the
reporting schedule up to date. Since your projects must report every month
for the first three months, I would suggest that new projects be added to
the list in which their third month occurs. So if a new project must report
in July, August and September, add it to the [March, June, September,
December] group.

--- Noel

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

--
Davanum Srinivas : http://wso2.com/blogs/

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

Re: Thoughts

2006-04-23T10:03:01Z

On 4/23/06, Berin Lautenbach <berin@...> wrote:
> Hiya,
>
> To get out of the incubator, we need to start thinking about a few things.
>
> 1. We need copyright notices in all the source files and in the
> appropriate NOTICE file.
> 2. We need a web page/set of web pages for the JuiCE project. Do we
> create under security web pages? Happy to do this, interested in thoughts.
+1, for me.

> 3. What's our plan to get something released? Do we want to get a core
> set of algorithms fully tested and working and then release? If so -
> what would they be?
>
> Probably enough to be working on :>.
>
> Cheers,
> Berin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juice-dev-unsubscribe@...
> For additional commands, e-mail: juice-dev-help@...
>
>

--
http://r-bg.com

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

Thoughts

2006-04-23T05:37:09Z

Hiya,

To get out of the incubator, we need to start thinking about a few things.

1. We need copyright notices in all the source files and in the
appropriate NOTICE file.
2. We need a web page/set of web pages for the JuiCE project. Do we
create under security web pages? Happy to do this, interested in thoughts.
3. What's our plan to get something released? Do we want to get a core
set of algorithms fully tested and working and then release? If so -
what would they be?

Probably enough to be working on :>.

Cheers,
Berin

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

Re: Fwd: REMINDER: * Board Reports DUE! *

2006-04-13T23:51:34Z

Just did it and then saw this.

I have indicated that we want to graduate in the coming quarter. Which
will also involve promoting xml-security to TLP.

Cheers,
Berin

Cheers,
Berin

Davanum Srinivas wrote:

> FYI, Can someone please take the lead?
>
> thanks,
> dims
>
> ---------- Forwarded message ----------
> From: Noel J. Bergman <noel@...>
> Date: Apr 13, 2006 9:04 AM
> Subject: REMINDER: *** Board Reports DUE! ***
> To: general@...
>
>
> See: http://wiki.apache.org/incubator/April2006
>
> --- Noel
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@...
> For additional commands, e-mail: general-help@...
>
>
>
> --
> Davanum Srinivas : http://wso2.com/blogs/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juice-dev-unsubscribe@...
> For additional commands, e-mail: juice-dev-help@...
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

Fwd: REMINDER: * Board Reports DUE! *

2006-04-13T08:57:14Z

FYI, Can someone please take the lead?

thanks,
dims

---------- Forwarded message ----------
From: Noel J. Bergman <noel@...>
Date: Apr 13, 2006 9:04 AM
Subject: REMINDER: *** Board Reports DUE! ***
To: general@...

See: http://wiki.apache.org/incubator/April2006

--- Noel

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@...
For additional commands, e-mail: general-help@...

--
Davanum Srinivas : http://wso2.com/blogs/

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

Some news on JuiCE

2006-04-02T08:57:27Z

All,

the last day we got some great news about JuiCE:

- using Java 5 we now support the standard JCE EC methods, both
for Fp fields and for F2m fields. Note: only named curves
are supported (named curves according to NIST, X9.62, etc.). BTW,
the test cases show one error when using BC and keys generated
by Juice - this is not a generic problem, we need to encode/decode
the keys befroe BC can use them (JuiCE does this automatically). I'll
update the unit test during the next days.

- With JDK 1.4 we support interoperability with BC for EC (Fp fields
only)

- Diffie-Helman key agreement is now available. Most of the time for
DH is spent during parameter generation. We use OpenSSL here to
do it. The actual key generation that creates a private value and
computes the public part is very thin, I left that in Java. Probably
there is more overhead for Java/C JNI than it saves use some time.
(it's only create a random big int and do a big int modPow(..) )

- restructured the files, sources for Java 5 use generics (Java 5
"templates") thus they don't compile with JDK 1.4. I did this to
make sure you use a Java 5 environment to compile (JuiCE java 5
requiers the Java 5 libraries).

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

Re: AW: Proposal for restructuring JuiCE files - and some new functions

2006-03-22T00:27:28Z

Hmm. What fun! I've never played around with Windows installers.
Might be interesting.

Bags that bit :>.

cheers,
Berin

Dittmann, Werner wrote:

> Berin,
>
> don't worry too much :-). I've tried to keep the C files
> clean and without compiler warning even in Visual C
> (maybe not always the newest ... ) .
>
> Once we are somehow convinced we can have a first alpha
> or beta we need to think about to package the Windows
> native library (installer?)
>
> Regards,
> Werner
>
>
>>-----Ursprüngliche Nachricht-----
>>Von: Berin Lautenbach [mailto:berin@...]
>>Gesendet: Dienstag, 21. März 2006 09:17
>>An: juice-dev@...
>>Betreff: Re: Proposal for restructuring JuiCE files - and
>>some new functions
>>
>>+1. I really must get onto the Project files. I've been
>>trying to tie
>>up some stuff on the xml-security library.
>>
>>Cheers,
>> Berin
>>
>>Dittmann, Werner wrote:
>>
>>>All,
>>>
>>>after some tests and discussions with the BC guys a first step
>>>of the Elliptic Curve (EC) functions is available:
>>>
>>>- key generation for various key lengths according to X9.62
>>>- EC DSA with SHA1
>>>
>>>During the interop tests we got some problems with older versions
>>>of BC. Thus to interop with BC you have to use version 1.31 (or
>>>greater).
>>>
>>>While looking at EC and some other security stuff it became clear
>>>that a restructuring of the JuiCE files will be necessary. The
>>>Java versions 1.3, 1.4, and 1.5 (aka Java 5.0) each provide several
>>>enhancements of security both in java.security.* and javax.crypto.*
>>>that are _not_ compatible and/or fully upward compatible.
>>
>>To overcome
>>
>>>this problem we should introduce a structure similar to BC (similiar
>>>problems lead to similar solutions :-) )
>>>
>>>Currently we have:
>>>
>>>JuiCE/java/src/org/...
>>> and the classes stored in
>>>JuiCE/build/classes/...
>>>
>>>I propose the following structure:
>>>
>>>Juice/java/common/src/... the Java source files
>>>Juice/java/common/build/classes/... the class files
>>>Juice/java/common/build/... other files, dirs, (resources,
>>>etc)
>>>Juice/java/common/test/... test cases
>>>
>>>Juice/java/jdk14/src/...
>>>Juice/java/jdk14/build/classes/... the class files
>>>Juice/java/jdk14/build/... other files (resources, etc)
>>>Juice/java/jdk14/test/... test cases
>>>
>>>Juice/java/java5/src/...
>>>Juice/java/java5/build/classes/... the class files
>>>Juice/java/java5/build/... other files (resources, etc)
>>>Juice/java/java5/test/... test cases
>>>
>>>Such a structure would also support an Eclipse setup
>>
>>defining common,
>>
>>>jdk14,
>>>java5, ... as single projects that have dependencies. This
>>
>>is somehow
>>
>>>similar to the Axis2 setup with its modules (in our case
>>
>>the modules are
>>
>>>"common", "jdk14", "java5", ...).
>>>
>>>The distribution would then combine "common" and one of the
>>
>>Java version
>>
>>>dependent module to build a JuiCE jar. The names of the
>>
>>JuiCE jars would
>>
>>>be:
>>>
>>>juice-jdk14-0.9.jar
>>>juice-java5-0.9.jar
>>>
>>>where 0.9 would be a current JuiCE version number.
>>>
>>>I don't see any problems for the native code. It would always be a
>>>superset
>>>of functions required by the various Java JCE classes.
>>>
>>>Any thoughts, ideas?
>>>
>>>Regards,
>>>Werner
>>>
>>>
>>
>>---------------------------------------------------------------------
>>
>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>For additional commands, e-mail: juice-dev-help@...
>>>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>For additional commands, e-mail: juice-dev-help@...
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juice-dev-unsubscribe@...
> For additional commands, e-mail: juice-dev-help@...
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

AW: Proposal for restructuring JuiCE files - and some new functions

2006-03-21T05:05:15Z

Berin,

don't worry too much :-). I've tried to keep the C files
clean and without compiler warning even in Visual C
(maybe not always the newest ... ) .

Once we are somehow convinced we can have a first alpha
or beta we need to think about to package the Windows
native library (installer?)

Regards,
Werner

> -----Ursprüngliche Nachricht-----
> Von: Berin Lautenbach [mailto:berin@...]
> Gesendet: Dienstag, 21. März 2006 09:17
> An: juice-dev@...
> Betreff: Re: Proposal for restructuring JuiCE files - and
> some new functions
>
> +1. I really must get onto the Project files. I've been
> trying to tie
> up some stuff on the xml-security library.
>
> Cheers,
> Berin
>
> Dittmann, Werner wrote:
> > All,
> >
> > after some tests and discussions with the BC guys a first step
> > of the Elliptic Curve (EC) functions is available:
> >
> > - key generation for various key lengths according to X9.62
> > - EC DSA with SHA1
> >
> > During the interop tests we got some problems with older versions
> > of BC. Thus to interop with BC you have to use version 1.31 (or
> > greater).
> >
> > While looking at EC and some other security stuff it became clear
> > that a restructuring of the JuiCE files will be necessary. The
> > Java versions 1.3, 1.4, and 1.5 (aka Java 5.0) each provide several
> > enhancements of security both in java.security.* and javax.crypto.*
> > that are _not_ compatible and/or fully upward compatible.
> To overcome
> > this problem we should introduce a structure similar to BC (similiar
> > problems lead to similar solutions :-) )
> >
> > Currently we have:
> >
> > JuiCE/java/src/org/...
> > and the classes stored in
> > JuiCE/build/classes/...
> >
> > I propose the following structure:
> >
> > Juice/java/common/src/... the Java source files
> > Juice/java/common/build/classes/... the class files
> > Juice/java/common/build/... other files, dirs, (resources,
> > etc)
> > Juice/java/common/test/... test cases
> >
> > Juice/java/jdk14/src/...
> > Juice/java/jdk14/build/classes/... the class files
> > Juice/java/jdk14/build/... other files (resources, etc)
> > Juice/java/jdk14/test/... test cases
> >
> > Juice/java/java5/src/...
> > Juice/java/java5/build/classes/... the class files
> > Juice/java/java5/build/... other files (resources, etc)
> > Juice/java/java5/test/... test cases
> >
> > Such a structure would also support an Eclipse setup
> defining common,
> > jdk14,
> > java5, ... as single projects that have dependencies. This
> is somehow
> > similar to the Axis2 setup with its modules (in our case
> the modules are
> > "common", "jdk14", "java5", ...).
> >
> > The distribution would then combine "common" and one of the
> Java version
> > dependent module to build a JuiCE jar. The names of the
> JuiCE jars would
> > be:
> >
> > juice-jdk14-0.9.jar
> > juice-java5-0.9.jar
> >
> > where 0.9 would be a current JuiCE version number.
> >
> > I don't see any problems for the native code. It would always be a
> > superset
> > of functions required by the various Java JCE classes.
> >
> > Any thoughts, ideas?
> >
> > Regards,
> > Werner
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: juice-dev-unsubscribe@...
> > For additional commands, e-mail: juice-dev-help@...
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juice-dev-unsubscribe@...
> For additional commands, e-mail: juice-dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

Re: Proposal for restructuring JuiCE files - and some new functions

2006-03-21T00:16:52Z

+1. I really must get onto the Project files. I've been trying to tie
up some stuff on the xml-security library.

Cheers,
Berin

Dittmann, Werner wrote:

> All,
>
> after some tests and discussions with the BC guys a first step
> of the Elliptic Curve (EC) functions is available:
>
> - key generation for various key lengths according to X9.62
> - EC DSA with SHA1
>
> During the interop tests we got some problems with older versions
> of BC. Thus to interop with BC you have to use version 1.31 (or
> greater).
>
> While looking at EC and some other security stuff it became clear
> that a restructuring of the JuiCE files will be necessary. The
> Java versions 1.3, 1.4, and 1.5 (aka Java 5.0) each provide several
> enhancements of security both in java.security.* and javax.crypto.*
> that are _not_ compatible and/or fully upward compatible. To overcome
> this problem we should introduce a structure similar to BC (similiar
> problems lead to similar solutions :-) )
>
> Currently we have:
>
> JuiCE/java/src/org/...
> and the classes stored in
> JuiCE/build/classes/...
>
> I propose the following structure:
>
> Juice/java/common/src/... the Java source files
> Juice/java/common/build/classes/... the class files
> Juice/java/common/build/... other files, dirs, (resources,
> etc)
> Juice/java/common/test/... test cases
>
> Juice/java/jdk14/src/...
> Juice/java/jdk14/build/classes/... the class files
> Juice/java/jdk14/build/... other files (resources, etc)
> Juice/java/jdk14/test/... test cases
>
> Juice/java/java5/src/...
> Juice/java/java5/build/classes/... the class files
> Juice/java/java5/build/... other files (resources, etc)
> Juice/java/java5/test/... test cases
>
> Such a structure would also support an Eclipse setup defining common,
> jdk14,
> java5, ... as single projects that have dependencies. This is somehow
> similar to the Axis2 setup with its modules (in our case the modules are
> "common", "jdk14", "java5", ...).
>
> The distribution would then combine "common" and one of the Java version
> dependent module to build a JuiCE jar. The names of the JuiCE jars would
> be:
>
> juice-jdk14-0.9.jar
> juice-java5-0.9.jar
>
> where 0.9 would be a current JuiCE version number.
>
> I don't see any problems for the native code. It would always be a
> superset
> of functions required by the various Java JCE classes.
>
> Any thoughts, ideas?
>
> Regards,
> Werner
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juice-dev-unsubscribe@...
> For additional commands, e-mail: juice-dev-help@...
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

Re: Proposal for restructuring JuiCE files - and some new functions

2006-03-20T09:04:52Z

+1 for me also,
I want to play with NIO buffers...

Regards,
And keep the good job...

Raul

On 3/20/06, Davanum Srinivas <davanum@...> wrote:

> +1 from me.
>
> On 3/20/06, Dittmann, Werner <werner.dittmann@...> wrote:
> > All,
> >
> > after some tests and discussions with the BC guys a first step
> > of the Elliptic Curve (EC) functions is available:
> >
> > - key generation for various key lengths according to X9.62
> > - EC DSA with SHA1
> >
> > During the interop tests we got some problems with older versions
> > of BC. Thus to interop with BC you have to use version 1.31 (or
> > greater).
> >
> > While looking at EC and some other security stuff it became clear
> > that a restructuring of the JuiCE files will be necessary. The
> > Java versions 1.3, 1.4, and 1.5 (aka Java 5.0) each provide several
> > enhancements of security both in java.security.* and javax.crypto.*
> > that are _not_ compatible and/or fully upward compatible. To overcome
> > this problem we should introduce a structure similar to BC (similiar
> > problems lead to similar solutions :-) )
> >
> > Currently we have:
> >
> > JuiCE/java/src/org/...
> > and the classes stored in
> > JuiCE/build/classes/...
> >
> > I propose the following structure:
> >
> > Juice/java/common/src/... the Java source files
> > Juice/java/common/build/classes/... the class files
> > Juice/java/common/build/... other files, dirs, (resources,
> > etc)
> > Juice/java/common/test/... test cases
> >
> > Juice/java/jdk14/src/...
> > Juice/java/jdk14/build/classes/... the class files
> > Juice/java/jdk14/build/... other files (resources, etc)
> > Juice/java/jdk14/test/... test cases
> >
> > Juice/java/java5/src/...
> > Juice/java/java5/build/classes/... the class files
> > Juice/java/java5/build/... other files (resources, etc)
> > Juice/java/java5/test/... test cases
> >
> > Such a structure would also support an Eclipse setup defining common,
> > jdk14,
> > java5, ... as single projects that have dependencies. This is somehow
> > similar to the Axis2 setup with its modules (in our case the modules are
> > "common", "jdk14", "java5", ...).
> >
> > The distribution would then combine "common" and one of the Java version
> > dependent module to build a JuiCE jar. The names of the JuiCE jars would
> > be:
> >
> > juice-jdk14-0.9.jar
> > juice-java5-0.9.jar
> >
> > where 0.9 would be a current JuiCE version number.
> >
> > I don't see any problems for the native code. It would always be a
> > superset
> > of functions required by the various Java JCE classes.
> >
> > Any thoughts, ideas?
> >
> > Regards,
> > Werner
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: juice-dev-unsubscribe@...
> > For additional commands, e-mail: juice-dev-help@...
> >
> >
>
>
> --
> Davanum Srinivas : http://wso2.com/blogs/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juice-dev-unsubscribe@...
> For additional commands, e-mail: juice-dev-help@...
>
>

--
http://r-bg.com

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

Re: Proposal for restructuring JuiCE files - and some new functions

2006-03-20T08:37:26Z

+1 from me.

On 3/20/06, Dittmann, Werner <werner.dittmann@...> wrote:

--
Davanum Srinivas : http://wso2.com/blogs/

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

Proposal for restructuring JuiCE files - and some new functions

2006-03-20T00:50:24Z

All,

after some tests and discussions with the BC guys a first step
of the Elliptic Curve (EC) functions is available:

- key generation for various key lengths according to X9.62
- EC DSA with SHA1

During the interop tests we got some problems with older versions
of BC. Thus to interop with BC you have to use version 1.31 (or
greater).

While looking at EC and some other security stuff it became clear
that a restructuring of the JuiCE files will be necessary. The
Java versions 1.3, 1.4, and 1.5 (aka Java 5.0) each provide several
enhancements of security both in java.security.* and javax.crypto.*
that are _not_ compatible and/or fully upward compatible. To overcome
this problem we should introduce a structure similar to BC (similiar
problems lead to similar solutions :-) )

Currently we have:

JuiCE/java/src/org/...
and the classes stored in
JuiCE/build/classes/...

I propose the following structure:

Juice/java/common/src/... the Java source files
Juice/java/common/build/classes/... the class files
Juice/java/common/build/... other files, dirs, (resources,
etc)
Juice/java/common/test/... test cases

Juice/java/jdk14/src/...
Juice/java/jdk14/build/classes/... the class files
Juice/java/jdk14/build/... other files (resources, etc)
Juice/java/jdk14/test/... test cases

Juice/java/java5/src/...
Juice/java/java5/build/classes/... the class files
Juice/java/java5/build/... other files (resources, etc)
Juice/java/java5/test/... test cases

Such a structure would also support an Eclipse setup defining common,
jdk14,
java5, ... as single projects that have dependencies. This is somehow
similar to the Axis2 setup with its modules (in our case the modules are
"common", "jdk14", "java5", ...).

The distribution would then combine "common" and one of the Java version
dependent module to build a JuiCE jar. The names of the JuiCE jars would
be:

juice-jdk14-0.9.jar
juice-java5-0.9.jar

where 0.9 would be a current JuiCE version number.

I don't see any problems for the native code. It would always be a
superset
of functions required by the various Java JCE classes.

Any thoughts, ideas?

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

[JuiCE] New ciphers, key factories, key pair generators avaliable - additional info

2006-03-05T05:58:53Z

I forgot something:

The AES, DES, and DESede cipher also support the OFB and CFB
modes. If the OpenSSL library supports it also CFB1 and CFB8
is available (CFB1 has a problem in BouncyCastle - it procuces
a divide by zero exception).

Regards,
Werner

All,

in the last few days I implemented some more features and functions
in JuiCE. It's getting more to a full blown JCE now. In addition to
the new features the error handling was improved, in particular for
the native library. It now uses exception to signal errors/problems
to the Java code.

Here is a full list of supported algorithms:

Ciphers

- AES (all key sizes), DES, DESEDE in ECB and CBC mode,
available paddings are: none, PKCS5/PKCS7, ISO10126, ZEROBYTE

- RSA RAW, RSA PKCS1padding, RSA OAEP padding

- RC2 with key sizes up to 128, ECB and CBC mode

- RC4 stream cipher with key sizes up to 128

Password based (PBE) ciphers

- PBEwithSHAand128bitAES-CBC-BC, PBEwithSHAand192bitAES-CBC-BC,
PBEwithSHAand256bitAES-CBC-BC

- PBEwithMD5and128bitAES-CBC-OPENSSL, BEwithMD5and192bitAES-CBC-OPENSSL,
PBEwithMD5and256bitAES-CBC-OPENSSL

- PBEwithMD5andDES, PBEwithSHA1andDES, PBEwithSHAand3-KeyTripleDES-CBC

- PBEwithMD5andRC2, PBEwithSHA1andRC2 - these use RC2 with 64bit key
PBEwithSHAand128bitRC2, PBEwithSHAand40bitRC2-CBC

- PBEwithSHAand128bitRC4, PBEwithSHAand40bitRC4

NOTE: all the PBE ciphers require that you use the associated secret key
factories. This also requires that the BouncyCastle library is on your
classpath (see note below). These PBE cipher algorithms are compatible
with the implementations available in the BouncyCastle library. Please
refer to the test cases to see how these are used.

Digests

- MD2, MD4, MD5, SHA1, SHA256, SHA512 (the latter two only if the
installed OpenSSL library supports them), RIPEMD160

Signatures

- MD5WithRSAEncryption, SHA1WithRSAEncryption (also with SHA256
and SHA512 if supported by openSSL, see remark for digests)

- standard DSA with SHA1

MACs

- HMAC (Hashed MACs) with MD{2,4,5}, SHA1 (also SHA256 and SHA512 if
supported by openSSL, see remark for digests), RIPEMD160

- Cipher based MAC for DES (64-bit key) and DESEDE (192-bit Key)

Secret Key Factories

- DES, DESede

- PBEwithSHAand128bitAES-CBC-BC, PBEwithSHAand192bitAES-CBC-BC,
PBEwithSHAand256bitAES-CBC-BC

- PBEwithMD5and128bitAES-CBC-OPENSSL,PBEwithMD5and192bitAES-CBC-OPENSSL,
PBEwithMD5and256bitAES-CBC-OPENSSL

- PBEwithMD5andDES, PBEwithSHA1andDES, PBEwithSHAand3-KeyTripleDES-CBC

- PBEwithMD5andRC2, PBEwithSHA1andRC2 - these use RC2 with 64bit key
PBEwithSHAand128bitRC2, PBEwithSHAand40bitRC2-CBC

- PBEwithSHAand128bitRC4, PBEwithSHAand40bitRC4

NOTE: if you use the Secret Key Factories you must have the
BouncyCastle library on your classpath. While the key generation and
the actual ciphers use OpenSSL functions to get more speed the BC
library is responsible to handle all the ASN.1/PKCS format related
stuff.

Key Pair Generators

- RSA

- DSA

NOTE: Refer to the note on secret key factories - the same applies to
the key pair generators.

Unit tests for all implemented algorithms are available. Please refer
to them to see how to use JuiCE.

Have fun.

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

[JuiCE] New ciphers, key factories, key pair generators avaliable

2006-03-05T05:53:06Z

All,

in the last few days I implemented some more features and functions
in JuiCE. It's getting more to a full blown JCE now. In addition to
the new features the error handling was improved, in particular for
the native library. It now uses exception to signal errors/problems
to the Java code.

Here is a full list of supported algorithms:

Ciphers

- AES (all key sizes), DES, DESEDE in ECB and CBC mode,
available paddings are: none, PKCS5/PKCS7, ISO10126, ZEROBYTE

- RSA RAW, RSA PKCS1padding, RSA OAEP padding

- RC2 with key sizes up to 128, ECB and CBC mode

- RC4 stream cipher with key sizes up to 128

Password based (PBE) ciphers

- PBEwithSHAand128bitAES-CBC-BC, PBEwithSHAand192bitAES-CBC-BC,
PBEwithSHAand256bitAES-CBC-BC

- PBEwithMD5and128bitAES-CBC-OPENSSL, BEwithMD5and192bitAES-CBC-OPENSSL,
PBEwithMD5and256bitAES-CBC-OPENSSL

- PBEwithMD5andDES, PBEwithSHA1andDES, PBEwithSHAand3-KeyTripleDES-CBC

- PBEwithMD5andRC2, PBEwithSHA1andRC2 - these use RC2 with 64bit key
PBEwithSHAand128bitRC2, PBEwithSHAand40bitRC2-CBC

- PBEwithSHAand128bitRC4, PBEwithSHAand40bitRC4

NOTE: all the PBE ciphers require that you use the associated secret key
factories. This also requires that the BouncyCastle library is on your
classpath (see note below). These PBE cipher algorithms are compatible
with the implementations available in the BouncyCastle library. Please
refer to the test cases to see how these are used.

Digests

- MD2, MD4, MD5, SHA1, SHA256, SHA512 (the latter two only if the
installed OpenSSL library supports them), RIPEMD160

Signatures

- MD5WithRSAEncryption, SHA1WithRSAEncryption (also with SHA256
and SHA512 if supported by openSSL, see remark for digests)

- standard DSA with SHA1

MACs

- HMAC (Hashed MACs) with MD{2,4,5}, SHA1 (also SHA256 and SHA512 if
supported by openSSL, see remark for digests), RIPEMD160

- Cipher based MAC for DES (64-bit key) and DESEDE (192-bit Key)

Secret Key Factories

- DES, DESede

- PBEwithSHAand128bitAES-CBC-BC, PBEwithSHAand192bitAES-CBC-BC,
PBEwithSHAand256bitAES-CBC-BC

- PBEwithMD5and128bitAES-CBC-OPENSSL,PBEwithMD5and192bitAES-CBC-OPENSSL,
PBEwithMD5and256bitAES-CBC-OPENSSL

- PBEwithMD5andDES, PBEwithSHA1andDES, PBEwithSHAand3-KeyTripleDES-CBC

- PBEwithMD5andRC2, PBEwithSHA1andRC2 - these use RC2 with 64bit key
PBEwithSHAand128bitRC2, PBEwithSHAand40bitRC2-CBC

- PBEwithSHAand128bitRC4, PBEwithSHAand40bitRC4

NOTE: if you use the Secret Key Factories you must have the
BouncyCastle library on your classpath. While the key generation and
the actual ciphers use OpenSSL functions to get more speed the BC
library is responsible to handle all the ASN.1/PKCS format related
stuff.

Key Pair Generators

- RSA

- DSA

NOTE: Refer to the note on secret key factories - the same applies to
the key pair generators.

Unit tests for all implemented algorithms are available. Please refer
to them to see how to use JuiCE.

Have fun.

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

[JuiCE] Some new features avaliable

2006-02-26T06:08:49Z

All,

the latest version of JuiCE now supports following MAC functions:

- HMAC (Hashed MACs) with MD{2,4,5}, SHA1 (other SHA also
if supported by openSSL, see remark for digests), RIPEMD160

- Cipher based MAC for DES (64-bit key) and DESEDE (192-bit Key)

As usual unit tests are available.

The block cipher algorithms now support a new padding mode
"ZEROBYTEPADDING".

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

Re: Question regaring Password based encryption (PBE)

2006-02-25T01:26:35Z

Berin,

the license of BC is very iberal and allows to copy their code, modify
it etc for any purpose (there is a copy of BC's license in the LICENSE
directory of JuiCE).

This is what I had in mid as well. The key generation uses message
digests (SHA, MD5, ...) to derive the actual key from a given password,
salt, and iteration count. AFAIK this specific algo is not implemented
in OpenSSL. Thus we can use the OpenSSL digest code to generate the
actual key - this link is already implemented in JuiCE.

Regards,
Werner

Berin Lautenbach wrote:

> What's the license for BC, and what's the code that needs to be
> implemented? Is it the actual key generation? If so - might we be
> better off implementing it in the C component of the library and linking
> it more closely with the OpenSSL code?
>
> If the of JuiCE is to implement as much as we can directly around the
> OpenSSL core in C++/C to give us the speed advantage, then my preference
> would be to go down that track.
>
> Cheers,
> Berin
>
> Werner Dittmann wrote:
>
>> All,
>>
>> I started to get PBE up and running in JuiCE. The code modifications
>> in existing code are fairly small because PBE uses the same existing
>> encryption engines (AES, DES, etc.). There are problems remaining:
>> enabling PBE in the existing code requires that we need to copy
>> a fair amount of code from BouncyCastle to be able to handle the
>> password based keys.
>>
>> I've tried to do a "lightwight" implementation but it turned out that
>> this is not possible because not all required methods are "public" in
>> BC thus we cannot access them.
>>
>> As copying over the code and modifing it to run with JuiCE is not a
>> big deal. Would it be ok to use a larger amount of BC code more or
>> less verbatim? According to BC's license it is ok to do so.
>>
>> Regards,
>> Werner
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: juice-dev-unsubscribe@...
>> For additional commands, e-mail: juice-dev-help@...
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juice-dev-unsubscribe@...
> For additional commands, e-mail: juice-dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

Re: Question regaring Password based encryption (PBE)

2006-02-25T00:45:49Z

What's the license for BC, and what's the code that needs to be
implemented? Is it the actual key generation? If so - might we be
better off implementing it in the C component of the library and linking
it more closely with the OpenSSL code?

If the of JuiCE is to implement as much as we can directly around the
OpenSSL core in C++/C to give us the speed advantage, then my preference
would be to go down that track.

Cheers,
Berin

Werner Dittmann wrote:

> All,
>
> I started to get PBE up and running in JuiCE. The code modifications
> in existing code are fairly small because PBE uses the same existing
> encryption engines (AES, DES, etc.). There are problems remaining:
> enabling PBE in the existing code requires that we need to copy
> a fair amount of code from BouncyCastle to be able to handle the
> password based keys.
>
> I've tried to do a "lightwight" implementation but it turned out that
> this is not possible because not all required methods are "public" in
> BC thus we cannot access them.
>
> As copying over the code and modifing it to run with JuiCE is not a
> big deal. Would it be ok to use a larger amount of BC code more or
> less verbatim? According to BC's license it is ok to do so.
>
> Regards,
> Werner
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juice-dev-unsubscribe@...
> For additional commands, e-mail: juice-dev-help@...
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

Question regaring Password based encryption (PBE)

2006-02-25T00:23:24Z

All,

I started to get PBE up and running in JuiCE. The code modifications
in existing code are fairly small because PBE uses the same existing
encryption engines (AES, DES, etc.). There are problems remaining:
enabling PBE in the existing code requires that we need to copy
a fair amount of code from BouncyCastle to be able to handle the
password based keys.

I've tried to do a "lightwight" implementation but it turned out that
this is not possible because not all required methods are "public" in
BC thus we cannot access them.

As copying over the code and modifing it to run with JuiCE is not a
big deal. Would it be ok to use a larger amount of BC code more or
less verbatim? According to BC's license it is ok to do so.

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

Re: AW: AW: Some more JNI questions

2006-02-21T01:57:51Z

Thank the lord for versioning. After mucking it up completely I
eventually got the right code into src. I've also updated Makefile.am,
buildNew.xml (including cleaning the ^Ms in the unix version) and
configure.ac in the appropriate directories to get it to work. It now
seems to compile and test under *NIX.

I'll start doing the Win32 projects tomorrow night.

Cheers,
Berin

Dittmann, Werner wrote:

> No problemns from my side. I just left the old source as
> reference and fall back.
>
> When you do it just give a short notice that I can modify
> the autoconfig stuff (it's just one mod in a Makefile.am).
>
> Regards,
> Werner
>
>
>>-----Ursprüngliche Nachricht-----
>>Von: Berin Lautenbach [mailto:berin@...]
>>Gesendet: Dienstag, 21. Februar 2006 09:04
>>An: juice-dev@...
>>Betreff: Re: AW: Some more JNI questions
>>
>>OK - That makes sense then.
>>
>>So one other (I promise:>) question - can we move everything out of
>>srcNew and into src and delete the stuff in src? (It's still
>>in svn if
>>we want it). Otherwise I'm just going to have to re-setup all the
>>project stuff when we do eventually do the move.
>>
>>Cheers,
>> Berin
>>
>>
>>Dittmann, Werner wrote:
>>
>>>Berin,
>>>
>>>this individual intialization has "historical" reasons
>>>as I started with just one set of algorithms. Then using
>>>"copy&paste" just brought it over to the other classes.
>>>
>>>Yes, putting it in the JuiCEProviderOpenSSL would be a
>>>good idea. Failing to load the lib or failing to for
>>>some other reason would throw the exception at that point
>>>and we can remove these checks from the individual
>>>classes.
>>>
>>>Regards,
>>>Werner
>>>
>>>
>>>
>>>>-----Ursprüngliche Nachricht-----
>>>>Von: Berin Lautenbach [mailto:berin@...]
>>>>Gesendet: Montag, 20. Februar 2006 20:49
>>>>An: juice-dev@...
>>>>Betreff: Some more JNI questions
>>>>
>>>>Werner et al.
>>>>
>>>>Was doing some thinking about initialisation last night.
>>>>
>>>>Is it a requirement that each class separately call
>>>>"System.LoadLibrary()" or might it be possible to do this once in
>>>>JuiCEProviderOpenSSL?
>>>>
>>>>My reason for asking is there are a couple of ways to test what
>>>>algorithms are available in OpenSSL (version dependant). If
>>>>we link to
>>>>the library for the provider initialisation, then unless each class
>>>>needs to do it separately we can remove the code for
>>
>>LoadLibrary from
>>
>>>>each of the other classes.
>>>>
>>>>Cheers,
>>>> Berin
>>>>
>>>>
>>>>------------------------------------------------------------
>>
>>---------
>>
>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>For additional commands, e-mail: juice-dev-help@...
>>>>
>>>>
>>>
>>>
>>>
>>---------------------------------------------------------------------
>>
>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>For additional commands, e-mail: juice-dev-help@...
>>>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>For additional commands, e-mail: juice-dev-help@...
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juice-dev-unsubscribe@...
> For additional commands, e-mail: juice-dev-help@...
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

AW: AW: Some more JNI questions

2006-02-21T00:09:42Z

No problemns from my side. I just left the old source as
reference and fall back.

When you do it just give a short notice that I can modify
the autoconfig stuff (it's just one mod in a Makefile.am).

Regards,
Werner

> -----Ursprüngliche Nachricht-----
> Von: Berin Lautenbach [mailto:berin@...]
> Gesendet: Dienstag, 21. Februar 2006 09:04
> An: juice-dev@...
> Betreff: Re: AW: Some more JNI questions
>
> OK - That makes sense then.
>
> So one other (I promise:>) question - can we move everything out of
> srcNew and into src and delete the stuff in src? (It's still
> in svn if
> we want it). Otherwise I'm just going to have to re-setup all the
> project stuff when we do eventually do the move.
>
> Cheers,
> Berin
>
>
> Dittmann, Werner wrote:
> > Berin,
> >
> > this individual intialization has "historical" reasons
> > as I started with just one set of algorithms. Then using
> > "copy&paste" just brought it over to the other classes.
> >
> > Yes, putting it in the JuiCEProviderOpenSSL would be a
> > good idea. Failing to load the lib or failing to for
> > some other reason would throw the exception at that point
> > and we can remove these checks from the individual
> > classes.
> >
> > Regards,
> > Werner
> >
> >
> >>-----Ursprüngliche Nachricht-----
> >>Von: Berin Lautenbach [mailto:berin@...]
> >>Gesendet: Montag, 20. Februar 2006 20:49
> >>An: juice-dev@...
> >>Betreff: Some more JNI questions
> >>
> >>Werner et al.
> >>
> >>Was doing some thinking about initialisation last night.
> >>
> >>Is it a requirement that each class separately call
> >>"System.LoadLibrary()" or might it be possible to do this once in
> >>JuiCEProviderOpenSSL?
> >>
> >>My reason for asking is there are a couple of ways to test what
> >>algorithms are available in OpenSSL (version dependant). If
> >>we link to
> >>the library for the provider initialisation, then unless each class
> >>needs to do it separately we can remove the code for
> LoadLibrary from
> >>each of the other classes.
> >>
> >>Cheers,
> >> Berin
> >>
> >>
> >>------------------------------------------------------------
> ---------
> >>To unsubscribe, e-mail: juice-dev-unsubscribe@...
> >>For additional commands, e-mail: juice-dev-help@...
> >>
> >>
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: juice-dev-unsubscribe@...
> > For additional commands, e-mail: juice-dev-help@...
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juice-dev-unsubscribe@...
> For additional commands, e-mail: juice-dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

Re: AW: Some more JNI questions

2006-02-21T00:04:00Z

OK - That makes sense then.

So one other (I promise:>) question - can we move everything out of
srcNew and into src and delete the stuff in src? (It's still in svn if
we want it). Otherwise I'm just going to have to re-setup all the
project stuff when we do eventually do the move.

Cheers,
Berin

Dittmann, Werner wrote:

> Berin,
>
> this individual intialization has "historical" reasons
> as I started with just one set of algorithms. Then using
> "copy&paste" just brought it over to the other classes.
>
> Yes, putting it in the JuiCEProviderOpenSSL would be a
> good idea. Failing to load the lib or failing to for
> some other reason would throw the exception at that point
> and we can remove these checks from the individual
> classes.
>
> Regards,
> Werner
>
>
>>-----Ursprüngliche Nachricht-----
>>Von: Berin Lautenbach [mailto:berin@...]
>>Gesendet: Montag, 20. Februar 2006 20:49
>>An: juice-dev@...
>>Betreff: Some more JNI questions
>>
>>Werner et al.
>>
>>Was doing some thinking about initialisation last night.
>>
>>Is it a requirement that each class separately call
>>"System.LoadLibrary()" or might it be possible to do this once in
>>JuiCEProviderOpenSSL?
>>
>>My reason for asking is there are a couple of ways to test what
>>algorithms are available in OpenSSL (version dependant). If
>>we link to
>>the library for the provider initialisation, then unless each class
>>needs to do it separately we can remove the code for LoadLibrary from
>>each of the other classes.
>>
>>Cheers,
>> Berin
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>For additional commands, e-mail: juice-dev-help@...
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juice-dev-unsubscribe@...
> For additional commands, e-mail: juice-dev-help@...
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

AW: Some more JNI questions

2006-02-20T23:09:36Z

Berin,

this individual intialization has "historical" reasons
as I started with just one set of algorithms. Then using
"copy&paste" just brought it over to the other classes.

Yes, putting it in the JuiCEProviderOpenSSL would be a
good idea. Failing to load the lib or failing to for
some other reason would throw the exception at that point
and we can remove these checks from the individual
classes.

Regards,
Werner

> -----Ursprüngliche Nachricht-----
> Von: Berin Lautenbach [mailto:berin@...]
> Gesendet: Montag, 20. Februar 2006 20:49
> An: juice-dev@...
> Betreff: Some more JNI questions
>
> Werner et al.
>
> Was doing some thinking about initialisation last night.
>
> Is it a requirement that each class separately call
> "System.LoadLibrary()" or might it be possible to do this once in
> JuiCEProviderOpenSSL?
>
> My reason for asking is there are a couple of ways to test what
> algorithms are available in OpenSSL (version dependant). If
> we link to
> the library for the provider initialisation, then unless each class
> needs to do it separately we can remove the code for LoadLibrary from
> each of the other classes.
>
> Cheers,
> Berin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juice-dev-unsubscribe@...
> For additional commands, e-mail: juice-dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

AW: [JuiCE] Some information about latest state

2006-02-20T23:04:56Z

Raul,

inserting a provider at poisition zero is not a good idea. I've
tried that with BouncyCastle and that failed. This is due that
the Sun (maybe also IBM) loader that checks the JCE jar signatures
has some "hardwired" dependency on the JCE provider that is on
position zero. Putting on position one may help. On the other
hand we shall IMHO provide some way to explicitly specify a
provider.

I haven't tested if putting e.g. JuiCE at position one always
uses JuiCE for the standard algos like RSA, DSA, AES etc or if
in that case to provider at position zero is selected.

I'll give it a try during the next days.

Regards,
Werner

> -----Ursprüngliche Nachricht-----
> Von: raul.benito.garcia@...
> [mailto:raul.benito.garcia@...] Im Auftrag von Raul Benito
> Gesendet: Montag, 20. Februar 2006 17:26
> An: juice-dev@...
> Betreff: Re: [JuiCE] Some information about latest state
>
> On 2/20/06, Dittmann, Werner <werner.dittmann@...> wrote:
> >
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Scott Cantor [mailto:cantor.2@...]
> > > Gesendet: Montag, 20. Februar 2006 16:13
> > > An: juice-dev@...
> > > Betreff: RE: [JuiCE] Some information about latest state
> > >
> > > > In WSS4J I use the following way to set the provider for
> > > the Signature
> > > > and Hash implementations:
> > > >
> > > > ...
> > > > import org.apache.xml.security.algorithms.JCEMapper;
> > > > ...
> > > > JCEMapper.setProviderId("JuiCE");
> > > >
> > > > This call intializes a static variable in JCEMapper that
> > > the algorithm
> > > > implementations use later on. IMHO there is no way to
> specify the
> > > > provider via config.xml.
> > >
> > > So this is something the code should call during
> initialization of the
> > > servlets, then? And that should route requests for supported
> > > algorithms to
> > > JuiCE?
> > >
> > Yes, in WSS4J we do this very early during intialization.
> At least the
> > RSA algorithm implementation of xml-sec use the provider info of
> > JCEMapper. I've looked into DSA algo implementation but
> this does _not_
> > use it - another incompatibility inside xml-sec (I've tested it with
> > RSA only :-( ).
> >
> I'm one the one to blame for all this things with JCEMapper, sorry...
> I think that the best way is to store register the Juice provider as
> the default provider using
> java.security.Security.insertProviderAt( new .... ,0)
> I think we shall depcretaed JCEMapper
>
> Regards,
>
> Raul
> > I'll dive into the stuff and try to fix it and propose a patch.
> >
> > So, if you test it then only the RSA based signatures will work
> > with JuiCE.
> >
> > Regards,
> > Werner
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: juice-dev-unsubscribe@...
> > For additional commands, e-mail: juice-dev-help@...
> >
> >
>
>
> --
> http://r-bg.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juice-dev-unsubscribe@...
> For additional commands, e-mail: juice-dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

Some more JNI questions

2006-02-20T11:49:19Z

Werner et al.

Was doing some thinking about initialisation last night.

Is it a requirement that each class separately call
"System.LoadLibrary()" or might it be possible to do this once in
JuiCEProviderOpenSSL?

My reason for asking is there are a couple of ways to test what
algorithms are available in OpenSSL (version dependant). If we link to
the library for the provider initialisation, then unless each class
needs to do it separately we can remove the code for LoadLibrary from
each of the other classes.

Cheers,
Berin

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

Re: [JuiCE] Some information about latest state

2006-02-20T08:26:19Z

On 2/20/06, Dittmann, Werner <werner.dittmann@...> wrote:

>
>
> > -----Ursprüngliche Nachricht-----
> > Von: Scott Cantor [mailto:cantor.2@...]
> > Gesendet: Montag, 20. Februar 2006 16:13
> > An: juice-dev@...
> > Betreff: RE: [JuiCE] Some information about latest state
> >
> > > In WSS4J I use the following way to set the provider for
> > the Signature
> > > and Hash implementations:
> > >
> > > ...
> > > import org.apache.xml.security.algorithms.JCEMapper;
> > > ...
> > > JCEMapper.setProviderId("JuiCE");
> > >
> > > This call intializes a static variable in JCEMapper that
> > the algorithm
> > > implementations use later on. IMHO there is no way to specify the
> > > provider via config.xml.
> >
> > So this is something the code should call during initialization of the
> > servlets, then? And that should route requests for supported
> > algorithms to
> > JuiCE?
> >
> Yes, in WSS4J we do this very early during intialization. At least the
> RSA algorithm implementation of xml-sec use the provider info of
> JCEMapper. I've looked into DSA algo implementation but this does _not_
> use it - another incompatibility inside xml-sec (I've tested it with
> RSA only :-( ).
>

I'm one the one to blame for all this things with JCEMapper, sorry...
I think that the best way is to store register the Juice provider as
the default provider using
java.security.Security.insertProviderAt( new .... ,0)
I think we shall depcretaed JCEMapper

Regards,

Raul

> I'll dive into the stuff and try to fix it and propose a patch.
>
> So, if you test it then only the RSA based signatures will work
> with JuiCE.
>
> Regards,
> Werner
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juice-dev-unsubscribe@...
> For additional commands, e-mail: juice-dev-help@...
>
>

--
http://r-bg.com

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

AW: [JuiCE] Some information about latest state

2006-02-20T07:46:21Z

> -----Ursprüngliche Nachricht-----
> Von: Scott Cantor [mailto:cantor.2@...]
> Gesendet: Montag, 20. Februar 2006 16:13
> An: juice-dev@...
> Betreff: RE: [JuiCE] Some information about latest state
>
> > In WSS4J I use the following way to set the provider for
> the Signature
> > and Hash implementations:
> >
> > ...
> > import org.apache.xml.security.algorithms.JCEMapper;
> > ...
> > JCEMapper.setProviderId("JuiCE");
> >
> > This call intializes a static variable in JCEMapper that
> the algorithm
> > implementations use later on. IMHO there is no way to specify the
> > provider via config.xml.
>
> So this is something the code should call during initialization of the
> servlets, then? And that should route requests for supported
> algorithms to
> JuiCE?
>

Yes, in WSS4J we do this very early during intialization. At least the
RSA algorithm implementation of xml-sec use the provider info of
JCEMapper. I've looked into DSA algo implementation but this does _not_
use it - another incompatibility inside xml-sec (I've tested it with
RSA only :-( ).

I'll dive into the stuff and try to fix it and propose a patch.

So, if you test it then only the RSA based signatures will work
with JuiCE.

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

RE: [JuiCE] Some information about latest state

2006-02-20T07:13:25Z

> In WSS4J I use the following way to set the provider for the Signature
> and Hash implementations:
>
> ...
> import org.apache.xml.security.algorithms.JCEMapper;
> ...
> JCEMapper.setProviderId("JuiCE");
>
> This call intializes a static variable in JCEMapper that the algorithm
> implementations use later on. IMHO there is no way to specify the
> provider via config.xml.

So this is something the code should call during initialization of the
servlets, then? And that should route requests for supported algorithms to
JuiCE?

> If your tests use XMLCipher be aware that XMLCipher does _not_ use
> this way but you have to define the provider id using specific
> "getProviderInstance()" calls - long live common programming
> patterns :-).

No encryption in this code yet.

> When you install JuiCE pls have a look into the README.txt, gives some
> ideas how to do it.

Thx.

-- Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

AW: [JuiCE] Some information about latest state

2006-02-20T06:54:14Z

> -----Ursprüngliche Nachricht-----
> Von: Scott Cantor [mailto:cantor.2@...]
> Gesendet: Montag, 20. Februar 2006 15:25
> An: juice-dev@...
> Betreff: RE: [JuiCE] Some information about latest state
>
> > We need some support to have real multi-threading tests
> > of the JuiCE implementation to see if the JuiCE OpenSSL
> > thread locking works on real multi-processor systems
> > (together with the Java part). Does anybody have such a
> > system "at hand" to setup a real thread test?
>
> It would be relatively easy to set up a load test against a
> Shibboleth IdP
> that was using Juice for signing. However, I'd need some
> quick guidance or a
> pointer to such explaining how to drop this into an xmlsec
> application.
>
> To be honest, I've lost track of all the permutations of config.xml in
> xmlsec and how to turn on alternate providers.

In WSS4J I use the following way to set the provider for the Signature
and Hash implementations:

...
import org.apache.xml.security.algorithms.JCEMapper;
...
JCEMapper.setProviderId("JuiCE");

This call intializes a static variable in JCEMapper that the algorithm
implementations use later on. IMHO there is no way to specify the
provider via config.xml.

If your tests use XMLCipher be aware that XMLCipher does _not_ use
this way but you have to define the provider id using specific
"getProviderInstance()" calls - long live common programming patterns :-).

When you install JuiCE pls have a look into the README.txt, gives some
ideas how to do it. If you running on a *nix based system make sure
the native shared lib is contained in you library path, e.g. LD_LIBRARY_PATH

Pls e-mail if you have any questions.

Regards,
Werner

> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juice-dev-unsubscribe@...
> For additional commands, e-mail: juice-dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

RE: [JuiCE] Some information about latest state

2006-02-20T06:24:57Z

> We need some support to have real multi-threading tests
> of the JuiCE implementation to see if the JuiCE OpenSSL
> thread locking works on real multi-processor systems
> (together with the Java part). Does anybody have such a
> system "at hand" to setup a real thread test?

It would be relatively easy to set up a load test against a Shibboleth IdP
that was using Juice for signing. However, I'd need some quick guidance or a
pointer to such explaining how to drop this into an xmlsec application.

To be honest, I've lost track of all the permutations of config.xml in
xmlsec and how to turn on alternate providers.

-- Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

[JuiCE] Some information about latest state

2006-02-20T04:02:28Z

During the last days JuiCE did another step forward.

Thanks to Berin the native part of JuiCE can be built
with VC++ for Windows and is available as DLL. Berin
works on some topics to make it installable.

Using a 64-bit Java 5 (JDK 1.5.0_6) and a 64-bit SuSE
Linux system I was able to create and test a real 64-bit
version of JuiCE.

We need some support to have real multi-threading tests
of the JuiCE implementation to see if the JuiCE OpenSSL
thread locking works on real multi-processor systems
(together with the Java part). Does anybody have such a
system "at hand" to setup a real thread test?

Regards,
Werner

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

Re: AW: Problems to setup Juice with Windows

2006-02-19T04:58:53Z

Berin,

I used Visual C++ Express to test the stuff (without your latest mods of
course) and it also worked fine. Looking forward to see your latest
updates,

Regards,
Werner

Berin Lautenbach wrote:

> Used what you sent me and then updated the jar files - it works
> beautifully now under Windows for a VC 6 debug build. I'll also add the
> files for release, VC 7 and VC 8 over the next couple of days.
>
> Nice!
>
> Cheers,
> Berin
>
> Werner Dittmann wrote:
>
>> Berin,
>>
>> usually I also update a signed jar into JuiCE's dist directory.
>>
>> Regards,
>> Werner
>>
>> Berin Lautenbach wrote:
>>
>>> Werner,
>>>
>>> 1st question - am I able to get a copy of the signing keystore for the
>>> JAR file? I've done some minor mods, but I cannot test.
>>>
>>> I took your changes, cleaned up a couple of minor warnings under VC 6.0
>>> and compiled into a new DLL. Of course I then got JNI errors because my
>>> JAR was still calling the old methods.
>>>
>>> I then went and updated the InitializeOpenSSL.java file. Then
>>> everything broke completely because my JAR is not signed :>.
>>>
>>> So I've checked in the slightly cleaned code, and a new version of the
>>> project file that includes all the files for a debug build. If I am
>>> allowed to get something that allows me to sign the jar that would be
>>> fantastic!
>>>
>>> NOTE - I've *not* checked in my changes to the java code.
>>>
>>> Cheers,
>>> Berin
>>>
>>> Werner Dittmann wrote:
>>>
>>>
>>>> Berin,
>>>>
>>>> after looking into the problem I changed the thread locking to use
>>>> pthreads on Linux and mutexes for Windows. Pls have a look into the
>>>> modifed InitializeOpenSSL.c code. I've tested it for Linux, tetsing
>>>> Windows maybe tomorrow.
>>>>
>>>> Regards,
>>>> Werner
>>>>
>>>> Werner Dittmann wrote:
>>>>
>>>>
>>>>> Berin,
>>>>>
>>>>> thanks for point out the JNIEnv and thread problem - I didn't catch
>>>>> that
>>>>> while reading the JNI docs.
>>>>>
>>>>> Well, The idea to use the Jave thread locking was driven to be fully
>>>>> interoperable with Java threading :-) ... I'm not sure if for example
>>>>> in Linux the pthreads work together with Java. Thus I thought it would
>>>>> be a goo idea to use Java's own thread locking - not I have a
>>>>> backfire.
>>>>>
>>>>> I'm going to think about the problem and see how it can be solved.
>>>>>
>>>>> Regards,
>>>>> Werner
>>>>>
>>>>>
>>>>> Berin Lautenbach wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Been thinking about this more, so am going to display my complete
>>>>>> Java
>>>>>> ignorance to ask some silly questions :>.
>>>>>>
>>>>>> Looking around on the web, I've found that the JNIEnv is thread
>>>>>> unique,
>>>>>> and it is important not to have one thread use a JNIEnv for another
>>>>>> thread.
>>>>>>
>>>>>> However, the way the initialise works is it checks to see if
>>>>>> OPenSSL is
>>>>>> already initialised, if not set the global JNIEnv to be the JNIEnv of
>>>>>> the current thread. Then it never enters again.
>>>>>>
>>>>>> However the thread locking function uses the global JNIEnv, which
>>>>>> means
>>>>>> it doesn't matter what thread calls it, it will always use that
>>>>>> JNIEnv.
>>>>>> That appears on the surface to be incorrect behaviour.
>>>>>>
>>>>>> Have I got this up wrong?
>>>>>>
>>>>>> Also, why do we use the Java thread locking system for OpenSSL?
>>>>>> Is the
>>>>>> normal OpenSSL system inadequate in the Java environment?
>>>>>>
>>>>>> Cheers,
>>>>>> Berin
>>>>>>
>>>>>> Berin Lautenbach wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> OK - I know what's causing it, but my knowledge of JNI is not good
>>>>>>> enough for me to work out the best way to fix it.
>>>>>>>
>>>>>>> enabling -Xcheck:jni on the jvm call showed that the JEnv is being
>>>>>>> called by a non-java thread.
>>>>>>>
>>>>>>> By doing some tracing, I worked out that java_locking_callback is
>>>>>>> being called *after* junit has completed.
>>>>>>>
>>>>>>> My belief is that this is because the OpenSSL library shuts down on
>>>>>>> program exit. Because Java.exe is the program the DLL is hooked to,
>>>>>>> this is happening long after java has shut down the actual java
>>>>>>> environment.
>>>>>>>
>>>>>>> Assuming I'm correct, we need to do one of the following:
>>>>>>>
>>>>>>> 1. Have the provider shut down OpenSSL prior to everything
>>>>>>> finishing.
>>>>>>> 2. Have the program shut down OpenSSL prior to exitting - i.e. user
>>>>>>> responsibility (still need to implement the function to do this)
>>>>>>> 3. Have a check within the java_locking_callback that sees whether
>>>>>>> the JEnv is valid, and doesn't call it if it's not.
>>>>>>>
>>>>>>> Of the options, my favourite is 1 - is there some provider function
>>>>>>> that we can hook into here? Not guaranteed to work, there might be
>>>>>>> some locking calls that OpenSSL has to do on exit that we cannot
>>>>>>> pre-empt.
>>>>>>>
>>>>>>> Option 2 is horrible. Last case only.
>>>>>>>
>>>>>>> Option 3 is not the best, but will work if all else fails. We might
>>>>>>> be able to mix it with Option 1 - i.e. when the provider de-inits,
>>>>>>> call a function that unregisters the locking function in OpenSSL.
>>>>>>>
>>>>>>> Open to thoughts. Happy to do the implementation, but as I said,
>>>>>>> not
>>>>>>> enough of a JNI or provider expert to know which is the best option.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Berin
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Dittmann, Werner wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Berin,
>>>>>>>>
>>>>>>>> thanks for the setup of the VC 6.0 project. After downloading
>>>>>>>> a Visual C++ Express environment (MS provides that free of
>>>>>>>> charge for everybody :-) ) plus the Platform SDK, thus installing
>>>>>>>> about 2GB of MS development environment I was able to build
>>>>>>>> the openSSL4Java.dll starting with your project files.
>>>>>>>>
>>>>>>>> Running the same test results in the same error. The Package
>>>>>>>> test terminated after 23 tests (I added 2 more tests for
>>>>>>>> SecureRandom).
>>>>>>>> The result was a memory access violation.
>>>>>>>> The I started a standalone test with the same result - but only
>>>>>>>> after
>>>>>>>> all tests were done. This made me believe it has something to do
>>>>>>>> with
>>>>>>>> process termination. Just as a simple test I added a System.exit(0)
>>>>>>>> call as the last line of the Package.java main method - and voila
>>>>>>>> - no
>>>>>>>> more memory access error.
>>>>>>>>
>>>>>>>> As an additional test I forced one unit test to fail - also this
>>>>>>>> works as expected: it reports the failures and terminates without
>>>>>>>> memory access violation (after System.exit(0) was added.
>>>>>>>>
>>>>>>>> Because Java starts some threads internaly and tries to terminate
>>>>>>>> them in an orderly fashion - could it a threading problem?
>>>>>>>>
>>>>>>>> I just updated package.java and OpenSSLTestBlock.java to call
>>>>>>>> System.exit(0). IMHO we should try to drill down on the problem.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Werner
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> -----Ursprüngliche Nachricht-----
>>>>>>>>> Von: Berin Lautenbach [mailto:berin@...] Gesendet:
>>>>>>>>> Mittwoch, 15. Februar 2006 11:30
>>>>>>>>> An: juice-dev@...
>>>>>>>>> Betreff: Re: AW: AW: Problems to setup Juice with Windows
>>>>>>>>>
>>>>>>>>> The autogen problem was me Debian installing automake 1.4 by
>>>>>>>>> default(!) Once I had 1.9 everything was cool.
>>>>>>>>>
>>>>>>>>> I have imported a *very* basic debug build for VC 6.0 into the
>>>>>>>>> repo.
>>>>>>>>> There are some interesting complile time messages that I will look
>>>>>>>>> at, but I get 21 tests run successfully before I get a rather
>>>>>>>>> nasty
>>>>>>>>> memory access violation. I'll sort that one out in a few days as
>>>>>>>>> well :>.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Berin
>>>>>>>>>
>>>>>>>>> Dittmann, Werner wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Berin,
>>>>>>>>>>
>>>>>>>>>> this project file is for the old juice native software. Pls
>>>>>>>>>> be informed that I introduced a new setup for Juice.
>>>>>>>>>>
>>>>>>>>>> The autoconf under Linux should simply work. Have a look
>>>>>>>>>> the the configure.ac and tha Makefile.am files, but running
>>>>>>>>>> ./configure should work (if zou download the GZ file), otherwise
>>>>>>>>>> just run the autogen.sh script. This creates all necessary
>>>>>>>>>> files and runs ./configure. After "make" the shared lib
>>>>>>>>>> is in srcNew/.libs.
>>>>>>>>>>
>>>>>>>>>> Don't forget to set LD_LIBRARY_PATH correctly for the test
>>>>>>>>>> cases.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Werner
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> -----Ursprüngliche Nachricht-----
>>>>>>>>>>> Von: Berin Lautenbach [mailto:berin@...] Gesendet:
>>>>>>>>>>> Dienstag, 14. Februar 2006 10:27
>>>>>>>>>>> An: juice-dev@...
>>>>>>>>>>> Betreff: Re: AW: Problems to setup Juice with Windows
>>>>>>>>>>>
>>>>>>>>>>> Just started having a look. Is see there is already a project
>>>>>>>>>>> file for VC++ 6.0 in the old source directory. I'll set up
>>>>>>>>>>> something in the "standard" "Projects/..." folder structure
>>>>>>>>>>> to get
>>>>>>>>>>> it going.
>>>>>>>>>>>
>>>>>>>>>>> But first I'll get it running under Linux to see how it should
>>>>>>>>>>> work :>. Having an interesting time getting it to autoconf, but
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'll work it
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> out tomorrow night.
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Berin
>>>>>>>>>>>
>>>>>>>>>>> Dittmann, Werner wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Berin,
>>>>>>>>>>>>
>>>>>>>>>>>> sureI'm open to that.
>>>>>>>>>>>> The whole native stuff is in plain C, just 5 modules
>>>>>>>>>>>> in C plus the headers. IMHO I don't use any stuff
>>>>>>>>>>>> that is Linux specific.
>>>>>>>>>>>>
>>>>>>>>>>>> The only prerequistite is the availabilty of the openSSL
>>>>>>>>>>>> headers and crypto lib.
>>>>>>>>>>>>
>>>>>>>>>>>> You can find the sources in incubator/juice/native/srcNew.
>>>>>>>>>>>>
>>>>>>>>>>>> If you have ides/questions just send a mail.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Werner
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> -----Ursprüngliche Nachricht-----
>>>>>>>>>>>>> Von: Berin Lautenbach [mailto:berin@...]
>>>>>>>>>>>>> Gesendet:
>>>>>>>>>>>>> Dienstag, 14. Februar 2006 09:28
>>>>>>>>>>>>> An: juice-dev@...
>>>>>>>>>>>>> Betreff: Re: Problems to setup Juice with Windows
>>>>>>>>>>>>>
>>>>>>>>>>>>> Having played with getting things running under Cygwin - I
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> think I'd
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> tend to agree with Scott. It adds some extra complications
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> into the
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> build/run process that could well trip you up.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Is it possible to get the stuff to compile on VC++? Are you
>>>>>>>>>>>>> open for me to have a look to see if I can get it up and
>>>>>>>>>>>>> running?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Berin
>>>>>>>>>>>>>
>>>>>>>>>>>>> Scott Cantor wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - using cygwin I was able to setup the autoconf stuff,
>>>>>>>>>>>>>>> create a
>>>>>>>>>>>>>>> configure script, and compiled the native sources into a
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> DLL. Before
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> the compile was sucessful I copied the files "jni.h" and
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> "jni_md.h"
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> from the Java include directory to /usr/include of
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> cygwin. Then I
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>>> changed the "typedef __int64 jlong" to "typedef long
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> long jint" to
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>>> be compliant with gcc.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Is cygwin the way people would want to use this? I somehow
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> doubt it. Most
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> people on Windows don't wish to pull in the cygwin DLLs,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> they want proper
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Windows builds.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Any ideas? Any help is appreciated.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regardless of the previous point, is there actual proof
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> that the JVM can
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> load native code built with cygwin? Maybe it just works,
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> but I'd try and
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> verify that independently before I went looking for root
>>>>>>>>>>>>>> causes.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -- Scott
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>>> juice-dev-help@...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>>>>>>>> For additional commands, e-mail: juice-dev-help@...
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>>>>>>> For additional commands, e-mail: juice-dev-help@...
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>>>>>> For additional commands, e-mail: juice-dev-help@...
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>>>>> For additional commands, e-mail: juice-dev-help@...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>>>> For additional commands, e-mail: juice-dev-help@...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>>> For additional commands, e-mail: juice-dev-help@...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>> For additional commands, e-mail: juice-dev-help@...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>> For additional commands, e-mail: juice-dev-help@...
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>> For additional commands, e-mail: juice-dev-help@...
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>> For additional commands, e-mail: juice-dev-help@...
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>> For additional commands, e-mail: juice-dev-help@...
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: juice-dev-unsubscribe@...
>> For additional commands, e-mail: juice-dev-help@...
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juice-dev-unsubscribe@...
> For additional commands, e-mail: juice-dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

Re: AW: Problems to setup Juice with Windows

2006-02-19T03:27:38Z

Used what you sent me and then updated the jar files - it works
beautifully now under Windows for a VC 6 debug build. I'll also add the
files for release, VC 7 and VC 8 over the next couple of days.

Nice!

Cheers,
Berin

Werner Dittmann wrote:

> Berin,
>
> usually I also update a signed jar into JuiCE's dist directory.
>
> Regards,
> Werner
>
> Berin Lautenbach wrote:
>
>>Werner,
>>
>>1st question - am I able to get a copy of the signing keystore for the
>>JAR file? I've done some minor mods, but I cannot test.
>>
>>I took your changes, cleaned up a couple of minor warnings under VC 6.0
>>and compiled into a new DLL. Of course I then got JNI errors because my
>>JAR was still calling the old methods.
>>
>>I then went and updated the InitializeOpenSSL.java file. Then
>>everything broke completely because my JAR is not signed :>.
>>
>>So I've checked in the slightly cleaned code, and a new version of the
>>project file that includes all the files for a debug build. If I am
>>allowed to get something that allows me to sign the jar that would be
>>fantastic!
>>
>>NOTE - I've *not* checked in my changes to the java code.
>>
>>Cheers,
>> Berin
>>
>>Werner Dittmann wrote:
>>
>>
>>>Berin,
>>>
>>>after looking into the problem I changed the thread locking to use
>>>pthreads on Linux and mutexes for Windows. Pls have a look into the
>>>modifed InitializeOpenSSL.c code. I've tested it for Linux, tetsing
>>>Windows maybe tomorrow.
>>>
>>>Regards,
>>>Werner
>>>
>>>Werner Dittmann wrote:
>>>
>>>
>>>>Berin,
>>>>
>>>>thanks for point out the JNIEnv and thread problem - I didn't catch that
>>>>while reading the JNI docs.
>>>>
>>>>Well, The idea to use the Jave thread locking was driven to be fully
>>>>interoperable with Java threading :-) ... I'm not sure if for example
>>>>in Linux the pthreads work together with Java. Thus I thought it would
>>>>be a goo idea to use Java's own thread locking - not I have a backfire.
>>>>
>>>>I'm going to think about the problem and see how it can be solved.
>>>>
>>>>Regards,
>>>>Werner
>>>>
>>>>
>>>>Berin Lautenbach wrote:
>>>>
>>>>
>>>>
>>>>>Been thinking about this more, so am going to display my complete Java
>>>>>ignorance to ask some silly questions :>.
>>>>>
>>>>>Looking around on the web, I've found that the JNIEnv is thread unique,
>>>>>and it is important not to have one thread use a JNIEnv for another
>>>>>thread.
>>>>>
>>>>>However, the way the initialise works is it checks to see if OPenSSL is
>>>>>already initialised, if not set the global JNIEnv to be the JNIEnv of
>>>>>the current thread. Then it never enters again.
>>>>>
>>>>>However the thread locking function uses the global JNIEnv, which means
>>>>>it doesn't matter what thread calls it, it will always use that JNIEnv.
>>>>>That appears on the surface to be incorrect behaviour.
>>>>>
>>>>>Have I got this up wrong?
>>>>>
>>>>>Also, why do we use the Java thread locking system for OpenSSL? Is the
>>>>>normal OpenSSL system inadequate in the Java environment?
>>>>>
>>>>>Cheers,
>>>>> Berin
>>>>>
>>>>>Berin Lautenbach wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>OK - I know what's causing it, but my knowledge of JNI is not good
>>>>>>enough for me to work out the best way to fix it.
>>>>>>
>>>>>>enabling -Xcheck:jni on the jvm call showed that the JEnv is being
>>>>>>called by a non-java thread.
>>>>>>
>>>>>>By doing some tracing, I worked out that java_locking_callback is
>>>>>>being called *after* junit has completed.
>>>>>>
>>>>>>My belief is that this is because the OpenSSL library shuts down on
>>>>>>program exit. Because Java.exe is the program the DLL is hooked to,
>>>>>>this is happening long after java has shut down the actual java
>>>>>>environment.
>>>>>>
>>>>>>Assuming I'm correct, we need to do one of the following:
>>>>>>
>>>>>>1. Have the provider shut down OpenSSL prior to everything finishing.
>>>>>>2. Have the program shut down OpenSSL prior to exitting - i.e. user
>>>>>>responsibility (still need to implement the function to do this)
>>>>>>3. Have a check within the java_locking_callback that sees whether
>>>>>>the JEnv is valid, and doesn't call it if it's not.
>>>>>>
>>>>>>Of the options, my favourite is 1 - is there some provider function
>>>>>>that we can hook into here? Not guaranteed to work, there might be
>>>>>>some locking calls that OpenSSL has to do on exit that we cannot
>>>>>>pre-empt.
>>>>>>
>>>>>>Option 2 is horrible. Last case only.
>>>>>>
>>>>>>Option 3 is not the best, but will work if all else fails. We might
>>>>>>be able to mix it with Option 1 - i.e. when the provider de-inits,
>>>>>>call a function that unregisters the locking function in OpenSSL.
>>>>>>
>>>>>>Open to thoughts. Happy to do the implementation, but as I said, not
>>>>>>enough of a JNI or provider expert to know which is the best option.
>>>>>>
>>>>>>Cheers,
>>>>>> Berin
>>>>>>
>>>>>>
>>>>>>
>>>>>>Dittmann, Werner wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Berin,
>>>>>>>
>>>>>>>thanks for the setup of the VC 6.0 project. After downloading
>>>>>>>a Visual C++ Express environment (MS provides that free of
>>>>>>>charge for everybody :-) ) plus the Platform SDK, thus installing
>>>>>>>about 2GB of MS development environment I was able to build
>>>>>>>the openSSL4Java.dll starting with your project files.
>>>>>>>
>>>>>>>Running the same test results in the same error. The Package
>>>>>>>test terminated after 23 tests (I added 2 more tests for
>>>>>>>SecureRandom).
>>>>>>>The result was a memory access violation.
>>>>>>>The I started a standalone test with the same result - but only after
>>>>>>>all tests were done. This made me believe it has something to do with
>>>>>>>process termination. Just as a simple test I added a System.exit(0)
>>>>>>>call as the last line of the Package.java main method - and voila
>>>>>>>- no
>>>>>>>more memory access error.
>>>>>>>
>>>>>>>As an additional test I forced one unit test to fail - also this
>>>>>>>works as expected: it reports the failures and terminates without
>>>>>>>memory access violation (after System.exit(0) was added.
>>>>>>>
>>>>>>>Because Java starts some threads internaly and tries to terminate
>>>>>>>them in an orderly fashion - could it a threading problem?
>>>>>>>
>>>>>>>I just updated package.java and OpenSSLTestBlock.java to call
>>>>>>>System.exit(0). IMHO we should try to drill down on the problem.
>>>>>>>
>>>>>>>Regards,
>>>>>>>Werner
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>-----Ursprüngliche Nachricht-----
>>>>>>>>Von: Berin Lautenbach [mailto:berin@...] Gesendet:
>>>>>>>>Mittwoch, 15. Februar 2006 11:30
>>>>>>>>An: juice-dev@...
>>>>>>>>Betreff: Re: AW: AW: Problems to setup Juice with Windows
>>>>>>>>
>>>>>>>>The autogen problem was me Debian installing automake 1.4 by
>>>>>>>>default(!) Once I had 1.9 everything was cool.
>>>>>>>>
>>>>>>>>I have imported a *very* basic debug build for VC 6.0 into the repo.
>>>>>>>>There are some interesting complile time messages that I will look
>>>>>>>>at, but I get 21 tests run successfully before I get a rather nasty
>>>>>>>>memory access violation. I'll sort that one out in a few days as
>>>>>>>>well :>.
>>>>>>>>
>>>>>>>>Cheers,
>>>>>>>> Berin
>>>>>>>>
>>>>>>>>Dittmann, Werner wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Berin,
>>>>>>>>>
>>>>>>>>>this project file is for the old juice native software. Pls
>>>>>>>>>be informed that I introduced a new setup for Juice.
>>>>>>>>>
>>>>>>>>>The autoconf under Linux should simply work. Have a look
>>>>>>>>>the the configure.ac and tha Makefile.am files, but running
>>>>>>>>>./configure should work (if zou download the GZ file), otherwise
>>>>>>>>>just run the autogen.sh script. This creates all necessary
>>>>>>>>>files and runs ./configure. After "make" the shared lib
>>>>>>>>>is in srcNew/.libs.
>>>>>>>>>
>>>>>>>>>Don't forget to set LD_LIBRARY_PATH correctly for the test
>>>>>>>>>cases.
>>>>>>>>>
>>>>>>>>>Regards,
>>>>>>>>>Werner
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>-----Ursprüngliche Nachricht-----
>>>>>>>>>>Von: Berin Lautenbach [mailto:berin@...] Gesendet:
>>>>>>>>>>Dienstag, 14. Februar 2006 10:27
>>>>>>>>>>An: juice-dev@...
>>>>>>>>>>Betreff: Re: AW: Problems to setup Juice with Windows
>>>>>>>>>>
>>>>>>>>>>Just started having a look. Is see there is already a project
>>>>>>>>>>file for VC++ 6.0 in the old source directory. I'll set up
>>>>>>>>>>something in the "standard" "Projects/..." folder structure to get
>>>>>>>>>>it going.
>>>>>>>>>>
>>>>>>>>>>But first I'll get it running under Linux to see how it should
>>>>>>>>>>work :>. Having an interesting time getting it to autoconf, but
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>I'll work it
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>out tomorrow night.
>>>>>>>>>>
>>>>>>>>>>Cheers,
>>>>>>>>>> Berin
>>>>>>>>>>
>>>>>>>>>>Dittmann, Werner wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>Berin,
>>>>>>>>>>>
>>>>>>>>>>>sureI'm open to that.
>>>>>>>>>>>The whole native stuff is in plain C, just 5 modules
>>>>>>>>>>>in C plus the headers. IMHO I don't use any stuff
>>>>>>>>>>>that is Linux specific.
>>>>>>>>>>>
>>>>>>>>>>>The only prerequistite is the availabilty of the openSSL
>>>>>>>>>>>headers and crypto lib.
>>>>>>>>>>>
>>>>>>>>>>>You can find the sources in incubator/juice/native/srcNew.
>>>>>>>>>>>
>>>>>>>>>>>If you have ides/questions just send a mail.
>>>>>>>>>>>
>>>>>>>>>>>Regards,
>>>>>>>>>>>Werner
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>-----Ursprüngliche Nachricht-----
>>>>>>>>>>>>Von: Berin Lautenbach [mailto:berin@...] Gesendet:
>>>>>>>>>>>>Dienstag, 14. Februar 2006 09:28
>>>>>>>>>>>>An: juice-dev@...
>>>>>>>>>>>>Betreff: Re: Problems to setup Juice with Windows
>>>>>>>>>>>>
>>>>>>>>>>>>Having played with getting things running under Cygwin - I
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>think I'd
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>tend to agree with Scott. It adds some extra complications
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>into the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>build/run process that could well trip you up.
>>>>>>>>>>>>
>>>>>>>>>>>>Is it possible to get the stuff to compile on VC++? Are you
>>>>>>>>>>>>open for me to have a look to see if I can get it up and
>>>>>>>>>>>>running?
>>>>>>>>>>>>
>>>>>>>>>>>>Cheers,
>>>>>>>>>>>> Berin
>>>>>>>>>>>>
>>>>>>>>>>>>Scott Cantor wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>- using cygwin I was able to setup the autoconf stuff,
>>>>>>>>>>>>>>create a
>>>>>>>>>>>>>>configure script, and compiled the native sources into a
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>DLL. Before
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>the compile was sucessful I copied the files "jni.h" and
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>"jni_md.h"
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>from the Java include directory to /usr/include of
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>cygwin. Then I
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>>>changed the "typedef __int64 jlong" to "typedef long
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>long jint" to
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>be compliant with gcc.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>Is cygwin the way people would want to use this? I somehow
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>doubt it. Most
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>people on Windows don't wish to pull in the cygwin DLLs,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>they want proper
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>Windows builds.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>Any ideas? Any help is appreciated.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>Regardless of the previous point, is there actual proof
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>that the JVM can
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>load native code built with cygwin? Maybe it just works,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>but I'd try and
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>verify that independently before I went looking for root
>>>>>>>>>>>>>causes.
>>>>>>>>>>>>>
>>>>>>>>>>>>>-- Scott
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>---------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>>>>>>>>For additional commands, e-mail: juice-dev-help@...
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>---------
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>>>>>>>For additional commands, e-mail: juice-dev-help@...
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>---------
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>>>>>>For additional commands, e-mail: juice-dev-help@...
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>---------
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>>>>>For additional commands, e-mail: juice-dev-help@...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>---------------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>>>>For additional commands, e-mail: juice-dev-help@...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>---------------------------------------------------------------------
>>>>>>>>
>>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>>>For additional commands, e-mail: juice-dev-help@...
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>---------------------------------------------------------------------
>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>>For additional commands, e-mail: juice-dev-help@...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>For additional commands, e-mail: juice-dev-help@...
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>For additional commands, e-mail: juice-dev-help@...
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>For additional commands, e-mail: juice-dev-help@...
>>>>
>>>>
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>For additional commands, e-mail: juice-dev-help@...
>>>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>For additional commands, e-mail: juice-dev-help@...
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juice-dev-unsubscribe@...
> For additional commands, e-mail: juice-dev-help@...
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

Re: AW: Problems to setup Juice with Windows

2006-02-19T03:02:42Z

Berin,

usually I also update a signed jar into JuiCE's dist directory.

Regards,
Werner

Berin Lautenbach wrote:

> Werner,
>
> 1st question - am I able to get a copy of the signing keystore for the
> JAR file? I've done some minor mods, but I cannot test.
>
> I took your changes, cleaned up a couple of minor warnings under VC 6.0
> and compiled into a new DLL. Of course I then got JNI errors because my
> JAR was still calling the old methods.
>
> I then went and updated the InitializeOpenSSL.java file. Then
> everything broke completely because my JAR is not signed :>.
>
> So I've checked in the slightly cleaned code, and a new version of the
> project file that includes all the files for a debug build. If I am
> allowed to get something that allows me to sign the jar that would be
> fantastic!
>
> NOTE - I've *not* checked in my changes to the java code.
>
> Cheers,
> Berin
>
> Werner Dittmann wrote:
>
>> Berin,
>>
>> after looking into the problem I changed the thread locking to use
>> pthreads on Linux and mutexes for Windows. Pls have a look into the
>> modifed InitializeOpenSSL.c code. I've tested it for Linux, tetsing
>> Windows maybe tomorrow.
>>
>> Regards,
>> Werner
>>
>> Werner Dittmann wrote:
>>
>>> Berin,
>>>
>>> thanks for point out the JNIEnv and thread problem - I didn't catch that
>>> while reading the JNI docs.
>>>
>>> Well, The idea to use the Jave thread locking was driven to be fully
>>> interoperable with Java threading :-) ... I'm not sure if for example
>>> in Linux the pthreads work together with Java. Thus I thought it would
>>> be a goo idea to use Java's own thread locking - not I have a backfire.
>>>
>>> I'm going to think about the problem and see how it can be solved.
>>>
>>> Regards,
>>> Werner
>>>
>>>
>>> Berin Lautenbach wrote:
>>>
>>>
>>>> Been thinking about this more, so am going to display my complete Java
>>>> ignorance to ask some silly questions :>.
>>>>
>>>> Looking around on the web, I've found that the JNIEnv is thread unique,
>>>> and it is important not to have one thread use a JNIEnv for another
>>>> thread.
>>>>
>>>> However, the way the initialise works is it checks to see if OPenSSL is
>>>> already initialised, if not set the global JNIEnv to be the JNIEnv of
>>>> the current thread. Then it never enters again.
>>>>
>>>> However the thread locking function uses the global JNIEnv, which means
>>>> it doesn't matter what thread calls it, it will always use that JNIEnv.
>>>> That appears on the surface to be incorrect behaviour.
>>>>
>>>> Have I got this up wrong?
>>>>
>>>> Also, why do we use the Java thread locking system for OpenSSL? Is the
>>>> normal OpenSSL system inadequate in the Java environment?
>>>>
>>>> Cheers,
>>>> Berin
>>>>
>>>> Berin Lautenbach wrote:
>>>>
>>>>
>>>>
>>>>> OK - I know what's causing it, but my knowledge of JNI is not good
>>>>> enough for me to work out the best way to fix it.
>>>>>
>>>>> enabling -Xcheck:jni on the jvm call showed that the JEnv is being
>>>>> called by a non-java thread.
>>>>>
>>>>> By doing some tracing, I worked out that java_locking_callback is
>>>>> being called *after* junit has completed.
>>>>>
>>>>> My belief is that this is because the OpenSSL library shuts down on
>>>>> program exit. Because Java.exe is the program the DLL is hooked to,
>>>>> this is happening long after java has shut down the actual java
>>>>> environment.
>>>>>
>>>>> Assuming I'm correct, we need to do one of the following:
>>>>>
>>>>> 1. Have the provider shut down OpenSSL prior to everything finishing.
>>>>> 2. Have the program shut down OpenSSL prior to exitting - i.e. user
>>>>> responsibility (still need to implement the function to do this)
>>>>> 3. Have a check within the java_locking_callback that sees whether
>>>>> the JEnv is valid, and doesn't call it if it's not.
>>>>>
>>>>> Of the options, my favourite is 1 - is there some provider function
>>>>> that we can hook into here? Not guaranteed to work, there might be
>>>>> some locking calls that OpenSSL has to do on exit that we cannot
>>>>> pre-empt.
>>>>>
>>>>> Option 2 is horrible. Last case only.
>>>>>
>>>>> Option 3 is not the best, but will work if all else fails. We might
>>>>> be able to mix it with Option 1 - i.e. when the provider de-inits,
>>>>> call a function that unregisters the locking function in OpenSSL.
>>>>>
>>>>> Open to thoughts. Happy to do the implementation, but as I said, not
>>>>> enough of a JNI or provider expert to know which is the best option.
>>>>>
>>>>> Cheers,
>>>>> Berin
>>>>>
>>>>>
>>>>>
>>>>> Dittmann, Werner wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Berin,
>>>>>>
>>>>>> thanks for the setup of the VC 6.0 project. After downloading
>>>>>> a Visual C++ Express environment (MS provides that free of
>>>>>> charge for everybody :-) ) plus the Platform SDK, thus installing
>>>>>> about 2GB of MS development environment I was able to build
>>>>>> the openSSL4Java.dll starting with your project files.
>>>>>>
>>>>>> Running the same test results in the same error. The Package
>>>>>> test terminated after 23 tests (I added 2 more tests for
>>>>>> SecureRandom).
>>>>>> The result was a memory access violation.
>>>>>> The I started a standalone test with the same result - but only after
>>>>>> all tests were done. This made me believe it has something to do with
>>>>>> process termination. Just as a simple test I added a System.exit(0)
>>>>>> call as the last line of the Package.java main method - and voila
>>>>>> - no
>>>>>> more memory access error.
>>>>>>
>>>>>> As an additional test I forced one unit test to fail - also this
>>>>>> works as expected: it reports the failures and terminates without
>>>>>> memory access violation (after System.exit(0) was added.
>>>>>>
>>>>>> Because Java starts some threads internaly and tries to terminate
>>>>>> them in an orderly fashion - could it a threading problem?
>>>>>>
>>>>>> I just updated package.java and OpenSSLTestBlock.java to call
>>>>>> System.exit(0). IMHO we should try to drill down on the problem.
>>>>>>
>>>>>> Regards,
>>>>>> Werner
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> -----Ursprüngliche Nachricht-----
>>>>>>> Von: Berin Lautenbach [mailto:berin@...] Gesendet:
>>>>>>> Mittwoch, 15. Februar 2006 11:30
>>>>>>> An: juice-dev@...
>>>>>>> Betreff: Re: AW: AW: Problems to setup Juice with Windows
>>>>>>>
>>>>>>> The autogen problem was me Debian installing automake 1.4 by
>>>>>>> default(!) Once I had 1.9 everything was cool.
>>>>>>>
>>>>>>> I have imported a *very* basic debug build for VC 6.0 into the repo.
>>>>>>> There are some interesting complile time messages that I will look
>>>>>>> at, but I get 21 tests run successfully before I get a rather nasty
>>>>>>> memory access violation. I'll sort that one out in a few days as
>>>>>>> well :>.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Berin
>>>>>>>
>>>>>>> Dittmann, Werner wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Berin,
>>>>>>>>
>>>>>>>> this project file is for the old juice native software. Pls
>>>>>>>> be informed that I introduced a new setup for Juice.
>>>>>>>>
>>>>>>>> The autoconf under Linux should simply work. Have a look
>>>>>>>> the the configure.ac and tha Makefile.am files, but running
>>>>>>>> ./configure should work (if zou download the GZ file), otherwise
>>>>>>>> just run the autogen.sh script. This creates all necessary
>>>>>>>> files and runs ./configure. After "make" the shared lib
>>>>>>>> is in srcNew/.libs.
>>>>>>>>
>>>>>>>> Don't forget to set LD_LIBRARY_PATH correctly for the test
>>>>>>>> cases.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Werner
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> -----Ursprüngliche Nachricht-----
>>>>>>>>> Von: Berin Lautenbach [mailto:berin@...] Gesendet:
>>>>>>>>> Dienstag, 14. Februar 2006 10:27
>>>>>>>>> An: juice-dev@...
>>>>>>>>> Betreff: Re: AW: Problems to setup Juice with Windows
>>>>>>>>>
>>>>>>>>> Just started having a look. Is see there is already a project
>>>>>>>>> file for VC++ 6.0 in the old source directory. I'll set up
>>>>>>>>> something in the "standard" "Projects/..." folder structure to get
>>>>>>>>> it going.
>>>>>>>>>
>>>>>>>>> But first I'll get it running under Linux to see how it should
>>>>>>>>> work :>. Having an interesting time getting it to autoconf, but
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I'll work it
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> out tomorrow night.
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Berin
>>>>>>>>>
>>>>>>>>> Dittmann, Werner wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Berin,
>>>>>>>>>>
>>>>>>>>>> sureI'm open to that.
>>>>>>>>>> The whole native stuff is in plain C, just 5 modules
>>>>>>>>>> in C plus the headers. IMHO I don't use any stuff
>>>>>>>>>> that is Linux specific.
>>>>>>>>>>
>>>>>>>>>> The only prerequistite is the availabilty of the openSSL
>>>>>>>>>> headers and crypto lib.
>>>>>>>>>>
>>>>>>>>>> You can find the sources in incubator/juice/native/srcNew.
>>>>>>>>>>
>>>>>>>>>> If you have ides/questions just send a mail.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Werner
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> -----Ursprüngliche Nachricht-----
>>>>>>>>>>> Von: Berin Lautenbach [mailto:berin@...] Gesendet:
>>>>>>>>>>> Dienstag, 14. Februar 2006 09:28
>>>>>>>>>>> An: juice-dev@...
>>>>>>>>>>> Betreff: Re: Problems to setup Juice with Windows
>>>>>>>>>>>
>>>>>>>>>>> Having played with getting things running under Cygwin - I
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> think I'd
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> tend to agree with Scott. It adds some extra complications
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> into the
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> build/run process that could well trip you up.
>>>>>>>>>>>
>>>>>>>>>>> Is it possible to get the stuff to compile on VC++? Are you
>>>>>>>>>>> open for me to have a look to see if I can get it up and
>>>>>>>>>>> running?
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Berin
>>>>>>>>>>>
>>>>>>>>>>> Scott Cantor wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> - using cygwin I was able to setup the autoconf stuff,
>>>>>>>>>>>>> create a
>>>>>>>>>>>>> configure script, and compiled the native sources into a
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> DLL. Before
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> the compile was sucessful I copied the files "jni.h" and
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> "jni_md.h"
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> from the Java include directory to /usr/include of
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> cygwin. Then I
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>>> changed the "typedef __int64 jlong" to "typedef long
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> long jint" to
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>> be compliant with gcc.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Is cygwin the way people would want to use this? I somehow
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> doubt it. Most
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> people on Windows don't wish to pull in the cygwin DLLs,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> they want proper
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Windows builds.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Any ideas? Any help is appreciated.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Regardless of the previous point, is there actual proof
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> that the JVM can
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> load native code built with cygwin? Maybe it just works,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> but I'd try and
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> verify that independently before I went looking for root
>>>>>>>>>>>> causes.
>>>>>>>>>>>>
>>>>>>>>>>>> -- Scott
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>>>>>>> For additional commands, e-mail: juice-dev-help@...
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>>>>>> For additional commands, e-mail: juice-dev-help@...
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>>>>> For additional commands, e-mail: juice-dev-help@...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>>>> For additional commands, e-mail: juice-dev-help@...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>>> For additional commands, e-mail: juice-dev-help@...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>> For additional commands, e-mail: juice-dev-help@...
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>> For additional commands, e-mail: juice-dev-help@...
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>> For additional commands, e-mail: juice-dev-help@...
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>> For additional commands, e-mail: juice-dev-help@...
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>> For additional commands, e-mail: juice-dev-help@...
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: juice-dev-unsubscribe@...
>> For additional commands, e-mail: juice-dev-help@...
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juice-dev-unsubscribe@...
> For additional commands, e-mail: juice-dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

Re: AW: Problems to setup Juice with Windows

2006-02-18T16:12:31Z

Werner,

1st question - am I able to get a copy of the signing keystore for the
JAR file? I've done some minor mods, but I cannot test.

I took your changes, cleaned up a couple of minor warnings under VC 6.0
and compiled into a new DLL. Of course I then got JNI errors because my
JAR was still calling the old methods.

I then went and updated the InitializeOpenSSL.java file. Then
everything broke completely because my JAR is not signed :>.

So I've checked in the slightly cleaned code, and a new version of the
project file that includes all the files for a debug build. If I am
allowed to get something that allows me to sign the jar that would be
fantastic!

NOTE - I've *not* checked in my changes to the java code.

Cheers,
Berin

Werner Dittmann wrote:

> Berin,
>
> after looking into the problem I changed the thread locking to use
> pthreads on Linux and mutexes for Windows. Pls have a look into the
> modifed InitializeOpenSSL.c code. I've tested it for Linux, tetsing
> Windows maybe tomorrow.
>
> Regards,
> Werner
>
> Werner Dittmann wrote:
>
>>Berin,
>>
>>thanks for point out the JNIEnv and thread problem - I didn't catch that
>>while reading the JNI docs.
>>
>>Well, The idea to use the Jave thread locking was driven to be fully
>>interoperable with Java threading :-) ... I'm not sure if for example
>>in Linux the pthreads work together with Java. Thus I thought it would
>>be a goo idea to use Java's own thread locking - not I have a backfire.
>>
>>I'm going to think about the problem and see how it can be solved.
>>
>>Regards,
>>Werner
>>
>>
>>Berin Lautenbach wrote:
>>
>>
>>>Been thinking about this more, so am going to display my complete Java
>>>ignorance to ask some silly questions :>.
>>>
>>>Looking around on the web, I've found that the JNIEnv is thread unique,
>>>and it is important not to have one thread use a JNIEnv for another thread.
>>>
>>>However, the way the initialise works is it checks to see if OPenSSL is
>>>already initialised, if not set the global JNIEnv to be the JNIEnv of
>>>the current thread. Then it never enters again.
>>>
>>>However the thread locking function uses the global JNIEnv, which means
>>>it doesn't matter what thread calls it, it will always use that JNIEnv.
>>>That appears on the surface to be incorrect behaviour.
>>>
>>>Have I got this up wrong?
>>>
>>>Also, why do we use the Java thread locking system for OpenSSL? Is the
>>>normal OpenSSL system inadequate in the Java environment?
>>>
>>>Cheers,
>>> Berin
>>>
>>>Berin Lautenbach wrote:
>>>
>>>
>>>
>>>>OK - I know what's causing it, but my knowledge of JNI is not good
>>>>enough for me to work out the best way to fix it.
>>>>
>>>>enabling -Xcheck:jni on the jvm call showed that the JEnv is being
>>>>called by a non-java thread.
>>>>
>>>>By doing some tracing, I worked out that java_locking_callback is
>>>>being called *after* junit has completed.
>>>>
>>>>My belief is that this is because the OpenSSL library shuts down on
>>>>program exit. Because Java.exe is the program the DLL is hooked to,
>>>>this is happening long after java has shut down the actual java
>>>>environment.
>>>>
>>>>Assuming I'm correct, we need to do one of the following:
>>>>
>>>>1. Have the provider shut down OpenSSL prior to everything finishing.
>>>>2. Have the program shut down OpenSSL prior to exitting - i.e. user
>>>>responsibility (still need to implement the function to do this)
>>>>3. Have a check within the java_locking_callback that sees whether
>>>>the JEnv is valid, and doesn't call it if it's not.
>>>>
>>>>Of the options, my favourite is 1 - is there some provider function
>>>>that we can hook into here? Not guaranteed to work, there might be
>>>>some locking calls that OpenSSL has to do on exit that we cannot
>>>>pre-empt.
>>>>
>>>>Option 2 is horrible. Last case only.
>>>>
>>>>Option 3 is not the best, but will work if all else fails. We might
>>>>be able to mix it with Option 1 - i.e. when the provider de-inits,
>>>>call a function that unregisters the locking function in OpenSSL.
>>>>
>>>>Open to thoughts. Happy to do the implementation, but as I said, not
>>>>enough of a JNI or provider expert to know which is the best option.
>>>>
>>>>Cheers,
>>>> Berin
>>>>
>>>>
>>>>
>>>>Dittmann, Werner wrote:
>>>>
>>>>
>>>>
>>>>>Berin,
>>>>>
>>>>>thanks for the setup of the VC 6.0 project. After downloading
>>>>>a Visual C++ Express environment (MS provides that free of
>>>>>charge for everybody :-) ) plus the Platform SDK, thus installing
>>>>>about 2GB of MS development environment I was able to build
>>>>>the openSSL4Java.dll starting with your project files.
>>>>>
>>>>>Running the same test results in the same error. The Package
>>>>>test terminated after 23 tests (I added 2 more tests for SecureRandom).
>>>>>The result was a memory access violation.
>>>>>The I started a standalone test with the same result - but only after
>>>>>all tests were done. This made me believe it has something to do with
>>>>>process termination. Just as a simple test I added a System.exit(0)
>>>>>call as the last line of the Package.java main method - and voila - no
>>>>>more memory access error.
>>>>>
>>>>>As an additional test I forced one unit test to fail - also this
>>>>>works as expected: it reports the failures and terminates without
>>>>>memory access violation (after System.exit(0) was added.
>>>>>
>>>>>Because Java starts some threads internaly and tries to terminate
>>>>>them in an orderly fashion - could it a threading problem?
>>>>>
>>>>>I just updated package.java and OpenSSLTestBlock.java to call
>>>>>System.exit(0). IMHO we should try to drill down on the problem.
>>>>>
>>>>>Regards,
>>>>>Werner
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>-----Ursprüngliche Nachricht-----
>>>>>>Von: Berin Lautenbach [mailto:berin@...] Gesendet:
>>>>>>Mittwoch, 15. Februar 2006 11:30
>>>>>>An: juice-dev@...
>>>>>>Betreff: Re: AW: AW: Problems to setup Juice with Windows
>>>>>>
>>>>>>The autogen problem was me Debian installing automake 1.4 by
>>>>>>default(!) Once I had 1.9 everything was cool.
>>>>>>
>>>>>>I have imported a *very* basic debug build for VC 6.0 into the repo.
>>>>>>There are some interesting complile time messages that I will look
>>>>>>at, but I get 21 tests run successfully before I get a rather nasty
>>>>>>memory access violation. I'll sort that one out in a few days as
>>>>>>well :>.
>>>>>>
>>>>>>Cheers,
>>>>>> Berin
>>>>>>
>>>>>>Dittmann, Werner wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Berin,
>>>>>>>
>>>>>>>this project file is for the old juice native software. Pls
>>>>>>>be informed that I introduced a new setup for Juice.
>>>>>>>
>>>>>>>The autoconf under Linux should simply work. Have a look
>>>>>>>the the configure.ac and tha Makefile.am files, but running
>>>>>>>./configure should work (if zou download the GZ file), otherwise
>>>>>>>just run the autogen.sh script. This creates all necessary
>>>>>>>files and runs ./configure. After "make" the shared lib
>>>>>>>is in srcNew/.libs.
>>>>>>>
>>>>>>>Don't forget to set LD_LIBRARY_PATH correctly for the test
>>>>>>>cases.
>>>>>>>
>>>>>>>Regards,
>>>>>>>Werner
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>-----Ursprüngliche Nachricht-----
>>>>>>>>Von: Berin Lautenbach [mailto:berin@...] Gesendet:
>>>>>>>>Dienstag, 14. Februar 2006 10:27
>>>>>>>>An: juice-dev@...
>>>>>>>>Betreff: Re: AW: Problems to setup Juice with Windows
>>>>>>>>
>>>>>>>>Just started having a look. Is see there is already a project
>>>>>>>>file for VC++ 6.0 in the old source directory. I'll set up
>>>>>>>>something in the "standard" "Projects/..." folder structure to get
>>>>>>>>it going.
>>>>>>>>
>>>>>>>>But first I'll get it running under Linux to see how it should
>>>>>>>>work :>. Having an interesting time getting it to autoconf, but
>>>>>>
>>>>>>
>>>>>>
>>>>>>I'll work it
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>out tomorrow night.
>>>>>>>>
>>>>>>>>Cheers,
>>>>>>>> Berin
>>>>>>>>
>>>>>>>>Dittmann, Werner wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Berin,
>>>>>>>>>
>>>>>>>>>sureI'm open to that.
>>>>>>>>>The whole native stuff is in plain C, just 5 modules
>>>>>>>>>in C plus the headers. IMHO I don't use any stuff
>>>>>>>>>that is Linux specific.
>>>>>>>>>
>>>>>>>>>The only prerequistite is the availabilty of the openSSL
>>>>>>>>>headers and crypto lib.
>>>>>>>>>
>>>>>>>>>You can find the sources in incubator/juice/native/srcNew.
>>>>>>>>>
>>>>>>>>>If you have ides/questions just send a mail.
>>>>>>>>>
>>>>>>>>>Regards,
>>>>>>>>>Werner
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>-----Ursprüngliche Nachricht-----
>>>>>>>>>>Von: Berin Lautenbach [mailto:berin@...] Gesendet:
>>>>>>>>>>Dienstag, 14. Februar 2006 09:28
>>>>>>>>>>An: juice-dev@...
>>>>>>>>>>Betreff: Re: Problems to setup Juice with Windows
>>>>>>>>>>
>>>>>>>>>>Having played with getting things running under Cygwin - I
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>think I'd
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>tend to agree with Scott. It adds some extra complications
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>into the
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>build/run process that could well trip you up.
>>>>>>>>>>
>>>>>>>>>>Is it possible to get the stuff to compile on VC++? Are you
>>>>>>>>>>open for me to have a look to see if I can get it up and running?
>>>>>>>>>>
>>>>>>>>>>Cheers,
>>>>>>>>>> Berin
>>>>>>>>>>
>>>>>>>>>>Scott Cantor wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>- using cygwin I was able to setup the autoconf stuff, create a
>>>>>>>>>>>>configure script, and compiled the native sources into a
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>DLL. Before
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>the compile was sucessful I copied the files "jni.h" and
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>"jni_md.h"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>from the Java include directory to /usr/include of
>>>>>>
>>>>>>
>>>>>>
>>>>>>cygwin. Then I
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>>>>changed the "typedef __int64 jlong" to "typedef long
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>long jint" to
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>be compliant with gcc.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>Is cygwin the way people would want to use this? I somehow
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>doubt it. Most
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>people on Windows don't wish to pull in the cygwin DLLs,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>they want proper
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>Windows builds.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>Any ideas? Any help is appreciated.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>Regardless of the previous point, is there actual proof
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>that the JVM can
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>load native code built with cygwin? Maybe it just works,
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>but I'd try and
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>verify that independently before I went looking for root causes.
>>>>>>>>>>>
>>>>>>>>>>>-- Scott
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>---------
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>>>>>>For additional commands, e-mail: juice-dev-help@...
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>---------
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>>>>>For additional commands, e-mail: juice-dev-help@...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>>---------
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>>>>For additional commands, e-mail: juice-dev-help@...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>>---------
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>>>For additional commands, e-mail: juice-dev-help@...
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>>For additional commands, e-mail: juice-dev-help@...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>For additional commands, e-mail: juice-dev-help@...
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>For additional commands, e-mail: juice-dev-help@...
>>>>>
>>>>>
>>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>For additional commands, e-mail: juice-dev-help@...
>>>>
>>>>
>>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>For additional commands, e-mail: juice-dev-help@...
>>>
>>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>For additional commands, e-mail: juice-dev-help@...
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juice-dev-unsubscribe@...
> For additional commands, e-mail: juice-dev-help@...
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

AW: Problems to setup Juice with Windows

2006-02-18T04:59:03Z

Berin,

after looking into the problem I changed the thread locking to use
pthreads on Linux and mutexes for Windows. Pls have a look into the
modifed InitializeOpenSSL.c code. I've tested it for Linux, tetsing
Windows maybe tomorrow.

Regards,
Werner

Werner Dittmann wrote:

> Berin,
>
> thanks for point out the JNIEnv and thread problem - I didn't catch that
> while reading the JNI docs.
>
> Well, The idea to use the Jave thread locking was driven to be fully
> interoperable with Java threading :-) ... I'm not sure if for example
> in Linux the pthreads work together with Java. Thus I thought it would
> be a goo idea to use Java's own thread locking - not I have a backfire.
>
> I'm going to think about the problem and see how it can be solved.
>
> Regards,
> Werner
>
>
> Berin Lautenbach wrote:
>
>>Been thinking about this more, so am going to display my complete Java
>>ignorance to ask some silly questions :>.
>>
>>Looking around on the web, I've found that the JNIEnv is thread unique,
>>and it is important not to have one thread use a JNIEnv for another thread.
>>
>>However, the way the initialise works is it checks to see if OPenSSL is
>>already initialised, if not set the global JNIEnv to be the JNIEnv of
>>the current thread. Then it never enters again.
>>
>>However the thread locking function uses the global JNIEnv, which means
>>it doesn't matter what thread calls it, it will always use that JNIEnv.
>> That appears on the surface to be incorrect behaviour.
>>
>>Have I got this up wrong?
>>
>>Also, why do we use the Java thread locking system for OpenSSL? Is the
>>normal OpenSSL system inadequate in the Java environment?
>>
>>Cheers,
>> Berin
>>
>>Berin Lautenbach wrote:
>>
>>
>>>OK - I know what's causing it, but my knowledge of JNI is not good
>>>enough for me to work out the best way to fix it.
>>>
>>>enabling -Xcheck:jni on the jvm call showed that the JEnv is being
>>>called by a non-java thread.
>>>
>>>By doing some tracing, I worked out that java_locking_callback is
>>>being called *after* junit has completed.
>>>
>>>My belief is that this is because the OpenSSL library shuts down on
>>>program exit. Because Java.exe is the program the DLL is hooked to,
>>>this is happening long after java has shut down the actual java
>>>environment.
>>>
>>>Assuming I'm correct, we need to do one of the following:
>>>
>>>1. Have the provider shut down OpenSSL prior to everything finishing.
>>>2. Have the program shut down OpenSSL prior to exitting - i.e. user
>>>responsibility (still need to implement the function to do this)
>>>3. Have a check within the java_locking_callback that sees whether
>>>the JEnv is valid, and doesn't call it if it's not.
>>>
>>>Of the options, my favourite is 1 - is there some provider function
>>>that we can hook into here? Not guaranteed to work, there might be
>>>some locking calls that OpenSSL has to do on exit that we cannot
>>>pre-empt.
>>>
>>>Option 2 is horrible. Last case only.
>>>
>>>Option 3 is not the best, but will work if all else fails. We might
>>>be able to mix it with Option 1 - i.e. when the provider de-inits,
>>>call a function that unregisters the locking function in OpenSSL.
>>>
>>>Open to thoughts. Happy to do the implementation, but as I said, not
>>>enough of a JNI or provider expert to know which is the best option.
>>>
>>>Cheers,
>>> Berin
>>>
>>>
>>>
>>>Dittmann, Werner wrote:
>>>
>>>
>>>>Berin,
>>>>
>>>>thanks for the setup of the VC 6.0 project. After downloading
>>>>a Visual C++ Express environment (MS provides that free of
>>>>charge for everybody :-) ) plus the Platform SDK, thus installing
>>>>about 2GB of MS development environment I was able to build
>>>>the openSSL4Java.dll starting with your project files.
>>>>
>>>>Running the same test results in the same error. The Package
>>>>test terminated after 23 tests (I added 2 more tests for SecureRandom).
>>>>The result was a memory access violation.
>>>>The I started a standalone test with the same result - but only after
>>>>all tests were done. This made me believe it has something to do with
>>>>process termination. Just as a simple test I added a System.exit(0)
>>>>call as the last line of the Package.java main method - and voila - no
>>>>more memory access error.
>>>>
>>>>As an additional test I forced one unit test to fail - also this
>>>>works as expected: it reports the failures and terminates without
>>>>memory access violation (after System.exit(0) was added.
>>>>
>>>>Because Java starts some threads internaly and tries to terminate
>>>>them in an orderly fashion - could it a threading problem?
>>>>
>>>>I just updated package.java and OpenSSLTestBlock.java to call
>>>>System.exit(0). IMHO we should try to drill down on the problem.
>>>>
>>>>Regards,
>>>>Werner
>>>>
>>>>
>>>>
>>>>>-----Ursprüngliche Nachricht-----
>>>>>Von: Berin Lautenbach [mailto:berin@...] Gesendet:
>>>>>Mittwoch, 15. Februar 2006 11:30
>>>>>An: juice-dev@...
>>>>>Betreff: Re: AW: AW: Problems to setup Juice with Windows
>>>>>
>>>>>The autogen problem was me Debian installing automake 1.4 by
>>>>>default(!) Once I had 1.9 everything was cool.
>>>>>
>>>>>I have imported a *very* basic debug build for VC 6.0 into the repo.
>>>>>There are some interesting complile time messages that I will look
>>>>>at, but I get 21 tests run successfully before I get a rather nasty
>>>>>memory access violation. I'll sort that one out in a few days as
>>>>>well :>.
>>>>>
>>>>>Cheers,
>>>>> Berin
>>>>>
>>>>>Dittmann, Werner wrote:
>>>>>
>>>>>
>>>>>>Berin,
>>>>>>
>>>>>>this project file is for the old juice native software. Pls
>>>>>>be informed that I introduced a new setup for Juice.
>>>>>>
>>>>>>The autoconf under Linux should simply work. Have a look
>>>>>>the the configure.ac and tha Makefile.am files, but running
>>>>>>./configure should work (if zou download the GZ file), otherwise
>>>>>>just run the autogen.sh script. This creates all necessary
>>>>>>files and runs ./configure. After "make" the shared lib
>>>>>>is in srcNew/.libs.
>>>>>>
>>>>>>Don't forget to set LD_LIBRARY_PATH correctly for the test
>>>>>>cases.
>>>>>>
>>>>>>Regards,
>>>>>>Werner
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>-----Ursprüngliche Nachricht-----
>>>>>>>Von: Berin Lautenbach [mailto:berin@...] Gesendet:
>>>>>>>Dienstag, 14. Februar 2006 10:27
>>>>>>>An: juice-dev@...
>>>>>>>Betreff: Re: AW: Problems to setup Juice with Windows
>>>>>>>
>>>>>>>Just started having a look. Is see there is already a project
>>>>>>>file for VC++ 6.0 in the old source directory. I'll set up
>>>>>>>something in the "standard" "Projects/..." folder structure to get
>>>>>>>it going.
>>>>>>>
>>>>>>>But first I'll get it running under Linux to see how it should
>>>>>>>work :>. Having an interesting time getting it to autoconf, but
>>>>>
>>>>>
>>>>>
>>>>>I'll work it
>>>>>
>>>>>
>>>>>>>out tomorrow night.
>>>>>>>
>>>>>>>Cheers,
>>>>>>> Berin
>>>>>>>
>>>>>>>Dittmann, Werner wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Berin,
>>>>>>>>
>>>>>>>>sureI'm open to that.
>>>>>>>>The whole native stuff is in plain C, just 5 modules
>>>>>>>>in C plus the headers. IMHO I don't use any stuff
>>>>>>>>that is Linux specific.
>>>>>>>>
>>>>>>>>The only prerequistite is the availabilty of the openSSL
>>>>>>>>headers and crypto lib.
>>>>>>>>
>>>>>>>>You can find the sources in incubator/juice/native/srcNew.
>>>>>>>>
>>>>>>>>If you have ides/questions just send a mail.
>>>>>>>>
>>>>>>>>Regards,
>>>>>>>>Werner
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>-----Ursprüngliche Nachricht-----
>>>>>>>>>Von: Berin Lautenbach [mailto:berin@...] Gesendet:
>>>>>>>>>Dienstag, 14. Februar 2006 09:28
>>>>>>>>>An: juice-dev@...
>>>>>>>>>Betreff: Re: Problems to setup Juice with Windows
>>>>>>>>>
>>>>>>>>>Having played with getting things running under Cygwin - I
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>think I'd
>>>>>>>
>>>>>>>
>>>>>>>>>tend to agree with Scott. It adds some extra complications
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>into the
>>>>>>>
>>>>>>>
>>>>>>>>>build/run process that could well trip you up.
>>>>>>>>>
>>>>>>>>>Is it possible to get the stuff to compile on VC++? Are you
>>>>>>>>>open for me to have a look to see if I can get it up and running?
>>>>>>>>>
>>>>>>>>>Cheers,
>>>>>>>>> Berin
>>>>>>>>>
>>>>>>>>>Scott Cantor wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>- using cygwin I was able to setup the autoconf stuff, create a
>>>>>>>>>>>configure script, and compiled the native sources into a
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>DLL. Before
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>the compile was sucessful I copied the files "jni.h" and
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>"jni_md.h"
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>from the Java include directory to /usr/include of
>>>>>
>>>>>
>>>>>
>>>>>cygwin. Then I
>>>>>
>>>>>
>>>>>>>>>>>changed the "typedef __int64 jlong" to "typedef long
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>long jint" to
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>>be compliant with gcc.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Is cygwin the way people would want to use this? I somehow
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>doubt it. Most
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>people on Windows don't wish to pull in the cygwin DLLs,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>they want proper
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>Windows builds.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>Any ideas? Any help is appreciated.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Regardless of the previous point, is there actual proof
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>that the JVM can
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>load native code built with cygwin? Maybe it just works,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>but I'd try and
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>verify that independently before I went looking for root causes.
>>>>>>>>>>
>>>>>>>>>>-- Scott
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>---------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>>>>>For additional commands, e-mail: juice-dev-help@...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>---------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>>>>For additional commands, e-mail: juice-dev-help@...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>------------------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>>---------
>>>>>
>>>>>
>>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>>>For additional commands, e-mail: juice-dev-help@...
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>------------------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>>---------
>>>>>
>>>>>
>>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>>For additional commands, e-mail: juice-dev-help@...
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>---------------------------------------------------------------------
>>>>>
>>>>>
>>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>>For additional commands, e-mail: juice-dev-help@...
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>>For additional commands, e-mail: juice-dev-help@...
>>>>>
>>>>>
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>>For additional commands, e-mail: juice-dev-help@...
>>>>
>>>>
>>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>>For additional commands, e-mail: juice-dev-help@...
>>>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: juice-dev-unsubscribe@...
>>For additional commands, e-mail: juice-dev-help@...
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: juice-dev-unsubscribe@...
> For additional commands, e-mail: juice-dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: juice-dev-unsubscribe@...
For additional commands, e-mail: juice-dev-help@...

Nabble - Juice - Dev

Fwd: Incubator Quarterly Board Reporting Schedule

Re: Thoughts

Thoughts

Re: Fwd: REMINDER: *** Board Reports DUE! ***

Fwd: REMINDER: *** Board Reports DUE! ***

Some news on JuiCE

Re: AW: Proposal for restructuring JuiCE files - and some new functions

AW: Proposal for restructuring JuiCE files - and some new functions

Re: Proposal for restructuring JuiCE files - and some new functions

Re: Proposal for restructuring JuiCE files - and some new functions

Re: Proposal for restructuring JuiCE files - and some new functions

Proposal for restructuring JuiCE files - and some new functions

[JuiCE] New ciphers, key factories, key pair generators avaliable - additional info

[JuiCE] New ciphers, key factories, key pair generators avaliable

[JuiCE] Some new features avaliable

Re: Question regaring Password based encryption (PBE)

Re: Question regaring Password based encryption (PBE)

Question regaring Password based encryption (PBE)

Re: AW: AW: Some more JNI questions

AW: AW: Some more JNI questions

Re: AW: Some more JNI questions

AW: Some more JNI questions

AW: [JuiCE] Some information about latest state

Some more JNI questions

Re: [JuiCE] Some information about latest state

AW: [JuiCE] Some information about latest state

RE: [JuiCE] Some information about latest state

AW: [JuiCE] Some information about latest state

RE: [JuiCE] Some information about latest state

[JuiCE] Some information about latest state

Re: AW: Problems to setup Juice with Windows

Re: AW: Problems to setup Juice with Windows

Re: AW: Problems to setup Juice with Windows

Re: AW: Problems to setup Juice with Windows

AW: Problems to setup Juice with Windows

Re: Fwd: REMINDER: * Board Reports DUE! *

Fwd: REMINDER: * Board Reports DUE! *