Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-12-11T15:56:14Zhttps://gitlab.torproject.org/legacy/trac/-/issues/25638Design mocks for torproject.org2020-12-11T15:56:14ZIsabela FernandesDesign mocks for torproject.orgThis ticket is to track design work related to torproject.org.This ticket is to track design work related to torproject.org.website redesignAntonelaantonela@torproject.orgAntonelaantonela@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/25637sitemap for torproject.org2020-12-11T15:56:14ZIsabela Fernandessitemap for torproject.orgCreate a sitemap for Antonela to finish her design and for stakeholders to understand which content goes where.
Please refer to mapped content at:
!https://docs.google.com/spreadsheets/d/1hoceLEYevlxbVu5z5g7mdCPoBuhv6e0xJ3bRPEYWv4A/ed...Create a sitemap for Antonela to finish her design and for stakeholders to understand which content goes where.
Please refer to mapped content at:
!https://docs.google.com/spreadsheets/d/1hoceLEYevlxbVu5z5g7mdCPoBuhv6e0xJ3bRPEYWv4A/edit#gid=0website redesignIsabela FernandesIsabela Fernandeshttps://gitlab.torproject.org/legacy/trac/-/issues/10591Create a sitemap for current torproject.org website2020-12-11T15:56:14ZAndrew LewmanCreate a sitemap for current torproject.org websiteDuring the Tor Dev Meeting in Berlin 2015, we decided on new information structure for torproject.org website:
https://trac.torproject.org/projects/tor/wiki/Website/MainSiteRedesign
We also had some suggestions on what to do with the co...During the Tor Dev Meeting in Berlin 2015, we decided on new information structure for torproject.org website:
https://trac.torproject.org/projects/tor/wiki/Website/MainSiteRedesign
We also had some suggestions on what to do with the content that we were removing from the homepage.
The goal of this task is to map all the current content on torproject.org so we can make sure we are not forgetting any page and we have a plan for everything we are moving out of it.WebsiteV3Isabela FernandesIsabela Fernandeshttps://gitlab.torproject.org/legacy/trac/-/issues/13703Adding doc/HARDENING2020-12-11T15:41:49ZTracAdding doc/HARDENINGThe two text files currently in the doc directory are doc/HACKING and doc/TUNING. The latter is the only one that deals with relay operation, and its subject is oddly specific: increasing the maximum number of file descriptors. If we're ...The two text files currently in the doc directory are doc/HACKING and doc/TUNING. The latter is the only one that deals with relay operation, and its subject is oddly specific: increasing the maximum number of file descriptors. If we're going to put critical documentation in the codebase, I think it would also be worthwhile to have a basic hardening guide. It could include suggestions like:
* allowing only public key non-root SSH login
* using a firewall
* keeping your system up-to-date
* not running any other programs (especially networked ones)
* considering hardened or security-focused OS choices
Nick suggested that most of the actual information be contained in referenced links, which I agree with. There's no good reason to duplicate effort when there are, for example, so many good SSH hardening guides.
Let me know what you think, or if you have any contributions. If this is generally considered a good idea, I can start writing a draft.
**Trac**:
**Username**: mmccTor: unspecifiedjarugajarugahttps://gitlab.torproject.org/legacy/trac/-/issues/27668Wikipedia wants more attention2020-12-11T15:41:49ZtraumschuleWikipedia wants more attentionThere's probably more to do, but these stubs are a starting point:
https://en.wikipedia.org/wiki/Category:Tor_(anonymity_network)_stubs
(was not sure if Webpages are a better place, if you don't like to have it, feel free to move :)There's probably more to do, but these stubs are a starting point:
https://en.wikipedia.org/wiki/Category:Tor_(anonymity_network)_stubs
(was not sure if Webpages are a better place, if you don't like to have it, feel free to move :)https://gitlab.torproject.org/legacy/trac/-/issues/16576Add a 'community projects' list (separate page?) to the website2020-12-11T15:41:49ZRoger DingledineAdd a 'community projects' list (separate page?) to the websiteWe have a growing list of community projects -- projects that use Tor but have their own community / entity / something as well.
I'm thinking Ricochet, SecureDrop, Globaleaks, Whonix, Onion Browser, ChatSecure, HTTPS Everywhere, Onionsh...We have a growing list of community projects -- projects that use Tor but have their own community / entity / something as well.
I'm thinking Ricochet, SecureDrop, Globaleaks, Whonix, Onion Browser, ChatSecure, HTTPS Everywhere, Onionshare, pond, tor-ramdisk, Cupcake, Ahmia.
In the future we might list OnionBalance, OnionTip, Roster.
Since there are quite a few, we might list some at the top as 'highlighted community projects', and then the rest down below that.WebsiteV3traumschuletraumschulehttps://gitlab.torproject.org/legacy/trac/-/issues/32101Generate and publish doxygen output automatically2020-12-11T15:36:49ZNick MathewsonGenerate and publish doxygen output automaticallyWe should have a cron job or a jenkins process or something that runs "doxygen" in our codebase and publishes it at some official location.We should have a cron job or a jenkins process or something that runs "doxygen" in our codebase and publishes it at some official location.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/31261cleanup services inventories in the wiki2020-12-11T15:36:11Zanarcatcleanup services inventories in the wikiwe have three places where we inventory services right now:
* [[org/operations/services]]
* [[org/operations/Infrastructure]] - done, merged with above
* [[org/operations/ProductsandAssignments]]
* [[org/operations]] (fixed, old list ju...we have three places where we inventory services right now:
* [[org/operations/services]]
* [[org/operations/Infrastructure]] - done, merged with above
* [[org/operations/ProductsandAssignments]]
* [[org/operations]] (fixed, old list just removed, but has links to the above)
* [[org/operations/Infrastructure/Hosts]]anarcatanarcathttps://gitlab.torproject.org/legacy/trac/-/issues/32645Update URL bar onion indicators2020-12-11T13:05:04ZAntonelaantonela@torproject.orgUpdate URL bar onion indicatorsSince FF70, the green locks at the URL bar are gone. The current Firefox approach to security indicators is detailed here[1]. Chrome is leading towards this intention, too[2].
As part of S27, I'm working on unifying (and simplifying) t...Since FF70, the green locks at the URL bar are gone. The current Firefox approach to security indicators is detailed here[1]. Chrome is leading towards this intention, too[2].
As part of S27, I'm working on unifying (and simplifying) the brand presence of onions in Tor Browser, either for referring to the network or to the onion services.
I'm opening this ticket to discuss the following:
- are we ok following the Firefox approach and removing green icons from the URL bar?
- are we ok unifying the visual anchor for onions and onion routing at the URL bar and also at the circuit display?
- are we ok removing EV label from the URL bar and leave it at the identity doorhanger?
[1]FF70 https://blog.mozilla.org/security/2019/10/15/improved-security-and-privacy-indicators-in-firefox-70/
[2]CH69 https://blog.chromium.org/2018/05/evolving-chromes-security-indicators.html
[*]TB8 https://trac.torproject.org/projects/tor/wiki/org/teams/UxTeam/Misc/OnionSecurityIndicatorrichardrichardhttps://gitlab.torproject.org/legacy/trac/-/issues/24275Testing Lecktor as a possible framework to be used for all portals related to...2020-12-11T12:18:56ZIsabela FernandesTesting Lecktor as a possible framework to be used for all portals related to website redesign project# Requirements
We are looking for a framework that:
* makes it easy for folks to update content
* makes it easy for having mirrored static content
* the internationalization of it works with Transifex
* its easy to haver our stylegui...# Requirements
We are looking for a framework that:
* makes it easy for folks to update content
* makes it easy for having mirrored static content
* the internationalization of it works with Transifex
* its easy to haver our styleguide bootstrap working with it (for building the site theme)
# How to test it
The live test can be accessed here: http://pipeline.torproject.net:9900/
Here is the git repository: https://oniongit.eu/infra/portal
Here is the framework home page: https://www.getlektor.com
Lektor can work as a console tool, like Jekyll. Also, if you have a mac though, you do not have to install anything from the console. You can use the mac desktop app.
https://github.com/lektor/lektor/releases/tag/3.0.1
What the app does is run the local lektor server that will allow you to edit the website as you would in a normal cms.
If you would like to give it a try, you have to clone the git repository for the project first and then open the lektor app and browse to the repository folder.
The idea is that once you make your changes you will be able to make a push and a merge request to the oniongit repository. I understand a small familiarity with git is required in this case.
Please leave any questions or feedback as a comment on this ticket, if you feel working with this framework and if you think it can make your life easier.website redesignHiroHirohttps://gitlab.torproject.org/legacy/trac/-/issues/32864Reproduce Arthur's exit failures and then contact or badexit the relays2020-11-16T20:44:00ZRoger DingledineReproduce Arthur's exit failures and then contact or badexit the relayshttps://arthuredelstein.net/exits/
lists a pile of exit relays, including some very fast exit relays, that are failing all of their dns queries. That is, they claim to be exits but Tor clients probably rarely use them, yet clients still ...https://arthuredelstein.net/exits/
lists a pile of exit relays, including some very fast exit relays, that are failing all of their dns queries. That is, they claim to be exits but Tor clients probably rarely use them, yet clients still *try* to use them, contributing to the long tail of low-probability high-impact misery of being a Tor client.
We should verify that we agree with his scripts, and also make sure we are comfortable running the checks on our own.
Then we should contact the affected relays, and either get them to fix their dns, or figure out what the bug is, or failing all of that, set the badexit flag for them to save clients the trouble of trying them and failing.
Then once we've done a round of that, we should come up with a process by which we repeat it regularly.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/legacy/trac/-/issues/33663Check checktest.py related errors shown by our network-health scanners2020-11-13T13:45:10ZGeorg KoppenCheck checktest.py related errors shown by our network-health scannersI often see something like
```
2020-03-17 21:03:56,973 modules.checktest [ERROR] Check thinks <https://metrics.torproject.org/rs.html#details/296B2178FD742AB35AB20C9ADF04D5DFD3D407EB> isn't Tor. Desc addr is 206.55.74.0 and check addr i...I often see something like
```
2020-03-17 21:03:56,973 modules.checktest [ERROR] Check thinks <https://metrics.torproject.org/rs.html#details/296B2178FD742AB35AB20C9ADF04D5DFD3D407EB> isn't Tor. Desc addr is 206.55.74.0 and check addr is 206.55.74.0.
```
. We should figure out a) what's up with that and b) whether we actually still need that test to be running.https://gitlab.torproject.org/legacy/trac/-/issues/33029dir-auth: Dir auths should resume sending 503's but never to relays or other ...2020-11-13T13:39:33ZDavid Gouletdgoulet@torproject.orgdir-auth: Dir auths should resume sending 503's but never to relays or other dir authsThis is a child ticket from #33018.
The idea here is that even if we hit the global write limit (bw), we should not return 503 code but rather answer another directory authority.
Dirauth _must_ be able to talk to each other at all time...This is a child ticket from #33018.
The idea here is that even if we hit the global write limit (bw), we should not return 503 code but rather answer another directory authority.
Dirauth _must_ be able to talk to each other at all time regardless of the bandwidth state.
Setting 043 milestone because this should be considered a bug and could even be considered for backport since dirauth are suffering from this at the moment.Tor: 0.4.2.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33018Dir auths using an unsustainable 400+ mbit/s, need to diagnose and fix2020-11-13T13:39:33ZRoger DingledineDir auths using an unsustainable 400+ mbit/s, need to diagnose and fixWe've been having problems establishing a consensus lately. We realized that maatuska was rate limiting to only 10MBytes/s, and asked Linus to bump it up, so he did.
Then today we realized that moria1 was unable to serve dirport answers...We've been having problems establishing a consensus lately. We realized that maatuska was rate limiting to only 10MBytes/s, and asked Linus to bump it up, so he did.
Then today we realized that moria1 was unable to serve dirport answers because it was maxed out at its BandwidthRate of 30MBytes. I raised that to 50MBytes and it stayed maxed out. I have put it back down to 30MBytes so my host doesn't get too upset.
This is not a sustainable situation. We need to figure out what is asking the dir auths for so many bytes, and get it to stop or slow down.
This is a ticket to collect info and to brainstorm ideas.Tor: 0.4.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/24497Improve documentation for tor relay operators2020-10-30T02:33:54ZArthur EdelsteinImprove documentation for tor relay operatorsThe documentation is somewhat confusing and incomplete.
irl has been collecting instructions here:
https://trac.torproject.org/projects/tor/wiki/OperatorsTipsThe documentation is somewhat confusing and incomplete.
irl has been collecting instructions here:
https://trac.torproject.org/projects/tor/wiki/OperatorsTipshttps://gitlab.torproject.org/legacy/trac/-/issues/26619Include in Tor Relay Guide doc instructions on how to deploy relay in OpenBSD2020-10-30T02:31:20ZGusInclude in Tor Relay Guide doc instructions on how to deploy relay in OpenBSDTor Relay Guide doesn't provide any information about how to setup relay in OpenBSD. Is there any reason for this?
Here's the step by step:
**OpenBSD**
1. Add these rules in pf file /etc/pf.conf
```
pass in log on egress proto tcp fr...Tor Relay Guide doesn't provide any information about how to setup relay in OpenBSD. Is there any reason for this?
Here's the step by step:
**OpenBSD**
1. Add these rules in pf file /etc/pf.conf
```
pass in log on egress proto tcp from any to any port { 9001 }
pass out log on egress proto tcp from any to any port { 9001 }
```
2. Enable the new rules
```
pfctl -f /etc/pf.conf
```
3. Configure the repository
```
echo https://ftp.openbsd.org/pub/OpenBSD >> /etc/installurl
```
4. Install the tor package
```
pkg_add tor
```
5. Put the configuration file /usr/local/etc/tor/torrc in place.
```
#change the nickname "myNiceRelay" to a name that you like
Nickname myNiceRelay
ORPort 9001
ExitRelay 0
SocksPort 0
# Change the email address bellow and be aware that it will be published
ContactInfo tor-operator@your-emailaddress-domain
Log notice syslog
```
6. Start the tor daemon and make sure it starts at boot:
```
rcctl enable tor
rcctl start tor
```
More information: https://torbsd.org/2017/02/27/running-openbsd-current-for-tor-relays.htmlhttps://gitlab.torproject.org/legacy/trac/-/issues/28410systemd restart loop when tor@default.service::Type=notify2020-10-30T02:28:54ZTracsystemd restart loop when tor@default.service::Type=notifyI'm experiencing a 300sec restart loop when Tor is run as a service. This is Debian stretch using systemd.
This is a system in which tor-0.3.4.8 was installed and running OK. Then I overrode the tor executable with a 0.3.5.4-alpha build...I'm experiencing a 300sec restart loop when Tor is run as a service. This is Debian stretch using systemd.
This is a system in which tor-0.3.4.8 was installed and running OK. Then I overrode the tor executable with a 0.3.5.4-alpha build (with configure `--prefix=`), and it started showing this problem.
I tried some workarounds found on the Net, such as changing the /var/run symlink from /run to ../run (which shouldn't need to be done), tweaking values of ReadWriteDirectories in `tor@default.service`, and changing TimeoutStartSec to 0. None of that worked.
What does work is setting Type=simple instead of notify, but then I came across ticket #11016 and really, notify should work. So if it doesn't, I wonder if this version of tor 0.3.5 alpha could have a fault? How can I look into that more closely to verify?
This is the log in syslog prior to restart:
```
systemd[1]: tor@default.service: Start operation timed out. Terminating.
systemd[1]: Failed to start Anonymizing overlay network for TCP.
systemd[1]: tor@default.service: Unit entered failed state.
systemd[1]: tor@default.service: Failed with result 'timeout'.
systemd[1]: tor@default.service: Service hold-off time over, scheduling restart.
systemd[1]: Stopped Anonymizing overlay network for TCP.
systemd[1]: Starting Anonymizing overlay network for TCP...
```
And here is my current `tor@default.service`:
```
[Unit]
Description=Anonymizing overlay network for TCP
After=network.target nss-lookup.target
PartOf=tor.service
ReloadPropagatedFrom=tor.service
[Service]
#Type=notify
Type=simple
NotifyAccess=all
PIDFile=/var/run/tor/tor.pid
PermissionsStartOnly=yes
ExecStartPre=/usr/bin/install -Z -m 02755 -o debian-tor -g debian-tor -d /var/run/tor
ExecStartPre=/usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 --verify-config
ExecStart=/usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0
ExecReload=/bin/kill -HUP ${MAINPID}
KillSignal=SIGINT
TimeoutStartSec=300
TimeoutStopSec=60
Restart=on-failure
LimitNOFILE=65536
# Hardening
AppArmorProfile=-system_tor
NoNewPrivileges=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectHome=yes
ProtectSystem=full
ReadOnlyDirectories=/
ReadWriteDirectories=-/proc
ReadWriteDirectories=-/var/lib/tor
ReadWriteDirectories=-/var/log/tor
ReadWriteDirectories=-/var/run
CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE CAP_DAC_READ_SEARCH
```
Advice?
**Trac**:
**Username**: jchevaliTor: 0.3.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/16164Building with systemd support should not depend on systemd itself.2020-10-30T02:28:53Zweasel (Peter Palfrader)Building with systemd support should not depend on systemd itself.Why do we care if systemd is installed? We shouldn't.
Trying to build 0.2.6.8 with --enable-systemd blows up with:
```
checking for SYSTEMD... yes
checking for SYSTEMD209... no
configure: error: Package requirements (systemd >= 209) we...Why do we care if systemd is installed? We shouldn't.
Trying to build 0.2.6.8 with --enable-systemd blows up with:
```
checking for SYSTEMD... yes
checking for SYSTEMD209... no
configure: error: Package requirements (systemd >= 209) were not met:
No package 'systemd' found
```
cf. https://buildd.debian.org/status/fetch.php?pkg=tor&arch=s390x&ver=0.2.6.8-1&stamp=1432377274
```
--- a/configure.ac
+++ b/configure.ac
@@ -131,7 +131,7 @@ if test x$have_systemd = xyes; then
AC_DEFINE(HAVE_SYSTEMD,1,[Have systemd])
TOR_SYSTEMD_CFLAGS="${SYSTEMD_CFLAGS}"
TOR_SYSTEMD_LIBS="${SYSTEMD_LIBS}"
- PKG_CHECK_MODULES(SYSTEMD209, [systemd >= 209],
+ PKG_CHECK_MODULES(LIBSYSTEMD209, [libsystemd >= 209],
[AC_DEFINE(HAVE_SYSTEMD_209,1,[Have systemd v209 or more])], [])
fi
AC_SUBST(TOR_SYSTEMD_CFLAGS)
```Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/31521Investigate 10-second delay in TTFB2020-10-20T20:20:00ZKarsten LoesingInvestigate 10-second delay in TTFBWhile looking into OnionPerf data I noticed a 10-second delay in time to first byte. I'll attach an ECDF shortly.
I started hunting down this issue and found that many of these cases (though not all of them) had their stream detached fr...While looking into OnionPerf data I noticed a 10-second delay in time to first byte. I'll attach an ECDF shortly.
I started hunting down this issue and found that many of these cases (though not all of them) had their stream detached from a circuit and re-attached to another circuit following a 10-second timeout of some sort. The following example shows relevant controller events:
```
2019-05-05 09:55:00 1557046500.54 650 STREAM 45043 NEW 0 137.50.19.2:80 SOURCE_ADDR=127.0.0.1:36454 PURPOSE=USER
2019-05-05 09:55:00 1557046500.54 650 STREAM 45043 SENTCONNECT 29430 137.50.19.2:80
2019-05-05 09:55:00 1557046500.69 650 STREAM_BW 45043 13 2 2019-05-05T08:55:00.682587
^^ <- 10 second delay here
2019-05-05 09:55:10 1557046510.69 650 STREAM 45043 DETACHED 29430 137.50.19.2:80 REASON=TIMEOUT
2019-05-05 09:55:10 1557046510.69 650 STREAM 45043 SENTCONNECT 29411 137.50.19.2:80
2019-05-05 09:55:11 1557046511.12 650 STREAM 45043 REMAP 29411 137.50.19.2:80 SOURCE=EXIT
2019-05-05 09:55:11 1557046511.12 650 STREAM 45043 SUCCEEDED 29411 137.50.19.2:80
2019-05-05 09:55:11 1557046511.68 650 STREAM_BW 45043 55 10 2019-05-05T08:55:11.682353
2019-05-05 09:55:12 1557046512.68 650 STREAM_BW 45043 0 637971 2019-05-05T08:55:12.681636
2019-05-05 09:55:13 1557046513.21 650 STREAM_BW 45043 0 410673 2019-05-05T08:55:13.211188
2019-05-05 09:55:13 1557046513.21 650 STREAM 45043 CLOSED 29411 137.50.19.2:80 REASON=DONE
```
1% of measurements seems a lot to me, and I could imagine that these cases are particularly annoying to users. Maybe this timeout could be shorter or made more dynamic like other timeouts.
If the timeout cannot be changed, it would be nice to tell the user that their stream has just been attached to another circuit and that that's why they had to wait for the past 10 seconds.https://gitlab.torproject.org/legacy/trac/-/issues/28306Please add signing keys to db.torproject.org2020-10-19T16:05:39ZtraumschulePlease add signing keys to db.torproject.orgNot entirely sure of this is in the scope of db.torproject.org:
For #22637 it would be useful to have all keys in the db which are listed on
https://www.torproject.org/docs/signing-keys.html.en
Then we could link to it instead of pgp.m...Not entirely sure of this is in the scope of db.torproject.org:
For #22637 it would be useful to have all keys in the db which are listed on
https://www.torproject.org/docs/signing-keys.html.en
Then we could link to it instead of pgp.mit.edu which sometimes gives errors.