KSecretService in KDE 4.6
lemma at confuego.org
Thu Oct 28 08:25:56 BST 2010
as announced at Akademy we would really like to get a first
implementation of ksecretservice into KDE 4.6 in order to further the
project and adoption of the new D-Bus API. However due to various
work-work and personal reasons I haven't been as productive as I would
have liked to be during the last month and - as a result - there are
some things left to do before ksecretservice can be merged into trunk.
When looking at the release schedule I was quite baffled. Somehow a
4-week period between soft and hard freeze was stuck to my mind.
Obviously the 2 weeks we are left with doesn't leave us with enough time
to finish everything needed to release AND have a proper review period.
Therefor I'd like to ask for an exception in order to still get
ksecretservice into KDE 4.6. We're very dedicated to the project and I
managed to get some time off work-work in order to improve the chances
of finishing in time.
The parts to be merged will be:
- A new implementation for KWallet::Wallet using the secrets storage
D-Bus API (ksecretserviced, gnome-keyring). It is meant to enable a
smooth transition to the new client API to be released with KDE 4.7. The
new implementation will not sport any new public API.
- A new daemon implementation called ksecretserviced which fully
replaces kwalletd and uses the new D-Bus API. It will end up in
This is the timeline which seems reasonable in order to finish:
04.11. Move both parts to kdereview
14.11. Merge with trunk
So this would involve both a shortened review period of 1.5 weeks as
well as merging after hard freeze. Tests are already in place and
extended in parallel to the actual code. We're well aware that angering
our users by releasing something that puts their secrets in danger is
not an option and are committed to either releasing quality or not
I'd be grateful if we could make this work somehow. If you have any
questions I'd be happy to answer them.
More information about the kde-core-devel