Mint Linux project’s anti-netneutrality hostility toward Tor and privacy is why I dropped support for Mint users - Sopuli
sopuli.xyz
I stopped distributing Linux Mint to the low-tech users who I support roughly ~10 years ago when the project jailed their docs in tor-hostile Cloudflare websites (e.g. readthedocs.io [http://readthedocs.io], IIRC). A recent general search for info on getting a piece of hardware working on linux led to forums.linuxmint.com (the query had no relevance to Mint specifically). This website uses #Sucuri for elitist tor-hostile gatekeeping. There is no action for me to take since I already quit supporting Mint, other than perhaps to ask others in my local linux support group to also drop Mint support because our users should not face a choice between software freedom and privacy. Certainly when I am asked to install Mint for someone, I will refuse and try to steer them to Debian, perhaps with Cinnamon. Screenshot attached. Not sure how long linuxmint has been using Sucuri for crude IP reputation discrimination, but note that the Debian project that feeds the Mint project demonstrates respect for people’s privacy. Mint adds value in some ways, but at the same time worsens a good distro by jailing information. This is not a “something is better than nothing” scenario. It’s actually destructive. When you host a discriminatory access-restricted forum, you create an attraction for useful info and simultaneously become an obstacle to the information that would otherwise find a better host. If forums.linuxmint.com did not exist, the discussion would still occur somewhere and it would have a chance at occurring in an open access venue.

(cross-posted in !collaboration@sopuli.xyz)

There are two common methods for starting a new repository: using git init or git clone. This post demonstrates the former.

Preconditions:

  • SSH, git, and Tor are installed
  • a Tor SOCKS proxy listens on port 9050 (i.e. SocksPort 9050 in /etc/tor/torrc)
  • (optional) You have an HTTP proxy such as privoxy listening on port 8118

Create an accout and a repository on a gitea instance. The following parameters are placeholders assumed for these instructions:

forge: gitea
instance: git.platypush.tech (many choices)
repo name: tuneInTurnOffDropOut
username: timLeary

Locally, make a new directory and go there. CLI steps from there:

$ git init
$ git config http.proxy http://127.0.0.1:8118/; # optional; only useful if you later want/need to switch to HTTP and you run an HTTP proxy over Tor
$ git config credential.helper store; # optional; only useful to store your creds if you later want/need to forgo SSH keys
$ git config user.name timLeary

Visit your settings (e.g. https://git.platypush.tech/user/settings), ☑ Hide email address, and see what special address is supplied. Use that in the next step.

(update) some gitea servers have this tickbox but they do not mention a special email address. 🤷

$ git config user.email timLeary@noreply.git.platypush.tech; # get this from account settings, or use an email address of your choice

Visit your new repo (e.g. https://git.platypush.tech/timLeary/tuneInTurnOffDropOut) which will show a “quick guide” because it’s an empty repo. Highlight “SSH“ to see the SSH username to the left of the “@”. Remember that for the next step.

$ git remote add origin forgejo@platy:timLeary/tuneInTurnOffDropOut.git; # ⚠ Do not use the gitea-suggested parameter verbatim; just grab the git API username (generally “git” or “forgejo”) from the previous step to prefix into this format. “platy” is an arbitrary string of your choice.
$ git checkout -b main; # “master” is a popular historic variation to “main”, but main is the woke gitea default so we’ll run with it
$ printf '%s\n' 'Put a blurb about the project here.' > README.md
$ git add README.md
$ git commit -m "first commit"
$ ssh-keygen -t rsa -N '' -C 'timLeary at platypush' -f ~/.ssh/id_rsa_platypush-timLeary; # the "-C $comment" parameter is optional
$ wl-copy < ~/.ssh/id_rsa_platypush-timLeary.pub; # Use your preferred way to get the pubkey in your clipboard. wl-copy is the Wayland-specific way to do that.

git.platypush.tech → settings → SSH/GPG Keys → Manage SSH Key → add key → (paste from clipboard)

$ ssh-keygen -l -f ~/.ssh/id_rsa_platypush-timLeary; # optional check; compare the local sha256 fingerprint to that in platypush/timLeary web account settings
$ cat >> ~/.ssh/config <<eof
host platy
     hostname     git.platypush.tech
     ForwardX11   no
     ProxyCommand connect -4 -S 127.0.0.1:9050 \$(tor-resolve %h 127.0.0.1:9050) %p
     IdentityFile /home/$(whoami)/.ssh/id_rsa_platypush-timLeary
eof

$ git push -u origin main

Note that the host value in ~/.ssh/config is any identifier you want. But it must match the token between @ and : in the git remote add origin command. I chose platy in the example.

Benefits

The beauty of this configuration is that you never need to prefix your git commands with torsocks going forward. All cloud ops will automatically tunnel over Tor. In fact, using torsocks would fail with this config.

Drawbacks

  • Probably does not work on gitea onion instances (ouch!)
  • Some gitea instances refuse SSH and/or Tor connections, but they are opaque about it. In those cases you get error messages that lie. Switching to HTTP is the workaround.

Onion workaround (untested)

How can this be done for onion hosts? Would this work?:

$ sudo tee -a /etc/tor/torrc <<< 'mapaddress 192.168.1.25 hsdtecd4h2b5z732pvkg2yw3746epap4qusgvjjze6nhmfcdpz2suiad.onion'
$ cat >> ~/.ssh/config <<eof
host nogafam-onion
     hostname     192.168.1.25
     ForwardX11   no
     ProxyCommand connect -4 -S 127.0.0.1:9050 %h %p
     IdentityFile /home/$(whoami)/.ssh/id_rsa_nogafam
eof

Or is there a better way?

(note that nogafam.es is not a good example for testing because they block SSH deliberately)

update: the above stanza does not work.

Improvements?

Any feedback for improvements is welcome.