Review Request 123593: [WIP] Refactored code to implement ssl and provide backward compatibility

Vineet Garg grg.vineet at gmail.com
Wed May 27 15:08:05 UTC 2015



> On May 27, 2015, 4:08 a.m., Albert Vaca Cintora wrote:
> > src/org/kde/kdeconnect/Backends/LanBackend/LanLink.java, line 75
> > <https://git.reviewboard.kde.org/r/123593/diff/2/?file=370817#file370817line75>
> >
> >     If the public key never changes, we can just initialize it in the constructor and never refresh it. Or does it change?

It changes if we have a pairing, as after pairing we will get a PublicKey, that is why I used a reinitialiseLink which is called from pairing done.


> On May 27, 2015, 4:08 a.m., Albert Vaca Cintora wrote:
> > src/org/kde/kdeconnect/Backends/LanBackend/LanLink.java, lines 104-108
> > <https://git.reviewboard.kde.org/r/123593/diff/2/?file=370817#file370817line104>
> >
> >     I think sending payloads won't work calling encrypt() before this function. This is because we need to call encrypt *after* we call setPayloadTransferInfo() and now it happens before. Can you make sure sending a file from your phone works this way, or otherwise change it back? 
> >     
> >     I might be wrong, but I remember the encryption call was inside the function for this reason (even though it looks better outside, I agree :).

Yes, payload transfer info will not be set then. Will revert it back using a useEncryption boolean in sendPackageInternal instead and encrypting it according to that boolean instead of public key.


- Vineet


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


On May 26, 2015, 1:11 p.m., Vineet Garg wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/123593/
> -----------------------------------------------------------
> 
> (Updated May 26, 2015, 1:11 p.m.)
> 
> 
> Review request for kdeconnect and Albert Vaca Cintora.
> 
> 
> Repository: kdeconnect-android
> 
> 
> Description
> -------
> 
> * Moved private key and public key from Device to Link
> * Encrypt and decrypt functions moved from NetworkPackage class to LanLink class
> * Added a new ParingHandler class so that each type of link can handle its own pairing process
> * Added a field of "type" in device so that we can differentiate between devices based on types
> * Now device need to send which type of link they will prefer in identity package, if nothing is send, the type is considered "normal". No change is done in createIdentityPackage now.
> 
> ISSUES
> * SFTP plugin is not working now, because it uses public key from device which is not present now
> * There is an instance of Public Key in pairing handler also, which needs to be removed, this instance is only used to save public key when pairing is done
> 
> 
> Diffs
> -----
> 
>   src/org/kde/kdeconnect/Backends/BaseLink.java 579a7af 
>   src/org/kde/kdeconnect/Backends/LanBackend/LanLink.java 5994142 
>   src/org/kde/kdeconnect/Backends/LanBackend/LanLinkProvider.java ae26958 
>   src/org/kde/kdeconnect/Backends/LoopbackBackend/LoopbackLink.java add92f8 
>   src/org/kde/kdeconnect/Backends/LoopbackBackend/LoopbackLinkProvider.java bd9c41b 
>   src/org/kde/kdeconnect/BackgroundService.java 855a52d 
>   src/org/kde/kdeconnect/Device.java 0d9d9b1 
>   src/org/kde/kdeconnect/Helpers/SecurityHelper/RsaHelper.java PRE-CREATION 
>   src/org/kde/kdeconnect/NetworkPackage.java e5a777e 
>   src/org/kde/kdeconnect/Plugins/SftpPlugin/SftpImpl.java ec41060 
> 
> Diff: https://git.reviewboard.kde.org/r/123593/diff/
> 
> 
> Testing
> -------
> 
> Testing done with pairing and unpairing both pc and mobile, working fine
> Tested using Ping plugin and Touchpad plugin, working fine.
> 
> 
> Thanks,
> 
> Vineet Garg
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20150527/985d2224/attachment.html>


More information about the KDEConnect mailing list