Automatic hosts files update protocol extension for Tinc

Benjamin zorlin at gmail.com
Fri Oct 16 06:07:27 CEST 2015


That sounds pretty amazing. Excellent work and thanks for contributing, I
hope this gets implemented.
On 16 Oct 2015 11:02, "Рысь" <lynx at lynxlynx.tk> wrote:

> Hello dear Tincers!
>
> I recently developed an extension to tinc 1.0.x protocol which
> introduces automatic and decentralized hosts update subsystem.
>
> The idea is to provide stable protocol extension to tinc which will do
> all the dirty work of spreading information about new hosts in network
> across all nodes by powers of tinc itself.
>
> If you're interested, you can take a look at the diff made for tinc
> 1.0.16 here:
>
> https://github.com/siblynx/tinc-1.0.16_hostupd/commit/6a6cc34d6d80696ea525956375de59c7f752fa42
>
> The code introduces two request types, and uses RSA signatures to
> prevent tampering. It also introduces some sort of privileges: who can
> and who cannot spread updates. Each node which has child connections
> forwards update requests.
>
> Users can decide to whom to trust, and can turn off updates for their
> own node. They also can setup completely trustful network in which
> everyone will be permitted to update the whole network.
>
> Please see source file src/protocol_hostsupdate.c, it contains more
> information about the extension implementation and how to configure
> each node for it. In future I probably will move it to a README.hostupd
> file.
>
> This is a motivation from the lesson I learned recently when my central
> update service crashed inside my network with huge disk failures, and
> that node's key became unrecoverable (yeah, I lost it, no backups, it
> was a cheap "PC" router), resulting in unmanaged network for a few
> weeks. It served updates centrally via http, and it's URL was the only
> one which was recorded in update scripts and binaries for windows
> everywhere.
>
> Even when I started using tinc, I seen that it misses something
> important when I was forced to update hosts by hand for some time.
>
> This work is still experimental, I even test it now, and if you will
> want to merge it into current or future versions of Tinc, you will
> probably need to trim it of my extensions for my network. It probably
> _contains_ bugs I still did not found, and I am not a pro in
> cryptography (albeit having some experience with in past).
>
> This work is currently (my own code) is licensed under GPLv2 only. I
> will happily unlicense it (making it public domain) if it will go into
> any versions of Tinc, just with mentioning my contribution in THANKS
> file. If not, it will stay as is.
>
> With best wishes!
>
> P.S. I found Tinc a great code inside when I developed extension for
> it. I was able to quickly understand configuration and requests
> subsystem, and the rest was no a problem. It's a shame that Tinc still
> gets little attention in VPN area!
>
> --
> http://lynxlynx.tk/
> Power electronics made simple
> Unix and simple KISS C code
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20151016/5795a729/attachment.html>


More information about the tinc mailing list