Review Request 124312: Initial SSL implementation

Tue Jul 21 22:42:36 UTC 2015

> On July 20, 2015, 10:28 p.m., Albert Vaca Cintora wrote:
> > core/backends/lan/server.h, line 28
> > <https://git.reviewboard.kde.org/r/124312/diff/3/?file=386055#file386055line28>
> >
> >     Can you add a comment explaining why did you have to extend QTcpServer? ie: why was not enough to just use it directly.
> 
> Vineet Garg wrote:
>     On using QTcpServer directly it binds QTcpSocket to native socket descriptor, setting SSL configuration to it is not possible. By using custom server QSslSocket is binded to native socket descriptor and QSslSocket is returned by nextPendingConnection instead of QTcpSocket.

Add it as a comment in the code.

> On July 20, 2015, 10:28 p.m., Albert Vaca Cintora wrote:
> > core/device.cpp, lines 212-213
> > <https://git.reviewboard.kde.org/r/124312/diff/3/?file=386067#file386067line212>
> >
> >     This long chain of -> looks bad. Change this to be a Q_FOREACH(PairingHandler handler, pairingHandlers). You should have a way to get all the pairing handlers to do that. Now, you are only going through the pairing handlers of the providers which can currently see the device, instead of all.
> 
> Vineet Garg wrote:
>     I told you earlier that there can be two approaches, pair one time and use a some kind of meta pairing package with all info. This is where we need all pairing handlers at one. In current approach device will be paired using the availaible link. Later if some some other links tries to connect and find out that the device is paired but needed data is not their, it will send pairing request automatically. Like if device is paired and certificate or public key is not there it will send a pairing request automatically. Since it is paired from other side too, other side will respond automatically. The automatic response is already added but and an automatic pairing request is not yet added here, but added on Android side.

My point is: If you need to chain three -> it means that things are not where you need them.

> On July 20, 2015, 10:28 p.m., Albert Vaca Cintora wrote:
> > core/device.cpp, lines 284-286
> > <https://git.reviewboard.kde.org/r/124312/diff/3/?file=386067#file386067line284>
> >
> >     Should be done in the pairing handler.
> 
> Vineet Garg wrote:
>     But it's not related to pairing. It is how I set the certificate by adding it to identity package after handshake.

The certificate is for SSL pairing what the public key is for non-SSL pairing. If the public key is managed by the handler, this should be as well, no?

> On July 20, 2015, 10:28 p.m., Albert Vaca Cintora wrote:
> > core/device.cpp, line 474
> > <https://git.reviewboard.kde.org/r/124312/diff/3/?file=386067#file386067line474>
> >
> >     Split into storeDevicPublicKey and storeDeviceCertificate. PS: Actually I see that you already started doing that with setDeviceProperty and getDeviceProperty, even though you never used it. That seems a better approach than this.
> 
> Vineet Garg wrote:
>     What about adding a generalised addTrustedDevice funtion with a QMap as input ?

I don't like it either. Let's keep the addTrustedDevice with both things for now.

- Albert

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124312/#review82739
-----------------------------------------------------------

On July 19, 2015, 9:33 a.m., Vineet Garg wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124312/
> -----------------------------------------------------------
> 
> (Updated July 19, 2015, 9:33 a.m.)
> 
> 
> Review request for kdeconnect.
> 
> 
> Repository: kdeconnect-kde
> 
> 
> Description
> -------
> 
> * Similar to Android version, this SSL implementation supports old version also.
> * Certificate is generated when public key is generated using QCA, but used as QSslCertificate because QSslSocket don't like QCA certificate.
> * A new server is written overriding QTcpServer for setting socket descriptor to QSslSocket.
> * QSslSocket works as plain socket to transfer identity package and then either uses encrypted mode or normal mode according to the received package.
> * If connetion is to be on SSL, new link is only added after successful handshake.
> * Certificate is embedded into identity package on start of encrypted mode and then set in device using it.
> * PairingHandler is added like in Android version so that each LinkProvider manage pairing according to its own rules.
> 
> P.S. : Uploaded the patch with some debug statements, will comment out them.
> 
> 
> Diffs
> -----
> 
>   cli/kdeconnect-cli.cpp 3aa49e5 
>   core/CMakeLists.txt dd8fedb 
>   core/backends/lan/CMakeLists.txt 7c5be38 
>   core/backends/lan/downloadjob.h eeeab07 
>   core/backends/lan/downloadjob.cpp bba2e98 
>   core/backends/lan/landevicelink.h 7d31881 
>   core/backends/lan/landevicelink.cpp 0987057 
>   core/backends/lan/lanlinkprovider.h b379434 
>   core/backends/lan/lanlinkprovider.cpp f5d2b22 
>   core/backends/lan/lanpairinghandler.h PRE-CREATION 
>   core/backends/lan/lanpairinghandler.cpp PRE-CREATION 
>   core/backends/lan/server.h PRE-CREATION 
>   core/backends/lan/server.cpp PRE-CREATION 
>   core/backends/lan/socketlinereader.h b3be55a 
>   core/backends/lan/socketlinereader.cpp a6bd85e 
>   core/backends/lan/uploadjob.h 12b6f7e 
>   core/backends/lan/uploadjob.cpp b0d35fc 
>   core/backends/linkprovider.h f4fc309 
>   core/backends/pairinghandler.h PRE-CREATION 
>   core/backends/pairinghandler.cpp PRE-CREATION 
>   core/daemon.h 674ca01 
>   core/daemon.cpp af4c67b 
>   core/device.h 03f528c 
>   core/device.cpp c2dc609 
>   core/kdeconnectconfig.h af6c6df 
>   core/kdeconnectconfig.cpp 919505c 
>   core/networkpackage.h 6a0bf9c 
>   core/networkpackage.cpp 64cfab7 
>   tests/CMakeLists.txt b00a574 
>   tests/testsocketlinereader.cpp 77a9b4b 
> 
> Diff: https://git.reviewboard.kde.org/r/124312/diff/
> 
> 
> Testing
> -------
> 
> * Working fine, tested using connection to Android devices.
> * Pairing handler needs to be tested using two LinkProvider, working fine with one, but there be some problems with two LinkProviders simultaneouly.
> 
> 
> Thanks,
> 
> Vineet Garg
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20150721/6e470767/attachment-0001.html>