directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot>
Subject Re: Status...
Date Fri, 05 Apr 2013 11:51:59 GMT

It's more or less what I was thinking.
3.6 is a good lowest target.

Thanks Jeff.


On 5 avr. 2013, at 13:46, Jeff MAURY <> 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 <> wrote:
> Hi Stefan,
> On 4 avr. 2013, at 21:20, Stefan Seelmann <> 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 <> 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 <>
> >>> 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
> >>>
> >>> 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

View raw message