[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-dev] Second release of OnioNS beta



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
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev