On 8/3/25 22:21, Alexandru N. Barloiu wrote:
On Sat, 2025-08-02 at 11:57 +0200, Jan-Espen Oversand wrote:Hi,I've been the maintainer (by proxy) of net-vpn/vtun. But, as there is no upstream maintenance since 2016, I am afraid it is going to get increasingly difficult to maintain. The greatest risks to maintaining it as far as I can see is deprecations and removals of openssl-features and algorithms. Quite soon it is probably going to need use-flags on openssl to enable deprecated algorithms. Also it has started to fall out of other distros and operating system ports. So, I basically had enough, and I imported the project into github, and over a few weeks rewrote the codebase in rust. I have moved most of my own tunnel-setups to this github-project. So basically I just wanted to ask whether there are any opinions on whether this project (vtun-ng) could be a viable replacement for vtun? Probably no hurry right now, but could possibly be considered over the next few months? I've uploaded ebuilds to the GURU-repository at net-vpn/vtun-ng Github: https://github.com/leakingmemory/vtun-ng Regards, Jan-Espen OversandHello. I am invested in that package. And I think I'll keep a pi around with an older openssl version just for that. For like many years. Have no reason to abandon vtun coz the encryption is already done by ssh. I use vtun to feed 8 tap connections into a bond connection to parallel compress distcc stuff. One tap tun means one core compression. 8 however means multicore compression. Its like my favorite toy. I doubt I will give it up. But, I will keep an eye on your port/fork. Good luck with it. axl
Thanks. Also, if there is anything in vtun that does not work in vtun-ng (expects config at /etc/vtunngd.conf as opposed to /etc/vtund.conf for vtun) I will appreciate issues created on the github page. Priority one now is compatibility both with configuration and interoperability with vtun.
Also I'm not going to call for removal of vtun unless it becomes absolutely impossible to keep it. Actually I've got a good read through and review of the code base. Although there is some clever pointer magic going on in the lfd_*.c files that looks suspicious at first sight it doesn't really go wrong because the buffers are allocated with sufficient space both below and above. But that is also probably one of the reasons it is difficult to move on with that code, because it is so easy to refactor that into a real problem.
Anyway, if/when openssl becomes a problem again, it would probably be fixable by replacing lfd_encrypt.c and auth.c. It's just a matter of effort and patch size. And lfd_legacy_encrypt.c could probably be tossed, it's not adviceable at all to use any of the -ecb-algorithms unless plaintext would be ok anyway.
Jan-Espen Oversand
OpenPGP_0x2D770B902F0C4749.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
