gitea: 1.18.0 on Windows error: can not resolve localhost, ! [remote rejected] master -> master (pre-receive hook declined)

I think this issue should be re-opened and it needs a patch.

To make the workaround prominent, I didn’t say too much about my guess before.

Here is my opinion of this bug:

How it happens?

Gitea (Golang net package) can not resolve host localhost.

Golang’s net package need correct /etc/hosts and /etc/nsswitch.conf to resolve domains correctly. If anything is broken, it may not resolve some domains. On Windows, it also depends on C:\Windows\System32\Drivers\etc\hosts file

Why there are so many reports recently?

Possibility 1

Alpine / Go or Go for Windows changed some behaviors which conflict with user’s environment, then Golang’s net package doens’t work well in some rare cases (no evidence yet). But since some users reported that 1.17.x works but 1.18.x fails, maybe there is something changed.

Possibility 2

Many users’ systems were already broken, they messed up their hosts file, they might have deleted the 127.0.0.1 localhost line. I know a lot of such users.

Before, some public DNS servers can also resolve localhost, for example, there is still one now:

$ dig localhost @223.5.5.5
;; ANSWER SECTION:
localhost.		2495	IN	A	127.0.0.1

Recently some public DNS servers might have stopped such non-standard behavior, if they do not resolve localhost anymore, the users with broken localhost definition will encounter the problem.

So, some users with broken hosts files can get Gitea working before, but get errors now.

The patch

Approach 1

Use 127.0.0.1 instead of localhost for the default value of LOCAL_ROOT_URL

• Pros

  • 127.0.0.1 is the de-facto standard loopback IP, it should exist in every OS
  • won’t be affected by Host OS/Alpine/Golang anymore (in most cases)
  • even if the user’s hosts file is broken, it still works

• Cons

  • In a pure IPv6 network, the 127.0.0.1 may not exist, but the pure IPv6 network should be pretty rarer than broken hosts files, and a user with pure IPv6 must be an experienced user, they should be able to set LOCAL_ROOT_URL to a IPv6 loopback without any question.

Approach 2

Find the root case why 1.17.x works but 1.18.x doesn’t.

Update: maybe it’s a Go 1.19 bug: https://github.com/golang/go/issues/53490

And: https://tip.golang.org/doc/go1.19#net

The net package now has initial support for the netgo build tag on Windows. When used, the package uses the Go DNS client (as used by Resolver.PreferGo) instead of asking Windows for DNS results. The upstream DNS server it discovers from Windows may not yet be correct with complex system network configurations, however.

Removing the netgo tag from Windows build may resolve the problem.

Approach 3

Try to resolve localhost at startup, report fatal errors if the resolution fails.

I think it’s related to this Go bug:

• https://github.com/golang/go/issues/53490

And: https://tip.golang.org/doc/go1.19#net

The net package now has initial support for the netgo build tag on Windows. When used, the package uses the Go DNS client (as used by Resolver.PreferGo) instead of asking Windows for DNS results. The upstream DNS server it discovers from Windows may not yet be correct with complex system network configurations, however.

---

Removing the netgo tag from Windows build may resolve the problem.

For others seeing this conversation the LOCAL_ROOT_URL is in the [server] section of the app.ini and it must be added there.