Unable to automatic upgrade due to Geographical Discrimination

The issue I’m reporting here is the inability to use the built-in auto upgrade facility in Syncthing because the program is unable to download an updated version.

Further examination reveals that the downloads http server is refusing to serve the request. This is understood to be caused due to the client’s IP country. In the country where the issue is reported, inability to download releases from Github is a nation-wide experienced phenomenon.

Said Github downloads are usually obtained from the domain objects.githubusercontent.com over https. But the URL’s query string indicates that the data is being served from Amazon (see below for URL details).

Regardless of which source is blocking the downloads, this is, in my opinion, a case of Geographical Discrimination. And while the reasons for blocking access are very probably political in nature, the principles of FOSS inherently promote the idea of software being freely available to everyone, irrespective of their geographical location.

I hereby suggest and encourage the Syncthing project maintainers to also provide a mirror downloads server that is location-agnostic (and politics-agnostic), and enable the program updater to fallback to the mirror servers.

Additionally, as a hosting service provider owner, I offer to host this mirror free of charge for the Syncthing project for as long as possible, in order to resolve cases like this one, without incurring additional costs to the maintainers.

Diagnostics:

Syncthing checks for updates, by default, using the URL: https://upgrades.syncthing.net/meta.json Which lists release download URLs. For example:

[
	{
		"tag_name": "v1.27.7",
		"prerelease": false,
		"assets": [
			{
				"url": "https://github.com/syncthing/syncthing/releases/download/v1.27.7/sha1sum.txt.asc",
				"name": "sha1sum.txt.asc"
			},
			{
				"url": "https://github.com/syncthing/syncthing/releases/download/v1.27.7/sha256sum.txt.asc",
				"name": "sha256sum.txt.asc"
			},
			{
				"url": "https://github.com/syncthing/syncthing/releases/download/v1.27.7/syncthing-dragonfly-amd64-v1.27.7.tar.gz",
				"name": "syncthing-dragonfly-amd64-v1.27.7.tar.gz"
			},
			{
				"url": "https://github.com/syncthing/syncthing/releases/download/v1.27.7/syncthing-freebsd-386-v1.27.7.tar.gz",
				"name": "syncthing-freebsd-386-v1.27.7.tar.gz"
			},
...

These download URLs redirect to download the resource from an address similar to this one for Windows x64:

https://objects.githubusercontent.com/github-production-release-asset-2e65be/14712850/6818ba86-a2f2-4fc2-a020-d1e5818c538c?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAVCODYLSA78PQK4ZA%2F24540509%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20240509T273127Z&X-Amz-Expires=300&X-Amz-Signature=36bcf71dae54540aaa8ccf35e47f4058fc027e415ef90516da5195cb89eef5f1&X-Amz-SignedHeaders=host&actor_id=30826047&key_id=0&repo_id=14712850&response-content-disposition=attachment%3B%20filename%3Dsyncthing-windows-amd64-v1.27.7.zip&response-content-type=application%2Foctet-stream

From certain IP addresses, the connections time-out, and the Web GUI shows a Notice like this one:

With this error in text: dial tcp 185.199.111.133:443: connectex: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

We do no blocking of any kind, be it geographical, political, technical or otherwise. Obviously, we do not control any blocking GitHub or Amazon may do, but I don’t think they block entire countries either. You’ll need to look closer to home for the cause.

Still, it is a generous offer to donate a mirror server and I think it would be worthwhile adding support for such a fall-back. Basically include a “mirrors” attribute in that JSON response with a list of additional URLs to be tried. Then have the updater go through each of them in random order if the main one fails. It does check signature integrity after all, so we don’t open any security holes there, right?

I guess adding such code wouldn’t be hard, just someone needs to start investing the time.

The upgrade check URL is configurable by the way, so you could just re-write the URLs in that JSON document and serve that from your mirror. Then all users with such blocking issues just need to point Syncthing to your alternate update server URL.

2 Likes

Or make the relays into ad hoc upgrade CDN nodes :slight_smile:

1 Like

Apologies if this was understood to blame the Syncthing team. It is certainly not, and I’m very appreciative for every effort put by contributors.

Sorry to disappoint you. I could invite you to visit the middle east, but you can also take my word for it :grin: People over there have very long experience with the negative outcomes of US policies. (and I happen to know things)

This is also a feasible idea. My offer still stands, though :innocent: Please feel free to get in touch with me any time.

1 Like