The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2023-11-13T16:21:44Zhttps://gitlab.torproject.org/tpo/network-health/onbasca/-/issues/14Update all docs2023-11-13T16:21:44ZjugaUpdate all docsonbasca: 1.0jugajugahttps://gitlab.torproject.org/tpo/network-health/onbasca/-/issues/6Add docstrings2023-03-17T11:19:27ZjugaAdd docstringsonbasca: 1.0https://gitlab.torproject.org/tpo/network-health/team/-/issues/57Set up a template for and write instructions about how to "register" network ...2022-02-28T14:17:56ZGeorg KoppenSet up a template for and write instructions about how to "register" network experimentsExperiments on the Tor network are getting popular and we start collecting them on our status page as one way of informing users/operators about them. We should write a template for that and general instructions on what to do to get this...Experiments on the Tor network are getting popular and we start collecting them on our status page as one way of informing users/operators about them. We should write a template for that and general instructions on what to do to get this going smoothly.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/network-health/team/-/issues/54Clarify our policy on secrecy vs. transparency2024-03-05T15:25:44ZGeorg KoppenClarify our policy on secrecy vs. transparencyWe have a bunch of areas in bad-relay land where we opted for (partial) secrecy compared to our default transparency (e.g. when listing [the rejected fingerprints](https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Rejected-fi...We have a bunch of areas in bad-relay land where we opted for (partial) secrecy compared to our default transparency (e.g. when listing [the rejected fingerprints](https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Rejected-fingerprints-found-in-attacks) per month in our wiki or when developing scanners or parts of them in private repo).
We'd benefit from written down the general policy on secrecy vs. transparency that explains how we drew and draw the line in different network-health areas (such as those two above).https://gitlab.torproject.org/tpo/network-health/team/-/issues/53Rewrite non-malicious bad relay criteria to take non-exit nodes into account2023-06-14T16:57:20ZGeorg KoppenRewrite non-malicious bad relay criteria to take non-exit nodes into accountRight now we [focus](https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Criteria-for-rejecting-bad-relays#misconfigured-exit-relays) our non-malicious bad relay criteria on exit relays.
However,
```
Any other criteria that wo...Right now we [focus](https://gitlab.torproject.org/tpo/network-health/team/-/wikis/Criteria-for-rejecting-bad-relays#misconfigured-exit-relays) our non-malicious bad relay criteria on exit relays.
However,
```
Any other criteria that would give a safe but not fully functional experience for Tor users
```
clearly applies to non-exit nodes, too. Thus, we should rewrite the respective section taking both relay types into account.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/web/support/-/issues/207Answer the Tor + VPN question better2023-11-08T02:30:16ZemmapeelAnswer the Tor + VPN question betterAt https://support.torproject.org/faq/faq-5/ we have a link to https://trac.torproject.org/projects/tor/wiki/doc/TorPlusVPN which should be replaced as trac is not longer updated.At https://support.torproject.org/faq/faq-5/ we have a link to https://trac.torproject.org/projects/tor/wiki/doc/TorPlusVPN which should be replaced as trac is not longer updated.https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/8Create and document our commit workflow2023-04-11T18:29:51ZCecylia BocovichCreate and document our commit workflowAt the moment, each project has been maintained slightly differently, but with the branch changes we're taking the opportunity to document and consolidate our workflows on each of these projects. They don't all need to be handled the sam...At the moment, each project has been maintained slightly differently, but with the branch changes we're taking the opportunity to document and consolidate our workflows on each of these projects. They don't all need to be handled the same, but we should definitely document the different workflows and point out projects that have exceptions. This workflow should include the following:
- which repositories to push to and where our mirrors are pointing
- do we introduce merge commits or do we rebase branches before merging?
- do we use the gitlab interface or merge things locally?
- how many reviews do we need and who maintains/has access to which repository?
- we had some discussion over on #7 about signing commits
- which projects have releases and what is the release workflow?
This is generally a good idea, and something we should work into our workflow. Let's use this ticket to document a proposal for different workflows. Again, some repositories for our team are maintained by people outside TPI so the focus should be on documentation and best practices, not necessarily in making everything the same.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/7Set up gitolite <--> gitlab mirrors2022-03-01T17:19:09ZCecylia BocovichSet up gitolite <--> gitlab mirrorsSince our branch name change in #6, we'll have to update our mirrors and we might as well be consistent this time.
I'm proposing a one way mirror from Gitlab to git.tpo because it means we can use the gitlab merge feature. This would ma...Since our branch name change in #6, we'll have to update our mirrors and we might as well be consistent this time.
I'm proposing a one way mirror from Gitlab to git.tpo because it means we can use the gitlab merge feature. This would make git.tpo mostly read only except for the repositories that have not yet been migrated to gitlab.
However, I'm open to feedback. My only strong preference is that we're consistent.https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/40286Add Burmese as supported language in Windows installer2022-12-22T10:52:50ZMatthew FinkelAdd Burmese as supported language in Windows installerThis should be added in tbb-windows-installer, but I'm not sure a patch will be accepted right now.This should be added in tbb-windows-installer, but I'm not sure a patch will be accepted right now.https://gitlab.torproject.org/tpo/web/support/-/issues/181Add to FAQ section "Is it worth upgrading my Tor Relay"2023-11-13T05:22:53ZBurnleydevAdd to FAQ section "Is it worth upgrading my Tor Relay"Saw this question **"Is it worth upgrading my Tor Relay"** on reddit.com/r/Tor. It's worth adding it to the FAQ section to help others.Saw this question **"Is it worth upgrading my Tor Relay"** on reddit.com/r/Tor. It's worth adding it to the FAQ section to help others.https://gitlab.torproject.org/tpo/web/community/-/issues/193Past GSOC projects don't appear, but there is an empty section for them.2023-04-22T07:32:26ZemmapeelPast GSOC projects don't appear, but there is an empty section for them.at the bottom of https://community.torproject.org/gsoc/ there is a section only consisting of:
Past Projects
Here are some successful projects which have been implemented in the past by Google Summer of Code and Outreachy participants
...at the bottom of https://community.torproject.org/gsoc/ there is a section only consisting of:
Past Projects
Here are some successful projects which have been implemented in the past by Google Summer of Code and Outreachy participants
But the past projects are not there anymore.https://gitlab.torproject.org/tpo/web/community/-/issues/188[content][types of relays] Mentions to unexisting section are confusing2022-01-20T19:12:23Zemmapeel[content][types of relays] Mentions to unexisting section are confusingIn the page https://community.torproject.org/relay/types-of-relays/ , in the Exit relay section, we mention the 'legal considerations section' twice.
One is linked to https://community.torproject.org/relay/community-resources , but the ...In the page https://community.torproject.org/relay/types-of-relays/ , in the Exit relay section, we mention the 'legal considerations section' twice.
One is linked to https://community.torproject.org/relay/community-resources , but the other is unlinked, and there are no sections called 'legal considerations'.
> Exit relays have the greatest legal exposure and liability of all the relays. For example, if a user downloads copyrighted material while using your exit relay, you, the operator may receive a DMCA notice. Any abuse complaints about the exit will go directly to you (via your hoster, depending on the WHOIS records). Generally, most complaints can be handled pretty easily through template letters, which we'll discuss further in the **legal considerations section**.
> Because of the legal exposure that comes with running an exit relay, you should not run a Tor exit relay from your home. Ideal exit relay operators are affiliated with some institution, like a university, a library, a hackerspace or a privacy related organization. An institution can not only provide greater bandwidth for the exit, but is better positioned to handle abuse complaints or the rare law enforcement inquiry.
> If you are considering running an exit relay, please read the **section on legal considerations** for exit relay operators.
We should rephrase, mention the current name of the section, and also add a link where there is none.https://gitlab.torproject.org/tpo/core/tor/-/issues/40340Man tor - Option `ClientTransportPlugin` should move from `GENERAL OPTIONS` t...2023-04-03T16:38:12ZcypherpunksMan tor - Option `ClientTransportPlugin` should move from `GENERAL OPTIONS` to `CLIENT OPTIONS`For tor-0.4.6.0-alpha-dev.
ChangeLog :
```
o Documentation (man tor):
- Move option `ClientTransportPlugin` from `GENERAL OPTIONS` to `CLIENT OPTIONS`. Closes issue #40XXX
```
Output of `git diff HEAD` :
```
diff --git a/doc/...For tor-0.4.6.0-alpha-dev.
ChangeLog :
```
o Documentation (man tor):
- Move option `ClientTransportPlugin` from `GENERAL OPTIONS` to `CLIENT OPTIONS`. Closes issue #40XXX
```
Output of `git diff HEAD` :
```
diff --git a/doc/man/tor.1.txt b/doc/man/tor.1.txt
index f5dd1ec..308bf2d 100644
--- a/doc/man/tor.1.txt
+++ b/doc/man/tor.1.txt
@@ -334,20 +334,6 @@ forward slash (/) in the configuration file and on the command line.
as a float value. This is an advanced option; you generally shouldn't have
to mess with it. (Default: -1)
-[[ClientTransportPlugin]] **ClientTransportPlugin** __transport__ socks4|socks5 __IP__:__PORT__::
-**ClientTransportPlugin** __transport__ exec __path-to-binary__ [options]::
- In its first form, when set along with a corresponding Bridge line, the Tor
- client forwards its traffic to a SOCKS-speaking proxy on "IP:PORT".
- (IPv4 addresses should written as-is; IPv6 addresses should be wrapped in
- square brackets.) It's the
- duty of that proxy to properly forward the traffic to the bridge. +
- +
- In its second form, when set along with a corresponding Bridge line, the Tor
- client launches the pluggable transport proxy executable in
- __path-to-binary__ using __options__ as its command-line options, and
- forwards its traffic to it. It's the duty of that proxy to properly forward
- the traffic to the bridge. (Default: none)
-
[[ConnLimit]] **ConnLimit** __NUM__::
The minimum number of file descriptors that must be available to the Tor
process before it will start. Tor will ask the OS for as many file
@@ -1178,6 +1164,21 @@ The following options are useful only for clients (that is, if
controller request). If true, multicast DNS hostnames for machines on the
local network (of the form *.local) are also rejected. (Default: 1)
+[[ClientTransportPlugin1]] **ClientTransportPlugin** __transport__ socks4|socks5 __IP__:__PORT__ +
+
+[[ClientTransportPlugin2]] **ClientTransportPlugin** __transport__ exec __path-to-binary__ [options]::
+ In its first form, when set along with a corresponding Bridge line, the Tor
+ client forwards its traffic to a SOCKS-speaking proxy on "IP:PORT".
+ (IPv4 addresses should written as-is; IPv6 addresses should be wrapped in
+ square brackets.) It's the
+ duty of that proxy to properly forward the traffic to the bridge. +
+ +
+ In its second form, when set along with a corresponding Bridge line, the Tor
+ client launches the pluggable transport proxy executable in
+ __path-to-binary__ using __options__ as its command-line options, and
+ forwards its traffic to it. It's the duty of that proxy to properly forward
+ the traffic to the bridge. (Default: none)
+
[[ClientUseIPv4]] **ClientUseIPv4** **0**|**1**::
If this option is set to 0, Tor will avoid connecting to directory servers
and entry nodes over IPv4. Note that clients with an IPv4
```Tor: 0.4.8.x-freezeAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/community/relays/-/issues/16Review and incorporate Torservers.net abuse templates to the relay documentation2022-03-16T20:23:36ZGusReview and incorporate Torservers.net abuse templates to the relay documentationBrabo let us know that:
The torservers.net wiki which hosts https://www.torservers.net/wiki/abuse/templates which https://community.torproject.org/relay/community-resources/tor-abuse-templates/ links to will go defunct at some point in ...Brabo let us know that:
The torservers.net wiki which hosts https://www.torservers.net/wiki/abuse/templates which https://community.torproject.org/relay/community-resources/tor-abuse-templates/ links to will go defunct at some point in the future. It may be good to see which templates are useful to add to the tor project template set.https://gitlab.torproject.org/tpo/core/tor/-/issues/40328Man tor - Refactoring - Creation of a new `BANDWIDTH MANAGEMENT OPTIONS` section2023-04-03T16:43:38ZcypherpunksMan tor - Refactoring - Creation of a new `BANDWIDTH MANAGEMENT OPTIONS` sectionA total of 11 options (see the list below) should go in a new section named `BANDWIDTH MANAGEMENT OPTIONS`. This would reduce the amount of time spent scrolling around in the man tor page and make finding options more intuitive instead o...A total of 11 options (see the list below) should go in a new section named `BANDWIDTH MANAGEMENT OPTIONS`. This would reduce the amount of time spent scrolling around in the man tor page and make finding options more intuitive instead of having to remember the spreaded locations were bandwidth options are sometimes located.\\
We could also take this opportunity to change the location of the warning about how bandwidth-limiting options are managed. This warning is located at the end of the description of the option `BandwidthRate`. We could move the warning to the description of the newly created `BANDWIDTH MANAGEMENT OPTIONS` section, or at least, in the `THE CONFIGURATION FILE FORMAT` section.\\
Also, like it is said in description of the option `AccountingMax`:\
>>>
Note that (as also described in the Bandwidth section) Tor uses powers of two [...]
>>>
This "Bandwidth section" does not really exist, but now it will if this issue is approuved. The non-existing "Bandwidth section" seems to refer to the description of the option `BandwidthRate`.\\
I will make the neccessary changes in the man tor page and only show you the final result. You will just need to accept it or tell me what need more tweaking.\\
List of options that will need to move to the newly created one:\
>>>
GENERAL OPTIONS:\
- BandwidthBurst
- BandwidthRate
- CountPrivateBandwidth
- MaxAdvertisedBandwidth
- PerConnBWBurst
- PerConnBWRate
- RelayBandwidthBurst
- RelayBandwidthRate\
SERVER OPTIONS:\
- AccountingMax
- AccountingRule
- AccountingStart
>>>
The newly created section will look something like that:\
>>>
**BANDWIDTH MANAGEMENT OPTIONS**\
Description : The end of the description of the options `BandwidthRate` about size unit format.\\
- AccountingMax
- AccountingRule
- AccountingStart
- BandwidthBurst
- BandwidthRate
- CountPrivateBandwidth
- MaxAdvertisedBandwidth
- PerConnBWBurst
- PerConnBWRate
- RelayBandwidthBurst
- RelayBandwidthRate
>>>\
On an unrelated note to this issue:\
I try to use the functionalities of `GitLab Flavord Markdown` in my previous 2 issues, but that did not really goes has I expected, so sorry for the ugly formating of all my previous issues. I'm learning. I hope this issue look a bit better :)https://gitlab.torproject.org/tpo/core/tor/-/issues/40327Man tor - Refactoring - Creation of a `LOGS OPTIONS` section2023-04-03T16:42:53ZcypherpunksMan tor - Refactoring - Creation of a `LOGS OPTIONS` sectionA total of 13 options (see the list below) are all only related to logs. We should create a new section named `LOGS OPTIONS` and all put them there instead of leaving them in the `GENERAL OPTIONS` and `SERVER OPTIONS` sections.
This wou...A total of 13 options (see the list below) are all only related to logs. We should create a new section named `LOGS OPTIONS` and all put them there instead of leaving them in the `GENERAL OPTIONS` and `SERVER OPTIONS` sections.
This would reduce the amount of scrolling in the man tor page and make finding options more intuitive instead of having to remember the weird location that options descriptions are sometimes located. If this issue is approuved, I will make the necessary changes in the man tor page and only show you the final result. You will only need to accept it or tell me what need more tweaking.
Here is the list of affected options :
>>>
**GENERAL OPTIONS**
Log (x4)
LogMessageDomains
LogTimeGranularity
MaxUnparseableDescSizeToLog
ProtocolWarnings
SafeLogging
SyslogIdentityTag
TruncateLogFile
**SERVER OPTIONS**
HeartbeatPeriod
MainloopStats
>>>
The new `LOGS OPTIONS` section will look something like that :
>>>
**LOGS OPTIONS**
Description of LOGS OPTION : Do we really need it ? It is self-explanatory.
HeartbeatPeriod
Log (x4)
LogMessageDomains
LogTimeGranularity
MainloopStats
MaxUnparseableDescSizeToLog
ProtocolWarnings
SafeLogging
SyslogIdentityTag
TruncateLogFile
>>>https://gitlab.torproject.org/tpo/community/l10n/-/issues/40023Update documentation for developers2024-02-14T10:15:48ZemmapeelUpdate documentation for developersMaybe it was lost along with trac, maybe it was never there...
Lets update the https://gitlab.torproject.org/tpo/community/l10n/-/wikis/Localization-for-developers wikipage with resources for developers
- [x] promote the use of the [Tr...Maybe it was lost along with trac, maybe it was never there...
Lets update the https://gitlab.torproject.org/tpo/community/l10n/-/wikis/Localization-for-developers wikipage with resources for developers
- [x] promote the use of the [Transifex sandbox](https://www.transifex.com/otf/tor-project-sandbox/dashboard/)
- [ ] explain the situation of each of the languages, and how to see updates
- [ ] [restrict which languages are translation targets](https://gitlab.torproject.org/tpo/community/l10n/-/issues/40020)emmapeelemmapeelhttps://gitlab.torproject.org/tpo/network-health/bandwidth-authorities/-/issues/2Create bwauth and dirauths security guidelines?2023-11-13T16:24:04ZjugaCreate bwauth and dirauths security guidelines?Talking with @gaba about https://gitlab.torproject.org/tpo/network-health/sbws and bwauths operational and infrastructure security guidelines, we thought it might be interesting to have similar documentation to https://gitlab.torproject....Talking with @gaba about https://gitlab.torproject.org/tpo/network-health/sbws and bwauths operational and infrastructure security guidelines, we thought it might be interesting to have similar documentation to https://gitlab.torproject.org/legacy/trac/-/wikis/doc/OperationalSecurity, https://gitlab.torproject.org/legacy/trac/-/wikis/TorRelayGuide/Security or https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorRelaySecurity.jugajugahttps://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/anti-censorship/pluggable-transports/snowflake/-/issues/40031Improve instructions on how to to set up snowflake standalone proxy and add t...2022-12-04T16:44:53ZLhayamImprove instructions on how to to set up snowflake standalone proxy and add to Tor community portalSnowflake standalone proxy is such an effortless and easy way to contribute, it deserves more straight forward and more prominently placed documentation I think. Contrary to the web- and browser extension, it also covers volunteers which...Snowflake standalone proxy is such an effortless and easy way to contribute, it deserves more straight forward and more prominently placed documentation I think. Contrary to the web- and browser extension, it also covers volunteers which are running headless, or are just hesitant to run WebRTC in their browsers.
--- edit ---
Adding a checklist here so we can keep track of the work that should be done:
- [x] Update https://snowflake.torproject.org to point to community documentation
- [ ] The building from source instructions are not clear
- [ ] include instructions for go1.11
- [x] Update the README for `/proxy` in the git repository to include build instructions and point to community pages for running the proxy
- [ ] Some info for how to keep the proxy up to date (this actually should be discussed and completed for #32677)
- [ ] Some instructions on checking Snowflake logs
- [ ] How to check that it is working
- [ ] How to see how much bandwidth it is using
--- end edit ---
Couple of points/ideas:
The existing instructions on how to set up the GOPATH will leave many users with a more or less broken system, since the majority of distros don't use `bash_profile`, but `.profile`. After creating `.bash_profile`, `.profile` will [not be read any more](https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html#Bash-Startup-Files), and all what's configured after copy- and pasting the commands, is the GOPATH, which is ..bad.
On every semi updated installation, setting the GOPATH is not even necessary, beginning with the release of go-1.8 (2017) it will default to $HOME/go when no other path is specified. Since a lot of users will run go for the first time when setting up snowflake proxy, checking if $GOPATH exists and if it doesn't, exporting the GOPATH _temporarily_ for the shell might be a good idea still (?).
Use variables, like `mkdir -p "$GOPATH/src"`, to make the guide more universal.
How about offering a simple setup.sh (maybe that's another ticket though)?
Everybody who has some understanding of their system will know a way how to auto start snowflake at boot, there's no reason to alienate less technical inclined users with torproject's specific runit configuration.
Tell the user where to run the command to start the proxy. At least on go versions < 1.16 (Q1 2020, Debian stable is on 1.11 for reference), neither `$GOPATH/bin` nor `$GOPATH/src/snowflake/proxy/proxy` is in PATH by default, so just executing `nohup ./proxy &` will blatantly fail.
Tell the user how to save logs, since lack of feedback whether snowflake is doing as intended or not might discourage users.
Provide instructions on how to update. Personally I've a start-up script running which checks for updates every time snowflake is started, but even a manual approach will do.