מה ידוע מקריאת הקוד (לא נבדק על הדיסק)
GitMirrorService.init_mirror מעביר ל-git clone --mirror את ה-URL ש-_get_authenticated_url בונה. כשיש טוקן לבעלים של הריפו, זה https://oauth2:<TOKEN>@github.com/<owner>/<repo>.git.
- git שומר את ה-URL שה-clone נעשה ממנו ב-
remote.origin.url, בקובץ config של המראה. התיעוד של git (v2.43.0, Documentation/config/transfer.txt, סעיף transfer.credentialsInUrl) אומר ש-URL מוגדר יכול לשאת credentials בטקסט גלוי, שזה חל על clone, fetch ו-push, ושברירת המחדל היא allow — git לא מזהיר ולא מסרב.
fetch_updates מריץ git fetch --all --prune בלי URL, כלומר על ה-URL השמור. זו גם הסיבה הסבירה לכך ש-fetch של ריפו פרטי עובד היום: בלי טוקן שמור שם, הוא היה נכשל באימות.
ההשערה: הטוקן שמור בטקסט גלוי ב-<REPO_MIRROR_PATH>/<repo>.git/config, על הדיסק של הוובאפ ועל הדיסק של שירות ה-MCP. זה לא אומת.
הצעד הראשון: אימות, בלי להדפיס את הטוקן
על כל מראה, בשני השירותים:
git -C "$REPO_MIRROR_PATH/<repo>.git" config --get remote.origin.url | sed -E 's#//[^@/]*@#//***@#'
אם הפלט מכיל //***@, ה-URL השמור נושא credentials. הפקודה מסתירה אותם לפני שהם מגיעים למסך.
אם זה אכן כך — כיוון לתיקון (לא הוחלט)
- להוציא את הטוקן מה-URL השמור. על מראות קיימות:
git remote set-url origin https://github.com/<owner>/<repo>.git. במראות חדשות: clone עם URL נקי.
- להעביר את האימות לכל פקודה בנפרד, בלי לשמור אותו בדיסק — למשל credential helper שקורא מה-ENV, או כותרת אימות שמועברת ב-
-c בזמן ה-fetch. איזה מנגנון, ובאיזו צורה בדיוק, צריך לבדוק מול התיעוד של git לפני שכותבים.
- שני דברים שהתיעוד של git מזכיר ורלוונטיים כאן: credentials שבתוך URL עוברים גם כארגומנט של שורת פקודה בין תהליכי git (ולכן גלויים ברשימת התהליכים), ונשמרים "at rest" — כלומר גם בגיבוי של הדיסק.
_sanitize_output כבר מנקה credentials מתוך URL בפלט של git. זה מגן על הלוגים, לא על הקובץ בדיסק.
הקשר
זה עלה בעבודה על ref_not_mirrored (ענף claude/focused-ritchie-ju95we). בגלל זה המימוש שם קורא רק את הפלט של rev-parse, ואף פעם לא את config או את התוכן של FETCH_HEAD.
מה ידוע מקריאת הקוד (לא נבדק על הדיסק)
GitMirrorService.init_mirrorמעביר ל-git clone --mirrorאת ה-URL ש-_get_authenticated_urlבונה. כשיש טוקן לבעלים של הריפו, זהhttps://oauth2:<TOKEN>@github.com/<owner>/<repo>.git.remote.origin.url, בקובץconfigשל המראה. התיעוד של git (v2.43.0,Documentation/config/transfer.txt, סעיףtransfer.credentialsInUrl) אומר ש-URL מוגדר יכול לשאת credentials בטקסט גלוי, שזה חל על clone, fetch ו-push, ושברירת המחדל היאallow— git לא מזהיר ולא מסרב.fetch_updatesמריץgit fetch --all --pruneבלי URL, כלומר על ה-URL השמור. זו גם הסיבה הסבירה לכך ש-fetch של ריפו פרטי עובד היום: בלי טוקן שמור שם, הוא היה נכשל באימות.ההשערה: הטוקן שמור בטקסט גלוי ב-
<REPO_MIRROR_PATH>/<repo>.git/config, על הדיסק של הוובאפ ועל הדיסק של שירות ה-MCP. זה לא אומת.הצעד הראשון: אימות, בלי להדפיס את הטוקן
על כל מראה, בשני השירותים:
אם הפלט מכיל
//***@, ה-URL השמור נושא credentials. הפקודה מסתירה אותם לפני שהם מגיעים למסך.אם זה אכן כך — כיוון לתיקון (לא הוחלט)
git remote set-url origin https://github.com/<owner>/<repo>.git. במראות חדשות: clone עם URL נקי.-cבזמן ה-fetch. איזה מנגנון, ובאיזו צורה בדיוק, צריך לבדוק מול התיעוד של git לפני שכותבים._sanitize_outputכבר מנקה credentials מתוך URL בפלט של git. זה מגן על הלוגים, לא על הקובץ בדיסק.הקשר
זה עלה בעבודה על
ref_not_mirrored(ענףclaude/focused-ritchie-ju95we). בגלל זה המימוש שם קורא רק את הפלט שלrev-parse, ואף פעם לא אתconfigאו את התוכן שלFETCH_HEAD.