I personally believe this will be invaluable to areas where ISPs are being scum and are actively using methods to deter VPNs and encrypted DNS within their networks in order to secretly milk their customers more money.
I myself live in such an area and while it’s not a daily occurrence, it’s still a pain in the arse specially when my VPN gets disrupted for 24-48 hours.
I’m well aware that this won’t really help when they put in the effort to block popular VPN network ports but that will keep them from interfering with my VPN connection when I’m using port 443 TCP
I believe that the CLI/command-line binary for this should be enough for good operation.
As the IPFire development team is very small and their time is concentrated on security improvements and bug fixes for IPFire 2.x and working on developing IPFire 3.x, the usual way for new addons to be considered is for someone who wants a specific addon to join the development mailing list
Too often in the past people have submitted a patch for an addon and then have not provided any further support or update for it resulting in addons that become very out of date.
Therefore the expectation would be that the person submitting the addon patch would commit to providing ongoing support and updates.
Thanks for the info! Welp, can’t really say that my situation in real-life right now would allow me to devote myself to keeping an add-on updated in IPFire but I guess I’ll have to see first just how much effort is needed for it.
If anything, I should be able to provide the necessary foundation for GreenTunnel to run in IPFire. And if I do face any roadblocks I suppose I can always ask both here and the github page for GreenTunnel.
@bonnietwin Looks like GreenTunnel is dependent on npm but a workaround is to build GreenTunnel using a TypeScript-written tool called nexe:
I’ve noticed a thread talking about how npm is a security risk and I agree that it wouldn’t be a good idea to run that in IPFire. That said, I still need an environment to be able to build GreenTunnel using nexe that happens to be dependent on npm still. After the build however, the resulting binary will not be dependent on npm.
So the final question is, which distro would be an ideal build environment to make binaries targetting IPFire? Also, are there any caveats that need working on when the goal is building for IPFire?
If npm is required to build the addon then it will need to become part of the IPFire build environment, even if it doesn’t become part of the iso distribution.
So I would recommend joining the Development Mailing list and have a discussion about having npm added to IPFire before starting any work. No point in doing all the work if the core devs won’t accept having that package added to IPFire’s build environment unless you will only be building the addon for yourself.
EDIT:
I just had a quick look at npm and it looks like you have to create an account to be able to download the source. I don’t believe that requirement would be seen very positively in IPFire.
Thanks for the very detailed feedback on this. Admittedly, I have been highly occupied by IRL work for the whole month but thankfully, hardwork pays off. Thankfully, I anticipate myself to become less busy as Christmas / vacation season approaches.
Along the way, I managed to find an alternative to my needs that doesn’t involve GreenTunnel and the binaries involved use libraries native to Linux since it’s written using C.
I’ll first try to see if I can manage to build it myself and utilize it on my personal IPFire system and should be no problems even if I end up breaking my install as I’ve already done like 4 reinstalls just this year which got me pretty used to it already.
I’ll probably test it for a whole week after I manage to get it up and running before I join up the development mailing list for a full discussion about it.
Again, many thanks for pointing me in the right direction to get started!
