The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-12-04T16:24:11Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40023Snowflake client's global session manager is tied to melted SnowflakeCollector2020-12-04T16:24:11ZCecylia BocovichSnowflake client's global session manager is tied to melted SnowflakeCollectorThere was a bug introduced by our solution to #21314. We moved the broker poll loop inside the SOCKS handler, which means that each SOCKS connection effectively has their own pool of snowflakes (i.e., their own `SnowflakeCollector`). How...There was a bug introduced by our solution to #21314. We moved the broker poll loop inside the SOCKS handler, which means that each SOCKS connection effectively has their own pool of snowflakes (i.e., their own `SnowflakeCollector`). However, the session manager was kept global (shared by all connections). The session manager defines the dialContext for `RedialPacketConn` and is tied to the `SnowflakeCollector` it was created with.
The problem with this showed up most clearly in #40018, where mobile applications using Snowflake as a library are stopping and restarting Snowflake, but will happen in any scenario where the first `SnowflakeCollector` is melted, but a new SOCKS connection is created.Snowflake in Tor Browser 10.5Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40018Snowflake uses network continuously on mobile devices2021-03-20T16:53:00ZCecylia BocovichSnowflake uses network continuously on mobile devicesGuardian project is working on getting Snowflake working on mobile devices and are having trouble getting Snowflake to stop using the network on command. They've put together [a patch](https://github.com/tladesignz/IPtProxy/blob/feature/...Guardian project is working on getting Snowflake working on mobile devices and are having trouble getting Snowflake to stop using the network on command. They've put together [a patch](https://github.com/tladesignz/IPtProxy/blob/feature/stop_snowflake/snowflake.patch) file to expose the functions they want. Even after calling stop here, Snowflake continues to poll the broker for proxies indefinitely. See attached log file: [snowflake-go-ios-closing.txt](/uploads/1895eb6575581884d6c61972e45a532d/snowflake-go-ios-closing.txt)Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/community/support/-/issues/40062[China] Monitoring dynamic obfs4 bridges2023-01-31T22:01:53Zirl[China] Monitoring dynamic obfs4 bridgesInspired by #40054, let's use a ticket to track when we are seeing that these bridges are blocked.
We have two codenames for these bridges, Cobalt and Zinc. The current bridges can be found with these queries:
* https://metrics.torproj...Inspired by #40054, let's use a ticket to track when we are seeing that these bridges are blocked.
We have two codenames for these bridges, Cobalt and Zinc. The current bridges can be found with these queries:
* https://metrics.torproject.org/rs.html#search/Sr2Zinc%20type:bridge%20running:true
* https://metrics.torproject.org/rs.html#search/Sr2Cobalt%20type:bridge%20running:true
(Obviously these search by nickname, so it is entirely possible for someone to start spoofing bridges here.)
These bridges are distributed by moat and so when they are blocked, we will simply turn them off and deploy new bridges that will automatically be distributed by moat. All we need to coordinate here is the reachability checks. It would be good if we can do these at least weekly.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetshelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40054uTLS for broker negotiation2022-10-18T16:23:33Zmax-buTLS for broker negotiationThe connection from the snowflake client to the broker server currently uses go's `net/http.DefaultTransport`. That connection is optionally domain fronted, but the TLS handshake is easily fingerprintable as a go handshake, which might t...The connection from the snowflake client to the broker server currently uses go's `net/http.DefaultTransport`. That connection is optionally domain fronted, but the TLS handshake is easily fingerprintable as a go handshake, which might trigger additional scrutiny in regimes where that kind of TLS inspection is possible and actionable.
[This paper](https://sfrolov.io/papers/ndss19-frolov.pdf), though a bit out of date now (2019) references meek and even snowflake:
> Snowflake is under active development, and its authors were aware of potential TLS fingerprintability issues. Indeed,we find that Snowflake (built from git master branch on April17, 2018) generates a fingerprint that is close to, but not exactly the same as the default Golang TLS fingerprint. In particular,it diverges by including the NPN and ALPN extensions, and offers a different set of signature algorithms. As a result, this fingerprint is seen in fewer than 0.0008% of connections, making it susceptible to blocking.
The author of that paper, Sergey Frolov, maintains https://tlsfingerprint.io/ which is a list of the most popularly seen TLS fingerprints, and created https://github.com/refraction-networking/utls which is a library designed for creating TLS connections with various commonly witnessed TLS fingerprints.
There's a fork of that library, https://gitlab.com/yawning/utls which seems to be used in obfs4's `meeklite` implementation, and it looks like @dcf implemented a version of that in https://gitweb.torproject.org/pluggable-transports/meek.git/tree/meek-client/utls.go which actually implements a `RoundTripper`. It seems as though actually using that library could be a relatively painless way to adopt utls for the broker negotiation.
@cohosh @meskio and I discussed a little bit whether there would be a good way to identify whether snowflake is actually being identified and/or blocked due to TLS fingerprinting in the broker connection. I suggested that it seemed possible that higher connection error rates in China vs other countries as well as other protocols (such as meek) performing better than snowflake in China _could_ be indicative of TLS fingerprinting blocking, though that's not particularly solid.
I'm sure @dcf would have much more context and information on this area and the relative usefulness of utls on the broker negotiation, but I thought I should throw this out there/open this issue in case it can be of some help.
Related:
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40014 (DTLS)shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/issues/33736Update obfs4proxy package in debian2022-05-26T09:46:49ZCecylia BocovichUpdate obfs4proxy package in debianRight now the obfs4proxy package is about a year out of date. This is known and the Debian ticket for it is here: [948312](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948312).
Since more recent versions use utls, this requires som...Right now the obfs4proxy package is about a year out of date. This is known and the Debian ticket for it is here: [948312](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948312).
Since more recent versions use utls, this requires some new packages to be added. I've filed the following itp for yawning's fork of utls: [954209](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954209). From what I can tell, we'll need at least two more packages as well.
I've been chipping away at this, slowly, but if someone else wants to pick it up that's great.Ana CusturaAna Custurahttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/32900Reimplement and generalise BridgeDB?2020-09-02T18:05:21ZPhilipp Winterphw@torproject.orgReimplement and generalise BridgeDB?Over at legacy/trac#30946, I spent several hours trying to port BridgeDB to Python 3 but progress has been frustratingly slow. Given the port and our in-progress grant application proposing a social bridge distributor, I started thinking...Over at legacy/trac#30946, I spent several hours trying to port BridgeDB to Python 3 but progress has been frustratingly slow. Given the port and our in-progress grant application proposing a social bridge distributor, I started thinking about a rewrite of BridgeDB. Here's how I see the (dis)advantages breaking down:
Disadvantages:
* Re-implementations are never as smooth and straightforward as anticipated. It will take a lot of time.
* We won't (easily) be able to use Stem to parse bridge descriptors. We could extend [zoossh](https://gitweb.torproject.org/user/phw/zoossh.git/) though.
Advantages:
* We could re-implement the service in golang because the anti-censorship team is comfortable in the language.
* We could generalise the concept of BridgeDB: What goes in should be an abstract type of proxy (be it bridge descriptors, snowflake-style proxy registrations, or maybe even Lantern proxies) and distributors (as we already have them in BridgeDB) determine who gets these proxies.
* We would design the service with redundancy and "containerisation" in mind.
* It would make it easier to add new features, especially significant ones, like a new distributor.
* A re-implementation may be a return on investment and save us time in the long run.
Note that we don't need to abandon BridgeDB and then redirect our focus to its re-implementation. I would instead like to spend some hours experimenting with a new design in parallel to maintaining BridgeDB. We also don't need to aim for a feature-complete replacement of BridgeDB. For example, we don't need to PGP-sign emails. If all of the above proves fruitful, we can gradually transition to the new design.
Thoughts? Any other features or architectural changes we should make in a re-implementation?Sponsor 30 - Objective 2.3Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40011Task 4.1 Identify the input components that feed into a bridge distribution f...2023-10-03T18:54:14ZGabagaba@torproject.orgTask 4.1 Identify the input components that feed into a bridge distribution framework.- [ ] Track reachability of bridges in various regions.
- [ ] Understand ways that censors can enumerate or block bridges, and how to recognize or detect if each is
happening.
- [ ] Track load on bridges to know which distribution strate...- [ ] Track reachability of bridges in various regions.
- [ ] Understand ways that censors can enumerate or block bridges, and how to recognize or detect if each is
happening.
- [ ] Track load on bridges to know which distribution strategies are working.
- [ ] Approaches to maintain enough fresh proxies that we can rotate to new ones when they are needed.
- [ ] Identity mechanisms for tying client activities together if needed, including what client-side state is needed for each.Roger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40030Increase number of proxies available for restricted clients2023-01-06T12:58:15ZCecylia BocovichIncrease number of proxies available for restricted clientsIt looks like our solution to #33666 has solved the connectivity issues for clients behind restricted NATs, but we still have a relatively small number of unrestricted proxies available for restricted clients.
See the counts of proxy by...It looks like our solution to #33666 has solved the connectivity issues for clients behind restricted NATs, but we still have a relatively small number of unrestricted proxies available for restricted clients.
See the counts of proxy by type:
![proxy_types](/uploads/0edc55334e2fdeef8e295a18e7850377/proxy_types.png)
And a close-up on the counts of unrestricted proxies:
![unrestricted_proxies](/uploads/1be8466c9dd85144196606fc2c22b47a/unrestricted_proxies.png)
So, we're making progress! But, I'm still seeing a lot of restricted clients getting turned away at the broker because there were no available proxies. Here's a plot of the times a restricted client failed to be matched with a snowflake:
![unmatches](/uploads/cefc6c1067d3d78a62064ab59da4ea41/unmatches.png)
For reference, November (when we start seeing the spikes) was around the time we rolled out our remote probe test and started correctly classifying browser-based proxies. This both increased the amount of unrestricted proxies we had, but also decreased the number of unknown proxies we had. The end result for restricted clients (since they are handed either unknown or unrestricted proxies), is that while each proxy they get is more likely to work for them, the pool of proxies they can pull from is greatly reduced.
The spikes themselves are interesting. Some days we don't get any denied counts and some days we get way more than I'd expect. We almost surely need more unrestricted proxies, but it would also be useful to get some more metrics on what proportion of successful matches are for unrestricted vs restricted clients, and how many times a restricted client has to poll to get a working proxy.
So this ticket is both for measurements, but I also think we should try to run some reliable proxy-go instances that have unrestricted NATs.Snowflake in Tor Browser 10.5Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/34260Make BridgeDB take into account its BlockedBridges table2022-07-24T17:07:58ZPhilipp Winterphw@torproject.orgMake BridgeDB take into account its BlockedBridges tableBridgeDB has a table called BlockedBridges in its SQLite database. The table is empty and currently unused but we are extending it over at legacy/trac#34154.
BridgeDB already has code to deal with bridge blocking (e.g., [here](https://g...BridgeDB has a table called BlockedBridges in its SQLite database. The table is empty and currently unused but we are extending it over at legacy/trac#34154.
BridgeDB already has code to deal with bridge blocking (e.g., [here](https://gitweb.torproject.org/bridgedb.git/tree/bridgedb/bridges.py?id=2ccf7ef9dee07c0d645a5dfed5b099678c243fc5#n936)) but we still have to make it process BlockedBridges and take it into account when handing out bridges.Sponsor 30 - Objective 2.3Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40001BridgeDB pretends to reload descriptors but actually doesn't2020-07-07T15:58:28ZPhilipp Winterphw@torproject.orgBridgeDB pretends to reload descriptors but actually doesn'tBridgeDB is supposed to reload its bridges descriptors every 30 minutes. The following cron job takes care of that (you can see it by running `crontab -l` as the bridgedb user on polyanthum):
```
*/30 * * * * bin/reload-bridgedb >/dev/n...BridgeDB is supposed to reload its bridges descriptors every 30 minutes. The following cron job takes care of that (you can see it by running `crontab -l` as the bridgedb user on polyanthum):
```
*/30 * * * * bin/reload-bridgedb >/dev/null 2>&1
```
Among other things, the script `reload-bridgedb` does the following:
```
[...]
bridgedb -c ${BRIDGEDB_CONFIG} --reload
[...]
```
BridgeDB implements the `--reload` command line switch but the switch doesn't actually reload anything. In fact, it does nothing at all. So when the cron job runs bridgedb with the `--reload` switch every 30 minutes, it starts a separate (!) process that (re)loads the bridge descriptors and then exits because it cannot bind to the ports that the original BridgeDB is already bound to. Unfortunately, the new BridgeDB process writes to our log file, and makes it look like the original process is reloading bridge descriptors while it actually is our volatile, new process. In other words: the way it's set up now, BridgeDB never actually reloads bridges.
Fortunately, the fix is relatively simple: we just have to send the process a SIGHUP. BridgeDB has a SIGHUP handler that – unlike the `--reload` switch – actually works. We should also remove the `--reload` switch.Philipp Winterphw@torproject.orgPhilipp Winterphw@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/32276Help BridgeDB see client IP addresses of moat requests2021-08-16T20:11:10ZPhilipp Winterphw@torproject.orgHelp BridgeDB see client IP addresses of moat requestsBridgeDB sees the following HTTP headers for incoming moat requests:
```
Content-Length: ['504']
Via: ['1.1 bridges.torproject.org']
X-Forwarded...BridgeDB sees the following HTTP headers for incoming moat requests:
```
Content-Length: ['504']
Via: ['1.1 bridges.torproject.org']
X-Forwarded-Host: ['bridges.torproject.org']
X-Forwarded-For: ['127.0.0.1']
Connection: ['Keep-Alive']
Host: ['127.0.0.1:3881']
X-Forwarded-Server: ['bridges.torproject.org']
Content-Type: ['application/vnd.api+json']
```
As part of our BridgeDB metrics (legacy/trac#9316) it would be useful to see the IP address of incoming requests.
Here's an IRC conversation in which dcf explains the big picture and proposes a way to fix this issue:
```
dcf1│ phw: there are 2 layers of HTTP in Moat -- one is the CDN-traversal (meek) layer, and one is the end-to-end tunnelled HTTP to the web
server itself.
dcf1│ The CDN will set XFF on the outer meek layer, but not on the inner layer which is what BridgeDB sees (and it couldn't touch the inner
layer because it's HTTPS, which is the whole reason for the complicated proxypass setup).
dcf1│ phw: in other words, XFF is being set on the connection to port 2000, but then that layer is stripped off (only meek-server sees it)
and the tunneled contents go to port 3881.
dcf1│ Even though BridgeDB is an HTTP service, we go to the trouble of tunnelling a whole independent HTTP+TLS stream *inside* the
domain-fronted layer, just to prevent the CDN from tampering with end-to-end traffic.
dcf1│ That's why there are 2 proxypass: the first terminates the meek CDN layer, and the second terminates the tunnelled actual BridgeDB
exchange.
dcf1│ One way to solve this would be yet another shim that understands ExtORPort, parses out the USERADDR, and inserts it into XFF into an
HTTP header. As if the pipeline weren't long enough...
phw│ dcf1: gotcha. i'll create a ticket for this. do you mind if i quote your above explanation?
dcf1│ go for it
phw│ is meek-server exposed to USERADDR? i don't think i follow
dcf1│ meek-server can provide USERADDR to whatever port it forwards to. Currently I'm sure it's set up not to do that, to just forward the
contents without any prefix.
dcf1│ meek-server looks at Meek-IP, X-Forwarded-For, or request source IP address, and uses those to construct a USERADDR, which normally it
would provide to tor on tor's ExtORPort.
dcf1│ The purpose of ExtORPort, as opposed to ordinary ORPort, is to allow passing extra metadata like that, before the actual stream data.
dcf1│ So currently meek-server in Moat is set up to treat the local HTTPS server as its ORPort (not ExtORPort, because Apache wouldn't
understand that).
phw│ dcf1: ah, i understand. thanks for elaborating
dcf1│ Just thought of a research idea: see if any bridges are wrongly exposing their ExtORPort, which would conceivably permit manipulating
statistics.
phw│ we should call this new shim rube-goldberg-machine ;)
dcf1│ Take a subset of bridges, then port-scan them to see if any other port understands ExtORPort-prefixed Tor connections.
dcf1│ Moat is a concrete case where pluggable transports fall short of what you might want them to do. We're trying to "plug" meek-server
into another pipeline, but it's difficult because it's talking to something other than Tor. It's possible, but it quickly turns into a
big pile of shims and adapters.
```Sponsor 30 - Objective 2.1Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/41Is torproject-pusher deleting merge-request branches?2021-04-15T18:24:58ZNick MathewsonIs torproject-pusher deleting merge-request branches?Hi! I've been pulling my hair trying to figure out what happened to the merge-request branches that gitlab is supposed to be adding to the tor repo whenever a merge-request is opened.
See https://docs.gitlab.com/ee/user/project/merge_r...Hi! I've been pulling my hair trying to figure out what happened to the merge-request branches that gitlab is supposed to be adding to the tor repo whenever a merge-request is opened.
See https://docs.gitlab.com/ee/user/project/merge_requests/reviewing_and_managing_merge_requests.html#checkout-locally-by-modifying-gitconfig-for-a-given-repository for the information that made me expect these branches.
I had them working for a few minutes -- but then they seem to have disappeared.
My best guess of what happened is that torproject-pusher is deleting all branches that aren't present on our gitolite git instances ... and that's deleting our merge-request branches on gitlab.
@ahf, Is that possible?HiroHirohttps://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/45rotate gitlab backups using normal procedure2020-07-01T14:35:40Zanarcatrotate gitlab backups using normal procedureI just found out there's actually already a routing in GitLab itself to rotate backups, in:
<https://docs.gitlab.com/ee/raketasks/backup_restore.html#limit-backup-lifetime-for-local-files-prune-old-backups>
It seems that this settings ...I just found out there's actually already a routing in GitLab itself to rotate backups, in:
<https://docs.gitlab.com/ee/raketasks/backup_restore.html#limit-backup-lifetime-for-local-files-prune-old-backups>
It seems that this settings purges backups older than 7 days, for example:
```
## Limit backup lifetime to 7 days - 604800 seconds
gitlab_rails['backup_keep_time'] = 604800
```
Now it wouldn't flush away our secrets backups, but i figured those we should backup and manage some other ways anyways (ie. with bacula).
I just dealt with an outage tonight because the disk was full again so i figured I would look into backups. ;)HiroHirohttps://gitlab.torproject.org/tpo/tpa/team/-/issues/40887gnt-fsn cluster down again2022-09-20T18:37:17Zanarcatgnt-fsn cluster down againsimilar to https://gitlab.torproject.org/tpo/tpa/team/-/issues/40816, everything is down but the instances and fsn-node-08, bizarrely.
* [x] fsn-node-01
* [x] fsn-node-02
* [x] fsn-node-03
* [x] fsn-node-04
* [x] fsn-node-05
* [x] fsn-n...similar to https://gitlab.torproject.org/tpo/tpa/team/-/issues/40816, everything is down but the instances and fsn-node-08, bizarrely.
* [x] fsn-node-01
* [x] fsn-node-02
* [x] fsn-node-03
* [x] fsn-node-04
* [x] fsn-node-05
* [x] fsn-node-06
* [x] fsn-node-07
* [x] fsn-node-08 (did not crash!)anarcatanarcathttps://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/4Change labels to TPO ones2022-05-24T14:44:10ZGaba (admin)Change labels to TPO ones**TPO labels**: https://gitlab.torproject.org/groups/tpo/-/labels
Sprint labels:
* Icebox
* Backlog
* Next
* Doing
* Needs Review
* Merge Ready
* Needs Information
* Needs Design
* Needs User Research
* Blocked
Type of ticket labels:
...**TPO labels**: https://gitlab.torproject.org/groups/tpo/-/labels
Sprint labels:
* Icebox
* Backlog
* Next
* Doing
* Needs Review
* Merge Ready
* Needs Information
* Needs Design
* Needs User Research
* Blocked
Type of ticket labels:
* Bug
* Feature
* Project
* Task
Sponsor labels:
* Sponsor 2 .. 69
Across projects labels:
* UX
* Metrics
* Scalability
* Browser
* Core
**WHICH LABELS TO CHANGE ACROSS ALL TPO**
* type::defect -> Bug
* type::task -> Task
* type::enhancement -> Feature
* type::project -> Project
* status::needs-review -> Needs Review
* status::merge-ready -> Merge Ready
* status::needs-information -> Needs Information
sponsor::X-must/can/should ->> Sponsor X
(do not remove other sponsor::X labels please)
* ux-team --> UX
* tbb-usability --> UX
* metrics-team -> Metrics
Note: after changing labels we should remove the label that comes from trac.Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/52Ensure that external users have a project limit of 52020-07-09T19:55:49ZAlexander Færøyahf@torproject.orgEnsure that external users have a project limit of 5We should make sure that each external user (and the default for new users) has a project limit of 5 as per discussion in the Gitlab meeting on Tuesday the 7th of July 2020.We should make sure that each external user (and the default for new users) has a project limit of 5 as per discussion in the Gitlab meeting on Tuesday the 7th of July 2020.Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/53Disable "GitLab is used only for code review" banner?2020-07-10T19:07:30ZPhilipp Winterphw@torproject.orgDisable "GitLab is used only for code review" banner?It would be great if we had the option to disable the banner. I understand that this is important information for folks who are new to Gitlab but I find it mildly annoying to have the banner occupy thousands of pixels of browser real est...It would be great if we had the option to disable the banner. I understand that this is important information for folks who are new to Gitlab but I find it mildly annoying to have the banner occupy thousands of pixels of browser real estate.Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/54Deploy Lobby Webapp for Sign Ups2020-10-06T15:54:14ZAlexander Færøyahf@torproject.orgDeploy Lobby Webapp for Sign UpsI've finally managed to get the Lobby web application to the point where we can use it for user sign-ups + approvals. Next step will be the anonymous issue creation and commenting, but that is a secondary thing right now. It also depends...I've finally managed to get the Lobby web application to the point where we can use it for user sign-ups + approvals. Next step will be the anonymous issue creation and commenting, but that is a secondary thing right now. It also depends on whether we do Discourse or not.
We need to figure out how and where to deploy this app. It can use a SQLite database or PostgreSQL. It's written in Django, but I have no experience with running Django apps with Apache. I assume it's a lot like with Nginx.
The code in https://gitlab.torproject.org/ahf/lobby works now and can be tested with `./manage.py runserver` (test webserver) and by putting the right values in the `lobby/settings.py` file.Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/tpa/gitlab/-/issues/75change the default Git branch to "main" in GitLab2021-04-26T14:01:05Zanarcatchange the default Git branch to "main" in GitLabWe currently do not have any special configuration in GitLab regarding the branch name, which, in Git, defaults to `master`. Following recent events there has been a far and wide ranging conversation about changing that default to someth...We currently do not have any special configuration in GitLab regarding the branch name, which, in Git, defaults to `master`. Following recent events there has been a far and wide ranging conversation about changing that default to something else. Everywhere people are trying to get rid of that wording:
* GitHub is [changing to `main` on October 1st 2020](https://github.blog/changelog/2020-08-26-set-the-default-branch-for-newly-created-repositories/).
* Puppet has been [progressively removing mention of "master"](https://puppet.com/blog/removing-harmful-terminology-from-our-products/) and "blacklist"
* Git has [introduced a setting](https://lore.kernel.org/git/CAP8UFD1KfEps4hS8eadBK-E4e5WyWSh93XivRabZAVhiCuQimQ@mail.gmail.com/) to make the default changeable
* there's a proposal to [do the change in Wordpress as well](https://wptavern.com/proposal-to-rename-the-master-branch-from-wordpress-owned-git-repositories)
.. and that list is not exhaustive.
We should follow suit. There's already a [proposal to make the change in tor/core](https://gitlab.torproject.org/tpo/core/team/-/issues/2) but we should also change the default in GitLab as a whole. That's done in this admin section:
https://gitlab.torproject.org/admin/application_settings/repository
That affects only new repositories, for existing repositories, there are [various recipes](https://dev.to/damcosset/replacing-master-in-git-2jim) to make the change, but it's less trivial. Also note that this [does not affect wiki branch names](https://gitlab.com/gitlab-org/gitlab/-/issues/221159).
For now I propose we only change the default. GitHub has been working on [procedures to rename branches](https://github.com/github/renaming) which could prove interesting.
Update: @anarcat wrote this program to rename branches locally and on GitHub in batch: https://gitlab.com/anarcat/scripts/-/blob/main/git-branch-rename-remoteanarcatanarcat2020-10-24https://gitlab.torproject.org/tpo/core/tor/-/issues/2667Exits should block reentry into the tor network2023-08-23T19:53:08ZMike PerryExits should block reentry into the tor networkWith proposal 110, we blocked the ability of Tor clients to use the Tor protocol for an unbounded amplification attack to destroy the Tor network. However, we still have not completely prevented this attack. It is still possible to tunne...With proposal 110, we blocked the ability of Tor clients to use the Tor protocol for an unbounded amplification attack to destroy the Tor network. However, we still have not completely prevented this attack. It is still possible to tunnel tor over tor by using exits to connect back to other tor nodes. This property can still be used to execute the unbounded amplification attack on the Tor network, or just on the tor directory authorities.
One fix for this would be to add code to exit nodes to implicitly add all of the IP + ORport combinations of all other relays to their exit policy reject lines, or otherwise block this connection at some other level.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.org