Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[tcpcrypt-dev] tcpcrypt userland tests 3 and 6 fail

Andrea Bittau bittau at cs.stanford.edu
Wed Jul 23 10:40:28 PDT 2014


On Wed, Jul 23, 2014 at 10:26 AM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> 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?

I'm happy to take your advice on this.  I presume the .pod might be
better in the long run as it'll let us add more verbose explanations
and maybe a nice summary on what tcpcrypt actually is?  And stuff like
how to interpret test results.  I generally like to keep -h terse.  I
realize the .pod might be more work, but it might be worth it.  I'd
say go with that unless you suggest otherwise.

>
>> 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
>> directly.
>>
>> 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
>> version.
>
> 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.
>
> Regards,
>
>         --dkg
>


More information about the tcpcrypt-dev mailing list