Gå til hovedindhold

Spejling af repositories

fremforge understøtter både pull-spejling (et eksternt repository → fremforge, holdt synkroniseret efter en tidsplan) og push-spejling (et fremforge-repository → en ekstern destination, spejlet ved hvert push). Begge retninger bruger Forgejos indbyggede spejlfunktion og kører som planlagte baggrundsjob.

Opsætning af et spejl

Pull-spejl (eksternt → fremforge)

Når du opretter et nyt repository:

  1. Gå til frem.sh/repo/migrate (eller klik på “+” → “Ny migration” i topbjælken).
  2. Vælg kildetjenesten: GitHub, GitLab, Gitea, Forgejo, Bitbucket eller Plain Git.
  3. Indsæt kildens URL (HTTPS).
  4. Sæt flueben i “This repository will be a mirror”, før du klikker på Migrate. Uden det flueben er importen en engangskopi og ikke en løbende synkronisering.
  5. Spejlintervallet er som standard 8 timer. Du kan ændre det på repoets side Indstillinger → Spejl indstillinger efter oprettelsen. Det korteste interval er 10 minutter.

Push-spejl (fremforge → eksternt)

På et eksisterende repository:

  1. Repoets Indstillinger → Spejl indstillinger → afsnittet “Push Mirrors”.
  2. Tilføj destinationens URL (HTTPS) og legitimationsoplysninger (brugernavn og adgangstoken til destinationstjenesten).
  3. Spejlet kører ved hvert push til fremforge-repoets standardbranch og desuden med det konfigurerede interval (som standard 8 timer).

Understøttede kilde- og destinationsværter

Git-trafik ud fra fremforges Forgejo-pod går gennem en tilladelsesliste (dybdeforsvar mod SSRF og udtræk af data via spejl-URL’er). Disse værter er tilladt i dag:

VærtPull-spejlPush-spejlBemærkninger
github.com (+ *.githubusercontent.com)✅✅Inklusive GitHub Enterprise Cloud (*.github.com); GHES-instanser på kundens egne domæner kræver, at værten føjes til tilladelseslisten (se nedenfor).
*.gitlab.com✅✅GitLab.com SaaS. Selvhostede GitLab-instanser på kundens domæner kræver, at værten føjes til tilladelseslisten.
*.bitbucket.org✅✅Atlassian Bitbucket Cloud. Bitbucket Data Center på kundens domæner kræver, at værten føjes til tilladelseslisten.
codeberg.org✅✅Forgejo-baseret community-hosting.
dev.azure.com (+ *.visualstudio.com)✅✅Azure DevOps (nye og gamle værtsnavne).
code.forgejo.org✅✅Forgejo-projektets egen hosting.
gitea.com✅✅Gitea SaaS.
git.sr.ht✅✅SourceHut.

Kun HTTPS. Spejl-URL’er over SSH (git@<host>:owner/repo.git) understøttes ikke i dag: fremforges Forgejo-pod sender Git-trafik gennem HTTPS-proxyen, ikke direkte ud på port 22. Brug HTTPS-formen af kildens URL med et Personal Access Token, hvis kilden kræver godkendelse.

Mål på private netværk blokeres. RFC1918-intervallerne (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) og link-local afvises i Forgejo-laget uanset tilladelseslisten. Spejling fra en intern Git-server i virksomheden kræver, at serveren kan nås fra det offentlige internet via et stabilt værtsnavn.

Tilføj en vært til tilladelseslisten

For spejlkilder eller -destinationer, der ikke står på listen ovenfor (typisk selvhostet GitLab, GitHub Enterprise Server eller Bitbucket Data Center på et domæne, kunden ejer):

  1. Skriv til support@frem.sh med værtsnavnet og en kort beskrivelse af formålet.
  2. Vi føjer den til den globale tilladelsesliste inden for én arbejdsdag (der er ingen afgrænsning pr. kunde i dag: værten bliver tilgængelig for spejloperationer fra alle fremforge-tenants).
  3. Derefter kan du sætte spejlet op som beskrevet ovenfor.

Hvorfor du skal spørge os i stedet for selv at gøre det: tilladelseslisten deles af hele klyngens egress-proxy. Politik pr. tenant, så hver organisations administrator kan styre sin egen tilladelsesliste, står på vores køreplan (fase 2). Indtil da gennemgås tilføjelser af en operatør af den grund.

Grænser og egenskaber

  • Interval for pull-spejl: mindst 10 minutter, som standard 8 timer, kan indstilles pr. repo.
  • Udløser for push-spejl: ved hvert push til standardbranchen og med det konfigurerede interval.
  • Legitimationsoplysninger i hvile: Forgejo krypterer spejlets legitimationsoplysninger i sin database (spejlenes adgangskoder er ikke synlige for fremforges operatører).
  • Spejloperationer tæller med i repoets måling på samme måde som almindelige Git-operationer.

Trusselsmodel og revision

  • Hver oprettelse, ændring og sletning af et spejl udsender en revisionshændelse, som du kan se på <org>/_admin/audit-log.
  • Fejl ved hentning til et spejl (f.eks. legitimationsoplysninger, der er tilbagekaldt hos kilden) logges som advarsler i repoets aktivitetsstrøm. Vi tilkalder ikke vores vagt ved fejl i kunders spejle.
  • Et push-spejl med lækkede legitimationsoplysninger giver destinationstjenesten mulighed for at læse dit repo (og skrive, hvis du har sat push op). Behandl adgangstokenet som alle andre legitimationsoplysninger: rotér det, hvis du har mistanke om kompromittering. Fremgangsmåden for rotation er beskrevet hos destinationstjenesten.

Se også