4 ms·

> Tor embedded into the client This is the most interesting part of this announcement for me: >> You can test Arti ... as an embeddable library (if you don't

> Tor embedded into the client 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.

ivmoreau 4y ago
> Too bad rust doesn't really do dynamic linking. 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.
- pabs3 4y ago
  Apparently there is a dynamic linking ABI for Rust too, but it is not stable enough to use yet for distros like Debian. https://wiki.debian.org/StaticLinking#Rust https://wiki.debian.org/StaticLinking#Rust https://lwn.net/Articles/797616/ https://lwn.net/Articles/797616/ https://github.com/rust-lang/rfcs/pull/2603 https://github.com/rust-lang/rfcs/pull/2603 I note that the PR for Rust symbol mangling got merged, but it looks like it isn't the default yet, they are waiting on external tools supporting it.
  - ivmoreau 4y ago
    >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.
    - pabs3 4y ago
      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.
- zozbot234 4y ago
  > 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.)

ivmoreau 4y ago

> Too bad rust doesn't really do dynamic linking. 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.

pabs3 4y ago
Apparently there is a dynamic linking ABI for Rust too, but it is not stable enough to use yet for distros like Debian. https://wiki.debian.org/StaticLinking#Rust https://wiki.debian.org/StaticLinking#Rust https://lwn.net/Articles/797616/ https://lwn.net/Articles/797616/ https://github.com/rust-lang/rfcs/pull/2603 https://github.com/rust-lang/rfcs/pull/2603 I note that the PR for Rust symbol mangling got merged, but it looks like it isn't the default yet, they are waiting on external tools supporting it.
- ivmoreau 4y ago
  >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.
  - pabs3 4y ago
    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.
zozbot234 4y ago
> 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.)