commit 563f8610fd7471bd564b0f2e81223d7eb2e64da0 Author: Nick Mathewson nickm@torproject.org Date: Fri Aug 14 09:21:02 2020 -0400
Revise trac.torproject.org urls to refer to gitlab replacements.
Closes #40101. --- changes/ticket40101 | 3 +++ doc/HACKING/CircuitPaddingDevelopment.md | 14 ++++++------- doc/HACKING/CircuitPaddingQuickStart.md | 36 ++++++++++++++++---------------- doc/HACKING/Fuzzing.md | 2 +- doc/HACKING/GettingStarted.md | 11 +++++----- doc/HACKING/ReleasingTor.md | 2 +- doc/TUNING | 15 +++++++------ doc/man/tor.1.txt | 8 +++---- src/app/config/app_config.md | 3 +-- src/app/config/config.c | 4 ++-- src/core/or/circuitbuild.c | 2 +- src/core/or/circuitlist.c | 2 +- src/feature/relay/relay_config.c | 2 +- src/feature/relay/router.c | 2 +- src/lib/string/compat_string.h | 2 +- src/test/test_options.c | 2 +- 16 files changed, 56 insertions(+), 54 deletions(-)
diff --git a/changes/ticket40101 b/changes/ticket40101 new file mode 100644 index 0000000000..7af42b9499 --- /dev/null +++ b/changes/ticket40101 @@ -0,0 +1,3 @@ + o Documentation: + - Replace URLs from our old bugtracker so that they refer to the + new bugtracker and wiki. Closes ticket 40101. diff --git a/doc/HACKING/CircuitPaddingDevelopment.md b/doc/HACKING/CircuitPaddingDevelopment.md index a4e65697b8..1344ebd3d8 100644 --- a/doc/HACKING/CircuitPaddingDevelopment.md +++ b/doc/HACKING/CircuitPaddingDevelopment.md @@ -156,7 +156,7 @@ it).
This document focuses primarily on the circuit padding framework's cover traffic features, and will only briefly touch on the potential obfuscation and -application layer coupling points of the framework. Explicit layer coupling +application layer coupling points of the framework. Explicit layer coupling points can be created by adding either new [machine application events](#62-machine-application-events) or new [internal machine events](#63-internal-machine-events) to the circuit padding framework, so that @@ -178,7 +178,7 @@ Most importantly: this framing allows cover traffic defenses to be modeled as an optimization problem search space, expressed as fields of a C structure (which is simultaneously a compact opaque bitstring as well as a symbolic vector in an abstract feature space). This kind of space is particularly well -suited to search by gradient descent, GAs, and GANs. +suited to search by gradient descent, GAs, and GANs.
When performing this optimization search, each padding machine should have a fitness function, which will allow two padding machines to be compared for @@ -186,7 +186,7 @@ relative effectiveness. Optimization searches work best if this fitness can be represented as a single number, for example the total amount by which it reduces the [Balanced Accuracy](https://en.wikipedia.org/wiki/Precision_and_recall#Imbalanced_Data) -of an adversary's classifier, divided by an amount of traffic overhead. +of an adversary's classifier, divided by an amount of traffic overhead.
Before you begin the optimization phase for your defense, you should also carefully consider the [features and @@ -1024,11 +1024,11 @@ would gladly accept patches that do so.
The following list gives an overview of these improvements, but as this document ages, it may become stale. The canonical list of improvements that -researchers may find useful is tagged in our bugtracker with -[circpad-researchers](https://trac.torproject.org/projects/tor/query?keywords=~circpad-researchers), +researchers may find useful is labeled in our bugtracker with +[Padding Research](https://gitlab.torproject.org/tpo/core/tor/-/issues?scope=all&utf8=%E2%9...), and the list of improvements that are known to be necessary for some research -areas are tagged with -[circpad-researchers-want](https://trac.torproject.org/projects/tor/query?keywords=~circpad-researchers...). +areas are labeled with +[Padding Research Requires](https://gitlab.torproject.org/tpo/core/tor/-/issues?scope=all&utf8=%E2%9...).
Please consult those lists for the latest status of these issues. Note that not all fixes will be backported to all Tor versions, so be mindful of which diff --git a/doc/HACKING/CircuitPaddingQuickStart.md b/doc/HACKING/CircuitPaddingQuickStart.md index 2b01dae074..25bf05048c 100644 --- a/doc/HACKING/CircuitPaddingQuickStart.md +++ b/doc/HACKING/CircuitPaddingQuickStart.md @@ -7,7 +7,7 @@ circuit padding framework from scratch. Notes were taken as part of porting [Adaptive Padding Early (APE)](https://www.cs.kau.se/pulls/hot/thebasketcase-ape/) from basket2 to the circuit padding framework. The goal is just to document the process and provide -useful pointers along the way, not create a useful machine. +useful pointers along the way, not create a useful machine.
The quick and dirty plan is to: 1. clone and compile tor @@ -29,7 +29,7 @@ fixes that have since been merged to origin/master. If you need the newest framework features, you should use that master instead.
```console -$ sh autogen.sh +$ sh autogen.sh $ ./configure $ make ``` @@ -73,7 +73,7 @@ We have one more step left before we move on the machine: configure TB to always use our middle relay. Edit `Browser/TorBrowser/Data/Tor/torrc` and set `MiddleNodes <fingerprint>`, where `<fingerprint>` is the fingerprint of the relay. Start TB, visit a website, and manually confirm that the middle is used -by looking at the circuit display. +by looking at the circuit display.
## Add a bare-bones APE padding machine
@@ -89,10 +89,10 @@ might be broken in the future, just search for the headings): [circuitpadding_machines.h](https://gitweb.torproject.org/tor.git/tree/src/core/or/circuitpadding_machin...).
Please consult the above links for details. Moving forward, the focus is to -describe what was done, not necessarily explaining all the details why. +describe what was done, not necessarily explaining all the details why.
Since we plan to make changes to tor, create a new branch `git checkout -b -circuit-padding-ape-machine tor-0.4.1.5`. +circuit-padding-ape-machine tor-0.4.1.5`.
We start with declaring two functions, one for the machine at the client and one at the relay, in `circuitpadding_machines.h`: @@ -107,8 +107,8 @@ The definitions go into `circuitpadding_machines.c`: ```c /**************** Adaptive Padding Early (APE) machine ****************/
-/** - * Create a relay-side padding machine based on the APE design. +/** + * Create a relay-side padding machine based on the APE design. */ void circpad_machine_relay_wf_ape(smartlist_t *machines_sl) @@ -137,14 +137,14 @@ circpad_machine_relay_wf_ape(smartlist_t *machines_sl) // register the machine relay_machine->machine_num = smartlist_len(machines_sl); circpad_register_padding_machine(relay_machine, machines_sl); - + log_info(LD_CIRC, "Registered relay WF APE padding machine (%u)", relay_machine->machine_num); }
-/** - * Create a client-side padding machine based on the APE design. +/** + * Create a client-side padding machine based on the APE design. */ void circpad_machine_client_wf_ape(smartlist_t *machines_sl) @@ -191,13 +191,13 @@ circpad_machine_client_wf_ape(origin_padding_machines); circpad_machine_relay_wf_ape(relay_padding_machines); ```
-We run `make` to get a new `tor` binary and copy it to our local TB. +We run `make` to get a new `tor` binary and copy it to our local TB.
## Run the machine
To be able to view circuit info events in the console as we launch TB, we add `Log -[circ]info notice stdout` to `torrc` of TB. +[circ]info notice stdout` to `torrc` of TB.
Running TB to visit example.com we first find in the log:
@@ -224,13 +224,13 @@ Aug 30 18:36:55.000 [info] circpad_handle_padding_negotiated(): Middle node did We see that our middle support padding (since we upgraded to tor-0.4.1.5), that we attempt to negotiate, our machine starts on the client, transitions to the end state, and is freed. The last line shows that the middle doesn't have a -padding machine that can run. +padding machine that can run.
Next, we follow the same steps as earlier and replace the modified `tor` at our middle relay. We don't update the logging there to avoid logging on the info level on the live network. Looking at the client log again we see that negotiation works as before except for the last line: it's missing, so the -machine is running at the middle as well. +machine is running at the middle as well.
## Implementing the APE state machine
@@ -239,14 +239,14 @@ more machines (for the receive portion of WTFP-PAD, beyond AP), and pick reasonable parameters for the distributions (I completely winged it now, as when implementing APE). The [circuit-padding-ape-machine branch](https://github.com/pylls/tor/tree/circuit-padding-ape-machine) contains -the commits for the full machines with plenty of comments. +the commits for the full machines with plenty of comments.
Some comments on the process:
-- `tor-0.4.1.5` does not support two machines on the same circuit, the following - fix has to be made: https://trac.torproject.org/projects/tor/ticket/31111 . +- `tor-0.4.1.5` did not support two machines on the same circuit, the following + fix had to be made: https://bugs.torproject.org/tpo/core/tor/31111 . The good news is that everything else seems to work after the small change in - the fix. + the fix. - APE randomizes its distributions. Currently, this can only be done during start of `tor`. This makes sense in the censorship circumvention setting (`obfs4`), less so for WF defenses: further randomizing each circuit is likely diff --git a/doc/HACKING/Fuzzing.md b/doc/HACKING/Fuzzing.md index d9e133008a..1a9185aebf 100644 --- a/doc/HACKING/Fuzzing.md +++ b/doc/HACKING/Fuzzing.md @@ -130,4 +130,4 @@ $ src/test/fuzz/fuzz-http --debug < /path/to/test.case Please report any issues discovered using the process in Tor's security issue policy:
-https://trac.torproject.org/projects/tor/wiki/org/meetings/2016SummerDevMeet... +https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/SecurityPoli... diff --git a/doc/HACKING/GettingStarted.md b/doc/HACKING/GettingStarted.md index ee3da10a4b..6d61be9881 100644 --- a/doc/HACKING/GettingStarted.md +++ b/doc/HACKING/GettingStarted.md @@ -71,10 +71,11 @@ Once you've reached this point, here's what you need to know. Many people have gotten started by looking for an area where they personally felt Tor was underperforming, and investigating ways to fix it. If you're looking for ideas, you can head to - [trac](https://trac.torproject.org) our bug tracking tool and look for - tickets that have received the "easy" tag: these are ones that developers + [gitlab](https://gitlab.torproject.org) our bug tracking tool and look for + tickets that have received the "First Contribution" label: these are ones + that developers think would be pretty simple for a new person to work on. For a bigger - challenge, you might want to look for tickets with the "lorax" + challenge, you might want to look for tickets with the "Project Ideas" keyword: these are tickets that the developers think might be a good idea to build, but which we have no time to work on any time soon. @@ -140,10 +141,10 @@ Once you've reached this point, here's what you need to know. 8. Submitting your patch
We review patches through tickets on our bugtracker at - [trac](https://trac.torproject.org). You can either upload your patches there, or + [gitlab](https://gitlab.torproject.org). You can either upload your patches there, or put them at a public git repository somewhere we can fetch them (like gitlab, github or bitbucket) and then paste a link on the appropriate - trac ticket. + ticket.
Once your patches are available, write a short explanation of what you've done on trac, and then change the status of the ticket to diff --git a/doc/HACKING/ReleasingTor.md b/doc/HACKING/ReleasingTor.md index 6513583ec5..24b66a069a 100644 --- a/doc/HACKING/ReleasingTor.md +++ b/doc/HACKING/ReleasingTor.md @@ -215,7 +215,7 @@ $ git push origin tag tor-0.4.x.y-<status> can vary.
For templates to use when announcing, see: - https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/Announce... + https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/Announcement...
## V. Aftermath and cleanup
diff --git a/doc/TUNING b/doc/TUNING index 24552a38cb..7da37e1adc 100644 --- a/doc/TUNING +++ b/doc/TUNING @@ -1,13 +1,13 @@ -Most operating systems limit an amount of TCP sockets that can be used +Most operating systems limit an amount of TCP sockets that can be used simultaneously. It is possible for a busy Tor relay to run into these -limits, thus being unable to fully utilize the bandwidth resources it +limits, thus being unable to fully utilize the bandwidth resources it has at its disposal. Following system-specific tips might be helpful to alleviate the aforementioned problem.
Linux -----
-Use 'ulimit -n' to raise an allowed number of file descriptors to be +Use 'ulimit -n' to raise an allowed number of file descriptors to be opened on your host at the same time.
FreeBSD @@ -17,7 +17,7 @@ Tune the followind sysctl(8) variables: * kern.maxfiles - maximum allowed file descriptors (for entire system) * kern.maxfilesperproc - maximum file descriptors one process is allowed to use - * kern.ipc.maxsockets - overall maximum numbers of sockets for entire + * kern.ipc.maxsockets - overall maximum numbers of sockets for entire system * kern.ipc.somaxconn - size of listen queue for incoming TCP connections for entire system @@ -31,8 +31,8 @@ Mac OS X
Since Mac OS X is BSD-based system, most of the above hold for OS X as well. However, launchd(8) is known to modify kern.maxfiles and kern.maxfilesperproc -when it launches tor service (see launchd.plist(5) manpage). Also, -kern.ipc.maxsockets is determined dynamically by the system and thus is +when it launches tor service (see launchd.plist(5) manpage). Also, +kern.ipc.maxsockets is determined dynamically by the system and thus is read-only on OS X.
OpenBSD @@ -79,8 +79,7 @@ Disclaimer
Do note that this document is a draft and above information may be technically incorrect and/or incomplete. If so, please open a ticket -on https://trac.torproject.org or post to tor-relays mailing list. +on https://gitlab.torproject.org or post to tor-relays mailing list.
Are you running a busy Tor relay? Let us know how you are solving the out-of-sockets problem on your system. - diff --git a/doc/man/tor.1.txt b/doc/man/tor.1.txt index e8dcc7b236..4b37548b07 100644 --- a/doc/man/tor.1.txt +++ b/doc/man/tor.1.txt @@ -211,9 +211,9 @@ backslash character () before the end of the line. Comments can be used in such multiline entries, but they must start at the beginning of a line.
Configuration options can be imported from files or folders using the %include -option with the value being a path. This path can have wildcards. Wildcards are -expanded first, then sorted using lexical order. Then, for each matching file or -folder, the following rules are followed: if the path is a file, the options from +option with the value being a path. This path can have wildcards. Wildcards are +expanded first, then sorted using lexical order. Then, for each matching file or +folder, the following rules are followed: if the path is a file, the options from the file will be parsed as if they were written where the %include option is. If the path is a folder, all files on that folder will be parsed following lexical order. Files starting with a dot are ignored. Files in subfolders are ignored. @@ -3854,7 +3854,7 @@ https://spec.torproject.org. See also **torsocks**(1) and **torify**(1). == BUGS
Because Tor is still under development, there may be plenty of bugs. Please -report them at https://trac.torproject.org/. +report them at https://bugs.torproject.org/.
== AUTHORS
diff --git a/src/app/config/app_config.md b/src/app/config/app_config.md index b359ce77f6..96a55494ff 100644 --- a/src/app/config/app_config.md +++ b/src/app/config/app_config.md @@ -2,5 +2,4 @@ @brief app/config: Top-level configuration code
Refactoring this module is a work in progress, see -[ticket 29211](https://trac.torproject.org/projects/tor/ticket/29211). - +[ticket 29211](https://bugs.torproject.org/tpo/core/tor/29211) diff --git a/src/app/config/config.c b/src/app/config/config.c index 23f280891b..b5ea8fcd71 100644 --- a/src/app/config/config.c +++ b/src/app/config/config.c @@ -3458,7 +3458,7 @@ options_validate_cb(const void *old_options_, void *options_, char **msg) "configured. This is bad because it's very easy to locate your " "entry guard which can then lead to the deanonymization of your " "hidden service -- for more details, see " - "https://trac.torproject.org/projects/tor/ticket/14917. " + "https://bugs.torproject.org/tpo/core/tor/14917. " "For this reason, the use of one EntryNodes with an hidden " "service is prohibited until a better solution is found."); return -1; @@ -3475,7 +3475,7 @@ options_validate_cb(const void *old_options_, void *options_, char **msg) "be harmful to the service anonymity. Because of this, we " "recommend you either don't do that or make sure you know what " "you are doing. For more details, please look at " - "https://trac.torproject.org/projects/tor/ticket/21155."); + "https://bugs.torproject.org/tpo/core/tor/21155."); }
/* Single Onion Services: non-anonymous hidden services */ diff --git a/src/core/or/circuitbuild.c b/src/core/or/circuitbuild.c index 76e9ccf0a5..ab4ce9f784 100644 --- a/src/core/or/circuitbuild.c +++ b/src/core/or/circuitbuild.c @@ -2148,7 +2148,7 @@ count_acceptable_nodes, (const smartlist_t *nodes, int direct)) * The alternative is building the circuit in reverse. Reverse calls to * onion_extend_cpath() (ie: select outer hops first) would then have the * property that you don't gain information about inner hops by observing - * outer ones. See https://trac.torproject.org/projects/tor/ticket/24487 + * outer ones. See https://bugs.torproject.org/tpo/core/tor/24487 * for this. * * (Note further that we still exclude the exit to prevent A - B - A diff --git a/src/core/or/circuitlist.c b/src/core/or/circuitlist.c index c0c28c9e2d..c31fe00dea 100644 --- a/src/core/or/circuitlist.c +++ b/src/core/or/circuitlist.c @@ -2144,7 +2144,7 @@ circuit_mark_all_dirty_circs_as_unusable(void) * This function is in the critical path of circuit_mark_for_close(). * It must be (and is) O(1)! * - * See https://trac.torproject.org/projects/tor/ticket/23512. + * See https://bugs.torproject.org/tpo/core/tor/23512 */ void circuit_synchronize_written_or_bandwidth(const circuit_t *c, diff --git a/src/feature/relay/relay_config.c b/src/feature/relay/relay_config.c index d3f904d286..6504c680eb 100644 --- a/src/feature/relay/relay_config.c +++ b/src/feature/relay/relay_config.c @@ -1037,7 +1037,7 @@ options_validate_relay_mode(const or_options_t *old_options, "Tor is currently configured as a relay and a hidden service. " "That's not very secure: you should probably run your hidden service " "in a separate Tor process, at least -- see " - "https://trac.torproject.org/8742"); + "https://bugs.torproject.org/tpo/core/tor/8742.");
if (options->BridgeRelay && options->DirPort_set) { log_warn(LD_CONFIG, "Can't set a DirPort on a bridge relay; disabling " diff --git a/src/feature/relay/router.c b/src/feature/relay/router.c index 675b977ade..9bf0e7026f 100644 --- a/src/feature/relay/router.c +++ b/src/feature/relay/router.c @@ -176,7 +176,7 @@ routerinfo_err_is_transient(int err) /** * For simplicity, we consider all errors other than * "not a server" transient - see discussion on - * https://trac.torproject.org/projects/tor/ticket/27034 + * https://bugs.torproject.org/tpo/core/tor/27034. */ return err != TOR_ROUTERINFO_ERROR_NOT_A_SERVER; } diff --git a/src/lib/string/compat_string.h b/src/lib/string/compat_string.h index f05265bdcc..5c9bf05ebd 100644 --- a/src/lib/string/compat_string.h +++ b/src/lib/string/compat_string.h @@ -42,7 +42,7 @@ static inline int strcasecmp(const char *a, const char *b) { * (If --enable-fragile-hardening is passed to configure, we use the hardened * variants, which do not suffer from this issue.) * - * See https://trac.torproject.org/projects/tor/ticket/15205 + * See https://bugs.torproject.org/tpo/core/tor/15205. */ #undef strlcat #undef strlcpy diff --git a/src/test/test_options.c b/src/test/test_options.c index 8e0d19f126..714ee4767f 100644 --- a/src/test/test_options.c +++ b/src/test/test_options.c @@ -1013,7 +1013,7 @@ test_options_validate__relay_with_hidden_services(void *ignored) "Tor is currently configured as a relay and a hidden service. " "That's not very secure: you should probably run your hidden servi" "ce in a separate Tor process, at least -- see " - "https://trac.torproject.org/8742%5Cn"); + "https://bugs.torproject.org/tpo/core/tor/8742.%5Cn");
done: teardown_capture_of_logs();