https://kotlinlang.org logo
Title
b

bmsantos

06/25/2017, 1:12 AM
I have the interest of using Kotlin to provide native functions and expose them through node ffi
n

napperley

06/25/2017, 1:29 AM
bmsantos: If Kotlin Native were to support Web Assembly then it would be safe to assume that Node FFI is supported as well.
Is the interest on the client or server?
b

bmsantos

06/25/2017, 1:31 AM
Node FFI just calls c libs. If Kotlin Native (and I have yet to play with kotlin native) can be used to generate c like libs and have its methods public exposed and not mangled, it should just work
the interest is for server side. the idea in this case to offload RSA ciphering functions from JS to parallelized native code. It can be done in Rust or C/C++. It would great if it could be done in Kotlin to.
Rust, just like Kotlin Native is plugging into LLVM to generate machine code. So, I suspect that it should just work.
n

napperley

06/25/2017, 1:38 AM
Using Node on the server would have many security issues (many of them serious)
b

bmsantos

06/25/2017, 1:48 AM
Funny you mention that! I have warned the customer, but he insists in using it. It’s a battle that I’ve recently gone through but that I could not win….
n

napperley

06/25/2017, 1:58 AM
At least you advised him. If the project turns pear shaped you have your escape hatch 😉
n

nish

06/25/2017, 4:23 AM
If you plan on using this in production, It’s worth noting that it’s in 0.3
it’s still in eap. However you can export C++ functions
j

janvladimirmostert

06/25/2017, 6:31 AM
@napperley what kind of security issues? I always assumed it's less secure due to it running JS, are there any specific things or case studies exploring these vulnerabilities?
n

napperley

06/25/2017, 6:37 AM
One brief knowledge base article (https://www.veracode.com/security/javascript-security) mentions XSS (Cross Site Scripting) and CSRF (Cross Site Request Forgery) as some of the security issues. Stackoverflow covers HTML injection (https://stackoverflow.com/questions/3793246/javascript-security-risks).
Here is a really good Stackoverflow Q&A (https://softwareengineering.stackexchange.com/questions/206558/why-does-the-us-government-disallow-dynamic-languages-for-secure-projects) that covers the general security risks in detail that apply to dynamic languages (including JS).
o

olonho

06/25/2017, 8:25 AM
small obstacle, which we could fix with the next release, is the fact, that for Node FFI you need to produce shared object/dll, while currently by default we link an executable on non-Android targets. Other than that, and potential performance implications, seems Kotlin/Native could be used with Node FFI.
👍 1
t

tunedal

06/26/2017, 11:25 AM
@napperley XSS and CSRF are browser issues, not language issues. Injection vulnerabilities come from incorrect encoding in protocols and data formats, not from the language. None of this is specific to JavaScript or Node, so saying Node has "many security issues (many of them serious)" seems a bit alarmist. (But I would be interested to learn of any serious issues that make it more insecure than for example Ruby, Python, Perl and PHP.)
j

janvladimirmostert

06/26/2017, 11:26 AM
Dynamic typing is probably the biggest weakness between all of them.
And
eval
-like functions in Ruby, JS and PHP is probably the other issue. Perl and Python can probably interprid text as well and just execute it.
b

bmsantos

06/26/2017, 1:31 PM
There’s a plethora of issues with nodejs, security, performance, efficient deployment, etc. Due to the way the event-loop works, if an async callback takes a bit too long, then your system will be easily vulnerable to DoD attacks. This is also problematic if you are trying to keep SLAs guarantees. If this starts to happen, and it is not that hard, the only way is to introduce code complexity in order to try to navigate against all these issues.
t

tunedal

06/26/2017, 1:41 PM
The issue of async callbacks blocking the event loop also applies to Kotlin's coroutines, right? (And could be mitigated in both cases with a pool of processes or threads.)
b

bmsantos

06/26/2017, 2:08 PM
Yes. This is not a Kotlin issue. It’s a NodeJS architectural issue.
t

tunedal

06/26/2017, 2:14 PM
But would you say "Using Kotlin coroutines on the server would have many security issues (many of them serious)"?
Anyway, what I'm trying to say is that while "lack of threads and static typing" could certainly be a problem in some situations, it's not quite the same thing as "serious security issues".
b

bmsantos

06/26/2017, 2:28 PM
No, Kotlin with coroutines (glorified Promises) are not the issue. The issue is NodeJS and their single-threaded event-loop. Battling such limitation means adding code complexity using
process.nextTick()
or
setImmediate()
which are not easy to use and require loads of experimentation and measuring in order to place them right. Another way to get around this is by calling native code from system libs in C/C++/Rust and hopefully soon, also through Kotlin Native.
What this means is that companies are choosing to go with NodeJS based on the promise of being fast, simpler to use and because they believe that they can just use JS everywhere (in server and client sides). A big mistake.
n

napperley

06/27/2017, 2:39 AM
Fast is certainly misleading with JS. Web Assembly appeared on the scene partly because JS isn't fast enough in certain areas (eg games, image manipulation, data science/big data processing).
b

bmsantos

06/30/2017, 6:44 PM
Not fast at all! I just did a small test where I compared: - A full RSA encryption decryption in JS implementation - A Rust based RSA implementation with node bindings The tests where executed with Jest on node 8:
Full JS impl - Jest result
  ✓ Should encrypt code (2265ms)
  ✓ Should decrypt code (2293ms)

JS bindings to Rust impl:
  ✓ Should encrypt data (2ms)
  ✓ Should decrypt data (2ms)
There’s slow…. and then there’s JS! 😄