Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

`onyxia-init.sh`: automatic clone of private GitHub repos fails (`could not read Username`) — token-only URL credentials dropped by git 2.55

Đang mở Phù hợp với người mới
#438 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 3 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
78/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
docker, git, github, shell
Lĩnh vực
backend, devops

Hướng nghiên cứu

Đọc base/scripts/onyxia-init.sh ở phần tạo CLONE_URL và so sánh các định dạng thông tin xác thực của GitHub, Bitbucket và GitLab trong diff được đề xuất. Tái hiện bằng vòng lặp git ls-remote được cung cấp trong image đã nêu, sử dụng một repository riêng tư và token hợp lệ; che thông tin xác thực khỏi mọi bản ghi trace. Hoàn tất khi quá trình tự động clone xác thực thành công bằng các định dạng URL đã sửa.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Summary

With git.token and git.repository set, the automatic clone of a private GitHub repository fails at startup:

Cloning into 'MarBLE'...
warning: redirecting to https://github.com/<owner>/<repo>.git/
fatal: could not read Username for 'https://github.com': No such device or address

The service then starts on a workspace folder that does not exist (code-server ... /home/onyxia/work/<repo>) and the user gets an empty VSCode.

The token is valid and has the repo scope. GitHub accepts it, but git sends the follow-up request without credentials (see the trace below).

Environment
  • Image: inseefrlab/onyxia-vscode-python:py3.13.15
    (sha256:e343e00be96d9c9b70abd7bd06eb2b90429e03e6b968a0e10a49d356f2fd8b6c)
  • Ubuntu 24.04.5 LTS
  • git 1:2.55.0-0ppa1~ubuntu24.04.2 (git-core PPA)
  • git-remote-https linked against libcurl-gnutls.so.4 (libcurl 8.5.0-2ubuntu10.16)
  • Service values:
    git:
      enabled: true
      token: <classic PAT, scope repo>
      repository: https://github.com/<owner>/<private-repo>.git
      branch: main
      asCodeServerRoot: true
    

This used to work. The failure started with a recent image (our /opt/onyxia-init.sh is dated 2026-10-19).

Root cause

For GitHub, base/scripts/onyxia-init.sh (l. 100) puts the token alone in the userinfo, with no password:

CLONE_URL="$URL_PREFIX"/"$GIT_PERSONAL_ACCESS_TOKEN"@"$URL_NO_PREFIX"
# -> https:///<TOKEN>@github.com/<owner>/<repo>.git

With git 2.55, the authenticated GET info/refs succeeds. Git then reports a "redirect", although GitHub did not send any 3xx or Location header. It continues on the URL without userinfo, and the POST git-upload-pack goes out unauthenticated and gets a 401:

GET  /<owner>/<repo>.git/info/refs?service=git-upload-pack  -> 401  (challenge, expected)
GET  /<owner>/<repo>.git/info/refs?service=git-upload-pack  -> 200  (Basic auth with user '<TOKEN>')
warning: redirecting to https://github.com/<owner>/<repo>.git/
POST /<owner>/<repo>.git/git-upload-pack                    -> 401  (no Authorization header)
fatal: could not read Username for 'https://github.com': terminal prompts disabled

If the userinfo has a password part (user:password@), git keeps the credentials across this false redirect and the clone succeeds.

I have not checked whether the regression comes from git 2.55 itself or from git 2.55 combined with libcurl 8.5. Either way, <TOKEN>@ no longer works in the current image.

Reproduction

Requires a classic PAT with repo scope and any private repository it can read.

docker run --rm -e TOKEN=<PAT> -e REPO=<owner>/<private-repo> \
  inseefrlab/onyxia-vscode-python:py3.13.15 bash -c '
    export GIT_TERMINAL_PROMPT=0
    for u in "$TOKEN" "$TOKEN:x-oauth-basic" "x-access-token:$TOKEN"; do
      echo "== userinfo: ${u//$TOKEN/<TOKEN>}"
      git ls-remote "https://[email protected]/$REPO.git" HEAD 2>&1 | sed "s/$TOKEN/<TOKEN>/g"
    done'

Observed:

userinfo result
<TOKEN>@ (format used by onyxia-init.sh) ❌ could not read Username
<TOKEN>:x-oauth-basic@ ✅
x-access-token:<TOKEN>@ ✅

The URL actually built by the script (https:///<TOKEN>@github.com/..., with three slashes) fails in the same way. I reproduced this on 3 different private repositories.

To get the HTTP trace above, add GIT_TRACE_CURL=1 GIT_TRACE_CURL_NO_DATA=1 to the failing command. Redact the Authorization lines before sharing.

Proposed fix

In base/scripts/onyxia-init.sh:

             if [ "$REPO_DOMAIN" = "github.com" ]; then
-                CLONE_URL="$URL_PREFIX"/"$GIT_PERSONAL_ACCESS_TOKEN"@"$URL_NO_PREFIX"
+                CLONE_URL="$URL_PREFIX"x-access-token:"$GIT_PERSONAL_ACCESS_TOKEN"@"$URL_NO_PREFIX"
             elif echo "$GIT_REPOSITORY" | grep -qi "bitbucket"; then
-                CLONE_URL="$URL_PREFIX"/x-token-auth:"$GIT_PERSONAL_ACCESS_TOKEN"@"$URL_NO_PREFIX"
+                CLONE_URL="$URL_PREFIX"x-token-auth:"$GIT_PERSONAL_ACCESS_TOKEN"@"$URL_NO_PREFIX"
             else
                 # GitLab (gitlab.com or hosted instance)
-                CLONE_URL="$URL_PREFIX"/oauth2:"$GIT_PERSONAL_ACCESS_TOKEN"@"$URL_NO_PREFIX"
+                CLONE_URL="$URL_PREFIX"oauth2:"$GIT_PERSONAL_ACCESS_TOKEN"@"$URL_NO_PREFIX"
             fi
  • GitHub: x-access-token:<TOKEN> works with classic and fine-grained PATs.
  • All providers: this also removes the extra /. $URL_PREFIX already ends with //, so the script currently builds https:///....

Suggestion: when the clone fails, the init script could also stop or log a clear error instead of starting code-server on a folder that does not exist.

Workaround for users

In a terminal inside the service:

git clone https://x-access-token:[email protected]/<owner>/<repo>.git /home/onyxia/work/<repo>

Then reload the window. The same command can go in a custom init script, guarded by [ -d /home/onyxia/work/<repo> ] ||.

Ngôn ngữ chính
Shell
Star
43
Fork
37
Merge trung bình
3 ngày 17 giờ
Pull request đã merge (30 ngày)
10

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của InseeFrLab/images-datascience

Tất cả issue của InseeFrLab/images-datascience

Issue tương tự

Thêm issue về Shell/Bash

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.