It's interesting that the funding for this came from the Zcash Community Grants. There's a lot of money involved with cryptocurrency and a lot of it gets invested into the software involved. It's interesting that in this case, serious money got invested into some software that isn't strictly cryptocurrency-related and is useful outside of cryptocurrency. It makes me wonder if there are other software projects that are generally useful, including but not exclusively to cryptocurrency projects, that could benefit similarly from seeking funding from cryptocurrency projects. Even if one disliked cryptocurrency, this could be seen as getting money redistributed to more useful endeavors to benefit everyone.
This project has come a long way, very fast. Great work to all involved. The biggest security holes in Tor are most likely going to be from the browser going forward.
Hardening the browser is tough, but that's a win for everyone (including those not using Tor).
This sentiment was one that I shared in my Rust work:
> the pickiness of the compiler has been a great boon. Generally speaking, if our Rust code compiles and passes its tests, it is much likelier to be correct than our C code under the same conditions.
This is the most interesting part of this announcement for me:
>> You can test Arti ... as an embeddable library (if you don't mind a little API instability).
My first thought was adding Tor as a transport for TCP DNS resolution for an existing recursive resolver like unbound. Or, a TOR proxy for DoH public recursive resolvers. Either would result in better privacy than directly using a centralized public resolver with DoH. For the former, you would need to send the query through multiple circuits to have confidence that a guard or an exit node wasn't modifying the query/result (with all exits for a particular query in the same country to minimize geo DNS load balancing causing different results-- this level of control would be easier with a library than a separate daemon communicated through via socks. For the latter, using a socks proxy would work, but the library would make for a simpler setup for the user.
Too bad rust doesn't really do dynamic linking. 'libtor' as a distribution maintained library that is automatically kept patched for security vulnerabilities would add piece of mind when running applications that embed Tor.
As far as I remember, you can actually do dynamic linking. But it has its caveats.
Maybe using two different crates, lib-internal and lib-external, where lib-internal compiles to an dylib/so that exposes a C-abi compatible interface. Lib-external it’s just a idiomatic Rust wrapper to that api. It’s a little bit wonky, but I’m pretty sure that it can work.
> It’s a little bit wonky, but I’m pretty sure that it can work.
Not that wonky, it's really a natural consequence of the fact that Rust's stable ABI is the C ABI. Plus you can then use lib-internal from any language that supports FFI to C, not just from Rust.
(Of course, some things just cannot be supported across a dylib boundary, such as arbitrary monomorphized code. But this limitation applies to all such languages; it's why you have "header-only" libraries in C/C++ for example.)
>but it is not stable enough
That's the problem. Is still, after all this years, unstable.
Of course you can do dynamic linking without the way that I previously described, but that library will be highly tight to a specific version of the compiler. I think that the biggest problem is dealing with product types for that matter.
Reading through the status tracking bug, it sounds like the ABI is now standardised, but they aren't changing the default to the newly standard ABI yet, because they are waiting on external tools to support it. That said, you could definitely use it today without worrying about the compiler version it seems.
More interesting than a social network is imo applying Tor for IoT. IoT devices suck because they all talk to some mothership and to talk to your own device you have to connect to a third party server. With Tor you can just run a hidden service and the Tor network does all the difficult things for you.
> For example, when we've had to get into the fine details of filesystem permissions, we've found that most everything we do takes different handling on Windows.
> At every stage, we've encountered way fewer bugs than during comparable C development. The bugs that we have encountered have almost all been semantic/algorithmic mistakes (real programming issues), not mistakes in using the Rust language and its facilities
> Development of comparable features has gone way faster, even considering that we're building most things for the second time
> Portability has been far easier than C
> We've found that Arti has attracted volunteer contributions in greater volume and with less friction than C Tor
Very cool, I fully support this and I plan to experiment with it. The developers should be proud of making such exciting progress.
But doesn’t “ready for production use” sound like hyperbole when the blog post describes a partially completed implementation? It can’t even connect to onion services yet. Similarly, “improved security” is a suspect claim to make when comparing brand new software to a battle-tested codebase.
There’s no point making claims like that in this phase of early-adopter outreach; it burns future credibility for no reason. We’ll play with the software regardless.
IMO a more accurate claim would be “Arti Tor client, socks proxy and Rust crate can now connect to clearnet hosts through the Tor network, but is still missing some features like bridges and pluggable transports.”
A quick search didn't find anything. I wonder, does Arti support communication over a unix domain socket yet?
Using a unix domain socket for a client in a private network namespace with no network interfaces is a nice extra layer to ensure no IP leaks. The regular Tor daemon has supported this for a few years now.
The project has the option to use `tokio`, which contains a staggering amount of unsafe code. I hope nobody distributes prebuilt version of Arti that use tokio.
To me this just seems pointless because an implementation in Rust is going to have similar features to one in C, Java, Python, or any of the handful of languages where Tor already exists... I want to rep another project that I think would be more relevant to Tor's goals. It is unfunded yet should it exist: would have the potential to transform privacy on the web. The project is https://github.com/Ayms/node-Tor It's about implementing Tor in Javascript.
Why is this a good idea? Well, if you had a Javascript version of Tor you could quite literally import it on any website. It would be the easiest way to add privacy to millions of users sessions. It would be so ridiculously accessible and easy to use that it would probably lead to rapid innovation in the underlying tech. There is a lot of cool p2p tech already built into the browser that would be an amazing test bed.
Currently Google Chrome are also experimenting with a socket-like API that I believe would be a useful piece of the puzzle [for the project.] It just seems to me that marketing, networking, and being a tech normie is more important than actually having a good idea. So you see pointless projects like this get all the funding while projects like Ayms stay unknown and don't get any. Historical note: the hacker Aaron Swartz (tragically deceased - those who know... know. It was an awful waste) was involved in this project and suggested it as an idea. It's definitely a good one in my opinion.
The authors emphasize how the Rust compiler prevented them from introducing many potential bugs.
Sometimes it's better to have no security software and fully understand the implications than to have a security software with bugs unknown to you, which are tacitly exploited by your adversary.
I see what you're saying. But there's no reason why you couldn't do the same thing with this design. You can build a basic DOM model that is allowed and only let that portion through. While the outer layer uses Javascript freely to run. You can decide what policy you want before displaying any output.
I don't think that Tor in javascript would improve anything. Tor in golang on the other hand would gain multithreading and ease of integration. It would drop in nicely with the Golang standard library.
A Go version wouldn't improve anything upon the Rust version either. At this scale, Go's simplicity would be a hindrance more than a help, development velocity would suffer compared to Rust. Integration would only be possible in the Go ecosystem, whereas Rust can expose a C API so that Arti can be used (eventually) as the engine for implementations in other languages (Go, Python, JS, etc). Multithreading and overall performance can be better optimized in Rust.
Tor is critical security software with a lot of implementation gotchas. Just like you shouldn't write your own crypto, you shouldn't write your own Tor. Arti is developed by contributors of the original C Tor, I wouldn't go near a Js/Go/whatever implementation from a team with less credentials.
So ? The fact that rustc compiler uses a component written in C++ doesn't mean that even pure Rust projects have a C++ dependency. Follow any language's bootstrap chain and you'll find C somewhere (or a bootstrapping purists telling you that didn't properly bootstrap the thing), making the "some of the FOOLANG compiler is written in BARLANG" argument pointless.
You don't need a C or C++ compiler (not even Clang) to compile Arti. The rustc packages typically use a vendored version of LLVM.
Yup, the core part of Tor is written in C so it can't get much speedier. Rewriting it in rust is almost is entirely to reduce the footguns you get in C
Might recall reading something to the effect of the C Tor daemon having run into bottlenecks due to lack of multi-threading of certain components and general concern over safety footguns.
I am happy for most software to move from C into almost anything else. Something unlikely to have memory exploits, or with standardized tooling for dependency management and compilation.
- There are no dynamic binaries. Everything it's static. But binaries and the userland are tiny and usable.
- Cross compile it's dumb easy. [0-9]c, one number per arch.
- Every OS comes with compilers, libraries and sources for every arch.
- Security it's handled by separated modules, a password/login daemon/server and namespaces. Totally different. That will be the future in 10 years, and not Rust.
The kind of "security" that you get by using a safer language like Rust (instead of C), can't be achieved by using anything that can be described as a "module" in an unsafe language.
I am not sure I can think of something that I more want reimplemented in Rust than Tor. In fact, as excited as I am about Rust inside the kernel, I'm more excited about this and the Rust-ification of Firefox. Given the distro I use, the biggest risks to me are almost guaranteedly through (some) browser.
In a way it is nice way to grow Rust ecosystem quickly at-least. Likely makes existing libraries better, and fills up the missing holes in ecosystem. If everyone builds just new stuff, it will likely grow at slower pace, and much smaller ecosystem for libraries.
I'd be fascinated to hear examples of what you think of as "new" and not a reimplmentation. Because the entirety of human history is learning from others, improving it and releasing that as a new invention. All of us stand on the shoulders of giants whenever we do anything.
Databases, text editors, network protocol implementations, GUI frameworks, command line argument parsers, game engines, search engines, build tools - no matter what program is written in any language, there is a program written elsewhere in another language that inspired and informed it.
That's not a knock on the new language, it's just stating a simple fact about human beings.
I think this happens with a lot of languages. The Rust implementations just get more eyeballs and press. Presumably because of the inherent memory safety + speed of (non unsafe) Rust.
So like Unix with C being rewritten in that language instead of the original one written in PDP11 assembler for portability.
Now people rewrites things in Rust for security. It's good, but I think it can be worse; it may make "lazy" programmers and if some bug it's discovered in the Rust runtime, everyone will be equally f*cked.
One of the explicit goals of rust is that it doesn’t have a runtime, so I’m not sure what you mean. If there’s a bug in rustc then we’re about as fucked as a bug in clang or gcc, so I’m not sure how that’s worse.
Sure, although in this sense C also has a runtime. I assure you there's no magic where CPUs just know that the C main() function is where your program starts. That's what CRT stands for if you see things like "crt0.s" or "crtmain" mentioned, C Run Time.
This Rust code is handing over from your operating system to the main() function of your Rust program, it's arranging that you've got all those modern application amenities like command line parameters, environment variables, it will name your thread (if the OS has names for threads) and so on.
Obviously if your Rust is firmware for $5 device it probably doesn't have an operating system, and it certainly doesn't have command line options, accordingly no_std (the Rust environment you are writing for) doesn't do this stuff. You will wake up alone, with the function you annotated (IIRC with #[start]) running and only the features from Rust's core library. The equivalent in C is standalone mode, C doesn't give you a library at all, just your language, operators etc and your wits. You will of course write your own library unless your project is tiny, because this is pretty unsatisfactory.
However, Arti is not intended to be firmware for a cheap piece of electronics, so both the C Tor implementation and Arti will end up with this very thin runtime to run as applications, the runtime just sets things in motion and calls your main function.
and it's worth noting that this isn't hypothetical. the c standard is somewhat unclear and contradictory, and as such no two c compilers fully agree with each other on what the standard actually means.
