You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by "Henning P. Schmiedehausen" <ma...@hometree.net> on 2001/12/14 15:29:08 UTC
Unix crypt implementation (adding cryptix jar to Turbine)
Hi,
I have a patch for Turbine (2.2beta) that implements Unix Crypt
support for user passwords (ah, the joys of adapting to legacy
databases =:-) ) in the DBUserManager and the DBUserService but I do
need an UnixCrypt implementation for this.
In the cryptix package is a suitable implementation for UnixCrypt,
which works fine for my case.
Are there objections in adding the cryptix32.jar to the Turbine 2.2
repository? Alternatively unbundling the cryptix.tools.UnixCrypt
method. The license seems compatible to the Apache License to me:
--- cut ---
Cryptix General License
Copyright (c) 1995, 1996, 1997, 1998, 1999, 2000 The Cryptix Foundation
Limited. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:
1. Redistributions of source code must retain the copyright notice,
this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.
THIS SOFTWARE IS PROVIDED BY THE CRYPTIX FOUNDATION LIMITED AND
CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE CRYPTIX FOUNDATION LIMITED OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
--- cut ---
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Unix crypt implementation (adding cryptix jar to Turbine)
Posted by Daniel Rall <dl...@finemaltcoding.com>.
henning@forge.intermeta.de (Henning Schmiedehausen) writes:
> Ah well, if this was C, you could use an ifdef and all would be good. ;-)
Anyone ever tried the following in your Java source code:
// @multiline_java_source_code_snippet_ant_token@
Where multiline_java_source_code_snippet_ant_token is preprocessed by
Ant at build-time to be a section of Java code (or if Ant is not used,
it's behind a comment, so no big deal).
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Unix crypt implementation (adding cryptix jar to Turbine)
Posted by Henning Schmiedehausen <he...@forge.intermeta.de>.
John McNally <jm...@collab.net> writes:
>Is there any way to restructure things, without rewriting too much, to
>make this optional. License looks compatible and since the jars are
>packaged with 2.x it should not be a problem, I assume the jar is
>small. But to carry the change into fulcrum, I think it would
>definitely be better to have it be optional.
Ah well, if this was C, you could use an ifdef and all would be good. ;-)
The problem is, that for making this crypt algorithm optional, you
would need a runtime lookup of the class which must comply to a public
known (i.e. java.security.MessageDigest) interface or superclass. The
bigger problem is, that there is now way (that I see) to seed the
algorithm with the required parameter to perform unix crypt(3). (That
may be the reason why there is no such implementation. ;-)
Sooner or later you must provide the crypt class
(cryptix.tools.UnixCrypt e.g.) to compile any class that references
it. That class won't compile without the jar. And if you don't want to
jump through hoops just to be able to implement this separate
(creating a security provider that provides "unix" and testing for
this one to call a specially casted "seed()" method...), I see no
really useful way to add this to Turbine without providing either the
cryptix32.jar or our own UnixCrypt class (which I do have handy, too
but then again we would have the export/import trouble stated in the
other post).
I will try to whip something up tonight.
Regards
Henning
>"Henning P. Schmiedehausen" wrote:
>>
>> Hi,
>>
>> I have a patch for Turbine (2.2beta) that implements Unix Crypt
>> support for user passwords (ah, the joys of adapting to legacy
>> databases =:-) ) in the DBUserManager and the DBUserService but I do
>> need an UnixCrypt implementation for this.
>>
>> In the cryptix package is a suitable implementation for UnixCrypt,
>> which works fine for my case.
>>
>> Are there objections in adding the cryptix32.jar to the Turbine 2.2
>> repository? Alternatively unbundling the cryptix.tools.UnixCrypt
>> method. The license seems compatible to the Apache License to me:
>>
>> --- cut ---
>> Cryptix General License
>>
>> Copyright (c) 1995, 1996, 1997, 1998, 1999, 2000 The Cryptix Foundation
>> Limited. All rights reserved.
>>
>> Redistribution and use in source and binary forms, with or without
>> modification, are permitted provided that the following conditions are
>> met:
>>
>> 1. Redistributions of source code must retain the copyright notice,
>> this list of conditions and the following disclaimer.
>> 2. Redistributions in binary form must reproduce the above copyright
>> notice, this list of conditions and the following disclaimer in
>> the documentation and/or other materials provided with the
>> distribution.
>>
>> THIS SOFTWARE IS PROVIDED BY THE CRYPTIX FOUNDATION LIMITED AND
>> CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
>> INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
>> MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
>> IN NO EVENT SHALL THE CRYPTIX FOUNDATION LIMITED OR CONTRIBUTORS BE
>> LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>> CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
>> SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
>> BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
>> WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
>> OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
>> IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>> --- cut ---
>>
>> Regards
>> Henning
>>
>> --
>> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
>> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
>>
>> Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
>> D-91054 Buckenhof Fax.: 09131 / 50654-20
>>
>> --
>> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>> For additional commands, e-mail: <ma...@jakarta.apache.org>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Unix crypt implementation (adding cryptix jar to Turbine)
Posted by Henning Schmiedehausen <he...@forge.intermeta.de>.
Kurt Schrader <ks...@engin.umich.edu> writes:
> From their FAQ:
>I going to have to have to go with a -1 on this unless Jason wants to
I will try to separate the code. I see your export concerns.
>start hosting Turbine in Canada for us.
I can host it over here in the free world (TM) for you too. ;-) I want to keep
a single version worldwide, however.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Unix crypt implementation (adding cryptix jar to Turbine)
Posted by Kurt Schrader <ks...@engin.umich.edu>.
From their FAQ:
Can Cryptix be exported from the US?
The U.S. Government says that you should ask for approval, and that has
not been granted to date by the few brave souls that have tried. The
U.S. crypto debate is well documented elsewhere.
This \ has been discussed on the general and/or Tomcat list previously,
and the conclusion was reached that it cannot be included because of
this.
I going to have to have to go with a -1 on this unless Jason wants to
start hosting Turbine in Canada for us.
-Kurt
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Unix crypt implementation (adding cryptix jar to Turbine)
Posted by John McNally <jm...@collab.net>.
Is there any way to restructure things, without rewriting too much, to
make this optional. License looks compatible and since the jars are
packaged with 2.x it should not be a problem, I assume the jar is
small. But to carry the change into fulcrum, I think it would
definitely be better to have it be optional.
john mcnally
"Henning P. Schmiedehausen" wrote:
>
> Hi,
>
> I have a patch for Turbine (2.2beta) that implements Unix Crypt
> support for user passwords (ah, the joys of adapting to legacy
> databases =:-) ) in the DBUserManager and the DBUserService but I do
> need an UnixCrypt implementation for this.
>
> In the cryptix package is a suitable implementation for UnixCrypt,
> which works fine for my case.
>
> Are there objections in adding the cryptix32.jar to the Turbine 2.2
> repository? Alternatively unbundling the cryptix.tools.UnixCrypt
> method. The license seems compatible to the Apache License to me:
>
> --- cut ---
> Cryptix General License
>
> Copyright (c) 1995, 1996, 1997, 1998, 1999, 2000 The Cryptix Foundation
> Limited. All rights reserved.
>
> Redistribution and use in source and binary forms, with or without
> modification, are permitted provided that the following conditions are
> met:
>
> 1. Redistributions of source code must retain the copyright notice,
> this list of conditions and the following disclaimer.
> 2. Redistributions in binary form must reproduce the above copyright
> notice, this list of conditions and the following disclaimer in
> the documentation and/or other materials provided with the
> distribution.
>
> THIS SOFTWARE IS PROVIDED BY THE CRYPTIX FOUNDATION LIMITED AND
> CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
> INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
> IN NO EVENT SHALL THE CRYPTIX FOUNDATION LIMITED OR CONTRIBUTORS BE
> LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
> WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
> OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
> IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> --- cut ---
>
> Regards
> Henning
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
>
> Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
> D-91054 Buckenhof Fax.: 09131 / 50654-20
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>