Commit 563f8610 authored by Nick Mathewson's avatar Nick Mathewson 👜
Browse files

Revise trac.torproject.org urls to refer to gitlab replacements.

Closes #40101.
parent 8669ace2
o Documentation:
- Replace URLs from our old bugtracker so that they refer to the
new bugtracker and wiki. Closes ticket 40101.
......@@ -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%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
[circpad-researchers-want](https://trac.torproject.org/projects/tor/query?keywords=~circpad-researchers-want).
areas are labeled with
[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
......
......@@ -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
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
......
......@@ -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
......@@ -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
......
......@@ -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
......
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.
......@@ -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
......
......@@ -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)
......@@ -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 */
......
......@@ -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
......
......@@ -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,
......
......@@ -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 "
......
......@@ -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;
}
......
......@@ -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
......
......@@ -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();
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment