Thanks, Mike! On Dec 19, 2011, at 10:27 PM, Mike Swingler wrote:
> I'll be happy to change the copyright. :-) > > ~Mike > > On Dec 19, 2011, at 10:23 PM, Weijun Wang wrote: > >> Hi All >> >> I've created a webrev. Please anyone take a review: >> >> http://cr.openjdk.java.net/~weijun/9999999/webrev.12/ >> >> *Jeannette*: >> >> Is a formal donate-to-openjdk process needed? The file in my webrev still >> has the Apple copyright line. IANAL and I do not want to make any change to >> it myself. >> >> Thanks >> Max >> >> >> On 12/20/2011 09:58 AM, Mike Swingler wrote: >>> This is just a .c file. No Objective-C here. >>> >>> ~Mike >>> >>> On Dec 19, 2011, at 5:56 PM, Weijun Wang wrote: >>> >>>> Hi Bino >>>> >>>> Thank you for locating it. I would be glad if you or Scott can do an >>>> integration. I guess this .m file is almost a pure .c file but I'm really >>>> unfamiliar with compiler settings on Mac. >>>> >>>> -Max >>>> >>>> >>>> On 12/20/2011 09:51 AM, Bino George wrote: >>>>> Hi Weijun, >>>>> >>>>> It looks like we did not port over some of the native code that Scott >>>>> Kovatch wrote for the Mac. Attached is the native file for JDK6 that >>>>> implements the missing JNI method. Can you or Scott try to integrate it >>>>> to JDK 7 ? If you have difficulty, let me know and I will take care of it >>>>> some time this week. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> Bino. >>>>> >>>>> >>>>> On Dec 19, 2011, at 5:19 PM, Weijun Wang wrote: >>>>> >>>>>> >>>>>> >>>>>> On 12/20/2011 09:10 AM, Bino George wrote: >>>>>>> Hi Weijun, >>>>>>> >>>>>>>> I'm testing on 10.6. >>>>>>> >>>>>>> Does JDK6 (Apple JVM) work for your test on 10.6 ??? >>>>>>> >>>>>>> The SCDynamicStoreConfig implementation only works on Lion (10.7). >>>>>>> >>>>>>> >>>>>>>> In fact, in src/share/classes/sun/security/krb5/Credentials.java, the >>>>>>>> native method declaration still exists: >>>>>>>> >>>>>>>> private static native Credentials acquireDefaultNativeCreds(); >>>>>>>> >>>>>>> >>>>>>> We don't do anything native on 10.6 and before we find the config file >>>>>>> using this logic and simply parse it in Config.java : >>>>>> >>>>>> I'm not talking about the config part at all. That part has no problem. >>>>>> >>>>>> What I said is credential cache, i.e. the little piece of private info >>>>>> stored on local computer (either a file or a block in memory) after >>>>>> kinit is called. The info is generated by kinit and can be viewed either >>>>>> by the native klist tool or thru the Java call >>>>>> >>>>>> sun.security.krb5,Credentials.acquireTGTFromCache() >>>>>> >>>>>> What I observed is that in Apple JDK 6 both these 2 methods return the >>>>>> same info but in macosx-port the Java method does not return anything. >>>>>> >>>>>> That's what I mentioned in the "Thu, 01 Dec 2011 22:54:57 +0800" mail. >>>>>> (scroll down to 2/3 place). >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>>> >>>>>>> private String findMacosConfigFile() { >>>>>>> String userHome = getProperty("user.home"); >>>>>>> finalString PREF_FILE = "/Library/Preferences/edu.mit.Kerberos"; >>>>>>> String userPrefs=userHome + PREF_FILE; >>>>>>> >>>>>>> >>>>>>> if (fileExists(userPrefs)) { >>>>>>> return userPrefs; >>>>>>> } >>>>>>> >>>>>>> >>>>>>> if (fileExists(PREF_FILE)) { >>>>>>> return PREF_FILE; >>>>>>> } >>>>>>> >>>>>>> >>>>>>> if (fileExists("/etc/krb5.conf")) { >>>>>>> return"/etc/krb5.conf"; >>>>>>> } >>>>>>> >>>>>>> >>>>>>> return ""; >>>>>>> } >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Bino. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Dec 19, 2011, at 4:49 PM, Weijun Wang wrote: >>>>>>> >>>>>>>> I take a brief look at >>>>>>>> >>>>>>>> src/macosx/native/java/util/SCDynamicStoreConfig.m >>>>>>>> src/share/classes/sun/security/krb5/SCDynamicStoreConfig.java >>>>>>>> >>>>>>>> and it is an alternative way of specifying krb5.conf, but there is no >>>>>>>> line on the credentials cache. >>>>>>>> >>>>>>>> In fact, in src/share/classes/sun/security/krb5/Credentials.java, the >>>>>>>> native method declaration still exists: >>>>>>>> >>>>>>>> private static native Credentials acquireDefaultNativeCreds(); >>>>>>>> >>>>>>>> but I cannot find the implementation codes for it. >>>>>>>> >>>>>>>> I'm testing on 10.6. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> >>>>>>>> On 12/20/2011 05:30 AM, Bino George wrote: >>>>>>>>> Hi Mike, >>>>>>>>> >>>>>>>>>> Actually, Bino - on Lion we compile in the SCDynamicStore version, >>>>>>>>>> and >>>>>>>>>> on SnowLeopard we compile it out an just use the file version in >>>>>>>>>> Java. >>>>>>>>>> Do you know if the SCDynamicStore version is building on SnowLeopard, >>>>>>>>>> but just not enabled? Does it rely on new constants that are only on >>>>>>>>>> Lion? >>>>>>>>> >>>>>>>>> >>>>>>>>> The difference between JDK6 and JDK7 is that in JDK6 we do not compile >>>>>>>>> the SCDynamicStore code. But since SCDynamicStore does not use any new >>>>>>>>> API, we compile it both on Lion and SnowLeopard on JDK7 and we only >>>>>>>>> load >>>>>>>>> the SCDynamicStore code on Lion (we check at runtime for os version). >>>>>>>>> We >>>>>>>>> don't rely on any OS provided constants, I don't think there are any, >>>>>>>>> we >>>>>>>>> just look for the following keys on Lion in SCDynamicStore : >>>>>>>>> >>>>>>>>> #define KERBEROS_DEFAULT_REALMS @"Kerberos-Default-Realms" >>>>>>>>> #define KERBEROS_DEFAULT_REALM_MAPPINGS >>>>>>>>> @"Kerberos-Domain-Realm-Mappings" >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Bino. >>>>>>>>> >>>>>>>>> On Dec 19, 2011, at 11:10 AM, Mike Swingler wrote: >>>>>>>>> >>>>>>>>>> On Dec 19, 2011, at 11:05 AM, Bino George wrote: >>>>>>>>>> >>>>>>>>>>> Hi Mike, >>>>>>>>>>> >>>>>>>>>>>> Bino, I thought we contributed all of the Kerberos implementation >>>>>>>>>>>> (including the new SCDynamicStore implementation for Lion). Do you >>>>>>>>>>>> think the system kinit and the SCDynamicStore versions aren't >>>>>>>>>>>> playing ball with each other? >>>>>>>>>>> >>>>>>>>>>> Yes, we did contribute that code already and we tested it in JDK7 on >>>>>>>>>>> Lion. Not sure if this is a SnowLeopard issue. >>>>>>>>>>> >>>>>>>>>>> Weijun, does your tests work with JDK6 from Apple on the same >>>>>>>>>>> machine, the code should be identical. >>>>>>>>>> >>>>>>>>>> Actually, Bino - on Lion we compile in the SCDynamicStore version, >>>>>>>>>> and >>>>>>>>>> on SnowLeopard we compile it out an just use the file version in >>>>>>>>>> Java. >>>>>>>>>> Do you know if the SCDynamicStore version is building on SnowLeopard, >>>>>>>>>> but just not enabled? Does it rely on new constants that are only on >>>>>>>>>> Lion? >>>>>>>>>> >>>>>>>>>> ~Mike >>>>>>>>>> >>>>>>>>>>> On Dec 19, 2011, at 10:50 AM, Mike Swingler wrote: >>>>>>>>>>> >>>>>>>>>>>> Bino, I thought we contributed all of the Kerberos implementation >>>>>>>>>>>> (including the new SCDynamicStore implementation for Lion). Do you >>>>>>>>>>>> think the system kinit and the SCDynamicStore versions aren't >>>>>>>>>>>> playing ball with each other? Weijun, what version of Mac OS X are >>>>>>>>>>>> you testing on? 10.6 or 10.7? >>>>>>>>>>>> >>>>>>>>>>>> ~Mike >>>>>>>>>>>> >>>>>>>>>>>> On Dec 18, 2011, at 10:49 PM, Jeannette Hung wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hey Mike, >>>>>>>>>>>>> What's the scope with the Kerberos code in the macos port? It >>>>>>>>>>>>> looks >>>>>>>>>>>>> like something is missing. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks >>>>>>>>>>>>> jeannette >>>>>>>>>>>>> >>>>>>>>>>>>> Begin forwarded message: >>>>>>>>>>>>> >>>>>>>>>>>>>> *From: *Weijun Wang<[email protected] >>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>>>>>> *Subject: **Some Mac JDK codes not open sourced (was Fwd: Re: >>>>>>>>>>>>>> Kerberos codes in Apple's Java)* >>>>>>>>>>>>>> *Date: *December 15, 2011 6:52:18 PM PST >>>>>>>>>>>>>> *To: *Frances Ho<[email protected] >>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>>>>>> *Cc: *Jeannette Hung<[email protected] >>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Frances >>>>>>>>>>>>>> >>>>>>>>>>>>>> I suspect some Kerberos native codes on Apple's JDK 6 are not >>>>>>>>>>>>>> included in their macosx-port OpenJDK 7 contribution. I've >>>>>>>>>>>>>> contacted with some Apple guys but get no answer until now. (see >>>>>>>>>>>>>> forwarded mail thread) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Do we have a project/product manager that can talk to someone >>>>>>>>>>>>>> inside Apple on this? >>>>>>>>>>>>>> >>>>>>>>>>>>>> In my opinion, these are not sensitive codes that they cannot >>>>>>>>>>>>>> open >>>>>>>>>>>>>> source. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> Max >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -------- Original Message -------- >>>>>>>>>>>>>> Subject: Re: Kerberos codes in Apple's Java >>>>>>>>>>>>>> Date: Thu, 01 Dec 2011 22:54:57 +0800 >>>>>>>>>>>>>> From: Weijun Wang<[email protected] >>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>>>>>> To: Bino George<[email protected]<mailto:[email protected]> >>>>>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>>>>>> CC: [email protected] >>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>> <[email protected] >>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>> <mailto:[email protected]>>, >>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Bino >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2. Reading native memory-based credentials cache into >>>>>>>>>>>>>>>> Credentials objects >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I don't think we do this in JDK6 either. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I just tried OS X's builtin kinit and klist command: >>>>>>>>>>>>>> >>>>>>>>>>>>>> $ kinit dummy >>>>>>>>>>>>>> Please enter the password for [email protected] >>>>>>>>>>>>>> <mailto:[email protected]> >>>>>>>>>>>>>> <mailto:[email protected]>: >>>>>>>>>>>>>> $ klist >>>>>>>>>>>>>> Kerberos 5 ticket cache: 'API:Initial default ccache' >>>>>>>>>>>>>> ... >>>>>>>>>>>>>> >>>>>>>>>>>>>> So here the ccache name is "API:Initial default ccache", which >>>>>>>>>>>>>> looks >>>>>>>>>>>>>> like an in-memory ccache. At least I cannot find normal >>>>>>>>>>>>>> file-based >>>>>>>>>>>>>> ccache file named /tmp/krb5cc_**. >>>>>>>>>>>>>> >>>>>>>>>>>>>> There is also a difference between Apple's JDK 6u29 and the >>>>>>>>>>>>>> current >>>>>>>>>>>>>> macosx-port OpenJDK build when calling the following method: >>>>>>>>>>>>>> >>>>>>>>>>>>>> sun.security.krb5,Credentials.acquireTGTFromCache() >>>>>>>>>>>>>> >>>>>>>>>>>>>> It returns a valid credential (which is identical to the klist >>>>>>>>>>>>>> output) >>>>>>>>>>>>>> in Apple's 6u29, but the macosx-port one returns null. So it >>>>>>>>>>>>>> seems the >>>>>>>>>>>>>> Apple JDK can see the special ccache object but macosx-port >>>>>>>>>>>>>> cannot. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> Max >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Regards >>>>>>>>>>>>>>> Bino. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Oct 14, 2011, at 10:38 AM, Weijun Wang wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Mike >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm working in the Java SE Security Team in Oracle. Apple's >>>>>>>>>>>>>>>> JRE (at >>>>>>>>>>>>>>>> least in the JDK 6 releases) supports some extra Kerberos >>>>>>>>>>>>>>>> features for >>>>>>>>>>>>>>>> OS X. As I know, at least there are: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1. Looking for krb5.conf at >>>>>>>>>>>>>>>> /Library/Preferences/edu.mit.Kerberos >>>>>>>>>>>>>>>> 2. Reading native memory-based credentials cache into >>>>>>>>>>>>>>>> Credentials objects >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I didn't see them on the Project Status page [1]. Is it >>>>>>>>>>>>>>>> because they >>>>>>>>>>>>>>>> are too trivial to be listed or you're not going to support >>>>>>>>>>>>>>>> them? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>> Max >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>>> http://wikis.sun.com/display/OpenJDK/Mac+OS+X+Port+Project+Status >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >
