JeffI'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 LTSIf 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.From an ISV point of view, it is very common to support current version and previous version of products only.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.
On Fri, Apr 5, 2013 at 12:18 PM, Pierre-Arnaud Marcelot <firstname.lastname@example.org> wrote:Hi Stefan,
Yeah, I was also thinking about moving the target to something more recent.
On 4 avr. 2013, at 21:20, Stefan Seelmann <email@example.com> 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.
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.
If you guys, Stefan, Jeff, have any idea. ;-)
Don't be. Since the release of Studio, we didn't have so many complaints about it.
>> On 3 avr. 2013, at 17:10, Jeff MAURY <firstname.lastname@example.org> 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.
>>> On Wed, Apr 3, 2013 at 10:43 AM, Pierre-Arnaud Marcelot <email@example.com> 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 :(
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.
> Kind Regards,
"Legacy code" often differs from its suggested alternative by actually working and scaling.
- Bjarne Stroustrup