Swift on Linux support about rethink-swift

[pixelspark]

Hi @demom! I am not currently working on Linux support, but this certainly would be interesting to have. I think the main issue is porting the network code (the driver currently uses GCDAsyncSocket, but there should be a Linux alternative available for that).

So feel free to give it a try and let me know if there's anything I can do.

/Tommy :)

[johnbona]

Hi @pixelspark!

Now that SPM support is in #7, I'm currently working on Linux support but going to have to switch GCDAsyncSocket and SCRAM to Swift-based implementations.

Do you prefer having two separate smaller PR's (one for networking and one for SCRAM) instead of one larger PR? Almost completed converting the network code over to vapor/socks.

[pixelspark]

Great to hear you're working on Linux support, @johnbona! Smaller PR's are preferred as they are a bit easier for me to test/review. Not sure what you had in mind re/ SCRAM, I guess it shouldn't be too difficult to rewrite in Swift and remove any Objective C code altogether (assuming vapor/socks works on macOS too?)

[johnbona]

Vapor/socks works on macOS as well.

Wanted to get your thoughts on crypto. CryptoSwift is all Swift but requires, on average, 130.55 ms to generate the HMACs when performing SCRAM auth. Vapor's crypto library does have a C dependency (LibreSSL) but on average only takes 32.54 ms for the same test.

Have SCRAM auth working using vapor/crypto at the moment but if you prefer not having C dependencies, I can switch over. 👍

krzyzanowskim/CryptoSwift	vapor/crypto
112.425982952118 ms	39.5439863204956 ms
138.751983642578 ms	29.2920470237732 ms
133.029997348785 ms	29.2499661445618 ms
125.846982002258 ms	29.9699902534485 ms
142.695963382721 ms	34.6269607543945 ms

[pixelspark]

@johnbona that's quite a difference in performance! Did you compile CryptoSwift in release mode with all optimizations turned on?

Ideally speaking we'd be fully Swift native - as the SCRAM authentication is only performed once when a connection is established, I don't think the lower performance is an issue. If we can be sure that libressl (or equivalent) is available on all platforms we compile on, then on the other hand I don't think we should use a separate implementation. So for now, feel free to stick with your libressl based solution if that gets the Linux port out of the door faster - we can always still switch to CryptoSwift afterwards.

[jrahaim]

What is the status of getting this working on Linux? Package manager seems to be working fine, but what about the Crypto and GCD Stuff? is there anything I can help with?

[pixelspark]

@jrahaim no news from my side but perhaps @johnbona has made some progress?

[matthijs2704]

Any news regarding this @johnbona, @pixelspark ?

[pixelspark]

@matthijs2704 sorry, no news from my side. Haven't heard from @johnbona either. His last work on this is from september last year (see https://github.com/johnbona/rethink-swift). Now assuming this contains the SCRAM stuff, I think the only other thing to do is to start using a portable sockets layer (could be vapor/socks or IBM-Swift/BlueSocket). Shouldn't be too difficult - anyone wants to step up?

[matthijs2704]

@pixelspark I just noticed that that fork already got merged into this one! I thought I'd give it a shot to move to Vapor/Sockets. I'll create a PR for that, so you can check what I've done.

[matthijs2704]

For Linux support also the SCRAM stuff needs to be rewritten in Swift (Swift on linux does not support Obj-C code). I've started doing this on matthijs2704/rethink-swift on the linux-travis branch. If you have a little spare time, could you take a look at it, as I'm not able to rewrite the xor function (in Utils.swift) in a way it matches the obj-c version, therefore the authentication doesn't work...

[pixelspark]

@matthijs2704 have you seen this? https://github.com/CryptoKitten/SCRAM

[matthijs2704]

Yes I have and I have used that. But CryptoKitten is deprecated and the source pretty outdated, so I had to update it. But for some reason the xor from the current SCRAM givs a different output from the CryptoKitten varient

[pixelspark]

Hm. Might be some endianness issue then?

[matthijs2704]

@pixelspark fixed it! Now I 'only' need to figure out why the data isn't being sent on Linux...