Improving KDEConnect encryption.

[vineet garg]

On Sat, Mar 7, 2015 at 2:58 PM, Albert Vaca <albertvaka at gmail.com> wrote:

> On Sat, Mar 7, 2015 at 1:06 AM, vineet garg <grgvineet at gmail.com> wrote:
> > Hi,
> >
> > I have a couple of suggestions on it.
> > First of all I would like to know how packages are distributed in
> kubuntu,
> > may be we could add a "check for update" button in kubuntu version of
> > application.
>
> No, we don't want to sneak around the distribution's packages manager.
> I'm actually a bit concerned about you suggesting this, first of all
> because we should care about every distribution, not only Kubuntu, and
> second because you say that you don't know how packages are
> distributed. What distro are you using that package distribution is a
> new thing for you?
>

I use Kubuntu and use Muon package manager and discover or apt-get to
install new packages, but I don't know how do we publish packages there.


> >
> > Or we could provide a link to old version of android application which
> does
> > not support ssl on application page of playstore.
>
> This is not user-friendly nor easy to maintain.
>
> >
> > Or the best one is to include "isSSLSupported" in identity package and
> have
> > a separate backend implementation for ssl and normal version, this would
> be
> > little difficult because simple socket can't connect to ssl server
> sockets
> > due to difference in protocols they follow, but it is achievable(May be
> we
> > need a SSLLanLink, SSLanLinkProvider and split Device into two, i.e
> normal
> > Device and SSLDevice).
> >
>
> This is in my opinion the way to go and I don't think it is that
> difficult. We should be able to have at the same time our current
> LanLinkProvider and a new SSLLinkProvider (maybe using a different
> port, so they don't clash). The Device should be completely unaware of
> the kind of Link that has underneath (that's the entire purpose of
> abstracting the links), so in no way we should need an SSLDevice.


The part I wrote about Device is because current Device class handles
public key, but we need to handle certificates in SSL, so we need to change
 that, we also need to change pairing callbacks to store certificate
instead of public keys.


> > I will further dig into it.
> >
> > Vineet Garg
> >
>
> Albert
>

Still, I get your point and will sort out this problem and I will include
it in my GSOC proposal.

Vineet Garg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20150307/10827db6/attachment.html>