Improving KDEConnect encryption.

[vineet garg]

I got it, that would be the real abstraction of links and that would also
not harm bluetooth backend which still needs the current encryption scheme
and where ssl can't be implemented.

On Sun, Mar 8, 2015 at 1:51 AM, Albert Vaca <albertvaka at gmail.com> wrote:

> That would mean that every link should now manage its own encryption
> (that actually makes a lot of sense), so a first step in the project
> should be a bit of refactoring to move everything related to
> encryption inside the link. Currently there are bits in NetworkPackage
> and in Device, so all this should be moved inside the specific link
> implementation, allowing every kind of link to have its own encryption
> mechanism.
>
> On Sat, Mar 7, 2015 at 12:10 PM, Albert Vaca <albertvaka at gmail.com> wrote:
> > Maybe the public keys have to be inside the specific link and not
> > inside Device then. This is something to consider, taking into account
> > what other links could need (bluetooth, online connection... are they
> > going to use key pairs, ssl sockets or something else?).
> >
> > On Sat, Mar 7, 2015 at 2:04 AM, vineet garg <grgvineet at gmail.com> wrote:
> >>
> >>
> >> 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/20150308/9084c012/attachment-0001.html>