KDE and smartcard support
Aaron J. Seigo
aseigo at kde.org
Thu May 24 01:35:43 BST 2007
On Wednesday 23 May 2007, Oswald Buddenhagen wrote:
> On Wed, May 23, 2007 at 02:17:43PM -0600, Aaron J. Seigo wrote:
> > so i think we're actually all on the same page. great =)
> great. and the verdict (from thiago, george, ...?) is ...?
> > > > prove the possibilities by solving the issues of getting
> > > > KPasswordDialog to have a token input mode;
> > >
> > > that one doesn't make too much sense. KPD cannot provide a universal
> > > token input mode - if this was possible, the entire kdm greeter
> > > plugin stuff would be thoroughly pointless.
> > what i mean is that KPD should be able to not only provision passwords
> > from the user to the application, but also it (or an analog of it)
> > should provide a user interface as well as an API for application
> > developers to easily request credentials via hardware based systems
> > (smartcard, fingerprint scanner, whatever) ...
> yes, i know. but this really makes no sense. the basic stuff is really
> trivial. and if KPD was versatile enough, configuring it properly would
> be more code than a purely custom solution.
> > > really work - the configuration framework needs to cover everything,
> > > so in any case we have to endorse the framework we are using
> > > internally - and if we switch, 3rd party developers (or rather, the
> > > users) would be pretty much screwed.
> > we've been there and done that already, just not with crypto but with
> > multimedia, hardware awareness, PIM data, etc. maybe we could learn
> > something from those lessons?
> mind elaborating some more (what went wrong, how this might be
> applicable to this case, etc.), particularly for alon & co.?
ah, sure.. so.. in the past kde had made decisions to use specific frameworks
that seemed to be quite good at the time; and indeed they were. however, one
of three things would happen:
a) the chosen framework would become unmaintained for an extended period of
b) another option that was in some way better would appear
c) we'd add support for a platform that wasn't supported by this framework
the end result in any case was lots of code specific to that framework that
was hard to maintain and left applications less featureful on certain
the approach has become in these cases to create entry points from the KDE API
to these frameworks, e.g. phonon to media backends rather than targetting
aRts directly (which is now unmaintained and essentially end of lifed) or
solid for hardware awareness instead of writing directly to HAL (which
currently doesn't exist on several of our supported platforms).
really, this is what Qt is as well.
so there is a certain amount of caution that is to be expected when a new
framework appears. especially when someone tries to get KDE to commit in a
very serious way to it.
we know OpenSSL. it has its warts (to say the last =) but at least it is the
devil we know; we're confident in its foundations and that it will continue
to be maintained.
so ... with QCA i think you'll find it much easier to get acceptance for it if
we start incrementally and prove its utility that way rather than asking for
an up-front commitment to it. the first step is probably to introduce it into
places where it won't result in application-visible code, e.g. kio and that
framework of classes.
> > i'd also be cautious about falling into the "perfect solution" trap.
> if you aim at perfection, you might get something acceptable. if you aim
> lower, you will ... oh, well. ;)
heh.. the flip side of that coin is to be content with acceptable once you are
> anyway, qca is there and i assume its concepts got some hammering. it
> can't get *that* bad, can it? :)
for all i know, qca is the best thing ever. i'm not disputing it one way or
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel