[commit-cp] classpath javax/security/auth/kerberos/ServiceP...

2006-04-05 Thread Tom Tromey
CVSROOT:/cvsroot/classpath
Module name:classpath
Branch: 
Changes by: Tom Tromey [EMAIL PROTECTED]  06/04/06 01:20:40

Modified files:
javax/security/auth/kerberos: ServicePermission.java 
.  : ChangeLog 

Log message:
* javax/security/auth/kerberos/ServicePermission.java: Now final.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/javax/security/auth/kerberos/ServicePermission.java.diff?tr1=1.1tr2=1.2r1=textr2=text
http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.7026tr2=1.7027r1=textr2=text




[commit-cp] classpath/javax/security/auth/kerberos

2006-04-03 Thread Tom Tromey
CVSROOT:/cvsroot/classpath
Module name:classpath
Branch: 
Changes by: Tom Tromey [EMAIL PROTECTED]  06/04/03 19:19:52

classpath/javax/security/auth/kerberos

Update of /cvsroot/classpath/classpath/javax/security/auth/kerberos
In directory savannah:/tmp/cvs-serv2985/javax/security/auth/kerberos

Log Message:
Directory /cvsroot/classpath/classpath/javax/security/auth/kerberos added to 
the repository




Re: Kerberos

2005-11-20 Thread Roman Kennke
Hi Jeff,

Am Samstag, den 19.11.2005, 23:09 -0500 schrieb Jeff Bailey:
 Hi!  I sent in a patch to implement the KerberosPrincipal class.

Cool!

 What I was thinking is that there should probably really be three
 implementations of the Kerberos stuff.  The first two are glue code
 around MIT Kerberos and Heimdal Kerberos.  That way if you have a user
 who's already got a ticket, it continues to be useful in their Java
 environment.  I think this is important for distribution integration.

Yeah, I think this would be extremely helpful.

 The third is a native implementation so that people don't
 need to install Kerberos in order to have classpath installed.  I don't
 know if this is necessary or even desirable.

I think (as with many other areas too, like imageio vs imagemagick)
having an own implementation would also be very desirable. GNU Classpath
is not only targetted to be used in Linux-Distros, but also in Embedded
Systems or at least systems that are completely different from Linux
(think of all the platforms that kaffe runs on). Also I don't think a
'native' implementation makes much sense, I would prefer a Java-only
solutions for as much stuff as possible, since native code is always a
little harder to port to strange platforms. But maybe you mean with
'native' something like 'our own implementation'? Or is there something
in Kerberos that can't be done Java-only?

Cheers, Roman



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath


Re: Kerberos

2005-11-20 Thread Jeff Bailey




On dim, 2005-11-20 at 20:42 +0100, Roman Kennke wrote:


 The third is a native implementation so that people don't
 need to install Kerberos in order to have classpath installed.  I don't
 know if this is necessary or even desirable.

I think (as with many other areas too, like imageio vs imagemagick)
having an own implementation would also be very desirable. GNU Classpath
is not only targetted to be used in Linux-Distros, but also in Embedded
Systems or at least systems that are completely different from Linux
(think of all the platforms that kaffe runs on). Also I don't think a
'native' implementation makes much sense, I would prefer a Java-only
solutions for as much stuff as possible, since native code is always a
little harder to port to strange platforms. But maybe you mean with
'native' something like 'our own implementation'? Or is there something
in Kerberos that can't be done Java-only?



Sorry, I chose my words poorly there. By 'native' I meant Done in Java. Is there a better word that means that? =)

Tks,
Jeff Bailey





signature.asc
Description: This is a digitally signed message part
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath


Re: Kerberos

2005-11-20 Thread Archie Cobbs

Jeff Bailey wrote:
Sorry, I chose my words poorly there.  By 'native' I meant Done in 
Java.  Is there a better word that means that? =)


Pure Java... ?

-Archie

__
Archie Cobbs  *CTO, Awarix*  http://www.awarix.com


___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath


Re: Kerberos

2005-11-20 Thread David Daney

Archie Cobbs wrote:

Jeff Bailey wrote:

Sorry, I chose my words poorly there.  By 'native' I meant Done in 
Java.  Is there a better word that means that? =)



Pure Java... ?


Nice, but I think it may be (tm) Sun Microsystems, Inc.


___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath


Kerberos

2005-11-19 Thread Jeff Bailey
Hi!  I sent in a patch to implement the KerberosPrincipal class.  Now
comes the fun part. =)

What I was thinking is that there should probably really be three
implementations of the Kerberos stuff.  The first two are glue code
around MIT Kerberos and Heimdal Kerberos.  That way if you have a user
who's already got a ticket, it continues to be useful in their Java
environment.  I think this is important for distribution integration.

The third is a native implementation so that people don't
need to install Kerberos in order to have classpath installed.  I don't
know if this is necessary or even desirable.  I'd imagine that if
someone has Kerberos on their network on in their distribution they'll
probably want to integrate getting a ticket with logging in and have
multiple Kerberized application.  It also means that our security issues
are limited to glue code, and are not based around my understanding of
asn.1 as an on-wire protocol. =)

I imagine for now, it just means another command line switch to
configure to enable it if possible, and select MIT vs. Heimdal.

Comments, flames, etc., appreciated.  In the absence of any, I'll just
start hacking and feeding patches to classpath-patches.

Tks,
Jeff Bailey


signature.asc
Description: This is a digitally signed message part
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath