Forking and attempting to do an incremental rewrite of parts
Status: Inactive
Brought to you by:
mtbishop
Menu
▾
▴
#64 Forking and attempting to do an incremental rewrite of parts
I'm creating a fork of vtun at https://github.com/leakingmemory/vtun-ng since this project has gone unmaintained for a while. Obviosly thanks for the great work done on this project, it is obviously great as vtun is still a thing nearly 10 years after the latest release. I would absolutely love to see prior developers coming back to the project.
(Raw dump of the cvs repository into git: https://github.com/leakingmemory/vtun )
I decided to try to bring the cvs history as much as possible and to initially start with the 3.0.4-code. I rewrote the lfd_encrypt part in rust first because that module was no longer compatible with modern openssl. So I'm quite confident it is possible to continue this path and rewrite more modules. Rust was chosen, not because it would be my first choise at all, but because I expect it to improve the public appearance in software that may be exposed to untrusted network environments. I think it is fine to keep non-network-exposed parts of the software (like config-parsing) in C, but on the other side a hybrid project might be more difficult to build and to set up for maintainers of packages for distroes.
Any interested parties, prior developers, are welcome to come along.
Best regards,
Jan-Espen Oversand
I also decided to make one more fork https://github.com/leakingmemory/vtun-embedded which is going to remain a C autoconf project. The intention is to keep this project in sync with vtun-ng for applications where the rust rewrite is not possible or not practical to use.
I personally recommend using vtun-ng as a replacement for vtun where possible, but whenever that is not possible I intent to maintain the vtun-embedded project as a compatible solution.
Best regards,
Jan-Espen Oversand