KDE and smartcard support

[Aaron J. Seigo]

On Wednesday 23 May 2007, Oswald Buddenhagen wrote:
> On Wed, May 23, 2007 at 10:09:43AM -0600, Aaron J. Seigo wrote:
> > let's try and not confuse the issue further, please, Oswald... i'm not
> > saying "let's only look at one type of hardware" i'm saying "let's
> > concentrate on the issue of hardware based auth and not get lost
> > discussing every usage of crypto and authentication in KDE".
>
> that's still too narrow-minded. who would want two high-level systems
> that do exactly the same, just with different hardware (yes, the cpu is
> hardware, too)?
> concentrating on just one usage (auth) isn't wise, either. it's just a
> matter of time when things overlap.

regardless, auth is something that needs addressing. it's a concrete issue 
that we can start working on, unlike the hand-wavey "all crypto, all the 
time" stuff.

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.

the unfortunate thing here is that before working things out piece by piece, 
Alon seems to want people to commit to a huge vision that there simply isn't 
enough confidence in. Alon can direct his own work within this vision of his, 
but he doesn't need to convince everyone of it right now.

what is needed is code that shows how this particular use case is enabled and 
improved ... then we can move to the next pieces.

for instance, i really don't see how gpg signing in kmail is at all relevant 
to smart card enabled kio. the ultimate goal should be to have consistent 
smart card support, but that does not need to be the first goal. it's not an 
all-or-nothing thing. more to the point, i purport that it is simply not 
practical or realistic to expect that to be the initial goal.

prove the possibilities by solving the issues of getting KPasswordDialog to 
have a token input mode; get this working in KIO ... -then- let's move on.

does that make sense to you?

> 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. e.g. KPasswordDialog. if the app developer sees any QCA in 
KPasswordDialog itself, then it's a failure. QCA (or whatever) should be an 
implementation detail.

exposing QCA all over the place is a non-starter (just as, as has been pointed 
out, is exposing OpenSSL all over teh place), which naturally leads to the 
concept of API that works at the same level as the stuff in kdelibs.

> and tt should once embrace something, not clone 

it's obviously not that cut and dry, however i think andreas has already noted 
how things can improve in this manner in the future. so this isn't an issue.

-- 
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/8866f9df/attachment.sig>