The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2021-07-22T16:19:44Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30745Document disabled CI2021-07-22T16:19:44ZteorDocument disabled CIAdd a section to our CI status page for disabled CI
Add a section to doc/HACKING/ReleasingTor.md reminding releasers to
manually check the status of whatever the disabled CI would have
checked.
CI person should periodically look at the...Add a section to our CI status page for disabled CI
Add a section to doc/HACKING/ReleasingTor.md reminding releasers to
manually check the status of whatever the disabled CI would have
checked.
CI person should periodically look at these jobs.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30630Put CI URLs in ReleasingTor.md2021-07-22T16:19:44ZteorPut CI URLs in ReleasingTor.mdarma asked us where the CI builders are.
The list is in ReleasingTor.md and on the wiki, but only the wiki has the URLs:
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CIFailures#CIBuildersarma asked us where the CI builders are.
The list is in ReleasingTor.md and on the wiki, but only the wiki has the URLs:
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CIFailures#CIBuildersTor: 0.4.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30455Improve documentation for chutney warnings in "make test-network-all"2021-07-22T16:19:43ZNick MathewsonImprove documentation for chutney warnings in "make test-network-all"It appears that in fb32c522320430f, we added a second call to test-network.sh inside our test-network-all loop. Now the code looks like this:
```
for f in $$flavors; do \
$(SHELL) $(top_srcdir)/test-driver --test-name $$f --log-file...It appears that in fb32c522320430f, we added a second call to test-network.sh inside our test-network-all loop. Now the code looks like this:
```
for f in $$flavors; do \
$(SHELL) $(top_srcdir)/test-driver --test-name $$f --log-file $(TEST_NETWORK_ALL_LOG_DIR)/$$f.log --trs-file $(TEST_NETWORK_ALL_LOG_DIR)/$$f.trs $(TEST_NETWORK_ALL_DRIVER_FLAGS) $(top_srcdir)/src/test/test-network.sh --flavor $$f $(TEST_NETWORK_FLAGS); \
$(top_srcdir)/src/test/test-network.sh $(TEST_NETWORK_WARNING_FLAGS); \
done; \
```
I might be wrong, but it looks to me like we're calling test-network.sh twice in each loop: once through `test-driver`, and once directly.
I'm not going to work on this till teor is back, though, since there are dragons here that I do not understand.Tor: 0.4.2.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30261Add "How do I find bug or feature versions?" to doc/HACKING2021-07-22T16:19:43ZteorAdd "How do I find bug or feature versions?" to doc/HACKINGWe need to find bugfix versions for changes files and backports, and feature versions for specifications.
Let's document the git commands to do that.
For an example, see:
https://trac.torproject.org/projects/tor/ticket/30224#comment:4We need to find bugfix versions for changes files and backports, and feature versions for specifications.
Let's document the git commands to do that.
For an example, see:
https://trac.torproject.org/projects/tor/ticket/30224#comment:4Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30119cert-spec uses binary encodings but does not specify byte order2021-07-22T16:19:43Zirlcert-spec uses binary encodings but does not specify byte orderFrom looking at the Tor implementation (in a black box way, didn't look at the source code) these seem to be big endian byte order. We should have a note in cert-spec for implementors so they don't have to guess.From looking at the Tor implementation (in a black box way, didn't look at the source code) these seem to be big endian byte order. We should have a note in cert-spec for implementors so they don't have to guess.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30112Fix outdated comments in dirserv_read_measured_bandwidths()2021-09-16T14:19:58ZteorFix outdated comments in dirserv_read_measured_bandwidths()We refactored the function to use tor_getdelim(), but didn't remove the comments about fgets().We refactored the function to use tor_getdelim(), but didn't remove the comments about fgets().Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/30109Document that MapAddress is automatically strict, but does not handle redirects2021-08-23T15:16:06ZteorDocument that MapAddress is automatically strict, but does not handle redirectsWe should document that:
1. StrictNodes does not apply to MapAddress
2. MapAddress ~~falls back to a random exit by default~~ fails rather than falling back to a random exit
Edited to add:
3. If the site does a redirect, MapAddress does...We should document that:
1. StrictNodes does not apply to MapAddress
2. MapAddress ~~falls back to a random exit by default~~ fails rather than falling back to a random exit
Edited to add:
3. If the site does a redirect, MapAddress does not apply to the new siteTor: 0.4.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29979Don't recommend expect() in CodingStandardsRust, because it panics2021-07-22T16:19:43ZteorDon't recommend expect() in CodingStandardsRust, because it panicsSee the pull request from a GitHub contributor:
https://github.com/torproject/tor/pull/883See the pull request from a GitHub contributor:
https://github.com/torproject/tor/pull/883Tor: 0.4.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29635tor man page screws up quotes when telling you to use quotes for command line2021-07-22T16:19:43ZRoger Dingledinetor man page screws up quotes when telling you to use quotes for command linetor.1.txt says
```
You will need to
quote options with spaces in them: if you want Tor to log all debugging
messages to debug.log, you will probably need to say --Log 'debug file
debug.log'.
```
which results in a man page that says
```
...tor.1.txt says
```
You will need to
quote options with spaces in them: if you want Tor to log all debugging
messages to debug.log, you will probably need to say --Log 'debug file
debug.log'.
```
which results in a man page that says
```
You will need to quote options with spaces in them:
if you want Tor to log all debugging messages to debug.log, you will
probably need to say --Log debug file debug.log.
```
which sure isn't going to help anybody.
Changing both the ' to " seems like it resolves it.
The bad quotes went in during commit f5e86bc.Tor: 0.4.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29310control-spec: "limits/max-mem-in-queues" appears to be undocumented2021-07-22T16:19:43Znusenucontrol-spec: "limits/max-mem-in-queues" appears to be undocumented```
GETINFO info/names
[...]
limits/max-mem-in-queues -- Actual limit on memory in queues
[...]
```
but it can not be found in:
https://gitweb.torproject.org/torspec.git/tree/control-spec.txt```
GETINFO info/names
[...]
limits/max-mem-in-queues -- Actual limit on memory in queues
[...]
```
but it can not be found in:
https://gitweb.torproject.org/torspec.git/tree/control-spec.txtTor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29219Write (more) guidelines for Tor coding best practices2021-07-22T16:19:43ZNick MathewsonWrite (more) guidelines for Tor coding best practicesWe should extend our best practices guidelines in doc/HACKING with all/most of the following:
* Avoiding layer violations
* Fewer levels of block nesting
* Small functions
* Small files
* Few includes per file
* Smaller state obje...We should extend our best practices guidelines in doc/HACKING with all/most of the following:
* Avoiding layer violations
* Fewer levels of block nesting
* Small functions
* Small files
* Few includes per file
* Smaller state objects
* Making new features compile-time optional modules
* incremental implementation and testing
* Fewer branches
* Fewer callers/callees per function
* "Leave it better than you find it"
* Well-bounded modules
* Fewer data dependencies
Some of these can be quantified; the ones that can be should have targets.
I'm putting an optimistically low time estimate on this one under the assumption that we will have only minimal debate. :)Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29216Document how to make new files/modules in Tor2021-07-22T16:20:05ZNick MathewsonDocument how to make new files/modules in TorWe should document how to make option/required files/modules in rust/CWe should document how to make option/required files/modules in rust/CTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29214Update 'tor-guts' archictecture documentation to describe current (actual, as...2021-07-22T16:20:05ZNick MathewsonUpdate 'tor-guts' archictecture documentation to describe current (actual, as-built) architecture.The official deliverable here is "Architectural documentation for how Tor modules work with one another, covering both the actuality and the refactored architecture". The "refactored architecture" is under legacy/trac#29215.The official deliverable here is "Architectural documentation for how Tor modules work with one another, covering both the actuality and the refactored architecture". The "refactored architecture" is under legacy/trac#29215.Tor: 0.4.3.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29121tor man page doesn't mention isolating between socksports2021-07-22T16:20:05ZRoger Dingledinetor man page doesn't mention isolating between socksportsIf I set SocksPort 9050 and also SocksPort 9060, then if I understand correctly, Tor automatically isolates stream requests that come in on the different socksports.
But the man page doesn't mention this level of isolation. Maybe becaus...If I set SocksPort 9050 and also SocksPort 9060, then if I understand correctly, Tor automatically isolates stream requests that come in on the different socksports.
But the man page doesn't mention this level of isolation. Maybe because there is no flag for influencing it?
It sure seems helpful to have a full sentence in the socksport intro stanza explaining what gets isolated by default, and what can be isolated by changing options. Or maybe there is a better place to put that than the socksport section?Tor: 0.4.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29079Minor bandwidth file spec updates2021-07-22T16:20:05ZteorMinor bandwidth file spec updatesThe terminator was 4 characters long from sbws 0.1.0 to sbws 1.0.0
https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-spec.txt#n96The terminator was 4 characters long from sbws 0.1.0 to sbws 1.0.0
https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-spec.txt#n96Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29055Add synonym OnionService* to HiddenService* torrc options2021-07-22T16:20:05Zs7rAdd synonym OnionService* to HiddenService* torrc optionsWe started referring as OnionService instead of HiddenService, would it make sense to make `OnionService*` torrc parameter synonym to `HiddenService*` for all torrc options, so that one can use:
```
OnionServiceDir /var/lib/tor/my-web-p...We started referring as OnionService instead of HiddenService, would it make sense to make `OnionService*` torrc parameter synonym to `HiddenService*` for all torrc options, so that one can use:
```
OnionServiceDir /var/lib/tor/my-web-page
OnionServicePort 80 127.0.0.1:80
OnionServiceVersion 3
```
`HiddenService*` parameters will of course still work, and continue to do so, in order not to break any existing torrc config files. Then we can simply update the manual, if we want to ditch the **HiddenService** code-name.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/29015Document tor_ersatz_socketpair() and the functions it calls2021-07-22T16:20:05ZteorDocument tor_ersatz_socketpair() and the functions it callsThe function comments in socketpair.c are missing or incomplete.
Maybe we should add function comments, using the tor_socketpair() comment as a starting point?
https://github.com/torproject/tor/blob/701eaef980de4f7dbb5c31c4fee9b7e1e266...The function comments in socketpair.c are missing or incomplete.
Maybe we should add function comments, using the tor_socketpair() comment as a starting point?
https://github.com/torproject/tor/blob/701eaef980de4f7dbb5c31c4fee9b7e1e266d7a1/src/lib/net/socket.c#L450Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28984Update dir-spec observed bandwidth to 5 days2021-07-22T16:20:05ZteorUpdate dir-spec observed bandwidth to 5 daysIn legacy/trac#23856 we accidentally updated the observed bandwidth to 5 days from 1 day. It's a good change for privacy, and it doesn't seem to affect load-balancing too much.
So let's update the spec, and review as part of sbws 1.1.In legacy/trac#23856 we accidentally updated the observed bandwidth to 5 days from 1 day. It's a good change for privacy, and it doesn't seem to affect load-balancing too much.
So let's update the spec, and review as part of sbws 1.1.Tor: 0.4.0.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28954fuzz-descriptor aborts with a crash2021-07-22T16:20:05Ztoralffuzz-descriptor aborts with a crashWith recent Tor (tor-0.3.5.3-alpha-727-g99713b176) the command
```
/usr/bin/afl-fuzz -i /home/torproject/tor-fuzz-corpora/descriptor -o tmp/ -m 45 -- /home/torproject/tor/src/test/fuzz/fuzz-descriptor
```
gives an
```
[-] Oops, the progr...With recent Tor (tor-0.3.5.3-alpha-727-g99713b176) the command
```
/usr/bin/afl-fuzz -i /home/torproject/tor-fuzz-corpora/descriptor -o tmp/ -m 45 -- /home/torproject/tor/src/test/fuzz/fuzz-descriptor
```
gives an
```
[-] Oops, the program crashed with one of the test cases provided. There are
several possible explanations:
- The test case causes known crashes under normal working conditions. If
so, please remove it. The fuzzer should be seeded with interesting
inputs - but not ones that cause an outright crash.
- The current memory limit (45.0 MB) is too low for this program, causing
it to die due to OOM when parsing valid files. To fix this, try
bumping it up with the -m setting in the command line. If in doubt,
try something along the lines of:
( ulimit -Sv $[44 << 10]; /path/to/binary [...] <testcase )
Tip: you can use http://jwilk.net/software/recidivm to quickly
estimate the required amount of virtual memory for the binary. Also,
if you are using ASAN, see /usr/share/doc/afl-2.52b/notes_for_asan.txt.
- Least likely, there is a horrible bug in the fuzzer. If other options
fail, poke <lcamtuf@coredump.cx> for troubleshooting tips.
[-] PROGRAM ABORT : Test case 'id:000153,orig:2136185e394ee1b2b4b9336ec365ac0c0dd5f2ac53065272591d3bb31375d568' results in a crash
Location : perform_dry_run(), afl-fuzz.c:2852
```
despite that recidivm marks a value of "45" as ok:
```
$ ../recidivm/recidivm -v -u M ./src/test/fuzz/fuzz-descriptor
recidivm: 35184372088832 -> ok
recidivm: 17592186044416 -> ok
recidivm: 8796093022208 -> ok
recidivm: 4398046511104 -> ok
recidivm: 2199023255552 -> ok
recidivm: 1099511627776 -> ok
recidivm: 549755813888 -> ok
recidivm: 274877906944 -> ok
recidivm: 137438953472 -> ok
recidivm: 68719476736 -> ok
recidivm: 34359738368 -> ok
recidivm: 17179869184 -> ok
recidivm: 8589934592 -> ok
recidivm: 4294967296 -> ok
recidivm: 2147483648 -> ok
recidivm: 1073741824 -> ok
recidivm: 536870912 -> ok
recidivm: 268435456 -> ok
recidivm: 134217728 -> ok
recidivm: 67108864 -> ok
recidivm: 33554432 -> exit status 127
recidivm: 50331648 -> ok
recidivm: 41943040 -> exit status 127
recidivm: 46137344 -> exit status 127
recidivm: 48234496 -> ok
recidivm: 47185920 -> ok
45
```
With "55" the fuzzer proceeds.
FWIW:
```
~/recidivm $ git describe
0.1.4-30-g844edc0
torproject@mr-fox ~/recidivm $
```
and
```
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-7.3.0-r3/work/gcc-7.3.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/7.3.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.3.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.3.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.3.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/g++-v7 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/7.3.0/python --enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo Hardened 7.3.0-r3 p1.4' --enable-esp --enable-libstdcxx-time --disable-libstdcxx-pch --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --with-multilib-list=m64 --disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libmudflap --disable-libssp --disable-libcilkrts --disable-libmpx --enable-vtable-verify --enable-libvtv --disable-libquadmath --enable-lto --without-isl --disable-libsanitizer --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.3.0 (Gentoo Hardened 7.3.0-r3 p1.4)
```Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28941tor-spec: Wrong default HiddenServiceVersion value in section 3.27 of control...2021-07-22T16:20:05Zrl1987tor-spec: Wrong default HiddenServiceVersion value in section 3.27 of control-spec.txt```
1695 (The "NEW:BEST" option obeys the HiddenServiceVersion torrc option default
1696 value. Currently it is 2.)
```
Since 0.3.5.1-alpha, default `HiddenServiceVersion` is 3.```
1695 (The "NEW:BEST" option obeys the HiddenServiceVersion torrc option default
1696 value. Currently it is 2.)
```
Since 0.3.5.1-alpha, default `HiddenServiceVersion` is 3.Tor: unspecified