Well it is a security risk sure, a bad guy could put a malicious libneko.so next to a neko executable, and if this exe has some special security authorizations then he gets these permissions, but you’re not supposed to put these kind of exe in a user writable directory anyway.
So I can understand Nicolas’ concerns since you can use neko to do any kind of application, maybe that’s worrying too much maybe not.
But since it’s unlikely you’d use openfl to make a security sensitive app and not a game that’s not really a problem. Personally I think we should replace the neko template with this version, and copy libneko.so, std.ndll … too to the export folder, that way you can ship the folder to someone who don’t have neko. (@singmajesty that’s probably required for the new deploy command right?)
I’m hoping that pull request goes through, and that’s all we need. Even without waiting, we could include updated Neko Linux binaries in our templates, if this is all we need to solve it
If it does solve it, then I think with a little work, the cross-desktop behavior could be patched up in the tools. My intention was to make “lime test windows” use C++ by default if you’re using Windows (unless you specify -neko) but to make “lime test windows” use Neko by default if you’re not using Windows, and instead generate a Neko build
Are there any updates on this @ibilon or @singmajesty ? The last update to this thread was about three weeks ago. I didn’t see the Haxe PR go through yet either.
Time flies, well if the pr doesn’t pass I guess the simplest would be to build neko linux ourselves with the modification and update the bundled version.
Since we’d have to change the version in the template if neko is updated anyway.
