Re: [tor-bugs] #22106 [Core Tor/Tor]: Initial Rust support

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#22106: Initial Rust support
--------------------------+------------------------------------
 Reporter:  Sebastian     |          Owner:
     Type:  defect        |         Status:  needs_revision
 Priority:  Medium        |      Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:                |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------------------

Comment (by Sebastian):

 Replying to [comment:5 teor]:
 > > 1) Just commit them along with the Rust and C source code
 >
 > We typically have tightly-bound dependencies in src/ext, this would be a
 good place for tor_util and maybe tiny_keccak (as we already have a C
 keccak in ext).

 I am not sure about that. if we want to use cargo for this (and I think we
 do, otherwise we have to mirror all the dependencies etc in our make
 system), there's a support to have a local crates.io "mirror". Having that
 in a separate location seems good (maybe ext/rust/ would be good).

 > I think it's ok to expect people to install rust's libc: we already do
 this with libevent and {open,libre,*}SSL. They'll have to install rust, so
 installing libc is a reasonable ask.

 I don't know what you mean with install rust'c libc. It's a crate that
 needs to be available during building, not a dynamic library you can link
 to or something. The crate provides bindings for different host libc
 implementations.

 > Specific commits:
 >
 > 9a96733a2dab56342d6b3de1f2c2915429b21725
 >
 > Should we run the following rust tests during make check?
 > * tiny_keccak (yes, if we include it in ext)
 > * libc (no, but we might want to run it on platforms with poor rust
 support, so let's say that in the instructions)

 often, crates have more dependencies for running their tests or might even
 require an unstable version of the compiler to run them. Maybe we should
 add a new make target to run tests for rust dependencies?

 > 57838056b20eb2fc555ff8dc9148fca1e22be3d3
 >
 > src/or/config.c:
 >
 > This violates the version-spec, which allows a single EXTRA_INFO with no
 spaces in brackets.
 > https://gitweb.torproject.org/torspec.git/tree/version-spec.txt#n22
 >
 > This matters for get_version(), because it's sent in response to GETINFO
 version. This will at least break stem's version parsing, see:
 > https://gitweb.torproject.org/stem.git/tree/stem/version.py#n168
 >
 > (Also see #22110 for a rare case where we break the version spec
 already, and #22109 for adding unit tests for parsing our own version.)
 >
 > (It would also matter for get_short_version(), which is in the
 descriptor, but we're not adding "rust" to that.)
 >
 > I'd prefer get_version add "(rust-*version*)", if possible.
 > But maybe it doesn't matter than much, we don't give C compiler
 versions.
 >
 > In tor_int in main.c, we have existing code that does:
 > {{{
 >     if (strstr(version, "alpha") || strstr(version, "beta"))
 >       log_notice(LD_GENERAL, "This version is not a stable Tor release.
 "
 >                  "Expect more bugs than usual.");
 > }}}
 > Do we want to log some message about rust being experimental as well?

 Great catch, thanks! Perhaps rust_welcome_string() should instead just
 give a line of its own that we only emit if we're building with Rust, and
 we don't reflect it in the version at all?

 > src/test/test_rust.c:
 >
 > I'd tt_assert() the string is non-null before taking its length.

 Thanks, fixup pushed.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/22106#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs