Search Mailing List Archives
[tcpcrypt-dev] tcpcrypt userland tests 3 and 6 fail
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Wed Jul 23 10:26:50 PDT 2014
On 07/23/2014 01:16 PM, Andrea Bittau wrote:
> It'd be great if you can write some man pages.
are you OK with my adding simple documentation as -h/--help and
-v/--version flags in the binaries themselves, or would you prefer
external .pod (or other syntax) that can be converted to man?
> The key components are tcpcryptd, launch_tcpcryptd.sh and
> libtcpcrypt.so (so people can get the session ID and start using
> tcpcrypt for authentication). tcnetstat is really nice to have for
> debugging. test/tcpcrypt is not critical I think. That was more for
> getting the numbers for the paper. A port of netcat that prints the
> session ID would be cool.
if we can get the package into debian, we should be able to start
supplying patches to other packages to see if we can get them ported by
default. That's a little ways away in the future, though :)
> Totally. I wonder whether it should call launch_tcpcryptd.sh or in
> fact we should get rid of the script entirely and just use init
> scripts. After all, it's all OS-dependent so init scripts might be
> best? I suggest using the OS init scripts and launching tcpcryptd
> One thing I want to keep though: if tcpcryptd crashes, the firewall
> rules should be reset to avoid network blockage. That's the night
> thing of launch_tcpcryptd.sh. So maybe we do need a script after all.
> I'm not sure how to accomplish this with the init scripts. If it's
> not possible, then the init script should call launch_tcpcryptd.sh.
I'm definitely aware of these concerns, and want to make sure we treat
them sensibly. That's why i actually want to ship tcpcryptd separately
first, and sort out the details of the automated system service later.
for the system service, i think starting with systemd and then dealing
with sysvinit is a reasonable way to go (though if someone else wants to
write up a sysvinit initscript, i'd be happy incorporate it too).
> Yes we should focus on the userspace. We actually had people (and
> companies) contact us saying that they'd deploy the user space version
> but not the kernel! So there's a lot of interest in the userspace
i find that a little weird, but i do understand the unwillingness to
tamper with the kernel without more testing and experience.
> The kernel version is outdated at this time.
ah, too bad. Maybe we can try to get that polished up once we've sorted
out the userspace daemon.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 949 bytes
Desc: OpenPGP digital signature
More information about the tcpcrypt-dev