Hi Daniel,
I actually suspected such (maturity) reasons after playing around with
it for a moment. And I do understand and agree with them.
So for now, please add the following or a similar sentence after "This
package contains the network daemon, which will accept and wrap
traffic redirected to it." in tcpcryptd's package description to make
people not expect a system service (as I did):
So far this package does not start the service automatically. Please
see the provided example script on how to start it.
Maybe the second sentence belongs to README.Debian instead, but I
think the package description is not a bad place either for now.
Daniel Kahn Gillmor wrote:
> On 08/08/2014 09:28 AM, Axel Beckert wrote:
> > while it seems that the provided
> > /usr/share/doc/tcpcryptd/examples/launch_tcpcryptd.sh seems to take care
> > of making the user aware that starting it may interrupt existing
> > connections, I think, it would be very useful and following the idea of
> > opportunistic encryption if tcpcryptd would be started by default,
> > e.g. via some init.d script.
> >
> > Maybe a debconf question of priority low or medium could ask the user if
> > it should be enabled by default, with the default set to yes.
>
> yes, this is definitely on the agenda for the package. (see debian/TODO
> for additional packaging work plans). I hope to get a sensible systemd
> tcpcryptd.service file sorted out during debconf
Please also provide an init.d script. Please do not make this package
dependent on systemd. I can imagine there are quite some paranoid
people out there who not trust systemd.
> there are a lot of possible nuances of how things could go wrong with
> enabling such a service by default -- from making sure it handles
> changes in network status properly, to questions about "phone-home"
> behavior on startup, to concerns about client linkability, to
> interaction with existing firewall rules,
Indeed. I must admit, I didn't get it working yet with the provided
example script. On one machine 3/6 tests failed, on another machine it
already failed to set the initial iptables rules and I haven't yet
found out why. (Both machines had fail2ban on it, but no further
iptables usage. The one where it failed immediately was a Xen DomU.)
> to the scary possibility of locking out the administrator of a
> remote machine if something goes wrong.
As far as I've understood it should suffice to disable tcpcrypt on his
local machine in that case.
> So for the moment, the package will be a tools-only package, not one
> that supplies a system service in any automated way.
I can understand that.
> But i'd be very happy for help/suggestions/patches to add a system
> service that address any of the above concerns.
As soon as I've understood what goes wrong with the example script in
my cases I may file more reports (I don't want to call them "bug
reports" :-) with how I had to improve the script to make it work. I
think this will also enlarge the chances to make it a system service
at some point in the future.
Regards, Axel
--
,''`. | Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
`- | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
