DevHeads.net

Exposing KSSL in KIO

In KDE Telepathy one the tasks I'm currently doing is certificate
handling. We get the certificate from telepathy and have to prompt the
user if they want to accept an invalid certificate.
All the normal SSL work is done in this telepathy component shared by
gnome, but any user prompts have to go through us so we match our DE
and gnome can do their thing.

Looking at the documentation KIO has everything I need, namely
KSSLCertificate and KSSLCertDialog. Unfortunately the headers aren't
installed so that I can't use any of it. Even though I could duplicate
that code myself it would be nice to get a consistent interface.

Is this deliberate? If so, why?
Is there any way I can use it currently? (i.e can I just copy the
headers without getting in lots of trouble)
Could this be changed for Frameworks?

Dave

Comments

Re: Exposing KSSL in KIO

By Thiago Macieira at 04/05/2012 - 19:36

On quinta-feira, 5 de abril de 2012 21.41.00, David Edmundson wrote:
Then that's already wrong. Please make sure that the Telepathy component is
using the KDE certificates. You must add a way to set the certificates.

It's deliberate. The dialogs are internal API. KDE applications are supposed
to be using one of the socket classes.

I don't think so. The classes are likely not to be exported.

If you submit the changes, yes.

Re: Exposing KSSL in KIO

By david at 04/05/2012 - 20:14

On Fri, Apr 6, 2012 at 12:36 AM, Thiago Macieira < ... at kde dot org> wrote:
Sure, right now it's on an in-built simple fall back mode "if valid
accept, otherwise reject" using whatever method it uses. As soon as we
say "actually I want to do the certificates myself" then it becomes
our job to accept or reject all certificates, which is what I'm trying
to do at the moment.

What I was trying (badly) to say is we can only handle certificates.
We can't put the entire stream into a KIO::TcpSlaveBase, which I
assume is how most people would use KSSL indirectly, as it's not our
component.

Weirdly they are. At least there's a "KIO_EXPORT" in the class
definition in the header of KSSLCertificate.

Deal.

Re: Exposing KSSL in KIO

By Thiago Macieira at 04/06/2012 - 09:04

On sexta-feira, 6 de abril de 2012 01.14.34, David Edmundson wrote:
Then they are exported. I didn't check the file, I just spoke in terms of
likelihood (I can't think of anyone that would want to use them aside from KIO
handling).

If they are exported, you might be able to do what you want.

Re: Exposing KSSL in KIO

By Sune Vuorela at 04/07/2012 - 10:25

On 2012-04-06, Thiago Macieira < ... at kde dot org> wrote:
but please please pretty please don't. if headers aren't installed it
is not public api and then you should stay out of it. really.

/Sune

Re: Exposing KSSL in KIO

By Thiago Macieira at 04/07/2012 - 10:54

On sábado, 7 de abril de 2012 14.25.10, Sune Vuorela wrote:
Of course, that's implied.

If it's private API, you should not use it. If you insist, then you are
linking against something that might change at any minute, from release to
release. And distributions might refuse to package your software.

Re: Exposing KSSL in KIO

By George Kiagiadakis at 04/07/2012 - 18:55

On Sat, Apr 7, 2012 at 5:54 PM, Thiago Macieira < ... at kde dot org> wrote:
But, I really really doubt that anybody is going to do any important
change in the kdelibs 4.x series, especially in this piece of
obviously dead code that nobody knew it was there, exported. So, I
suggest that we use it in kde-telepathy and just make an agreement
that nobody is to touch this code in kdelibs 4.x (which probably
wouldn't happen anyway), for the next X months/years that it will take
us before the new shiny frameworks are ready. :)

Re: Exposing KSSL in KIO

By Thiago Macieira at 04/07/2012 - 19:18

On domingo, 8 de abril de 2012 01.55.06, George Kiagiadakis wrote:
That change you're proposing is very simple: install the header. From that
release on, it becomes public API.

PS: it's not dead code, it's in use by the SSL dialogs.