Fallback needed for macOS without NetworkExtension

[barracuda156]

@jagerman NetworkExtension is available starting from 10.10. We need a fallback (a generic Unix one?) for earlier versions. Could we come up with one?

[jagerman]

Honestly it's a bit unlikely unless it's community contributed/maintained; you're talking about versions of macos that Apple doesn't support anymore (even with security updates), and the hacky approach we used to use before developing the network extension was far from reliable.

[jagerman]

(also I think you mean 10.15, not 10.10)

[barracuda156]

Honestly it's a bit unlikely unless it's community contributed/maintained; you're talking about versions of macos that Apple doesn't support anymore (even with security updates), and the hacky approach we used to use before developing the network extension was far from reliable.

@jagerman Could you please refer me to the earlier implementation? I can do testing on my end, and we can do testing in Macports once I make the port for lokinet (for which I need it fixed for 10.5+ and PowerPC).

Something to start with will be certainly helpful. Then we can hopefully improve upon that and keep maintaining for older MacOS.

[jagerman]

I believe that all of the pre-NetworkExtension code is present in v0.9.9 (v0.9.10 introduced the NetworkExtension), though we hadn't made a macos release with it since 0.9.0 because of multiple reports that the launchctl approach we were using failed to work entirely on macOS 11 and up.

Most of the supporting code/scripts/etc. are in the contrib/macos directory in v0.9.9.

[jagerman]

Also, by the way, I'd be thrilled to see a working Lokinet in macports. If I can help make that happen be sure to let me know.

[barracuda156]

Also, by the way, I'd be thrilled to see a working Lokinet in macports. If I can help make that happen be sure to let me know.

@jagerman Thank you! I intend to deal with this in coming days.

I wanted to ask also, what was the issue with a non-static build for macOS? With my yesterday’s PR merged, we will have all required dependencies, I believe. While a static build may be acceptable, it is generally not favored by Macports and not advised for Apple generally.

[jagerman]

I wanted to ask also, what was the issue with a non-static build for macOS? With my yesterday’s PR merged, we will have all required dependencies, I believe. While a static build may be acceptable, it is generally not favored by Macports and not advised for Apple generally.

Nothing: just redistributability for macos users who want a .dmg blob installer to download.

In Linux packaging we link against system libraries as much as possible.

[barracuda156]

@jagerman Great! So then we can remove error set in llar/apple and build non-statically in Macports.

[majestrate]

On Thursday, 25 May 2023 07:27:04 EDT Jason Rhinelander wrote: Honestly it's a bit unlikely unless it's community contributed/maintained; you're talking about versions of macos that Apple doesn't support anymore (even with security updates), and the hacky approach we used to use before developing the network extension was far from reliable.

I am considering supporting that mode of operation as not having to deal with code signing on apple sounds like it would help increase contributions from the community.

…

-- ~jeff

[barracuda156]

@jagerman It seems that the earlier source code here (dating back to 2021 only) already uses NetworkExtention for Apple: 3f0b34e (first commit in history).
Same if I go from 0.9.9 branch to Apple folder: https://raw.githubusercontent.com/oxen-io/lokinet/v0.9.9/llarp/apple/CMakeLists.txt

Is the earlier version preserved somewhere?

[barracuda156]

@jagerman @majestrate I think I have found it, and it looks huge: #1688
(Though from a first look not everything is relevant to the matter.)

P. S. Could someone say, why the build did not work in a normal Unix/Linux way, what lead to the horrors of Obj-C++ and Swift being needed? Say, i2pd builds from normal C++ and seems to work across the board. (GUI may be trickier, admittedly, but Qt4 is compatible with everything from archaic version to the latest.)

[jagerman]

@jagerman It seems that the earlier source code here (dating back to 2021 only) already uses NetworkExtention for Apple: 3f0b34e (first commit in history). Same if I go from 0.9.9 branch to Apple folder: https://raw.githubusercontent.com/oxen-io/lokinet/v0.9.9/llarp/apple/CMakeLists.txt

Is the earlier version preserved somewhere?

I think you need to go back a bit further, to maybe 0.9.5 or maybe even 0.9.0.

P. S. Could someone say, why the build did not work in a normal Unix/Linux way, what lead to the horrors of Obj-C++ and Swift being needed?

Apple's garbage NetworkExtension VPN interface sadly also requires using Apple's garbage languages. (And using the NetworkExtension is, sadly, the only way we can distribute a signed .dmg-installable release that works in newer macOS builds).

[barracuda156]

@jagerman BTW, will it be hard to allow configure option (for a case of building from source) to use a non-proprietary backend? Maybe rather that digging out an archaic code and trying to fit it into the current master, that can be done?

[majestrate]

@jagerman BTW, will it be hard to allow configure option (for a case of building from source) to use a non-proprietary backend? Maybe rather that digging out an archaic code and trying to fit it into the current master, that can be done?

you would be supporting an entirely distinct platform that is effectively a bitrotten fork of BSD from 1992.

it would run as root, no mac user wants to do this. they think they would but they really don't.

[barracuda156]

@majestrate I am fine with root. Macports folks are fine with root. Who is not – well, that is their problem.

[jagerman]

BTW, will it be hard to allow configure option (for a case of building from source) to use a non-proprietary backend?

No; it's a matter of adding a cmake option to use the alternate backend. The complicated parts, as I recall, was getting it to play nicely with MacOS's settings for things like DNS which of course are all proprietary because Apple.