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