Merge branch 'tor-gitlab/mr/126'

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.

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
+researchers may find useful is labeled in our bugtracker with
-[circpad-researchers](https://trac.torproject.org/projects/tor/query?keywords=~circpad-researchers),
+[Padding Research](https://gitlab.torproject.org/tpo/core/tor/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Padding%20Research),
 and the list of improvements that are known to be necessary for some research
-areas are tagged with
+areas are labeled with
-[circpad-researchers-want](https://trac.torproject.org/projects/tor/query?keywords=~circpad-researchers-want).
+[Padding Research Requires](https://gitlab.torproject.org/tpo/core/tor/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Padding%20Research%20Requires).
 
 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

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_machines.h).
 
 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
+- `tor-0.4.1.5` did not support two machines on the same circuit, the following
-  fix has to be made: https://trac.torproject.org/projects/tor/ticket/31111 .
+  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

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/2016SummerDevMeeting/Notes/SecurityIssuePolicy
+https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/SecurityPolicy

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
+     [gitlab](https://gitlab.torproject.org) our bug tracking tool and look for
-     tickets that have received the "easy" tag: these are ones that developers
+     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

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/AnnouncementTemplates
+       https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/AnnouncementTemplates
 
 ## V. Aftermath and cleanup
 

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, 
+when it launches tor service (see launchd.plist(5) manpage). Also,
-kern.ipc.maxsockets is determined dynamically by the system and thus is 
+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.
-

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 
+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 
+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 
+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
 

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)
-

src/app/config/config.c

@@ -3592,7 +3592,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;
@@ -3609,7 +3609,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 */

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

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,

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 "

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;
 }

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

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\n");
+            "https://bugs.torproject.org/tpo/core/tor/8742.\n");
 
  done:
   teardown_capture_of_logs();