The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:54:56Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24322make IPv6-only clients bootstrap without needing config changes.2020-06-27T13:54:56Zdkgmake IPv6-only clients bootstrap without needing config changes.legacy/trac#17281 suggests that an IPv6-only client should be able to bootstrap by setting some flags in torrc. I've done:
```
ClientUseIPv4 0
ClientUseIPv6 1
```
But, most clients are not *always* IPv4-only or IPv6-only. In particul...legacy/trac#17281 suggests that an IPv6-only client should be able to bootstrap by setting some flags in torrc. I've done:
```
ClientUseIPv4 0
ClientUseIPv6 1
```
But, most clients are not *always* IPv4-only or IPv6-only. In particular, i tend to move my laptop between networks that have different properties (i'm writing this from a v6-only network).
I shouldn't have to fiddle with my torrc to make tor work. it should be able to auto-detect this situation and do the right thing automatically.https://gitlab.torproject.org/tpo/core/tor/-/issues/24318Clarify that the RelayBandwidth* options exclude directory fetches by relays2021-07-22T16:21:37ZteorClarify that the RelayBandwidth* options exclude directory fetches by relaysTwice in the last few months, I have explained to relay operators that RelayBandwidthRate/Burst includes directory fetches from the relay by clients. But they do not include directory fetches by the relay (from authorities or other relay...Twice in the last few months, I have explained to relay operators that RelayBandwidthRate/Burst includes directory fetches from the relay by clients. But they do not include directory fetches by the relay (from authorities or other relays), because that is considered "client" activity.
We should clarify in the man page, because it clearly causes some confusion.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24317Do not use same country in the Tor circuits2020-06-27T13:54:56ZcypherpunksDo not use same country in the Tor circuitsRecently, Tor circuits often choose paths trough the same country. Paths with three relays within the same country occur frequently but should be a bad idea. This makes it easier for attackers with nation-wide power. The risk of correlat...Recently, Tor circuits often choose paths trough the same country. Paths with three relays within the same country occur frequently but should be a bad idea. This makes it easier for attackers with nation-wide power. The risk of correlation attacks should be mitigated by using relays located across different countries.https://gitlab.torproject.org/tpo/core/tor/-/issues/24315sandbox incompatible with glibc 2.26 (openat() not handled for all our files)2020-06-27T13:54:56ZDavid Gouletdgoulet@torproject.orgsandbox incompatible with glibc 2.26 (openat() not handled for all our files)If I enable the sandbox on my system, I get killed with:
```
(Sandbox) Caught a bad syscall attempt (syscall openat)
/usr/lib/x86_64-linux-gnu/libasan.so.4(+0x558c0)[0x7fb5203ab8c0]
/lib/x86_64-linux-gnu/libpthread.so.0(open64+0x4e)[0x7...If I enable the sandbox on my system, I get killed with:
```
(Sandbox) Caught a bad syscall attempt (syscall openat)
/usr/lib/x86_64-linux-gnu/libasan.so.4(+0x558c0)[0x7fb5203ab8c0]
/lib/x86_64-linux-gnu/libpthread.so.0(open64+0x4e)[0x7fb51ec6667e]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x13150)[0x7fb51ec67150]
/lib/x86_64-linux-gnu/libpthread.so.0(open64+0x4e)[0x7fb51ec6667e]
/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(evutil_open_closeonexec_+0x20)[0x7fb51fbb5540]
/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(evutil_read_file_+0x53)[0x7fb51fbb5603]
/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(evdns_base_load_hosts+0x8b)[0x7fb51fbc429b]
/home/dgoulet/Documents/git/tor/src/or/tor(+0x9f7adf)[0x55aa44446adf]
/home/dgoulet/Documents/git/tor/src/or/tor(do_main_loop+0x745)[0x55aa440f01d5]
/home/dgoulet/Documents/git/tor/src/or/tor(tor_run_main+0x1895)[0x55aa440f4065]
/home/dgoulet/Documents/git/tor/src/or/tor(tor_main+0x86)[0x55aa440e1fb6]
/home/dgoulet/Documents/git/tor/src/or/tor(main+0x1c)[0x55aa440df20c]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fb51db741c1]
/home/dgoulet/Documents/git/tor/src/or/tor(_start+0x2a)[0x55aa440e1c6a]
```
strace output:
```
19360 openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC) = 257
19360 --- SIGSYS {si_signo=SIGSYS, si_code=SYS_SECCOMP, si_call_addr=0x7f7d90ab667e, si_syscall=__NR_openat, si_arch=AUDIT_ARCH_X86_64 ---}
```
It is the first file being opened _after_ the seccomp sandbox has been applied. Our sandbox code only considers "open()" to touch that file:
`OPEN("/etc/hosts");`
My libc is 2.26.
We probably need to handle the same files with `openat()` as we do with `open()` for this.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24313Crash: died: Caught signal 11 [crash from rend_consider_services_intro_points]2020-06-27T13:54:56ZcypherpunksCrash: died: Caught signal 11 [crash from rend_consider_services_intro_points]```
[notice] Tor has successfully opened a circuit. Looks like client functionality is working.
[notice] Ignoring directory request, since no bridge nodes are available yet.
[notice] Ignoring directory request, since no bridge nodes are ...```
[notice] Tor has successfully opened a circuit. Looks like client functionality is working.
[notice] Ignoring directory request, since no bridge nodes are available yet.
[notice] Ignoring directory request, since no bridge nodes are available yet.
[notice] Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 892 buildtimes.
[notice] Ignoring directory request, since no bridge nodes are available yet.
[notice] Our directory information is no longer up-to-date enough to build circuits: We're missing descriptors for 1/2 of our primary entry guards (total microdescriptors: 6124/6450).
[notice] I learned some more directory information, but not enough to build a circuit: We're missing descriptors for 1/2 of our primary entry guards (total microdescriptors: 6124/6450).
[notice] Ignoring directory request, since no bridge nodes are available yet.
[notice] Ignoring directory request, since no bridge nodes are available yet.
[notice] Ignoring directory request, since no bridge nodes are available yet.
[notice] Ignoring directory request, since no bridge nodes are available yet.
[notice] Ignoring directory request, since no bridge nodes are available yet.
[notice] Tor has successfully opened a circuit. Looks like client functionality is working.
[notice] Tor has successfully opened a circuit. Looks like client functionality is working.
[warn] Error launching circuit to node [scrubbed] for service [scrubbed].
[warn] Error launching circuit to node [scrubbed] for service [scrubbed].
[warn] Error launching circuit to node [scrubbed] for service [scrubbed].
[warn] Error launching circuit to node [scrubbed] for service [scrubbed].
[warn] Error launching circuit to node [scrubbed] for service [scrubbed].
[warn] Error launching circuit to node [scrubbed] for service [scrubbed].
[warn] Error launching circuit to node [scrubbed] for service [scrubbed].
[warn] Error launching circuit to node [scrubbed] for service [scrubbed].
============================================================ T= 1510821832
Tor 0.3.2.3-alpha (git-894b61b1d19f6235) died: Caught signal 11
/usr/bin/tor(+0x1830c9)[0x55c71b98d0c9]
/usr/bin/tor(extend_info_free+0x1d)[0x55c71b8e0add]
/usr/bin/tor(extend_info_free+0x1d)[0x55c71b8e0add]
/usr/bin/tor(rend_intro_point_free+0x25)[0x55c71b88a8d5]
/usr/bin/tor(rend_consider_services_intro_points+0x5c4)[0x55c71b894744]
/usr/bin/tor(hs_service_run_scheduled_events+0xa1c)[0x55c71b97c15c]
/usr/bin/tor(+0x4e931)[0x55c71b858931]
/usr/bin/tor(+0x6e6d0)[0x55c71b8786d0]
/usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x6a0)[0x7f0067487420]
/usr/bin/tor(do_main_loop+0x29d)[0x55c71b85be1d]
/usr/bin/tor(tor_main+0x1c25)[0x55c71b85f925]
/usr/bin/tor(main+0x19)[0x55c71b8575c9]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7f0065ea31c1]
/usr/bin/tor(_start+0x2a)[0x55c71b85761a]
```Tor: 0.3.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/24312Update DirCache Warning2020-06-27T13:54:56ZcypherpunksUpdate DirCache WarningWhen DirCache is disabled tor 0.3.1.x says:
```
[warn] DirCache is disabled and we are configured as a relay. This may disqualify us from becoming a guard in the future.
```
Since TorBrowser ships tor 0.3.1.x we can consider this as gr...When DirCache is disabled tor 0.3.1.x says:
```
[warn] DirCache is disabled and we are configured as a relay. This may disqualify us from becoming a guard in the future.
```
Since TorBrowser ships tor 0.3.1.x we can consider this as granted (not in the future), right?Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24308MaxMemInCellQueues minimum of 256MB is still too large for low-RAM relays (LE...2020-08-18T12:53:14ZTracMaxMemInCellQueues minimum of 256MB is still too large for low-RAM relays (LEDE and OpenWRT routers)The minimum value for torrc configuration MaxMemInCellQueues of 256MB is still too large for memory constrained relays. I've been running a tor relay on my OpenWRT router for a few years reliably. I recently upgraded the router to use to...The minimum value for torrc configuration MaxMemInCellQueues of 256MB is still too large for memory constrained relays. I've been running a tor relay on my OpenWRT router for a few years reliably. I recently upgraded the router to use tor 0.2.9.12 where MaxMemInCellQueues is minimally defaulted to 256MB, even if the router only has 128 MB. Naturally, Linux oom-killer kills it after a few hours. I have a lot of bandwidth but I can't share it now...
This is related to ticket legacy/trac#9686
```
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.070987] Mem-Info:
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.073403] active_anon:18341 inactive_anon:51 isolated_anon:0
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.073403] active_file:35 inactive_file:73 isolated_file:0
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.073403] unevictable:0 dirty:0 writeback:0 unstable:0
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.073403] slab_reclaimable:728 slab_unreclaimable:2804
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.073403] mapped:41 shmem:1120 pagetables:102 bounce:0
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.073403] free:4723 free_pcp:40 free_cma:0
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.106437] Normal free:18892kB min:16384kB low:20480kB high:24576kB active_anon:73364kB inactive_anon:204kB active_file:
140kB inactive_file:292kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:131072kB managed:125640kB mlocked:0kB dirty:0kB writeback:0kB mapped:164kB shmem
:4480kB slab_reclaimable:2912kB slab_unreclaimable:11216kB kernel_stack:544kB pagetables:408kB unstable:0kB bounce:0kB free_pcp:160kB local_pcp:160kB free_cma:0kB write
back_tmWed Nov 15 11:24:32 2017 kern.warn kernel: [221491.151989] lowmem_reserve[]: 0 0
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.155468] Normal: 763*4kB (UMEH) 446*8kB (UMEH) 255*16kB (UMEH) 44*32kB (UME) 20*64kB (UMEH) 3*128kB (UME) 2*256kB (UH)
1*512kB (U) 4*1024kB (UMH) 0*2048kB 0*4096kB = 18892kB
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.171705] 1228 total pagecache pages
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.175610] 0 pages in swap cache
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.179077] Swap cache stats: add 0, delete 0, find 0/0
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.184476] Free swap = 0kB
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.187482] Total swap = 0kB
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.190505] 32768 pages RAM
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.193422] 0 pages HighMem/MovableOnly
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.197412] 1358 pages reserved
Wed Nov 15 11:24:32 2017 kern.info kernel: [221491.200683] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name
...
Wed Nov 15 11:24:32 2017 kern.info kernel: [221491.370877] [28850] 52 28850 21220 15276 25 0 0 0 tor
Wed Nov 15 11:24:32 2017 kern.info kernel: [221491.379539] [ 9935] 0 9935 296 9 3 0 0 0 sleep
Wed Nov 15 11:24:32 2017 kern.err kernel: [221491.388387] Out of memory: Kill process 28850 (tor) score 487 or sacrifice child
Wed Nov 15 11:24:32 2017 kern.err kernel: [221491.396016] Killed process 28850 (tor) total-vm:84880kB, anon-rss:61096kB, file-rss:8kB
```
**Trac**:
**Username**: pmetrasTor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24303Tor fails to start if %include2020-06-27T13:54:57ZTracTor fails to start if %includeIf %include is present in torrc then tor service will fail to start.
The directive I aded to torrc was
%include /etc/torrc.d/
Folder exist and perms are valid, but tor service will not start and tor will not write the reason why to log...If %include is present in torrc then tor service will fail to start.
The directive I aded to torrc was
%include /etc/torrc.d/
Folder exist and perms are valid, but tor service will not start and tor will not write the reason why to log.
**Trac**:
**Username**: littlefeatherTor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24300Failed to find node for hop #1 of our path. Discarding this circuit2020-07-28T15:53:25ZDavid Gouletdgoulet@torproject.orgFailed to find node for hop #1 of our path. Discarding this circuitBeen two days in a row with git master (033-alpha), when I boot up my computer and tor starts and fails to bootstrap. It takes around 8 minutes before it finally work.
The particularity I have with my tor client is that I pin my `EntryN...Been two days in a row with git master (033-alpha), when I boot up my computer and tor starts and fails to bootstrap. It takes around 8 minutes before it finally work.
The particularity I have with my tor client is that I pin my `EntryNodes` with one specific Guard for testing purposes and I stumbled on this issue.
Attached to the ticket are the info logs from the start of tor up to the 100% bootstrap.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24299Allow onion services to distinguish clients from each other2022-10-11T23:40:02ZGeorge KadianakisAllow onion services to distinguish clients from each otherWe should provide onion services with the option to distinguish their anonymous users from each other, and also to handle those clients in a clinical way to do diagnostics, rate-limiting, abusive client blocking, etc.
One proposed way t...We should provide onion services with the option to distinguish their anonymous users from each other, and also to handle those clients in a clinical way to do diagnostics, rate-limiting, abusive client blocking, etc.
One proposed way to do so comes from an old tor-dev thread which suggests we assign a virtual IP to each client based on the circuit ID:
https://lists.torproject.org/pipermail/tor-dev/2014-March/006610.html
I2P seems to have implemented a derivative of this idea. I wonder how it works for them:
https://github.com/i2p/i2p.i2p/blob/920b14212fa80a3a0e92d6e919fdae7e39ed22d5/apps/i2ptunnel/java/src/net/i2p/i2ptunnel/I2PTunnelServer.java#L739Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24298Better handling of DoS attacks on onion services2022-10-11T23:40:02ZGeorge KadianakisBetter handling of DoS attacks on onion servicesWe have received various reports on attackers being able to DoS onion services in various ways. Examples:
a) Layer-7 attacks where the attacker spams HTTP requests: https://www.hackerfactor.com/blog/index.php?/archives/777-Stopping-Tor-...We have received various reports on attackers being able to DoS onion services in various ways. Examples:
a) Layer-7 attacks where the attacker spams HTTP requests: https://www.hackerfactor.com/blog/index.php?/archives/777-Stopping-Tor-Attacks.html
b) DoS through the Tor protocol (intense circuit construction #16052m legacy/trac#15515).
We should come up with designs and plans on how to mitigate those DoS attacks better in the future.
Due to the anonymous unlinkable nature of Tor onion service clients, these designs should be modular enough so that onion service operators can write their own anti-DoS modules to handle specific cases of attacks.
This is a parent ticket to handle the various subtasks.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24279configure libevent leaks2020-06-27T13:54:57ZAlex Xuconfigure libevent leaksbreaks build with "CFLAGS=-fsanitize=address". probably be better just to use pkg-config, but...breaks build with "CFLAGS=-fsanitize=address". probably be better just to use pkg-config, but...Tor: 0.3.2.x-finalAlex XuAlex Xuhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24272Add a CacheDirectory option2020-06-27T13:54:57ZteorAdd a CacheDirectory optionTor puts a large number of large, rapidly changing documents in its DataDirectory, which defaults to /var/lib on many systems. This means that the size of backups blows out when running tor 0.3.1.1-alpha or later.
If we added a CacheDir...Tor puts a large number of large, rapidly changing documents in its DataDirectory, which defaults to /var/lib on many systems. This means that the size of backups blows out when running tor 0.3.1.1-alpha or later.
If we added a CacheDirectory option, it could default to /var/cache (or the appropriate paths on other operating systems), and be ignored by most backup tools.
This directory should contain
* cached directory documents, including cached (micro)descriptors and consensuses, and compressed directory document diffs
* any other files that tor can easily regenerate or re-download
This might also benefit mobile users with small disks, but application size appears to be less of a priority for mobile developers than CPU or network usage.
This is a breaking change for tools that expect to find consensuses in the data directory. Perhaps we should make CacheDirectory default to DataDirectory instead?
See this thread for background:
https://lists.torproject.org/pipermail/tor-relays/2017-November/013542.htmlTor: 0.3.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24269Raise a FATAL error if the user tried to combine v2 and prop224 hidden servic...2020-08-05T12:11:46ZcypherpunksRaise a FATAL error if the user tried to combine v2 and prop224 hidden service in same directoryA user is hosting a hidden service:
Hid /path/to/key/hs-www/
hidport 127.0.0.1:80 80
What will happen if he add "HidVersion V3" line to the middle of the config?
Hid /path/to/key/hs-www/
HidVersion V3
hidport 127.0.0.1:80 80
Tor shou...A user is hosting a hidden service:
Hid /path/to/key/hs-www/
hidport 127.0.0.1:80 80
What will happen if he add "HidVersion V3" line to the middle of the config?
Hid /path/to/key/hs-www/
HidVersion V3
hidport 127.0.0.1:80 80
Tor should detect this misconfiguration and raise an error.
(v2 and v3 keys should not exist in same directory)
should be;
==============================
Hid /path/to/key/hs-www/
hidport 127.0.0.1:80 80
Hid /path/to/key/hs-www-v3/
HidVersion V3
hidport 127.0.0.1:80 80
==============================https://gitlab.torproject.org/tpo/core/tor/-/issues/24268Keep parts of data directory in /var/cache instead of /var/lib2020-06-27T13:54:57ZSebastian HahnKeep parts of data directory in /var/cache instead of /var/libRoman Mamedov points out in https://lists.torproject.org/pipermail/tor-relays/2017-November/013541.html that we keep huge amounts of volatile data like consensus diffs in /var/lib/tor by default. I have just yesterday run into the same p...Roman Mamedov points out in https://lists.torproject.org/pipermail/tor-relays/2017-November/013541.html that we keep huge amounts of volatile data like consensus diffs in /var/lib/tor by default. I have just yesterday run into the same problem as him and needed to write exclusion rules for backups to keep the size sane.Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24265Fuzz all rust functions that are used by authorities to make sure they match C2020-07-28T15:55:36ZteorFuzz all rust functions that are used by authorities to make sure they match CWe could break consensus if some authorities are running the rust version of the code, and some are running the C version of the code, and their outputs differ on any input.
This is like legacy/trac#24029, but with arbitrary inputs that...We could break consensus if some authorities are running the rust version of the code, and some are running the C version of the code, and their outputs differ on any input.
This is like legacy/trac#24029, but with arbitrary inputs that may or may not be UTF-8.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24262hs-v3: Change "hsdir-interval" to "hsdir_interval" to match the spec2020-06-27T13:54:58ZDavid Gouletdgoulet@torproject.orghs-v3: Change "hsdir-interval" to "hsdir_interval" to match the specWe've merged the consensus param used by HS v3 in dir-spec.txt (legacy/trac#24118). They all follow some sort of common naming convention using underscores instead of hyphens.
The `hsdir-interval` is the only one in the code not followi...We've merged the consensus param used by HS v3 in dir-spec.txt (legacy/trac#24118). They all follow some sort of common naming convention using underscores instead of hyphens.
The `hsdir-interval` is the only one in the code not following this. It is in `get_time_period_length()`Tor: 0.3.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24257We should specify what is means for a Tor version to be obsolete2020-06-27T13:54:58ZRoger DingledineWe should specify what is means for a Tor version to be obsoleteAtlas hit legacy/trac#24256 because our logic for what Tor versions are obsolete is opaque.
We should try to write it down somewhere better than the tor_version_is_obsolete() function. Maybe version-spec.txt is a good location?Atlas hit legacy/trac#24256 because our logic for what Tor versions are obsolete is opaque.
We should try to write it down somewhere better than the tor_version_is_obsolete() function. Maybe version-spec.txt is a good location?Tor: 0.3.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24254There needs to be documentation on what kernel versions the KIST Scheduler wi...2021-07-22T16:21:37ZTracThere needs to be documentation on what kernel versions the KIST Scheduler will run onThere needs to be decimation on what kernel versions the KIST Scheduler will run on. Right now I'm running
Ubuntu 16.04.3 LTS (GNU/Linux 2.6.32-042stab120.11 x86_64) and it looks like it is running based off the logs.
**Trac**:
**Use...There needs to be decimation on what kernel versions the KIST Scheduler will run on. Right now I'm running
Ubuntu 16.04.3 LTS (GNU/Linux 2.6.32-042stab120.11 x86_64) and it looks like it is running based off the logs.
**Trac**:
**Username**: DbryrtfbcbhgfTor: 0.3.2.x-finalpastlypastlyhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24253Update GettingStartedRust.md with new build instructions2020-06-27T13:54:58ZChelsea KomloUpdate GettingStartedRust.md with new build instructionsAs we now build Rust modules in a single binary, the instructions for adding a new rust module has changed.
See attached patchAs we now build Rust modules in a single binary, the instructions for adding a new rust module has changed.
See attached patchTor: 0.3.3.x-final