KDE and smartcard support

[Oswald Buddenhagen]

On Wed, May 23, 2007 at 12:10:11PM -0600, Aaron J. Seigo wrote:
> let's say that this ends up with us using QCA everywhere. who knows,
> that might be the solution. to reach that one can rewrite all pieces
> of KDE crypto all at once in some massive branch in svn (which, i hope
> you'll agree, unrealistic and silly) or we can work things out piece
> by piece.
> 
hmm? who exactly said everything needs to migrate to QCA immediately?
alon just wants a verdict "yes, we want this", so he can start
contributing code which he knows won't go down the drain.

> it's not an all-or-nothing thing. 
> 
yes, exactly.
that doesn't change the fact that the framework itself needs to be
designed to support "everything" from the start. i assume it has been.
it's already there, you know.

> 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.
requesting tokens is the task of the particular provider. it might use
KPD or whatever else it deems appropriate. technically this is an almost
trivial issue - just like the implementation of KPD.

> > just face it, it's one big complex that needs a coherent solution.
> > if it was done right, qca is this solution. building anything around
> > it would be pretty pointless.
> 
> i think you're misunderstanding something here: the idea is not to
> reimplement QCA, the idea is to mate QCA into the existing application
> contact points in kdelibs.
> QCA (or whatever) should be an implementation detail.
> 
this works for individual classes (in theory), and it's sort of
self-evident (one would think).
but there is this fine distinction between theory and practice. i loathe
huge black boxes that claim to do everything for me but fail at the
first "interesting" task, and i have no way to teach it to them because
everything is an "implementation detail".
also, there will be applications that don't need some "crypto enabled"
high-level kde frameworks, but just plain crypto. fine, you say - they
are free to use qca. or openssl. or gnutls. or ... - but choice doesn't
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.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.