Native extension installed in pub-cache shows "Cannot load native extensions over http: or https:"

[MikeMitterer]

I'm playing around with native extensions (https://github.com/MikeMitterer/cmake-dart-extension-master)
The extension works with "dart bin/random.dart" but after installing it via pub global activate native_sample or after pub global activate --source path . it shows

Cannot load native extensions over http: or https:

It's a miracle to me why we get no support for native extensions! It's all about JS interop - native extensions are the unloved stepchild - why????

Nativ lib is in "hosted"-folder:

> .pub-cache $ find . -iname "*.so"
./hosted/pub.dartlang.org/dartify-0.0.3/devtest/libdartified_extension.so
./hosted/pub.dartlang.org/dartify-0.0.3/devtest/libtest_extension.so
./hosted/pub.dartlang.org/dartify-0.0.3/example/libexample_extension.so
./hosted/pub.dartlang.org/native_sample-0.2.0/lib/native/libsample_extension.so

> .pub-cache $ find . -iname "*.dylib"
./hosted/pub.dartlang.org/native_sample-0.2.0/lib/native/libsample_extension.dylib
> .pub-cache $

[zanderso]

Unfortunately, the error message is correct. By design, the VM is not permitted to load a native extension that might be coming from the network.

Since I don't think there's anything we can do about this on the VM side, I'm going to add some other labels on this one.

[nex3]

Pub does not officially support native extensions; you're on your own with any issues you run into when using or trying to distribute them. Unofficially, this may work with 1.22 due to some optimizations in the way pub precompiles executables.

@zanderso

Unfortunately, the error message is correct. By design, the VM is not permitted to load a native extension that might be coming from the network.

This never made any sense to me. Any malicious VM code with access to dart:io can just download the extension to the local disk and spawn an isolate that loads it. So why not allow non-malicious code to do the same thing more easily?

[zanderso]

@nex3 Native extension loading is part of the VM, independent of the embedder. File IO from dart:io is provided by the embedder. In this design, an especially security conscious embedder could sandbox or disable file IO from Dart code, but still let the VM load native extensions.

[nex3]

So why not provide a flag that the embedder can disable (or the VM can enable)?

[MikeMitterer]

You labeled it as bug but you also closed the issue??? Is this because the (hopefully) unofficial support in 1.22???

The situation is a bit annoying for me. You say pub does not support native extensions - and now?
I can't change pub - it's in your hand.

I think it would be rather helpful for Dart as a language if it has access to the native world. In this case it makes no sense if Dart supports native extensions but pub does not. The users installs Dart applications via pub. The few native extensions in pub.dartlang.org force the user to compile the native parts e.g. via shell-scripts and assume that the user has the right compiler and all the necessary stuff installed - not very user friendly.

PLEASE: Help me with this. Outdated documentation is one thing but the error message above makes it almost impossible to use native extensions in a user friendly way. For now I hope and pray that 1.22 gives a better experience.

[zanderso]

@MikeMitterer Even if we wanted to add a flag for this, it would still have to go through security review (and probably fail), so the fastest way forward for you is likely to find some way to avoid using 'pub run'.

[nex3]

Adding proper native extension support for pub would be a major undertaking that would require a large amount of time to design and implement. That said, pub is open source, and if you're interested in working on native extension support I'd be happy to work with you.

[MikeMitterer]

@zanderso + @nex3 First - thanks for your answer! @nex3 I think these core things are part of Googles responsibility. Native support must be part of the language and it's tools.

You work at Google and what ever you work on - they pay you. If I would work on this (and it's the same with MDL4Dart btw.) I have no economic benefit. I would have to market it somehow - not realistic for this case.

I think I will follow @zanderso advice - maybe I find a different route with Dart or I go with a mircorservice approach for my internal use.

However - Thats so frustrating with Dart. Dart want's to compete with JS/Node/Python/whatever but it is always a step behind - these things are solved since years in other languages.

[nex3]

@zanderso + @nex3 First - thanks for your answer! @nex3 I think these core things are part of Googles responsibility. Native support must be part of the language and it's tools.

You work at Google and what ever you work on - they pay you. If I would work on this (and it's the same with MDL4Dart btw.) I have no economic benefit. I would have to market it somehow - not realistic for this case.

There's another side of this coin. My time is finite, and since Google pays me, I need to allocate it in a way that lines up with Google's primary goals for the language. Right now, the Dart team is focusing on the browser and on mobile via Flutter—neither of which have much need for native extensions. A lot of us are personally excited about server-side Dart, but most of the actual movement there has come from the community.