Ok. It's more or less what I was thinking. 3.6 is a good lowest target.
Thanks Jeff. Regards, Pierre-Arnaud On 5 avr. 2013, at 13:46, Jeff MAURY <[email protected]> wrote: > Regarding my product, the lowest supported version of Eclipse is 3.5 and it > is sometimes difficult to support. > I've never seen a customer site using this version. > From an ISV point of view, it is very common to support current version and > previous version of products only. > If you apply it to Eclipse and assumed that 4.2 is not a real version (due to > its failure), this give 3.7 and 3.6. > I've head that the Eclipse Foundation will now have LTS versions so this > could be interesting to see which Eclipse version they start from in LTS > > Jeff > > > > On Fri, Apr 5, 2013 at 12:18 PM, Pierre-Arnaud Marcelot <[email protected]> > wrote: > Hi Stefan, > > On 4 avr. 2013, at 21:20, Stefan Seelmann <[email protected]> wrote: > > > On 03.04.2013 17:23, Pierre-Arnaud Marcelot wrote: > >> Thanks Jeff. > >> > >> I did look at that before working on it. > >> But, as far as I remember it was requiring a more recent version of > >> Eclipse (3.5 maybe, I don't remember exactly) than what we currently > >> support (3.3 I guess). > >> So the API is not available. > >> > >> The fact that you don't need to provide a password to read the data is > >> interesting and that's exactly why I chose to make this optional in Studio. > >> I really think most of our users don't want to be asked a password when > >> connecting to a server. > >> But for people dealing with very sensitive server connection, the > >> passwords keystore is a must have. > > > > Hm, I wonder why we need to stick with the 3.3 API? I mean that version > > is more then 5 years old. And the RCP application is already up-to-date > > and used version 3.8. > > Yeah, I was also thinking about moving the target to something more recent. > It's just that there's already many things to do and not much time. > So I was a bit hesitant on adding another subject on my plate. > I don't know which version we should target as our minimum requirements these > days without upsetting too many users. > 3.6, 3.7? > If you guys, Stefan, Jeff, have any idea. ;-) > > >> On 3 avr. 2013, at 17:10, Jeff MAURY <[email protected]> wrote: > >> > >>> 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: > >>> 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. > > > > I agree that we need such a thing. I feel ashamed and careless that I > > implemented the password saving without proper security back then :( > > Don't be. Since the release of Studio, we didn't have so many complaints > about it. > Software gets improved over time. :) > I was talking with some colleagues here about how the connections are stored > and they were kind of surprised to see the connection passwords in the > connections file. > On the other hand, they are quite happy that Studio doesn't ask their > passwords all the time, so they agree that's a good compromise for > non-critical passwords. > That's why I think we shouldn't enforce it as a default value. > But for some users dealing with highly sensitive data, having an option to > securely save their connection passwords, with just the hassle of being ask > for a master password from time to time, is really needed. > It's going to be a great addition for Studio 2.0. > > Regards, > Pierre-Arnaud > > > Kind Regards, > > Stefan > > > > -- > 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
