Improving KDEConnect encryption.

[Albert Vaca]

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
>>