The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2022-04-21T16:40:01Zhttps://gitlab.torproject.org/tpo/core/torspec/-/issues/7Authorization types for v3 onion service have to be clarified in documentation2022-04-21T16:40:01ZTracAuthorization types for v3 onion service have to be clarified in documentationProblem 1. Official [[https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt|spec]] mentions stealth auth:
> [TODO: Also specify stealth client authorization.].
However, stealth auth is only used for v2 onion services. It sh...Problem 1. Official [[https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt|spec]] mentions stealth auth:
> [TODO: Also specify stealth client authorization.].
However, stealth auth is only used for v2 onion services. It should be fixed.
----
Problem 2. According to teor's [[https://trac.torproject.org/projects/tor/ticket/20700#comment:23|comment]] the following auth types were planned: 'descriptor', 'intro', and 'standard'. However, only 'descriptor' type is documented by spec (man page for tor alpha refers to spec for details). Other auth types are not documented at all, though spec gives a strong impression that 'descriptor' is only one of possible authentication types.
If tor project already has some understanding of these future planned auth types, they must be described at least in tickets. If it is not the case, somewhere (e.g. in man page which now refers to spec) we should write that 'descriptor' is the only auth type which will be supported in foreseeable future.
**Trac**:
**Username**: geoiphttps://gitlab.torproject.org/tpo/community/relays/-/issues/15Proposed "Best Practices" for running Tor public network services2022-03-16T20:22:53ZGeorgeProposed "Best Practices" for running Tor public network servicesProposed Best Practices for Tor Public Services
including directory authorities and bandwidth scanners
In an effort to work towards standardized and current "best practices" for Tor public network infrastructure, this document servers a...Proposed Best Practices for Tor Public Services
including directory authorities and bandwidth scanners
In an effort to work towards standardized and current "best practices" for Tor public network infrastructure, this document servers as a starting point. Configuring and maintaining high-uptime internet public services is not a skill anyone is born with, but comes from experience and instruction. Input and updates are vital.
* Single-Purpose Servers
The most important rule for all Tor public services is that the servers should be configured and maintained for a single-purpose. These are critical servers for the network and millions of users, and extraneous functions can not only deprecate the operation, but provides a large footprint of possible vulnerabilities.
* Bare Metal over Virtualized
When there's a choice between a "bare metal" versus a virtual solution such as VPS or a cloud instance, opt for the former. Actual server hardware provides lower-level access to the system than any virtualized system. Virtualized systems are sharing various resources, such as processors, entropy sources and so on.
* Multiple IPs
Multiple IPs are useful to separate remote access via SSHD(8) from the publicly listening services.
* Operating System and Application Options
Stable versions of both the operating system and applications should be chosen over snapshot or current branches, as the former should require less attention and provide more stability. Tor public network services are not playgrounds to tinker with new software versions. The best operating system to use is the one the administrator is most comfortable with.
* Full-Disk Encryption (FDE)
FDE is an important aspect of security in the event an adversary takes physical control of the server. For a remote server, some type of console access may be required for FDE password.
* System Partitioning
Separate partition for the relevant service, in some cases this would be the
${TOR_DATA_DIR}. There are two benefits. First, distinct mount(8) options can be enforced to enhance security such as removing the ability to execute binaries (-o noexec). Second, in the event that the partition reaches full capacity, the server should remain accessible as it's separate from the main operating system's partitions. A minimum partition size should be pre-determined.
directory authority:
bandwidth scanner:
bridge directory authority: current partition utilization is 228Mb
* Time Synchronization
Reasonably accurate time is critical. All operating systems contain some sort of time-syncing daemon, such as NTPD. Accurate time should not be scheduled with tools like rdate, which perform periodic hard resets of time. Accurate time allows for easier correlation in troubleshooting any issues between remote servers. Setting time to UTC makes this task simpler between systems on different time zones.
* SSHD(8) and SSH(1)
SSHD should be configured with strong security knobs including the most current asymmetric encryption (ED25519 currently), public/private keypair authentication, with a password-secured private key. SSHD keypairs should periodically be replaced. Consider using tested two-factor authentication, such as YubiKey. By default, ssh(1) should notify you if host keys change. Turn off any non-essential sshd(8) knobs, such as "AllowAgentForwarding" and "X11Forwarding".
* SSHD(8) Host Keys
The SSHD(8) host keys are another critical authenticity measure. A list of host keys should be maintained, and in the event host key's change, other relevant parties should be notified immediately. Print out a hard copy of any relevant servers' host keys.
* .Onion SSHD
Running a separate tor instance with SSHD as a hidden or .onion service provides a quiet entryway into the server more difficult to locate for most adversaries.
* Ports/Packages over Source
Third-party packages/ports should be installed from the operating systems' packages/ports system which eases future upgrades. Installing from source means upgrades may leave residual files, and is more difficult to script.
* Minimize Ports/Packages
Post-install packages/ports should be kept to a bare minimum. In most cases, the base operating system utilities should be preferred over third-party packages.
* torrc Configuration
The specific torrc file should be provided, and configuration changes, if necessary, need to be communicated clearly. Only the minimum options should be included in the torrc.
* User Configuration
Separate users should be employed when possible to provide least-privilege. A regular, non-privileged user with sudo-type access should be the main remote management login. Any local scripts run via cron(8) should be run as separate, non-privileged users without a login shell (eg, /sbin/nologin). The root user's crontab(1) should not be used for Tor-related server functions if possible.
* Data Backups
Regular backups are vital, particularly for the ${TOR_DATA_DIR} which includes the server's fingerprint and keys. Backups should be stored remotely in a secure location.
* Backup Hardware
A cold, offline hardware backup server is strongly recommended. While the backup server might not have all the current data, it should be fully capable of quickly syncing once connected.
* DNS
DNS can be a tool to mitigate certain security problems. PTR records should be set to assist in determining the authenticity of a remote server. In the case that SSL/TLS is used, CAA records should also be configured. DNSSec should be employed for better verification of DNS queries. Servers might consider running a local DNS caching server if lookups are a required part of the system's requirements
* IPv6
IPv6 should be configured for the server. IPv6 is slowly being integrated into the Tor infrastructure, and maintaining functional IPv6 means developers can test code without server administrators playing catch-up.
* daily(8)
Daily operating system reports should be configured whether part of the base system, scripted or added as a third-party package. A regular check on system operation and health, including RAID disk status and packet throughput is important for maintaining server uptime.
* Remote Monitoring
Remote monitoring is vital for knowing when services are unavailable. Systems which require a listening agent, such as Nagios, should not be used, as they increase possible vulnerability footprints. There are lighter monitoring systems, such as Sysmon (xxxxx) which don't require any local configuration on the monitored device. With Sysmon, for instance, particular IP/port combinations can be checked at set intervals for responsiveness, with an alert delivered by email.
* Know Your Upstream Provider(s)
Relations with provider and upstream is critical, most obviously in instances where cold backup hardware needs to be swapped out with failing current hardware. Additionally, in the event of dealing with hardware seizure, DDOS attacks, etc. coordination with provider can be the critical ingredient.
* Backup Administrators and Mentoring
In most cases a single administrator is responsible for each network service. Carefully selected secondary administrators should be mentored in an effort to extend knowledge of building and maintaining high-uptime Tor services. Such person should be considered well-trusted, and it's also an opportunity to diversify Tor's administrators to more women and other less-represented groups.https://gitlab.torproject.org/tpo/core/tor/-/issues/28597Document SOCKSPolicy better2022-02-07T19:38:32ZteorDocument SOCKSPolicy betterWe can improve the documentation for SOCKSPolicy:
* the default policy is accept all
* mention SOCKSPolicy in SOCKSPort and DNSPortWe can improve the documentation for SOCKSPolicy:
* the default policy is accept all
* mention SOCKSPolicy in SOCKSPort and DNSPorthttps://gitlab.torproject.org/tpo/core/torspec/-/issues/23Describe consensus digest calculation2022-02-21T19:12:25ZDamian JohnsonDescribe consensus digest calculationHi lovely network team folks. No doubt I'm being blind but I'm having difficulty figuring out how to calculate network status document digests.
During the voting period (minutes 55-60 of the hour) I fetched the detached signatures and u...Hi lovely network team folks. No doubt I'm being blind but I'm having difficulty figuring out how to calculate network status document digests.
During the voting period (minutes 55-60 of the hour) I fetched the detached signatures and upcoming consensus. The detached signatures cite the digest...
```
% curl http://128.31.0.39:9131/tor/status-vote/next/consensus-signatures > sigs
% curl http://128.31.0.39:9131/tor/status-vote/next/consensus > next_consensus
% grep consensus-digest sigs
consensus-digest 296BA01987256A1C8EFB20E17667152DCFA50755
```
But in trying hex encoded sha1s of various ranges of the consensus I'm having difficulty getting a value that matches that. No doubt I'm missing something but the spec is unhelpfully vague saying simply 'this is the digest' without citing a section describing how it's calculated...
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n3309
It's probably buried in there somewhere but I've skimmed through the spec a few times and it's not jumping out at me. Mind clarifying in the spec how to calculate this?
Thanks!https://gitlab.torproject.org/tpo/core/torspec/-/issues/15CIRC_BW is only for origin circuits2022-02-21T19:13:04ZteorCIRC_BW is only for origin circuitsThe CIRC_BW event is only sent for origin circuits:
https://github.com/torproject/torspec/blob/master/control-spec.txt#L2990
We should update the control spec:
https://lists.torproject.org/pipermail/tor-relays/2018-December/016696.htmlThe CIRC_BW event is only sent for origin circuits:
https://github.com/torproject/torspec/blob/master/control-spec.txt#L2990
We should update the control spec:
https://lists.torproject.org/pipermail/tor-relays/2018-December/016696.htmlhttps://gitlab.torproject.org/tpo/web/support/-/issues/259Add reproducible builds verification notes for Android to our verifying signa...2022-01-20T19:20:29ZGeorg KoppenAdd reproducible builds verification notes for Android to our verifying signature pageOn https://www.torproject.org/docs/verifying-signatures.html.en#BuildVerification we outline how to make a link between the bundles we actually ship (including update files) to the artifacts one gets by following our reproducible builds ...On https://www.torproject.org/docs/verifying-signatures.html.en#BuildVerification we outline how to make a link between the bundles we actually ship (including update files) to the artifacts one gets by following our reproducible builds path.
So far, this contains instructions for Linux and Windows bundles. macOS is tricky and dealt with in legacy/trac#18925.
This ticket is to add respective instructions for our .apk file(s) we ship.https://gitlab.torproject.org/tpo/web/community/-/issues/162Document pkg-config is required to compile tor with --enable-systemd on debian2022-01-20T19:11:28ZtraumschuleDocument pkg-config is required to compile tor with --enable-systemd on debianI was missing this detail to compile tor on debian with `--enable-systemd`.
This information is missing in the FAQs too:
https://support.torproject.org/
https://www.torproject.org/docs/faq#comp-install
Improving the error message to me...I was missing this detail to compile tor on debian with `--enable-systemd`.
This information is missing in the FAQs too:
https://support.torproject.org/
https://www.torproject.org/docs/faq#comp-install
Improving the error message to mention pkg-config would be nice:
> ./configure --enable-lzma=yes --enable-zstd=yes --disable-asciidoc --disable-unittests --enable-systemd=yes --prefix=/usr
{{{
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for pkg-config... no
checking for SYSTEMD... no
configure: Okay, checking for systemd a different way...
checking for SYSTEMD... no
configure: error: Explicitly requested systemd support, but systemd not found
}}}
```
$ dpkg -l|grep systemd
ii dbus-user-session 1.10.26-0+deb9u1 all simple interprocess messaging system (systemd --user integration)
ii gnome-logs 3.22.1-2 i386 viewer for the systemd journal.
ii libpam-systemd:i386 232-25+deb9u6 i386 system and service manager - PAM module
ii libsystemd-dev:i386 232-25+deb9u6 i386 systemd utility library - development files
ii libsystemd0:i386 232-25+deb9u6 i386 systemd utility library
ii systemd 232-25+deb9u6 i386 system and service manager
ii systemd-sysv 232-25+deb9u6 i386 system and service manager - SysV links
```
This was documented in 2015 (legacy/trac#16164):
> /configure --build=s390x-linux-gnu --prefix=/usr --includedir=\${prefix}/include --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libexecdir=\${prefix}/lib/tor --disable-maintainer-mode --disable-dependency-tracking --enable-systemd --prefix=/usr --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --localstatedir=/var --sysconfdir=/etc --disable-silent-rules --enable-gcc-warnings-advisory
> configure: WARNING: unrecognized options: --disable-maintainer-mode
> ...
> configure: error: Package requirements (systemd >= 209) were not met:
> No package 'systemd' found
> Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix.
> Alternatively, you may set the environment variables SYSTEMD209_CFLAGS and SYSTEMD209_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details.
Trying current [build options](https://buildd.debian.org/status/fetch.php?pkg=tor&arch=i386&ver=0.3.4.9-7&stamp=1544209067&raw=0) at home also fails when pkg-config isn't present:
> ./configure --build=i686-linux-gnu --prefix=/usr --includedir=/usr/include --mandir=/usr/share/man --infodir=/usr/share/info --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir=/usr/lib/i386-linux-gnu --libexecdir=/usr/lib/i386-linux-gnu --disable-maintainer-mode --disable-dependency-tracking --enable-systemd --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --localstatedir=/var --sysconfdir=/etc --disable-silent-rules --enable-gcc-warnings-advisory
> configure: WARNING: unrecognized options: --disable-maintainer-mode
> ...
> checking for pkg-config... no
> checking for SYSTEMD... no
> configure: Okay, checking for systemd a different way...
> checking for SYSTEMD... no
> configure: error: Explicitly requested systemd support, but systemd not found
This ought to be common knowledge and it should be documented therefor.
Background: I was overwriting /usr/bin/tor with a compiled version without systemd support and experienced an undocumented in /usr/share/doc/tor systemd feature that lead to a restart loop (legacy/trac#28410).https://gitlab.torproject.org/tpo/core/tor/-/issues/29134Document the max number of v3 client auths I can make2022-02-07T19:38:32ZpastlyDocument the max number of v3 client auths I can makeI'm testing out v3 onion service client auth. I couldn't find a documented maximum number of clients I can authorize for a single onion service, so I tried a really big number (400).
Full log here: https://paste.debian.net/1061430/ and ...I'm testing out v3 onion service client auth. I couldn't find a documented maximum number of clients I can authorize for a single onion service, so I tried a really big number (400).
Full log here: https://paste.debian.net/1061430/ and first bit here:
```
matt@spacecow:~/src/tor$ ./src/app/tor -f torrc-server
Jan 19 13:34:11.635 [notice] Tor 0.3.5.7 (git-9beb085c10562a25) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.1.0j, Zlib 1.2.8, Liblzma N/A, and Libzstd N/A.
Jan 19 13:34:11.635 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jan 19 13:34:11.635 [notice] Read configuration file "/home/matt/src/tor/torrc-server".
Jan 19 13:34:11.640 [warn] Path for DataDirectory (data-server) is relative and will resolve to /home/matt/src/tor/data-server. Is this what you wanted?
Jan 19 13:34:11.640 [warn] Path for PidFile (data-server/tor.pid) is relative and will resolve to /home/matt/src/tor/data-server/tor.pid. Is this what you wanted?
Jan 19 13:34:11.640 [warn] Path for HiddenServiceDir (data-server/onion_service) is relative and will resolve to /home/matt/src/tor/data-server/onion_service. Is this what you wanted?
Jan 19 13:34:11.641 [warn] Your log may contain sensitive information - you disabled SafeLogging. Don't log unless it serves an important reason. Overwrite the log afterwards.
Jan 19 13:34:11.666 [notice] Bootstrapped 0%: Starting
Jan 19 13:34:11.948 [notice] Starting with guard context "default"
Jan 19 13:34:12.666 [notice] Bootstrapped 10%: Finishing handshake with directory server
Jan 19 13:34:12.666 [notice] Bootstrapped 80%: Connecting to the Tor network
Jan 19 13:34:12.722 [notice] Bootstrapped 90%: Establishing a Tor circuit
Jan 19 13:34:13.048 [notice] Bootstrapped 100%: Done
Jan 19 13:34:14.676 [warn] We just made an HS descriptor that's too big (54736).Failing.
Jan 19 13:34:14.676 [warn] tor_bug_occurred_(): Bug: src/feature/hs/hs_service.c:2828: upload_descriptor_to_hsdir: Non-fatal assertion !(service_encode_descriptor(service, desc, &desc->signing_kp, &encoded_desc) < 0) failed. (on Tor 0.3.5.7 9beb085c10562a25)
Jan 19 13:34:14.677 [warn] Bug: Non-fatal assertion !(service_encode_descriptor(service, desc, &desc->signing_kp, &encoded_desc) < 0) failed in upload_descriptor_to_hsdir at src/feature/hs/hs_service.c:2828. Stack trace: (on Tor 0.3.5.7 9beb085c10562a25)
Jan 19 13:34:14.677 [warn] Bug: ./src/app/tor(log_backtrace_impl+0x47) [0x564e05c29297] (on Tor 0.3.5.7 9beb085c10562a25)
Jan 19 13:34:14.677 [warn] Bug: ./src/app/tor(tor_bug_occurred_+0xc0) [0x564e05c24930] (on Tor 0.3.5.7 9beb085c10562a25)
Jan 19 13:34:14.677 [warn] Bug: ./src/app/tor(hs_service_run_scheduled_events+0x1d6a) [0x564e05b4c5ca] (on Tor 0.3.5.7 9beb085c10562a25)
Jan 19 13:34:14.677 [warn] Bug: ./src/app/tor(+0x65e71) [0x564e05aa7e71] (on Tor 0.3.5.7 9beb085c10562a25)
Jan 19 13:34:14.677 [warn] Bug: ./src/app/tor(+0x697e1) [0x564e05aab7e1] (on Tor 0.3.5.7 9beb085c10562a25)
Jan 19 13:34:14.677 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x6a0) [0x7f19b89755a0] (on Tor 0.3.5.7 9beb085c10562a25)
Jan 19 13:34:14.677 [warn] Bug: ./src/app/tor(do_main_loop+0x9d) [0x564e05aab21d] (on Tor 0.3.5.7 9beb085c10562a25)
Jan 19 13:34:14.677 [warn] Bug: ./src/app/tor(tor_run_main+0x1215) [0x564e05a990a5] (on Tor 0.3.5.7 9beb085c10562a25)
Jan 19 13:34:14.677 [warn] Bug: ./src/app/tor(tor_main+0x3a) [0x564e05a962ca] (on Tor 0.3.5.7 9beb085c10562a25)
Jan 19 13:34:14.677 [warn] Bug: ./src/app/tor(main+0x19) [0x564e05a95e49] (on Tor 0.3.5.7 9beb085c10562a25)
Jan 19 13:34:14.677 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f19b7ac12e1] (on Tor 0.3.5.7 9beb085c10562a25)
Jan 19 13:34:14.677 [warn] Bug: ./src/app/tor(_start+0x2a) [0x564e05a95e9a] (on Tor 0.3.5.7 9beb085c10562a25)
```
I didn't expect to be allowed an unlimited number of client authorizations, but I do expect Tor to handle too many more gracefully.
```
matt@spacecow:~/src/tor$ cat torrc-server
DataDirectory data-server
Log notice file data-server/notice.log
Log notice stdout
PidFile data-server/tor.pid
SocksPort 0
SafeLogging 0
LogTimeGranularity 1
HiddenServiceDir data-server/onion_service
HiddenServicePort 80 11223
```
```
matt@spacecow:~/src/tor$ cat torrc-client
DataDirectory data-client
Log notice file data-client/notice.log
Log notice stdout
PidFile data-client/tor.pid
SocksPort auto
SafeLogging 0
LogTimeGranularity 1
ClientOnionAuthDir data-client/v3onionauth
```
I wrote a script to generate a ton of .auth and .auth_private files.
1. Start the server's tor with DisableNetwork set, wait for it to bootstrap, then stop it. Grab the hostname of the onion service
2. Use this script (https://paste.debian.net/1061432/) to generate a bunch of .auth and .auth_private files. For example:
```
matt@spacecow:~/src/python-snippits/src ./x25519-gen.py \
> ck7vkjy5dfk4dh564wnhqrdhmeh4qrnnkmo5tdwu4n7wickkhbzrb7yd \
> 400 \
> ~/src/tor/data-server/onion_service/authorized_clients/ \
> ~/src/tor/data-client/v3onionauth/
```
3. Then remove DisableNetwork and start the server. It produces the above buggy logshttps://gitlab.torproject.org/tpo/core/torspec/-/issues/24PT_LOG and PT_STATUS event fields unspecifed2022-02-21T19:12:25ZDamian JohnsonPT_LOG and PT_STATUS event fields unspecifedRecently Tor added PT_LOG and PT_STATUS events to the spec...
https://gitweb.torproject.org/torspec.git/commit/?id=3028cf1
https://gitweb.torproject.org/torspec.git/commit/?id=b38257e
Unfortunately the 'pt-spec.txt section 3.3.5' secti...Recently Tor added PT_LOG and PT_STATUS events to the spec...
https://gitweb.torproject.org/torspec.git/commit/?id=3028cf1
https://gitweb.torproject.org/torspec.git/commit/?id=b38257e
Unfortunately the 'pt-spec.txt section 3.3.5' section they mention does not exist, and in looking around I can't find anything that describes what these event fields are defined as ('PT=' 'TYPE=', 'CONNECT=', etc).
I started to write a stem parser for these but can't continue until this is done (I can't parse events without knowing what fields they include).
David is aware of this and plans to has kindly offered to add the missing info...
```
22:24 <+atagar> dgoulet: Your control-spec addition to descript PT_LOG and PT_STATUS
cite a pt-spec section 3.3.4 which does not exist.
22:24 <+atagar> s/descript/describe
22:29 <+atagar> dgoulet: Huh. I'm not spotting anything that lists the keyword
arguments ('PT=' and 'SEVERITY=') so guess the sections simply
missing from the spec. I need that for stem support so please
give me a nudge when the event spec's done. :)
22:59 <+dgoulet> atagar: oh hmmm I'll fix that sorry
23:17 <+atagar> Thanks! Much appreciated. :)
```https://gitlab.torproject.org/tpo/web/dev/-/issues/9Make more accessible Core Tor documentation2022-03-14T18:50:57ZjugaMake more accessible Core Tor documentationThere's Core Tor documentation distributed in three (at least) sources. Even if it's documentation intended for developers, it'd be great that it would be more accessible by providing the HTML version online and using some torproject.org...There's Core Tor documentation distributed in three (at least) sources. Even if it's documentation intended for developers, it'd be great that it would be more accessible by providing the HTML version online and using some torproject.org subdomain or path or links.
The sources are:
- The HTML that can be generated from little-t tor code (with doxygen): https://people.torproject.org/~nickm/tor-auto/doxygen/
- Nickm's torgut repository: https://gitweb.torproject.org/user/nickm/torguts.git/tree/. Files are in markdown, the can be converted to HTML.
- The documentation included in little-t tor code: https://gitweb.torproject.org/tor.git/tree/doc/HACKING (also markdown).
I can provide scripts to generate/convert the documentation automatically.
We would need to decide where to put it, maybe get subdomain and get access to the server where it would live.Developer portalhttps://gitlab.torproject.org/tpo/network-health/onbasca/-/issues/84Document number of threads configuration depending on the machine available b...2022-03-03T11:41:08ZjugaDocument number of threads configuration depending on the machine available bandwidthFor instance, how many threads can we have when the machine available bandwidth is 100Mbps or 1Gbps.
Based on what we talked in https://trac.torproject.org/projects/tor/wiki/org/meetings/2019BrusselsNetworkTeam/Notes/SBWSRoadmap#QuestionsFor instance, how many threads can we have when the machine available bandwidth is 100Mbps or 1Gbps.
Based on what we talked in https://trac.torproject.org/projects/tor/wiki/org/meetings/2019BrusselsNetworkTeam/Notes/SBWSRoadmap#Questionsonbasca: 1.1https://gitlab.torproject.org/tpo/core/tor/-/issues/29802Document the v3 onion service key files in the tor man page2022-09-01T21:29:27ZteorDocument the v3 onion service key files in the tor man pageThe tor man page is missing the names of the key files for v3 onion services.The tor man page is missing the names of the key files for v3 onion services.https://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/issues/30072andlabs.org, linked from tor browser design doc, seems gone2022-12-09T13:19:35ZRoger Dingledineandlabs.org, linked from tor browser design doc, seems gonehttps://2019.www.torproject.org/projects/torbrowser/design/
in Section 3 of "Specific Fingerprinting Defenses in the Tor Browser" links to
http://www.andlabs.org/tools/jsrecon.html
which seems to have become a parked domain.https://2019.www.torproject.org/projects/torbrowser/design/
in Section 3 of "Specific Fingerprinting Defenses in the Tor Browser" links to
http://www.andlabs.org/tools/jsrecon.html
which seems to have become a parked domain.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/41253Include compile instructions in our tor-android-service repo2022-11-29T13:38:38ZGeorg KoppenInclude compile instructions in our tor-android-service repoThe `README.md` file in `tor-android-service` says currently
```
# tor-android-service
Android Service For Intalling and Running Tor
```
. We should be a bit more verbose to help others using this new tool and getting it built outside of...The `README.md` file in `tor-android-service` says currently
```
# tor-android-service
Android Service For Intalling and Running Tor
```
. We should be a bit more verbose to help others using this new tool and getting it built outside of Tor Browser.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/30604Describe why Tor Browser requests each permission on Android2022-11-29T13:07:02ZMatthew FinkelDescribe why Tor Browser requests each permission on AndroidTor Browser requests a few "risky" permissions, we should describe how each of them is used. This is especially important information for people on older Android devices where permissions are not optional (they must allow all permissions...Tor Browser requests a few "risky" permissions, we should describe how each of them is used. This is especially important information for people on older Android devices where permissions are not optional (they must allow all permissions at installation time or they don't install the app).
I'll start with Google Play, but we should add this information on our website (and F-Droid, in the future), too.https://gitlab.torproject.org/tpo/core/chutney/-/issues/30720Use test-network.sh for the examples in Chutney's README2022-02-07T19:30:52ZteorUse test-network.sh for the examples in Chutney's READMEChutney's README is confusing, because we provide examples that assume you have already started a chutney network.
Instead, we should provide test-network.sh command lines.Chutney's README is confusing, because we provide examples that assume you have already started a chutney network.
Instead, we should provide test-network.sh command lines.https://gitlab.torproject.org/tpo/core/torspec/-/issues/130clarify socks-extensions.txt spec resolve command and response2022-07-18T17:54:03Zcypherpunksclarify socks-extensions.txt spec resolve command and responsehttps://gitweb.torproject.org/torspec.git/tree/socks-extensions.txt
The spec leaves multiple open questions:
- What does "initiates a remote lookup of the hostname" mean?
The spec could be improved by saying "A" or/and "AAAA" DNS looku...https://gitweb.torproject.org/torspec.git/tree/socks-extensions.txt
The spec leaves multiple open questions:
- What does "initiates a remote lookup of the hostname" mean?
The spec could be improved by saying "A" or/and "AAAA" DNS lookup is performed.
- There is no information about the response in torspec.git/tree/socks-extensions.txt at all
related:
legacy/trac#31115
https://lists.torproject.org/pipermail/tor-dev/2019-July/013931.htmlhttps://gitlab.torproject.org/tpo/core/torspec/-/issues/13List all valid DirPort urls2022-02-21T19:12:26ZDamian 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/web/support/-/issues/20Improve NoScript documentation2022-02-15T20:01:35ZAntonelaantonela@torproject.orgImprove NoScript documentation[https://blog.torproject.org/comment/277954#comment-277954 A user asks] for a better documentation for NoScript 10.
> On the introductory page you have a link "FAQ", and there you will find a link "NoScript FAQ", which will open the FAQ ...[https://blog.torproject.org/comment/277954#comment-277954 A user asks] for a better documentation for NoScript 10.
> On the introductory page you have a link "FAQ", and there you will find a link "NoScript FAQ", which will open the FAQ for the old noscript version(s). There is no official documentation for noscript. All you can get is a link to a blog writer giving "basic" information about the new noscript. This is very basic indeed and not an official documentation.
> Another link will redirect you to a page inteding to give an overview of the new noscript in a nutshell. A nutshell is not enough for understanding the new noscript - as you can see from the "226 Responses to “NoScript, "Quantum" vs "Legacy" in a nutshell”.
The [https://www.torproject.org/docs/faq current/old FAQ] does not link the NoScript FAQ, while the [https://support.torproject.org/#tbb support page] does.
[https://support.torproject.org/#tbb-25 I'm having a problem with NoScript.] links to the NoScript FAQ which i think is fine although it may not reflect [https://noscript.net/changelog latest changes]?
BTW {{{Should I install a new add-on or extension in Tor Browser, like AdBlock Plus or uBlock Origin?}}} is listed twice ([https://support.torproject.org/#faq-3 faq-3] and [https://support.torproject.org/#tbb-14 tbb-14])
https://trac.torproject.org/projects/tor/ticket/28418https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/31426Update BridgeDB's specification2022-03-01T17:35:40ZPhilipp Winterphw@torproject.orgUpdate BridgeDB's specificationWe have [a BridgeDB spec](https://gitweb.torproject.org/torspec.git/tree/bridgedb-spec.txt) but it's outdated and was last modified in 2013. We should update the specification so it reflects BridgeDB's current implementation. We should a...We have [a BridgeDB spec](https://gitweb.torproject.org/torspec.git/tree/bridgedb-spec.txt) but it's outdated and was last modified in 2013. We should update the specification so it reflects BridgeDB's current implementation. We should also cover Moat, our new BridgeDB metrics (legacy/trac#9316), and maybe our anti-bot mechanism (legacy/trac#31252).
We should get the spec to a point where it can provide newcomers with a comprehensive understanding of BridgeDB's overall design.