You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lécharny <el...@gmail.com> on 2013/04/02 19:53:52 UTC
Status...
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
Re: Status...
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
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 <je...@jeffmaury.com> 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 <pa...@marcelot.net> wrote:
> Hi Stefan,
>
> On 4 avr. 2013, at 21:20, Stefan Seelmann <ma...@stefan-seelmann.de> 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 <je...@jeffmaury.com> 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 <pa...@marcelot.net> 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
Re: Status...
Posted by Jeff MAURY <je...@jeffmaury.com>.
Depends of the version of RAD or OEP.... [?]
Jeff
On Fri, Apr 5, 2013 at 1:55 PM, Emmanuel Lécharny <el...@gmail.com>wrote:
> Le 4/5/13 1:46 PM, Jeff MAURY a écrit :
> > 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
>
> One thing to consider is the version used by tools like IBM RAD or
> Oracle Enterprise pack.
>
> I have no idea which Eclipse version they are both based...
>
>
> --
> 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
Re: Status...
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 4/5/13 1:46 PM, Jeff MAURY a écrit :
> 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
One thing to consider is the version used by tools like IBM RAD or
Oracle Enterprise pack.
I have no idea which Eclipse version they are both based...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Status...
Posted by Jeff MAURY <je...@jeffmaury.com>.
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 <pa...@marcelot.net>wrote:
> Hi Stefan,
>
> On 4 avr. 2013, at 21:20, Stefan Seelmann <ma...@stefan-seelmann.de> 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 <je...@jeffmaury.com> 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 <
> pa@marcelot.net> 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
Re: Status...
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
Hi Stefan,
On 4 avr. 2013, at 21:20, Stefan Seelmann <ma...@stefan-seelmann.de> 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 <je...@jeffmaury.com> 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 <pa...@marcelot.net> 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
Re: Status...
Posted by Stefan Seelmann <ma...@stefan-seelmann.de>.
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.
> On 3 avr. 2013, at 17:10, Jeff MAURY <je...@jeffmaury.com> 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 <pa...@marcelot.net> 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 :(
Kind Regards,
Stefan
Re: Status...
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
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.
Regards,
Pierre-Arnaud
On 3 avr. 2013, at 17:10, Jeff MAURY <je...@jeffmaury.com> 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 <pa...@marcelot.net> 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 <el...@gmail.com> 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
Re: Status...
Posted by Jeff MAURY <je...@jeffmaury.com>.
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 <pa...@marcelot.net>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 <el...@gmail.com> 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
Re: Status...
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
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 <el...@gmail.com> 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
>
Re: Status...
Posted by Kiran Ayyagari <ka...@apache.org>.
On Tue, Apr 2, 2013 at 11:23 PM, Emmanuel Lécharny <el...@gmail.com>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 !
>
the mavibot partition tests are passing, some more testing is needed
after which I will conduct some initial performance tests.
>
> 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.
>
> bulk loading utility is ready for use and it currently creates in-memory
B+TreeS
we can switch to the persistent mode once the disk format and other storage
related
tasks complete in Mavibot
> 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 !
>
> IMHO, this is indeed a cool improvement (we can have revision based
backups too!)
> 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 !
>
> thanks Emmanuel
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
--
Kiran Ayyagari
http://keydap.com