Skip to content

Improper parsing of IPv6 literals from config file #10138

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
2 of 7 tasks
sciguy16 opened this issue Feb 4, 2020 · 1 comment · Fixed by #12321
Closed
2 of 7 tasks

Improper parsing of IPv6 literals from config file #10138

sciguy16 opened this issue Feb 4, 2020 · 1 comment · Fixed by #12321
Labels
issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented type/bug
Milestone

Comments

@sciguy16
Copy link

sciguy16 commented Feb 4, 2020

  • Gitea version (or commit ref):
    Gitea version 1.10.3 built with GNU Make 4.2.1, go1.13.6 : bindata, sqlite, pam
  • Git version:
    git version 2.25.0
  • Operating system:
    Arch Linux
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • Not relevant
  • Log gist:
2020/02/04 11:45:59 [T] UpdatePublicKeyUpdated: http://::1:3000/api/internal/ssh/8/update
2020/02/04 11:45:59 [...io/gitea/cmd/serv.go:332 runServ()] [F] UpdatePublicKey: Post http://::1:3000/api/internal/ssh/8/update: invalid URL port ":1:3000"

Description

When I try to interact with git over SSH Gitea is unable to access its internal UpdatePublicKey endpoint because of the way that it builds the URL with an IPv6 literal. The URL used is "http://::1:3000/" when it should be "http://[::1]:3000" and it looks like there is a string split happening that interprets the ":1:3000" as a port number.

-git pull
Verification code:
remote: Enumerating objects: 301, done.
remote: Counting objects: 100% (301/301), done.
remote: Compressing objects: 100% (258/258), done.
Gitea: Internal error4% (280/297)
UpdatePublicKey: Post http://::1:3000/api/internal/ssh/8/update: invalid URL port ":1:3000"
remote: Total 297 (delta 101), reused 0 (delta 0)
Receiving objects: 100% (297/297), 913.41 KiB | 3.18 MiB/s, done.
Resolving deltas: 100% (101/101), completed with 1 local object.

Error from the log file:

2020/02/04 11:45:59 [T] UpdatePublicKeyUpdated: http://::1:3000/api/internal/ssh/8/update
2020/02/04 11:45:59 [...io/gitea/cmd/serv.go:332 runServ()] [F] UpdatePublicKey: Post http://::1:3000/api/internal/ssh/8/update: invalid URL port ":1:3000"

The HTTP_ADDR in the config is set to [::1], which works for the web interface (proxied via nginx):

[server]
SSH_DOMAIN       = git.mydomain.com
DOMAIN           = git.mydomain.com
HTTP_PORT        = 3000
HTTP_ADDR        = [::1]
ROOT_URL         = https://git.mydomain.com/
DISABLE_SSH      = false
SSH_PORT         = 22

Netstat shows Gitea listening correctly on localhost:

tcp6       0      0 ::1:3000                :::*                    LISTEN      87006/gitea

I've found the relevant parts of the codebase. This line builds the internal API URL by concatentating the LocalURL setting with the API path:

reqURL := setting.LocalURL + fmt.Sprintf("api/internal/serv/command/%d/%s/%s?mode=%d",

Since the local URL has not been specified int he config file, this section sets the LocalURL parameter to HTTP_ADDR:HTTP_PORT/:

if HTTPAddr == "0.0.0.0" {
defaultLocalURL += "localhost"
} else {
defaultLocalURL += HTTPAddr
}
defaultLocalURL += ":" + HTTPPort + "/"
}
LocalURL = sec.Key("LOCAL_ROOT_URL").MustString(defaultLocalURL)

And this line sets the HTTP_ADDR to the value in the config file:

HTTPAddr = sec.Key("HTTP_ADDR").MustString("0.0.0.0")

The issue seems to be that when "[::1]" is parsed the brackets are dropped, which breaks the API URL building.

If I put the address in double quotes HTTP_ADDR = "[::1]" the git pull succeeds but Gitea still tries to access the broken http://::1:3000/api/internal/ssh/8/update URL.

@stale
Copy link

stale bot commented Apr 7, 2020

This issue has been automatically marked as stale because it has not had recent activity. I am here to help clear issues left open even if solved or waiting for more insight. This issue will be closed if no further activity occurs during the next 2 weeks. If the issue is still valid just add a comment to keep it alive. Thank you for your contributions.

@stale stale bot added the issue/stale label Apr 7, 2020
@zeripath zeripath added the issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented label Apr 7, 2020
@stale stale bot removed the issue/stale label Apr 7, 2020
@lafriks lafriks added this to the 1.13.0 milestone Jul 26, 2020
@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented type/bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants