The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T13:49:45Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/312293-hop tor circuit and malicious middle relays2020-06-27T13:49:45ZTrac3-hop tor circuit and malicious middle relaysTor traffic can be correlated if someones know both the guard and exit. The middle relay seems to know both the guard and exit. To make Tor secure again, we will need an extra pair of relays to make sure that no-one knows both the guard ...Tor traffic can be correlated if someones know both the guard and exit. The middle relay seems to know both the guard and exit. To make Tor secure again, we will need an extra pair of relays to make sure that no-one knows both the guard and exit except the user.
**Trac**:
**Username**: JessieTessiehttps://gitlab.torproject.org/tpo/core/tor/-/issues/31228Support spawning multiple transport instances2022-06-24T14:57:08ZPhilipp Winterphw@torproject.orgSupport spawning multiple transport instancesOne Tor instance can only handle one transport instance, i.e., one cannot run two obfs4 instances in one tor. Adding support for this use case will require changes in our PT spec, in PT spec implementations, and in tor.
As pointed out [...One Tor instance can only handle one transport instance, i.e., one cannot run two obfs4 instances in one tor. Adding support for this use case will require changes in our PT spec, in PT spec implementations, and in tor.
As pointed out [in this comment](https://trac.torproject.org/projects/tor/ticket/29285#comment:5), tor would need the config options `ServerTransportPlugin`, `ServerTransportListenAddr`, and `ServerTransportOptions` to support multiple instances of a single transport. One way to accomplish this would be to append a numeric, incrementing suffix to a transport's name, e.g.:
```
ServerTransportPlugin obfs4-0 exec /usr/bin/obfs4proxy
ServerTransportPlugin obfs4-1 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs4-0 0.0.0.0:10000
ServerTransportListenAddr obfs4-1 0.0.0.0:20000
```
legacy/trac#11211 is vaguely related in that it aims to add dual stack support for bridges so that, say, an obfs4 instance can listen on both an IPv4 and IPv6 address. legacy/trac#29285 is also related because it tracks our PT spec improvement process and supporting multiple instances of a transport is one potential improvement.https://gitlab.torproject.org/tpo/core/tor/-/issues/31223Research approaches for improving the availability of services under DoS2022-10-17T19:25:12ZGeorge KadianakisResearch approaches for improving the availability of services under DoSWe've been improving the health of the network during onion service DoS, but not the onion service availability. This is a task for looking at this angle.
During the related Stockholm session we looked into various approaches that could...We've been improving the health of the network during onion service DoS, but not the onion service availability. This is a task for looking at this angle.
During the related Stockholm session we looked into various approaches that could help us towards that goal. Here are some of them:
- Introducing application-layer anonymous tokens that allow legit clients to get priority over DoS attacker
- PoW approaches like argon2
- CAPTCHA approaches like introducing a token server giving reCAPTCHA tokens
- Hiding introduction points by rate limiting how quickly clients can find them. Valet nodes?
- Having intros check that clients don't use the same IP over and over. Proof-of-existence?
- Pay bitcoin to introduce
Each of the above solutions has problems and this is a ticket to investigate at least the most promising of them, and attempt to move forward with something.https://gitlab.torproject.org/tpo/core/tor/-/issues/31221Line unexpectedly reached at channel_tls_handle_cell at ../src/core/or/channe...2020-06-27T13:49:46Zweasel (Peter Palfrader)Line unexpectedly reached at channel_tls_handle_cell at ../src/core/or/channeltls.c:1111via https://bugs.debian.org/932789
might be a duplicate of legacy/trac#31136.
```
+---
| Tor[2185]: Bug: Line unexpectedly reached at channel_tls_handle_cell at ../src/core/or/channeltls.c:1111. Stack trace: (on Tor 0.3.5.8
+)
| Tor[21...via https://bugs.debian.org/932789
might be a duplicate of legacy/trac#31136.
```
+---
| Tor[2185]: Bug: Line unexpectedly reached at channel_tls_handle_cell at ../src/core/or/channeltls.c:1111. Stack trace: (on Tor 0.3.5.8
+)
| Tor[2185]: Bug: /usr/bin/tor(log_backtrace_impl+0x46) [0x55d7f7455aa6] (on Tor 0.3.5.8 )
| Tor[2185]: Bug: /usr/bin/tor(tor_bug_occurred_+0xc0) [0x55d7f74511c0] (on Tor 0.3.5.8 )
| Tor[2185]: Bug: /usr/bin/tor(channel_tls_handle_cell+0x49a) [0x55d7f72db71a] (on Tor 0.3.5.8 )
| Tor[2185]: Bug: /usr/bin/tor(+0x9a16a) [0x55d7f72ff16a] (on Tor 0.3.5.8 )
| Tor[2185]: Bug: /usr/bin/tor(connection_handle_read+0x99d) [0x55d7f72c918d] (on Tor 0.3.5.8 )
| Tor[2185]: Bug: /usr/bin/tor(+0x69ebe) [0x55d7f72ceebe] (on Tor 0.3.5.8 )
| Tor[2185]: Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba) [0x7fe17bc599ba] (on Tor 0.3.5.8 )
| Tor[2185]: Bug: /lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7fe17bc5a537] (on Tor 0.3.5.8 )
| Tor[2185]: Bug: /usr/bin/tor(do_main_loop+0xb0) [0x55d7f72d0290] (on Tor 0.3.5.8 )
| Tor[2185]: Bug: /usr/bin/tor(tor_run_main+0x10e5) [0x55d7f72be0d5] (on Tor 0.3.5.8 )
| Tor[2185]: Bug: /usr/bin/tor(tor_main+0x3a) [0x55d7f72bb30a] (on Tor 0.3.5.8 )
| Tor[2185]: Bug: /usr/bin/tor(main+0x19) [0x55d7f72baec9] (on Tor 0.3.5.8 )
| Tor[2185]: Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7fe17b53b09b] (on Tor 0.3.5.8 )
| Tor[2185]: Bug: /usr/bin/tor(_start+0x2a) [0x55d7f72baf1a] (on Tor 0.3.5.8 )
+---
(on a Debian buster system)
```Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31219Nautilus-S - FSB contractor project to spy on tor users2020-07-29T12:56:37ZcypherpunksNautilus-S - FSB contractor project to spy on tor usershttps://gizmodo.com/hackers-reportedly-break-into-sytech-a-contractor-for-1836584241https://gizmodo.com/hackers-reportedly-break-into-sytech-a-contractor-for-1836584241https://gitlab.torproject.org/tpo/core/tor/-/issues/31207Space out first connection_edge_process_relay_cell() line in circuit_receive_...2020-06-27T13:49:46ZNeel Chauhanneel@neelc.orgSpace out first connection_edge_process_relay_cell() line in circuit_receive_relay_cell()
The first `if` statement containing `connection_edge_process_relay_cell()` looks like this
```
if ((reason=connection_edge_process_relay_cell(cell, circ, conn, NULL))
< 0) {
```
Whereas the second looks like this:
...
The first `if` statement containing `connection_edge_process_relay_cell()` looks like this
```
if ((reason=connection_edge_process_relay_cell(cell, circ, conn, NULL))
< 0) {
```
Whereas the second looks like this:
```
if ((reason = connection_edge_process_relay_cell(cell, circ, conn,
layer_hint)) < 0) {
```
We should space out the firstTor: 0.4.2.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31202Refactor practracker's issue-listing code to return a generator2021-09-16T14:23:38ZNick MathewsonRefactor practracker's issue-listing code to return a generatorRight now, this issue-listing code exposes the problems with "print()". Instead, it should yield them as a generator, so that the invoking code can decide what to do with them.Right now, this issue-listing code exposes the problems with "print()". Instead, it should yield them as a generator, so that the invoking code can decide what to do with them.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31190List all valid DirPort urls2021-09-16T14:23:38ZDamian JohnsonList all valid DirPort urlsHi network team. Every so often folks stumble on DirPort resources Stem doesn't recognize...
https://trac.torproject.org/projects/tor/ticket/30930
https://trac.torproject.org/projects/tor/ticket/31187
Unfortunately section 'B' is the c...Hi network team. Every so often folks stumble on DirPort resources Stem doesn't recognize...
https://trac.torproject.org/projects/tor/ticket/30930
https://trac.torproject.org/projects/tor/ticket/31187
Unfortunately section 'B' is the closest enumeration we have, but even it doesn't include everything...
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n3888
Could we spec a listing of all urls the DirPort supports (similar to the GETINFO section in the control-spec)?
Thanks!https://gitlab.torproject.org/tpo/core/tor/-/issues/31189potential docs update needed for GuardLifetime?2020-07-14T22:24:18Zcypherpunkspotential docs update needed for GuardLifetime?The documentation for the GuardLifetime torrc option says:
```
If nonzero, and UseEntryGuards is set, minimum time to keep a guard before
picking a new one. If zero, we use the GuardLifetime parameter from the
consensus directo...The documentation for the GuardLifetime torrc option says:
```
If nonzero, and UseEntryGuards is set, minimum time to keep a guard before
picking a new one. If zero, we use the GuardLifetime parameter from the
consensus directory. No value here may be less than 1 month or greater
than 5 years; out-of-range values are clamped. (Default: 0)
```
In commit hash 385602e9826e79dbf0d8b51abfd925e59f275708 it appears that there was a behavior change which allows guard lifetimes of 1 day or greater (grep for `get_options()->GuardLifetime >= 86400`). `git blame` indicated the docs for the `GuardLifetime` option haven't been touched in 6-7 years, so I think they need an update after this change.
Is the expected behavior that setting `UseEntryGuards 1` and `GuardLifetime 1 day` will result in guards being used for no longer than one day?Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31188make[1]: don't know how to make ./src/rust/target/release/libtor_rust.a2022-06-17T18:31:31ZTracmake[1]: don't know how to make ./src/rust/target/release/libtor_rust.aHi,
I'm trying to add the option to build tor with Rust to pkgsrc. On NetBSD 9 (8.99.48) amd64, this fails at the moment:
...
CC src/trunnel/libor_trunnel_a-socks5.oCC src/trunnel/libor_trunnel_a-netinfo.oCC src/t...Hi,
I'm trying to add the option to build tor with Rust to pkgsrc. On NetBSD 9 (8.99.48) amd64, this fails at the moment:
...
CC src/trunnel/libor_trunnel_a-socks5.oCC src/trunnel/libor_trunnel_a-netinfo.oCC src/trunnel/libor_trunnel_a-circpad_negotiation.oAR src/trunnel/libor-trunnel.aCC src/lib/trace/trace.oAR src/lib/libtor-trace.a
make[1]: don't know how to make ./src/rust/target/release/libtor_rust.a. Stop
make[1]: stopped in /usr/work/pkgsrc-ng0/tor/work/tor-0.4.0.5
*** Error code 2
Stop.
make: stopped in /usr/work/pkgsrc-ng0/tor/work/tor-0.4.0.5
*** Error code 1
Stop.
make[1]: stopped in /usr/pkgsrc/pkgsrc-ng0/tor
*** Error code 1
Stop.
make: stopped in /usr/pkgsrc/pkgsrc-ng0/tor
rust and cargo are available in the build environment, and the crates are made available ahead of time and TOR_RUST_DEPENDENCIES points to the directory they are in.
Questions: to verify if I hit an error on tor's side or Rust specifics wrt NetBSD, and not on my side, do you support verbose builds?
If you have seen this kind of error before in to on other platforms, was there a resolution (I have seen 3 vaguely similar tickets).
Disclaimer: I'm a contributor to pkgsrc, but I'm not the pkgsrc maintainer for tor, so this is more of a personal exploration to see if I can propose it.
Thanks.
**Trac**:
**Username**: ng0https://gitlab.torproject.org/tpo/core/tor/-/issues/31183Situational symlink attacks on ControlPortWriteToFile etc.2022-09-01T21:39:47ZGeorge KadianakisSituational symlink attacks on ControlPortWriteToFile etc.Here is a bug report from paldium on hackerone. It's basically a very situational and restricted local priviledge escalation against certain setups and threat models:
```
# Summary
It is possible to change permissions of files through ...Here is a bug report from paldium on hackerone. It's basically a very situational and restricted local priviledge escalation against certain setups and threat models:
```
# Summary
It is possible to change permissions of files through tor or
gain write access to newly created ones. The target file can be
chosen by a local attacker if an adjusted configuration is used.
#How to reproduce
- Given is a FreeBSD or Mac OS X system.
- Tor is configured with a torrc file containing this line:
ControlPortWriteToFile /tmp/control.txt
- Optionally (race condition) this line is included as well:
ControlPortFileGroupReadable 1
- /tmp is a directory with sticky bit, i.e. trwxrwxrwx
##or
- Given is a Unix-like (Linux) system.
- Tor is configured with a torrc file containing this line:
ControlPortWriteToFile /tmp/proof/control.txt
- Optionally (race condition) this line is included as well:
ControlPortFileGroupReadable 1
- /tmp/proof is writable by the local attacker
When tor starts, then it will eventually write all available control
ports into file configured by "ControlPortWriteToFile". This file is not
written directly into, but a temporary file is used (the extension
".tmp" is added to file name). If this file already exists, then it is
simply truncated.
See src/lib/fs/files.c start_writing_to_file for details, especially
line 321 and following.
The problem is that an attacker can simply create the temporary file
before tor gets the chance to. On Mac this attack works by default
against /tmp, but Linux has a protection against symlink attacks on
directories with sticky bit like /tmp or /var/tmp. Therefore it takes an
unusual configuration on Linux or a different (regular) directory.
Let the attacker create a file which tor, even with dropped privileges,
can write to:
`attacker$ install -m 666 /dev/null /tmp/control.txt.tmp`
The tor process will use this file without adjusting the permissions,
because O_CREAT was not actually performed. Instead, O_TRUNC simply
truncated the file to remove existing content.
Afterwards tor will write content to this file, which the attacker could
simply override at this point. But there is no real need to, because
the target file will still keep the permissions of this temporary file
after rename.
See src/lib/fs/files.c replace_file for details. Basically it's a
simple rename() call which therefore removes the target inode and
renames the temporary file to the target one (in this setup).
At this point, the first attack is finished. The file /tmp/control.txt
is under control of the attacker. If "ControlPortFileGroupReadable 1"
is not given, this exploit code works on Linux systems as well (you
can skip the proof/ part on Mac due to lack of /tmp protection):
```In torrc: ControlPortWriteToFile /tmp/proof/control.txt
attacker$ install -Dm 666 /dev/null /tmp/proof/control.txt.tmp
root$ tor -f torrc
attacker$ ls -l /tmp/proof/control.txt
-rw-rw-rw- 1 attacker attacker 0 Jun 24 22:59 /tmp/proof/control.txt```
##Second attack
The second attack uses a race condition. Because /tmp/control.txt is
under control of the attacker, the file can be deleted and replaced with
a symbolic link to a target which we want to get group read permissions
for. This is a possible scenario if "ControlPortFileGroupReadable 1" is
given.
In this case, chmod() is called in tor process. See
src/feature/control/control.c control_ports_write_to_file for more
details, especially line 149 for more details (chmod).
The system call chmod() uses a file path as an argument. There is no
guarantee that the file path still refers to the file which has been
created by the tor process. Furthermore, chmod() follows symbolic
links, therefore the referenced target file is adjusted by chmod.
This is obviously a race condition but can be used to gain read access
to files which -- even by configuration -- should be private to the
tor user.
The attacker still needs group-read permissions, otherwise the newly
revealed files still cannot be accessed.
##Example
`tor just renamed controlled /tmp/control.txt.tmp to /tmp/control.txt`
`attacker$ rm /tmp/control.txt`
`attacker$ ln -s /var/lib/tor /tmp/control.txt`
`tor calls chmod on /tmp/control.txt and therefore on /var/lib/tor`
The attacker, if part of tor's group, can access /var/lib/tor now as well
(only read, but hierarchy is known through other tor installations)
#Solution
Use fchmod() on a file which has been opened with open() and O_NOFOLLOW
to prevent changing any files which have been reached through symbolic
links. Preventing symbolic links is already a great deal in file
src/lib/fs/dir.c check_private_dir, line 85. Could be implemented as
tor_chmod() to fix other chmod() calles in the code as well.
Use mkstemp() to atomically create a temporary file which has the
guaranteed permission 600 and owned by the tor user.
## Impact
A local attacker can modify the content of files which are considered trusted by dependent tools, e.g. the control port file.
Also a local attacker can extend privileges of files which are supposed to be private to the tor user and not readable by the group.
Timeline:
2019-06-25 10:24:59 +0000: @paldium (comment)
To clarify one aspesct about attack 1: Of course it is not a tor issue if someone creates a world writable directory and lets tor create files in there. Everyone could simply override the resulting file and tor will never be able to prevent that. Therefore, the rename()-issue is a non-issue on Linux. But as a user I would expect that temporary files within /tmp with sticky bits are properly handled.
But attack 2 (race condition) should even be prevented in a world writable directory (or writable by a possibly malicious user). Therefore I consider attack 2 on Linux to be unlikely but plausible.
I would like to add a patch to this, but I am not sure how you want to handle file permissions.
The nicest approach would be to supply the permissions to the function which creates the file, but that would be a no-op on Windows.
Otherwise tor_chmod could open() the file and at least prevent symbolic link attacks. Yet, files could still be modified which are not the ones we created.
As this is a design decision, I haven't started writing a patch because I do not know which one you would prefer.
```
Here is some further information:
```
ControlPortWriteFile is one example. The same attack scenarios are true for:
- ExtORPortCookieAuthFileGroupReadable 1
- CookieAuthFileGroupReadable 1
- DataDirectoryGroupReadable 1
- CacheDirectoryGroupReadable 1
- KeyDirectoryGroupReadable 1
```
Here is some of my analysis for attack scenarios:
```
Hello @paldium,
thanks for submitting this report.
Here is the best attacks we could find given the bugs you gave us:
Attack 1) The most realistic attack scenario I could think of is a system where the attacker is a local user who cannot establish outgoing connections, but is able to overwrite the ControlPortWriteToFile file, and replaces it with an attacker controlled IP:PORT, and then a controller program connects to the evil IP:PORT thereby deanonymizing the user. This seems to be a very artificial scenario, which assumes a particular threat model, and a tor with specific configuration parameters, and a very specific system,.
Attack 2) The most realistic attack scenario here would be the attacker using this "read anything controlled by Tor" race condition attack to learn the private keys of an onion service that are on the same system but not able to read them... I'm actually not sure if that would work, but I think it's possible. This also assumes a particular threat-model, a multi-user system, and specific configuration parameters.
@paldium, would it be possible to outline the various solutions we have for fixing this issue?I don't think specifying the permissions in the torrc is a nice thing from a UX perspective. Perhaps not following symlinks is a start but not the whole thing? Maybe we should just abort if there is a dangerous configuration? I wonder how prevalent this is.
```
and here is suggestions on patching:
```
Hi @asn,
I agree here, the attack is impossible against default setups and takes quite specific steps to be exploitable.
To fix this vulnerability at its root, I recommend to adjust the function `start_writing_to_file` in `src/lib/fs/files.c`. The system call `mkstemp` (included in POSIX) guarantees to create a unique file name for the (optional) temporary file. This way, an attacker cannot prepare a file before tor tries to create it. In case of conflict, mkstemp iterates through a huge pool of possible names and if all fail, it returns -1.
It must be checked if mkstemp is a viable option on all target systems, especially Windows. But it's POSIX, so it should work.
The attached patch performs these changes, but breaks a test which would be redundant then (it fails because it tries to create a temporary file beforehand, which `mkstemp` successfully prevents).
###Next improvement to consider (for attack 2):
As far as I understand the code, possible modes for files are:
- 0600 (default)
- 0640 (if configuration requests group-writable files, non-Windows systems only)
- 0400 (tor-gencert, which is not expected to run on Windows according to manual page)
If the special case 0400 is handled in tor-gencert directly, the functions in `src/lib/fs/files.c` can be further reduced in their feature set: Just add a "group readable" attribute to these functions and remove the explicit `mode` (if present):
- start_writing_to_stdio_file
- start_writing_to_file
- write_str_to_file
- write_bytes_to_file
All these functions would use 0600 by default and only support 0640 if the boolean "group readable" flag is set to true -- and that will only happen on non-Windows systems.
With these changes in place, the remaining `chmod` calls (except for the control socket) can be removed and that will also fix the second attack (and gives full atomic control to the newly introduced `fchmod` call):
###Before:
```
if (write_str_to_file(options->ControlPortWriteToFile, joined, 0) < 0) {
log_warn(LD_CONTROL, "Writing %s failed: %s",
options->ControlPortWriteToFile, strerror(errno));
}
#ifndef _WIN32
if (options->ControlPortFileGroupReadable) {
if (chmod(options->ControlPortWriteToFile, 0640)) {
log_warn(LD_FS,"Unable to make %s group-readable.",
options->ControlPortWriteToFile);
}
}
#endif /* !defined(_WIN32) */
```
###After:
```
if (write_str_to_file(options->ControlPortWriteToFile,
options->ControlPortFileGroupReadable, joined, 0) < 0) {
log_warn(LD_CONTROL, "Writing %s failed: %s",
options->ControlPortWriteToFile, strerror(errno));
}
```https://gitlab.torproject.org/tpo/core/tor/-/issues/31182Add more typesafe containers to tor2020-07-29T12:57:52ZNick MathewsonAdd more typesafe containers to torAs we migrate slowly towards Rust, we'll want a solution that lets us move to type-safe containers like vec and hashmap.As we migrate slowly towards Rust, we'll want a solution that lets us move to type-safe containers like vec and hashmap.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31181Deprecate more options in 0.4.32020-07-29T12:47:28ZNick MathewsonDeprecate more options in 0.4.3In 0.4.3, we should look for more options that nobody uses (or nobody _should_ use) and deprecate them.In 0.4.3, we should look for more options that nobody uses (or nobody _should_ use) and deprecate them.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31180Remove easy deprecated options in 0.4.52021-11-06T13:24:19ZNick MathewsonRemove easy deprecated options in 0.4.5We have accumulated a handful of deprecated options; We should remove some of them in 0.4.5.We have accumulated a handful of deprecated options; We should remove some of them in 0.4.5.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31179Eliminate non tor_queue.h linked lists.2020-06-27T13:49:47ZNick MathewsonEliminate non tor_queue.h linked lists.We should use tor_queue.h in place of anywhere that we currently manually manage a next and prev. (This may be a duplicate.)
We are planning to only do a couple of these for S31, though we might do more, time permitting.We should use tor_queue.h in place of anywhere that we currently manually manage a next and prev. (This may be a duplicate.)
We are planning to only do a couple of these for S31, though we might do more, time permitting.https://gitlab.torproject.org/tpo/core/tor/-/issues/31178Scripts to help with backport branches2020-06-27T13:49:47ZNick MathewsonScripts to help with backport branchesTeor mentioned wanting to create a helper script for use when backporting branches to older versions of Tor. It would behave like "merge-forward", but instead create a set of candidate branches -- and maybe pull requests for those branc...Teor mentioned wanting to create a helper script for use when backporting branches to older versions of Tor. It would behave like "merge-forward", but instead create a set of candidate branches -- and maybe pull requests for those branches too.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31177Start conversation about auto-formatting our C code2020-06-27T13:49:47ZNick MathewsonStart conversation about auto-formatting our C codeWith legacy/trac#29226 we want to automate our C formatting. But to do so, we will need to come to agreement about our style, and for that, we should start the discussion well in advance.With legacy/trac#29226 we want to automate our C formatting. But to do so, we will need to come to agreement about our style, and for that, we should start the discussion well in advance.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31176Teach practracker about .may_include files2021-09-16T14:23:38ZNick MathewsonTeach practracker about .may_include filesWe would like to introduce a second category of .may_include rules: those that should only apply on an advisory basis. We would treat violations of these rules as a best practices violation rather than an error. It would allow us to st...We would like to introduce a second category of .may_include rules: those that should only apply on an advisory basis. We would treat violations of these rules as a best practices violation rather than an error. It would allow us to start ratcheting down the number of layering violations.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31175Teach practracker to apply separate rules for C headers2020-06-27T13:49:48ZNick MathewsonTeach practracker to apply separate rules for C headersWe might want to impose stricter limits for length and includes on header files than we do on C files.We might want to impose stricter limits for length and includes on header files than we do on C files.Tor: 0.4.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31163A flag to use hostname than IP as relay2020-07-29T12:47:04ZTracA flag to use hostname than IP as relayThough we can add a hostname in the `Address` field in torrc, it finally resolves the name time to time and pushes the descriptor.
However, that hurts the dynamic IP relays. If tor could work on pure hostnames (yes, that'd cause a resol...Though we can add a hostname in the `Address` field in torrc, it finally resolves the name time to time and pushes the descriptor.
However, that hurts the dynamic IP relays. If tor could work on pure hostnames (yes, that'd cause a resolving overhead on every connection) then a whole range of dynamic IP relays could come into the picture which might strengthen the Tor network.
**Trac**:
**Username**: cyberbot