Hello everyone,

I am pleased to announce the second release of the Onion Name System (OnioNS) 
for beta testing. This release represents about 180 commits and is a major 
update from my last release. The two servers should be up long-term, so feel 
free to play around with it. "Example.tor" is live and new registrations should 
be available client-side about 20 seconds after upload.

As usual, the code, pre-built binaries, and instructions are available in the 
four OnioNS repositories at https://github.com/Jesse-V?tab=repositories
Please star them if they work well for you. Most people will probably just want 
OnioNS-client, which integrates into the Tor Browser.

The big changes include:
* Servers are now powered by hidden services. This means that they utilize 
existing Tor connections (circuits and TLS links) which is a major improvement 
over the direct communication in the last release. In the process, I switched 
all communications from SOCKS4 to SOCKS5 and it seems to work well. The OnioNS 
servers would be excellent candidates for single-onion services (Tor-embedded 
servers with only client-side anonymity) so I will switch to that when they 
becomes available.
* Servers now manage Ed25519 keys and I'm using floodberry's ed25519-donna 
implementation. All responses from a server are signed, so communication is 
automatically authenticated. The private key is held in the main working 
directory, which is ~/.OnioNS/ for the time being. Due to this, it's not 
currently possible to run two distinct servers as the same user.
* The trusted Quorum server now generates a Merkle tree and signs the root, 
which the client uses to authenticate Records (registrations) and to provide 
authenticated denial-of-existence. In effect, this prevents the client's name 
server from falsely returning a 404 or from forging a Record.
* I overhauled most of the networking code. It's significantly more stable, 
closely follows a request-response pattern, and I don't anticipate needing to 
change the networking format in the near future.
* The hidden service software now saves the generated Record to disk, so that 
it can try again if the upload fails.
* I introduced two static analysis tools: cppcheck and Clang's scan-build and 
created the scanBuild.sh script to facilitate analysis. They found one small 
memory leak, which I fixed, so now all of the repositories pass inspection.
* I'm now using the Travis continual integration system, which watches for 
commits in Github and then rebuilds the project. I get notifications in 
#tor-bots if the repo fails to build into a .deb, which is handy. Any pull 
requests are also checked in the same way.
* Many bugs were identified and fixed.

I need some help with:
* Testing a linking bug that is sometimes encountered when compiling from 
source. The ticket is https://github.com/Jesse-V/OnioNS-server/issues/79 I 
don't know whether the issue is dependent on Debian Wheezy, Ubuntu Trusty, or 
my CMakeLists. I'm not sure how to fix it, either.
* Testing an experimental .rpm format. I used the "alien" program to convert 
Wheezy and Trusty .deb files to .rpm, so as to better cater to Fedora. The 
rpm's are available in the Releases page on Github. I don't know if the 
packages work correctly, so if you are on Fedora, please try them out and let 
me know. If they don't work, I would appreciate instructions on how to build 
them properly.
* General testing: does the HS-side and client-side code work well and perform 
reliable for you?

Related notes:
* Earlier this month someone in Egypt created the ".tor" article on Wikipedia, 
which has a few details about this project. Thanks for that!
* S7r, I couldn't contact you on IRC, but if you're still up for running a name 
server to handle client connections, please let me know. I'll need your HS 
address and your server's Ed25519 public key, which is shown when the server 
starts. Then I'll push out an update that should transition clients over to 
you. It'll be nice to spread out ownership of the infrastructure.

Next on the list:
* I'm planning to focus the next release on stability, security, unit tests 
(I'm looking into coveralls.io), and doxygen documentation. The code is 
currently a bit fragile, so I'd like the next release to improve error 
handling. I'll be maintaining this version until the next one comes out, so I 
made a "stable" branch which will be for bug fixes and the like. I recommend 
that Ubuntu/Mint users use the PPA so that it's easy to deploy updates.
* I need to let servers update themselves if they are out-of-date. Once I fix 
this, it should be straightforward to add more servers to this system.

Thanks for the support everyone, and enjoy testing!

Jesse V.



Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
tor-dev mailing list
[email protected]
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Reply via email to