KDE and smartcard support

[Aaron J. Seigo]

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 
time
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 
platforms. 

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 
there.

> 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 
the other.

-- 
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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070523/8dc5cf5e/attachment.sig>