Community
Participate
Working Groups
The OS keychain should be utilized instead of the DefaultPasswordProvider on OS X. Zipped attachment to follow which provides this functionality.
Created attachment 97311 [details] Zip containing a new fragment which hooks into the os x keychain on carbon (and cocoa, in the future) I know of the following problems with this patch; A) I had to comment out a release of a storage token that is occasionally used in the setPassword function. For some reason it's causing an NPE within the JNI code and I haven't managed to figure out why yet. This should rarely be an issue, however - you'd only hit this when using the "change" feature from the preference page. B) the keychain sets up the access rights for the node such that the defining application has access. This wouldn't be an issue except that the defining app in this case may very well be java. It is this case in self-hosting, obviously, but this could be problematic if it gets the same result in a deployed app started in the traditional manner. I will attach the xcode project in another fashion - it appears to be too large to attach here.
Created attachment 97314 [details] Xcode project for the native library I had to delete a bunch of pre-cached symbol files to get this small enough to put on the bug. Hopefully those aren't important. :) The xcode project probably has my name embedded throughout it. Similarly, the project itself is a bit of a mess - I used the JNI template project to create the library and there are certain artifacts I cant get rid of. We may need an Xcode wizard to comb this project at some point and reduce it to its essential parts.
McQ: If I give you a built version of this plug-in tomorrow could you install it and give it the shakes?
yes.
Created attachment 97438 [details] Unified project with xcode.
Created attachment 97440 [details] Deployable plugin McQ: You should be able to put this in your dropins folder. It worked for me.
Thanks for the great work Kim. I am setting to 3.4 M7, I assume we want to attempt to put this in 3.4 and M7 is the last chance. Oleg, can you review and work with Kim to iron out the details. Kim, are you comfortable with providing needed support to ship this in 3.4?
(In reply to comment #7) > Thanks for the great work Kim. I am setting to 3.4 M7, I assume we want to > attempt to put this in 3.4 and M7 is the last chance. Oleg, can you review and > work with Kim to iron out the details. Kim, are you comfortable with providing > needed support to ship this in 3.4? > Provided McQ has no problems with me doing it, I'm good to go.
(In reply to comment #8) > (In reply to comment #7) > > ... Kim, are you comfortable with providing > > needed support to ship this in 3.4? > > > > Provided McQ has no problems with me doing it, I'm good to go. > As a fellow Mac user, I'm all for it. <g> Btw, I spent some time playing with Kim's plug-in this morning, and it seems to working fine for me (including with multiple repos). I am unlikely to get time to do more serious testing, though.
Created attachment 97489 [details] Updated based on discussions with Oleg Contained in this change: a) the name of the keystore key is now fixed at "equinox.secure.storage" for all applications (to prevent thrashing of the keystore) b) some minor refactoring in the java class c) I neglected to free the UTF strings in the natives. The new version of the native code (and compiled library) has these frees in place.
Created attachment 97490 [details] Updated deployable jar Note that if you start using this one after having used the original jar I've attached you are likely to invalidate your keystore (because we're now using a different key name, and subsequently, a different password). To get a clean test of this code you should delete the secure_preferences.equinox file in your home directory.
+1, great work Kim!
(In reply to comment #12) > +1, great work Kim! > Indeed. +1, thanks for the help Kim!!
+1 This is great work.... Now all we need is someone who can hack the gnome-keyring as fast :)
Adding Mike for PMC approval.
The new fragment added into CVS Head: org.eclipse.equinox/security/bundles/org.eclipse.equinox.security.osx (I fixed a few minor details in it like formatting, NLS, about.html.) Adding Kim M. to the CC list to see if we can incude it into builds.
I think it is important to be consistent with our macosx fragments. The fragment name should be org.eclipse.equinox.security.macosx (use macosx instead of osx).
Shouldn't the platform filter be this: Eclipse-PlatformFilter: (& (osgi.os=macosx) (|(osgi.arch=x86)(osgi.arch=ppc)) ) Currently it is Eclipse-PlatformFilter: (|(osgi.ws=carbon) (osgi.ws=cocoa)) This seems wrong. We don't really care what window system is used but we do care about the arch and os.
Created attachment 97518 [details] Test cases Oops! Forgot the test cases...
(In reply to comment #18) > Shouldn't the platform filter be this: > > Eclipse-PlatformFilter: (& (osgi.os=macosx) (|(osgi.arch=x86)(osgi.arch=ppc)) ) > > Currently it is > > Eclipse-PlatformFilter: (|(osgi.ws=carbon) (osgi.ws=cocoa)) > > This seems wrong. We don't really care what window system is used but we do > care about the arch and os. > This makes sense to me.
(In reply to comment #17) > I think it is important to be consistent with our macosx fragments. The > fragment name should be org.eclipse.equinox.security.macosx (use macosx instead > of osx). > Oleg: if you do this, you'll need to update the test case I just attached.
Fragment re-named as suggested in the comment 17 and added into CVS under: org.eclipse.equinox/security/bundles/org.eclipse.equinox.security.macosx The platform filter is updated as suggested in the comment 18 - that is a good catch, thank you. Kim H.: could you get the fragment from CVS and check to see if it still works? :-) You'll need to delete your secure storage file ("secure_preferences.equinox") as the provider's ID changed (it is the qualified extension ID). If not deleted you'll likely find some errors in the log file. JUnits: cool! when the fragment is in the builds I'll add/update them. The bug 228753 has been opened to remove equinox.security.osx from the repository.
(In reply to comment #22) > Fragment re-named as suggested in the comment 17 and added into CVS under: > > org.eclipse.equinox/security/bundles/org.eclipse.equinox.security.macosx > > The platform filter is updated as suggested in the comment 18 - that is a good > catch, thank you. > > Kim H.: could you get the fragment from CVS and check to see if it still works? > :-) > You'll need to delete your secure storage file ("secure_preferences.equinox") > as the provider's ID changed (it is the qualified extension ID). If not deleted > you'll likely find some errors in the log file. > > JUnits: cool! when the fragment is in the builds I'll add/update them. > > The bug 228753 has been opened to remove equinox.security.osx from the > repository. > Looks good to me!
Please update the map file with the new fragment and I'll update the feature and run a test build.
I tagged the org.eclipse.equinox.security.macosx project with v20080425-1136 and added the following line to the core.map. Kim we are ready for a test build, thanks. fragment@org.eclipse.equinox.security.macosx=v20080425-1136,:pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse,,org.eclipse.equinox/security/bundles/org.eclipse.equinox.security.macosx
(In reply to comment #24) > Please update the map file with the new fragment and I'll update the feature > and run a test build. > Kim, I noticed you updated the feature containing this bundle to specify that it was good for ppc, not x86. What impact will this have for us Intel Mac folks? Is there a way to specify that it works for both architectures or is there special magic for the Mac that delivers feature plugins for ppc to x86? I'm referring to org.eclipse.platform-feature/feature.xml...
I see two issues in the platform feature.xml. It specifies ppc only and it specifies os="mac" for the fragment: <plugin id="org.eclipse.equinox.security.macosx" os="mac" arch="ppc" download-size="0" install-size="0" version="0.0.0" fragment="true" unpack="false"/> I think the arch should be left unspecified and the os should be macosx: <plugin id="org.eclipse.equinox.security.macosx" os="macosx" download-size="0" install-size="0" version="0.0.0" fragment="true" unpack="false"/> This is the same as how the org.eclipse.core.filesystem.macosx fragment is specified.
thanks Tom, change released
Kim Horne, can this bug be closed now?
(In reply to comment #29) > Kim Horne, can this bug be closed now? > I think it can. It's been working for me in the last few builds.
Closing as Fixed. Thanks Kim.
Removing contributed. Kim is a committer on Eclipse so there is no need for the keyword. But we still appreciate the help Kim :)
