KDE and smartcard support
Aaron J. Seigo
aseigo at kde.org
Wed May 23 19:10:11 BST 2007
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
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
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
Size: 189 bytes
Desc: not available
More information about the kde-core-devel