Please note that Eclipse provides such a functionality out of the box. The secure storage is managed by Eclipse and you just need to save your sensitive configuration data (password). There is no need to provide a password when reading the data (at least on Windows at Eclipse has an integration with the Windows authentication layer). I have used it in my Eclipse based product, and for security reasons, I choose to make it non optional.
Jeff On Wed, Apr 3, 2013 at 10:43 AM, Pierre-Arnaud Marcelot <[email protected]>wrote: > Very interesting things. > > Thanks Emmanuel and Kiran for your hard work on all that and sharing it > with us. :) > > On my side, I worked on fixing important bug fixes for issues that were > mainly introduced in the last release of Apache Directory Studio. > A release is ready, but I don't know if I should wait for a new release of > ApacheDS (fixing the bugs we have around password policies and stuff like > that) or release Studio ASAP (and eventually release another version when > ApacheDS is fixed) > > You tell me what's best. ;-) > > In the past week, I've been working on a interesting and very important > feature for Apache Directory Studio: secure storage of connections > passwords into a password-protected keystore. > > At the moment, when you check the "Save password" checkbox in the > properties of a connection, that password gets saved in the connections > file alongside other parameters like host, port, etc. > The problem is that the password is saved in clear text in the file and > that could be an issue for some users. > > So, the idea is to have an option (disabled by default) in Apache > Directory Studio to save the passwords of the connections in a keystore > protected by a "master password". This password would be asked when > accessing the password of a connection (opening a connection for example). > > This is a very low-level addition in Studio's code and a very sensitive > refactoring, so I'm extra cautious here. > > I really think we can't release a 2.0 version of Studio without this kind > of functionality. It's really a must-have. > > Regards, > Pierre-Arnaud > > On 2 avr. 2013, at 19:53, Emmanuel Lécharny <[email protected]> wrote: > > > Hi guys, > > > > it was two tough weeks, with merely no work on the server... But still, > > we made some progress on some side projects critical to ApacheDS. Let me > > provide some headsup. > > > > 1) We are making progress on Mavibot. Mavibot is the backend replacement > > for JDBM. Currently, we are able to manage the additions, deletions and > > modifications in it. The performances are good, assuming the right page > > size/nb of elements per page are correctly set (up to 13 000 updates per > > second). The searches are blasting fast : 1 600 000 lookup per second. > > > > Kiran has added support for multiValues in it, and is currently testing > > a partition for mavibot. I let him giving some feedback on this part, > > but I'm quite exited ! > > > > We have a lot to do, still. We currently never remove any revision, so > > the file keeps growing after each modification. Kiran is working on a > > bulk load mechanism. I'm working on a mechanism that reclaim the pages > > that are not anymore in use. > > > > We will have to add a way to access the old revisons too and I'm > > currently working on that. This will allow us to get rid of the > > ChangeLog system, as it will now be just a matter to switch to an old > > revision to get back to the previous data set. That will make the test > > way faster ! > > > > I expect to have Mavibot completed by the end of april. > > > > 2) MINA 3 is also on its way, and sounds promizing. It's already 50% > > faster than MINA2, which is a huge gap. I hope to be able to build a > > working prototype based on MINA 3 by the end of april too. > > > > 3) In the mean time, I think we can get a 2.0-RC1 released. We have > > fixed some serious bugs lately, and I don't think we will add new > > features in this version. > > > > All in all, I think that once 2.0 will be out, we will be able to switch > > to Mavibot backend and MINA 3, to get way better performances. > > > > 4) The documentation > > > > It *absolutely* sucks :/ I have tried to improve the Kerberos > > documentation last month, it was a lot of work, as the kerberos server > > was also quite buggy. There is a lot to do, since we switched to the new > > system last year, we haven't made a lot of progress in this area. This > > is true for the server but also for the API. I can't seriously see how > > we can get a 2.0-GA if the documentation is not improved in one way or > > another... It's useless to have a fast and working server, if no one > > know how to use it :/ > > > > That's pretty much it, Kiran, feel free to complete this mail. > > Pierre-Arnaud, sorry if I haven't mentionned what you have done on > > Studio, so please, feel free to add your progress ! > > > > Many thanks guys ! > > > > -- > > Regards, > > Cordialement, > > Emmanuel Lécharny > > www.iktek.com > > > > -- Jeff MAURY "Legacy code" often differs from its suggested alternative by actually working and scaling. - Bjarne Stroustrup http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.twitter.com/jeffmaury
