The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-08-18T12:53:14Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24308MaxMemInCellQueues minimum of 256MB is still too large for low-RAM relays (LE...2020-08-18T12:53:14ZTracMaxMemInCellQueues minimum of 256MB is still too large for low-RAM relays (LEDE and OpenWRT routers)The minimum value for torrc configuration MaxMemInCellQueues of 256MB is still too large for memory constrained relays. I've been running a tor relay on my OpenWRT router for a few years reliably. I recently upgraded the router to use to...The minimum value for torrc configuration MaxMemInCellQueues of 256MB is still too large for memory constrained relays. I've been running a tor relay on my OpenWRT router for a few years reliably. I recently upgraded the router to use tor 0.2.9.12 where MaxMemInCellQueues is minimally defaulted to 256MB, even if the router only has 128 MB. Naturally, Linux oom-killer kills it after a few hours. I have a lot of bandwidth but I can't share it now...
This is related to ticket legacy/trac#9686
```
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.070987] Mem-Info:
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.073403] active_anon:18341 inactive_anon:51 isolated_anon:0
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.073403] active_file:35 inactive_file:73 isolated_file:0
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.073403] unevictable:0 dirty:0 writeback:0 unstable:0
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.073403] slab_reclaimable:728 slab_unreclaimable:2804
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.073403] mapped:41 shmem:1120 pagetables:102 bounce:0
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.073403] free:4723 free_pcp:40 free_cma:0
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.106437] Normal free:18892kB min:16384kB low:20480kB high:24576kB active_anon:73364kB inactive_anon:204kB active_file:
140kB inactive_file:292kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:131072kB managed:125640kB mlocked:0kB dirty:0kB writeback:0kB mapped:164kB shmem
:4480kB slab_reclaimable:2912kB slab_unreclaimable:11216kB kernel_stack:544kB pagetables:408kB unstable:0kB bounce:0kB free_pcp:160kB local_pcp:160kB free_cma:0kB write
back_tmWed Nov 15 11:24:32 2017 kern.warn kernel: [221491.151989] lowmem_reserve[]: 0 0
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.155468] Normal: 763*4kB (UMEH) 446*8kB (UMEH) 255*16kB (UMEH) 44*32kB (UME) 20*64kB (UMEH) 3*128kB (UME) 2*256kB (UH)
1*512kB (U) 4*1024kB (UMH) 0*2048kB 0*4096kB = 18892kB
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.171705] 1228 total pagecache pages
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.175610] 0 pages in swap cache
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.179077] Swap cache stats: add 0, delete 0, find 0/0
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.184476] Free swap = 0kB
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.187482] Total swap = 0kB
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.190505] 32768 pages RAM
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.193422] 0 pages HighMem/MovableOnly
Wed Nov 15 11:24:32 2017 kern.warn kernel: [221491.197412] 1358 pages reserved
Wed Nov 15 11:24:32 2017 kern.info kernel: [221491.200683] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name
...
Wed Nov 15 11:24:32 2017 kern.info kernel: [221491.370877] [28850] 52 28850 21220 15276 25 0 0 0 tor
Wed Nov 15 11:24:32 2017 kern.info kernel: [221491.379539] [ 9935] 0 9935 296 9 3 0 0 0 sleep
Wed Nov 15 11:24:32 2017 kern.err kernel: [221491.388387] Out of memory: Kill process 28850 (tor) score 487 or sacrifice child
Wed Nov 15 11:24:32 2017 kern.err kernel: [221491.396016] Killed process 28850 (tor) total-vm:84880kB, anon-rss:61096kB, file-rss:8kB
```
**Trac**:
**Username**: pmetrasTor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22881Unreachable relays launch multiple testing circuits per second2021-09-16T14:31:59ZteorUnreachable relays launch multiple testing circuits per secondWhen I start a relay behind a NAT with:
```
tor ORPort 12345 PublishServerDescriptor 0 Log "info stderr"
```
I see it launch multiple testing circuits every second.
This places a lot of load on the network: it should use exponential bac...When I start a relay behind a NAT with:
```
tor ORPort 12345 PublishServerDescriptor 0 Log "info stderr"
```
I see it launch multiple testing circuits every second.
This places a lot of load on the network: it should use exponential backoff instead.
We wanted to fix things like this as part of legacy/trac#4580 or legacy/trac#8625, but it seems we missed this case. Maybe we need to do exponential backoff at a lower level than directory requests?
Here are the log messages for one second:
```
Jul 11 19:07:20.000 [info] circuit_finish_handshake: Finished building circuit hop:
Jul 11 19:07:20.000 [info] internal circ (length 3, last hop Unnamed): $3E13E2EB87CCF5690564EE33E9F9F9F80B229FBB(open) $34D2E3C853C6C60A5CCD93E363CD524BA962D3D6(open) $4345CA43B1F4E1C08271F8FA907B4AE890591111(closed)
Jul 11 19:07:20.000 [info] circuit_send_next_onion_skin: Sending extend relay cell.
Jul 11 19:07:20.000 [info] consider_testing_reachability: Testing reachability of my ORPort: 124.171.199.202:12345.
Jul 11 19:07:20.000 [info] onion_pick_cpath_exit: Using requested exit node '$4345CA43B1F4E1C08271F8FA907B4AE890591111~Unnamed at 124.171.199.202'
Jul 11 19:07:20.000 [info] extend_info_from_node: Not including the ed25519 ID for $7202A9449EC084A305EB19A2A2A0E245FA8C111E~jonasBebe2 at 193.200.241.195, since it won't be able to authenticate it.
Jul 11 19:07:20.000 [info] extend_info_from_node: Not including the ed25519 ID for $CA618B8FB8FDF1C670BA7139B1E3EFCE25771551~bentleywashere3 at 198.199.90.205, since it won't be able to authenticate it.
Jul 11 19:07:20.000 [info] circuit_handle_first_hop: Next router is [scrubbed]: Not connected. Connecting.
Jul 11 19:07:20.000 [info] connection_or_set_identity_digest: Set identity digest for 0x7fcefb6f1cd0 ([scrubbed]): 7202A9449EC084A305EB19A2A2A0E245FA8C111E <unset>.
Jul 11 19:07:20.000 [info] connection_or_set_identity_digest: (Previously: 0000000000000000000000000000000000000000 <unset>)
Jul 11 19:07:20.000 [info] channel_tls_process_versions_cell: Negotiated version 4 with [scrubbed]:443; Sending cells: CERTS
Jul 11 19:07:20.000 [info] connection_or_client_learned_peer_id: learned peer id for 0x7fcefaf87090 ([scrubbed]): 650ABAB06345EEC29BB0B5322C27DC6E5E888019, <null>
Jul 11 19:07:20.000 [info] channel_tls_process_certs_cell: Got some good certificates from [scrubbed]:443: Authenticated it with RSA
Jul 11 19:07:20.000 [info] channel_tls_process_auth_challenge_cell: Got an AUTH_CHALLENGE cell from [scrubbed]:443: Sending authentication type 1
Jul 11 19:07:20.000 [info] circuit_send_next_onion_skin: First hop: finished sending CREATE cell to '$650ABAB06345EEC29BB0B5322C27DC6E5E888019~supc0re at 217.160.15.198'
Jul 11 19:07:20.000 [info] channel_tls_process_netinfo_cell: Got good NETINFO cell from [scrubbed]:443; OR connection is now open, using protocol version 4. Its ID digest is 650ABAB06345EEC29BB0B5322C27DC6E5E888019. Our address is apparently 124.171.199.202.
Jul 11 19:07:20.000 [info] circuit_expire_building: Abandoning circ 198 37.187.3.106:443:3622949943 (state 0,0:doing handshakes, purpose 18, len 3)
Jul 11 19:07:20.000 [info] internal circ (length 3, last hop Unnamed): $597422ADDADAF5FB2727369B7EFC7AA76B89D613(open) $E7578F3484C8ABD5FB3130E31F30C167206BCA7E(open) $4345CA43B1F4E1C08271F8FA907B4AE890591111(waiting for keys)
Jul 11 19:07:20.000 [info] circuit_testing_failed: Our testing circuit (to see if your ORPort is reachable) has failed. I'll try again later.
Jul 11 19:07:20.000 [info] circuit_finish_handshake: Finished building circuit hop:
Jul 11 19:07:20.000 [info] internal circ (length 3, last hop Unnamed): $650ABAB06345EEC29BB0B5322C27DC6E5E888019(open) $45D6A70CAEC4A2C2FCE46A127E461FF852A41280(closed) $4345CA43B1F4E1C08271F8FA907B4AE890591111(closed)
Jul 11 19:07:20.000 [info] circuit_send_next_onion_skin: Sending extend relay cell.
```Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/22355Update dir-spec with client fallback directory mirror attempt and timeout beh...2020-07-31T14:03:51ZteorUpdate dir-spec with client fallback directory mirror attempt and timeout behaviourLet's add these lines:
Clients try several fallback directory mirrors, and use the first one that connects. Each attempt happens after a short delay, regardless of the state of the previous attempt, until at least one attempt has connec...Let's add these lines:
Clients try several fallback directory mirrors, and use the first one that connects. Each attempt happens after a short delay, regardless of the state of the previous attempt, until at least one attempt has connected.
When several fallback directory mirrors have failed, clients start trying directory authorities in a similar fashion.
Somewhere near:
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n3292
I don't think we designed any explicit timeout behaviour, so we are probably using whatever was there before 0.2.8.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/21044ORPort self reachability test happens also when it shouldn't2020-08-06T14:38:06Zs7rORPort self reachability test happens also when it shouldn'tI think we did not cover all cases when the self reachability test before publishing descriptors was introduced.
I am running a bridge with `PublishServerDescriptor 0` and `ORPort 127.0.0.1:443` because I want to run it just to do some...I think we did not cover all cases when the self reachability test before publishing descriptors was introduced.
I am running a bridge with `PublishServerDescriptor 0` and `ORPort 127.0.0.1:443` because I want to run it just to do some responsible testing without hammering the public Guards used by other clients. The bridge is configured with `PublishServerDescriptor 0` so it means I don't need a descriptor, I don't intend to make the bridge (or relay) public.
When a bridge is run in the conditions described above the log is spammed (exactly one log message at every 20 minutes) with:
```
[warn] Your server (PUBLIC_IP:443) has not managed to confirm that its ORPort is reachable. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.
```
and
```
[warn] The IPv4 ORPort address 127.0.0.1 does not match the descriptor address PUBLIC_IP. If you have a static public IPv4 address, use 'Address <IPv4>' and 'OutboundBindAddress <IPv4>'. If you are behind a NAT, use two ORPort lines: 'ORPort <PublicPort> NoListen' and 'ORPort <InternalPort> NoAdvertise'.
```
What it did wrong:
- It guessed the public IP address and tried to make the self test on that address, regardless it's not the address explicitly configured at `ORPort`. `Address` is not set in this setup.
- Based on the second log message, I think it even overwritten the address used with `ORPort` with the public IP address that it guessed and built the descriptor.
- It infinitely tries once every 20 minutes and logs a message that the descriptor cannot be published (and my intention based on the options configured is exactly not to publish one even if the tests were successful).
What Tor should do:
- Bypass the protocol to guess `Address` (the public IP address) when `ORPort` / `DirPort` is explicitly configured as a loopback address or NAT address. This will have a logic follow-up (which I think we already do, but want to make sure) like this:
- Bypass self tests when `ORPort` / `DirPort` address is explicitly configured as a loopback address or NAT address (simplest thing would be to treat these cases as like `AssumeReachable 1` is set). Such addresses cannot be tested from the public internet anyway.
- `PublishServerDescriptor 0` maybe should not even build a descriptor at all, or at least bypass the self tests in this case too, it does not make sense to try to test something we never want to publish. Or, only make 1 attempt to test and log a message stating success or failure.
legacy/trac#19919 is kind of related, it treats as it should the cases where `ORPort` is explicitly configured as a public address. In this ticket we cover an extension for cases where `ORPort` is a loopback or NAT address.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/20165When a relay advertises a new, unreachable address, OR reachability can succe...2023-05-12T18:28:13ZteorWhen a relay advertises a new, unreachable address, OR reachability can succeed via the old addressIf a relay has advertised a reachable address in the past, and continues listening on the old address, clients and relays will continue to contact Tor on that address for a few hours.
If the relay starts advertising a new, unreachable a...If a relay has advertised a reachable address in the past, and continues listening on the old address, clients and relays will continue to contact Tor on that address for a few hours.
If the relay starts advertising a new, unreachable address, ORPort reachability will appear to succeed for that new address, because Tor doesn't (and probably can't) check the address clients are connecting to is the one it actually advertised.
And Tor doesn't do ongoing reachability checks, so it publishes its descriptor based on the mistaken reachability, and assumes everthing is OK from then on.
Fortunately, the mandatory DirPort check catches this in 0.2.8 and later.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19431ratelimit message is incorrect.2020-08-25T12:02:43ZNick Mathewsonratelimit message is incorrect.In 5c596cdbc086698c52 I added an XXXX comment to rate_limit_log.
When we say "100 messages suppressed in the last 3600 seconds", we're not being accurate. Those messages were suppressed over a period of time at the start of which the l...In 5c596cdbc086698c52 I added an XXXX comment to rate_limit_log.
When we say "100 messages suppressed in the last 3600 seconds", we're not being accurate. Those messages were suppressed over a period of time at the start of which the last message of this type was logged, and ending some time before the present... but they could have occurred days ago, or all 1 second ago.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18106Rename fascist_firewall_* functions to reachable_address_*2021-09-16T14:34:11ZteorRename fascist_firewall_* functions to reachable_address_*In legacy/trac#17840 and legacy/trac#9067 / legacy/trac#9068, we unified ReachableAddresses and ClientUseIPv4/ClientUseIPv6/UseBridges. We'd previously unified FascistFirewall, FirewallPorts and ReachableAddresses.
This means that the f...In legacy/trac#17840 and legacy/trac#9067 / legacy/trac#9068, we unified ReachableAddresses and ClientUseIPv4/ClientUseIPv6/UseBridges. We'd previously unified FascistFirewall, FirewallPorts and ReachableAddresses.
This means that the functions called fascist_firewall_* should probably be renamed to be more descriptive.
I think reachable_address_* is one option, but let's follow typical naming standards and not repeat words in names:
* fascist_firewall_choose_address_dir_server ->
* reachable_address_choose_address_dir_server ->
* reachable_address_choose_dir_server
Let's also use this as an opportunity to disambiguate fascist_firewall_choose_address_impl & fascist_firewall_choose_address_base.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/9062Authorities should describe their bwauth version in their votes2020-08-05T20:44:52ZNick MathewsonAuthorities should describe their bwauth version in their votesRight now, there's not a great way to tell which authorities have upgraded their bwauths, which creates trouble as in the case of legacy/trac#8688 . If we have future bwauth software report its version, and we have future Tor authoritie...Right now, there's not a great way to tell which authorities have upgraded their bwauths, which creates trouble as in the case of legacy/trac#8688 . If we have future bwauth software report its version, and we have future Tor authorities check that version and report it in their networkstatus votes, then we'll not stumble into that situation again.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7193Tor's sybil protection doesn't consider IPv62021-08-23T15:19:19ZGeorge KadianakisTor's sybil protection doesn't consider IPv6Some bugs:
`get_possible_sybil_list()` doesn't consider IPv6 addresses at all.
~~`clear_status_flags_on_sybil()` doesn't clear `ipv6_addr` (and maybe more flags).~~ Obsoleted by consensus method 24, because it requires the Running flag...Some bugs:
`get_possible_sybil_list()` doesn't consider IPv6 addresses at all.
~~`clear_status_flags_on_sybil()` doesn't clear `ipv6_addr` (and maybe more flags).~~ Obsoleted by consensus method 24, because it requires the Running flag for a router to be in the consensus.
Also, maybe we could add a `log_notice` or `log_info` to mention if and which relays were found to be part of a Sybil attack.
~~Finally (and this is a minor bug), in `get_possible_sybil_list()` we assume that `max_with_same_addr < max_with_same_addr_on_authority`, which is true in the current tor network, but maybe it shouldn't be an inherent property of the source code.~~ Obsoleted by legacy/trac#20960: max_with_same_addr_on_authority has been removed.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/6198Make sure that we clear addresses before freeing connections2020-08-11T14:33:17ZNick MathewsonMake sure that we clear addresses before freeing connectionsWe should decide whether we want to clear addresses for anonymized connections before we free them. This is not necessarily as sensitive as key material, but it's pretty sensitive.
One argument for why we might not want to is that it'd...We should decide whether we want to clear addresses for anonymized connections before we free them. This is not necessarily as sensitive as key material, but it's pretty sensitive.
One argument for why we might not want to is that it'd be a slippery slope that would eventually lead to clearing *everything* before freeing it, and if that's the way we're heading we should just do that.Tor: 0.4.5.x-freezeNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/5304Obfsproxy should respect OutboundBindAddress in torrc2020-10-15T16:30:29ZTracObfsproxy should respect OutboundBindAddress in torrcRather it just binds to * (any IP).
Tested with latest git obfsproxy and Tor 0.2.3.12-alpha.
**Trac**:
**Username**: korobkovRather it just binds to * (any IP).
Tested with latest git obfsproxy and Tor 0.2.3.12-alpha.
**Trac**:
**Username**: korobkovTor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/2178We launch dummy descriptor fetches more often than needed2020-09-22T15:11:40ZNick MathewsonWe launch dummy descriptor fetches more often than neededRight now, we have code in update_router_descriptor_downloads() to launch a fetch for authority.z if we want to learn our IP from a directory fetch. We do this if:
* We're a server
* We don't have the Address option set
* At le...Right now, we have code in update_router_descriptor_downloads() to launch a fetch for authority.z if we want to learn our IP from a directory fetch. We do this if:
* We're a server
* We don't have the Address option set
* At least 20 minutes have passed since we last launched a router descriptor download
* At least 20 minutes have passed since we last launched a
Per discussion in bug legacy/trac#652, we could be even more quiet about launching these fetches. We could also require that
* At least 20 minutes have passed since we last launched *any* appropriate directory op.
* At least 20 minutes have passed since we got a new incoming connection on what we think our IP is.
* At least 20 minutes have passed since we got confirmation of our current IP in a NETINFO cell
We could also make the "20 minutes" value configurable by a networkstatus parameter.
This is a minor issue, since the current behavior is inelegant, but not actually hurting anything.Tor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/web/community/-/issues/181Generate spanish and portuguese zine.2021-03-25T15:07:32ZGabagaba@torproject.orgGenerate spanish and portuguese zine.We need the PDFs for the onion guide zine in Spanish and Portuguese.
- [x] Spanish translation https://gitlab.torproject.org/tpo/community/l10n/-/issues/40012
- [x] Portuguese translation https://gitlab.torproject.org/tpo/community/l10...We need the PDFs for the onion guide zine in Spanish and Portuguese.
- [x] Spanish translation https://gitlab.torproject.org/tpo/community/l10n/-/issues/40012
- [x] Portuguese translation https://gitlab.torproject.org/tpo/community/l10n/-/issues/40011Sponsor 84: Onion GuidesGusGushttps://gitlab.torproject.org/tpo/web/community/-/issues/178Get feedback about Onion Guides to partners2021-02-02T14:23:31ZGabagaba@torproject.orgGet feedback about Onion Guides to partnersShare onion guides and zine with 3 or 4 partners and collect feedback.Share onion guides and zine with 3 or 4 partners and collect feedback.Sponsor 84: Onion GuidesGusGushttps://gitlab.torproject.org/tpo/community/l10n/-/issues/40012Translate Onion Guides to Spanish2021-02-02T16:53:48ZGabagaba@torproject.orgTranslate Onion Guides to SpanishTranslate https://docs.google.com/document/d/1d5OphgW3eEEbUoQSZOoJUfoG93ky8vQW_RvA8BLP60Q/edit#heading=h.ku8tenn2c0jeTranslate https://docs.google.com/document/d/1d5OphgW3eEEbUoQSZOoJUfoG93ky8vQW_RvA8BLP60Q/edit#heading=h.ku8tenn2c0jeSponsor 84: Onion GuidesGusGus2020-12-15https://gitlab.torproject.org/tpo/community/l10n/-/issues/40011Translate Onion Guides to Portuguese2021-03-02T11:40:27ZGabagaba@torproject.orgTranslate Onion Guides to PortugueseTranslate https://docs.google.com/document/d/1d5OphgW3eEEbUoQSZOoJUfoG93ky8vQW_RvA8BLP60Q/edit#heading=h.ku8tenn2c0jeTranslate https://docs.google.com/document/d/1d5OphgW3eEEbUoQSZOoJUfoG93ky8vQW_RvA8BLP60Q/edit#heading=h.ku8tenn2c0jeSponsor 84: Onion GuidesGusGus2020-12-15https://gitlab.torproject.org/tpo/ux/research/-/issues/17DDP Partners Survey2021-02-02T14:22:23ZAntonelaantonela@torproject.orgDDP Partners SurveyLet's use NC Forms
DDP Survey - [SURVEY: Please send this survey to end beneficiaries and share results with DDP.]
1. Were you able to continue to function in tough and pressing environments after receiving DDP support? (Yes/no)
2. The ...Let's use NC Forms
DDP Survey - [SURVEY: Please send this survey to end beneficiaries and share results with DDP.]
1. Were you able to continue to function in tough and pressing environments after receiving DDP support? (Yes/no)
2. The DDP intervention effectively responded to the threats I/we face? ( 1 – strongly disagree, 5 – strongly agree)
3. The DDP intervention helped me/us to respond to critical internet users under threat? ( 1- strongly disagree, 5- strongly agree)
4. Since the DDP intervention, I/we feel safer in our work? ( 1- strongly disagree, 5- strongly agree )
5. After receiving DDP assistance I/we can more easily identify threats (1-strongly disagree, 5-strongly agree)
6. Overall, I/we feel satisfied with the activities undertaken with the DDP funding (1- strongly disagree, 5-strongly agree)Sponsor 84: Onion Guides2020-12-15https://gitlab.torproject.org/tpo/web/community/-/issues/166Create onion guide fanzine2021-03-25T15:07:32ZAntonelaantonela@torproject.orgCreate onion guide fanzineContent
https://gitlab.torproject.org/tpo/web/community/-/issues?label_name%5B%5D=Sponsor+84Content
https://gitlab.torproject.org/tpo/web/community/-/issues?label_name%5B%5D=Sponsor+84Sponsor 84: Onion GuidesGusGus2020-11-27https://gitlab.torproject.org/tpo/ux/design/-/issues/2Create layout for Onion Guides fanzines2020-11-23T19:25:06ZAntonelaantonela@torproject.orgCreate layout for Onion Guides fanzinesCreate a zine ready to localize in ES and PT with onion guides content.Create a zine ready to localize in ES and PT with onion guides content.Sponsor 84: Onion GuidesAntonelaantonela@torproject.orgAntonelaantonela@torproject.orghttps://gitlab.torproject.org/tpo/web/community/-/issues/157[Onion service] Instructions on how to install webserver + Tor2021-11-12T11:19:40ZGus[Onion service] Instructions on how to install webserver + TorCreate snippets showing how to add an onion services to Apache2 and Nginx configuration file.Create snippets showing how to add an onion services to Apache2 and Nginx configuration file.Sponsor 84: Onion GuidesGusGus