MIR for vtun

Overall packaging looks good but it's quite scary to include this network service; it sounds like a light but less secure VPN. For instance debian/README.Encryption says:
"This program includes an "encryption" feature intended to protect the tunneled
data as it travels across the network. However, the protocol it uses is known
to be very insecure, and you should not rely on it to deter anyone but a casual
eavesdropper."

Chuck, you mention in the MIR that the software works out of the box but the README.Debian and default config seems to imply that one needs to setup vtun manually after install.

Please implement the status action in the init script.

FYI debian/rules isn't make -j safe:
clean: clean-patched unpatch

clean-patched should be listed in .PHONY.

vtun should depend on ${misc:Depends}

Could you explain how it is required to run eucalyptus? (I didn't it in jaunty)

I think I'll ask Kees for a security pass afterwards.

Hmm there are some compilation warnings such as not checking return values; this is worrying for a root running vpn daemon

Chuck, you mention in the MIR that the software works out of the box but the README.Debian and default config seems to imply that one needs to setup vtun manually after install.

You are right that was a mistake.

Please implement the status action in the init script.

Done

FYI debian/rules isn't make -j safe:
clean: clean-patched unpatch

clean-patched should be listed in .PHONY.

Done

vtun should depend on ${misc:Depends}

Done

Could you explain how it is required to run eucalyptus? (I didn't it in jaunty)

New features for Eucalyptus I dont have all the information yet, since it is not released.

  * debian/patches/07-fix-gcc-warnings.patch: Fix gcc warnings.

Ouch that actually *hides* the warning, but doesn't handle the error conditions at all

Thanks for the other changes, but I really think you should either handle the error conditions or remove the patch altogether.

[ NB:
  * Clean up debian directory.
I'd personally not touch anything we dont need to touch in Ubuntu as it makes it harder to merge newer Debian versions; up to you though. ]

Will assign to Kees for security comments.

Kees, what's your take on the security implications if we promote vtun to main? Thanks!

I have not performed a code review, but am familiar with the software. I am extremely uncomfortable promoting this to main as is because of the 'encryption' support. http://www.cs.auckland.ac.nz/~pgut001/pubs/linux_vpn.txt has a good summary. IMO if this were to be considered for main, we should completely disable/remove the 'encryption' support, as well as remove references to it in the documentation. I realize it has legitimate use cases for pure (ie unencrypted) tunneling, but if we upload it as is, it's easy to imagine someone saying 'oh, hey, it has encryption. let's use it!' This needs to be avoided.

A much better solution would be to have upstream use proper, modern tunneling software like openvpn. It can use preshared keys (among other things) to make initial setup easier (which will allow for security-concsious users to adjust as needed) and upstream can 'upgrade' to proper TLS down the road.

I would agree with jdstrand -- this can't go into main. It is flawed by design. A VPN without encryption means all the nodes between client and server must be trusted (why not just route?). -1.