I have the interest of using Kotlin to provide nat...

# kotlin-native

[bmsantos]

I have the interest of using Kotlin to provide native functions and expose them through node ffi

[napperley]

bmsantos: If Kotlin Native were to support Web Assembly then it would be safe to assume that Node FFI is supported as well.

[napperley]

Is the interest on the client or server?

[bmsantos]

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

[bmsantos]

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.

[bmsantos]

Rust, just like Kotlin Native is plugging into LLVM to generate machine code. So, I suspect that it should just work.

[napperley]

Using Node on the server would have many security issues (many of them serious) ❗

[bmsantos]

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

[napperley]

At least you advised him. If the project turns pear shaped you have your escape hatch 😉

[nish]

If you plan on using this in production, It’s worth noting that it’s in 0.3

[nish]

it’s still in eap. However you can export C++ functions

[nish]

https://github.com/JetBrains/kotlin-native/blob/master/runtime/src/launcher/kotlin/konan/start.kt

[janvladimirmostert]

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

[napperley]

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

[napperley]

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

[tunedal]

@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.)

[janvladimirmostert]

Dynamic typing is probably the biggest weakness between all of them.

[janvladimirmostert]

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.

[bmsantos]

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.

[tunedal]

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

[bmsantos]

Yes. This is not a Kotlin issue. It’s a NodeJS architectural issue.

[tunedal]

But would you say "Using Kotlin coroutines on the server would have many security issues (many of them serious)"?

[tunedal]

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

[bmsantos]

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.

[bmsantos]

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.

[napperley]

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

[bmsantos]

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)

[bmsantos]

There’s slow…. and then there’s JS! 😄