Gå til hovedinnhold

Speiling av repositoryer

fremforge støtter både pull-speiling (et eksternt repository → fremforge, holdt synkronisert etter en tidsplan) og push-speiling (et fremforge-repository → et eksternt mål, speilet ved hver push). Begge retningene bruker speilfunksjonen i Forgejo og kjører som planlagte bakgrunnsjobber.

Sette opp et speil

Pull-speil (eksternt → fremforge)

Når du oppretter et nytt repository:

  1. Gå til frem.sh/repo/migrate (eller klikk «+» → Ny migrasjon i toppfeltet).
  2. Velg kildetjenesten: GitHub, GitLab, Gitea, Forgejo, Bitbucket eller Plain Git.
  3. Lim inn kilde-URL-en (HTTPS).
  4. Huk av for «This repository will be a mirror» før du klikker Migrate. Uten denne avkrysningen blir importen en engangskopi, ikke en løpende synkronisering.
  5. Speilintervallet er 8 timer som standard. Du kan endre det på siden Innstillinger → Speilinnstillinger for repositoryet etter at det er opprettet. Minste intervall er 10 minutter.

Push-speil (fremforge → eksternt)

På et eksisterende repository:

  1. Repositoryets Innstillinger → Speilinnstillinger → seksjonen «Push Mirrors».
  2. Legg til mål-URL-en (HTTPS) og legitimasjon (brukernavn og tilgangstoken for måltjenesten).
  3. Speilet kjører ved hver push til standardbranchen i fremforge-repositoryet, og i tillegg med det konfigurerte intervallet (8 timer som standard).

Støttede kilde- og målverter

Utgående Git-trafikk fra Forgejo-poden i fremforge går gjennom en tillatelsesliste (dybdeforsvar mot SSRF og datalekkasje via speil-URL-er). Disse vertene er tillatt i dag:

VertPull-speilPush-speilMerknader
github.com (+ *.githubusercontent.com)✅✅Inkludert GitHub Enterprise Cloud (*.github.com); GHES-instanser på kundeeide domener krever et tillegg i tillatelseslisten (se nedenfor).
*.gitlab.com✅✅GitLab.com SaaS. Selvhostede GitLab-instanser på kundedomener krever et tillegg i tillatelseslisten.
*.bitbucket.org✅✅Atlassian Bitbucket Cloud. Bitbucket Data Center på kundedomener krever et tillegg i tillatelseslisten.
codeberg.org✅✅Forgejo-basert fellesskapshosting.
dev.azure.com (+ *.visualstudio.com)✅✅Azure DevOps (nye og eldre vertsnavn).
code.forgejo.org✅✅Forgejo-prosjektets egen hosting.
gitea.com✅✅Gitea SaaS.
git.sr.ht✅✅SourceHut.

Bare HTTPS. Speil-URL-er basert på SSH (git@<host>:owner/repo.git) støttes ikke i dag. Forgejo-poden i fremforge sender Git-trafikk gjennom HTTPS-proxyen, ikke direkte ut på port 22. Bruk HTTPS-formen av kilde-URL-en med et personlig tilgangstoken hvis kilden krever autentisering.

Mål i private nettverk er blokkert. RFC1918-områdene (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) og link-local-adresser avvises i Forgejo-laget uansett tillatelsesliste. For å speile fra en intern Git-server i virksomheten må den serveren kunne nås fra det offentlige internettet via et stabilt vertsnavn.

Legge til en vert i tillatelseslisten

For speilkilder eller -mål som ikke står i listen over (typisk selvhostet GitLab / GitHub Enterprise Server / Bitbucket Data Center på et kundeeid domene):

  1. Send e-post til support@frem.sh med vertsnavnet og en kort beskrivelse av bruksområdet.
  2. Vi legger den til i den globale tillatelseslisten innen én virkedag (det finnes ingen avgrensning per kunde i dag; verten blir tilgjengelig for speiloperasjoner fra alle fremforge-kunder).
  3. Deretter kan du konfigurere speilet som beskrevet over.

Hvorfor vi ber deg spørre i stedet for å la deg gjøre det selv: tillatelseslisten deles av hele klyngens utgående proxy. Policyhåndheving per kunde, som ville la hver organisasjonsadministrator styre sin egen tillatelsesliste, står på veikartet vårt (fase 2); inntil da gjennomgås tillegg av en operatør av grunnen over.

Grenser og egenskaper

  • Intervall for pull-speil: minst 10 minutter, 8 timer som standard, kan konfigureres per repository.
  • Utløser for push-speil: ved hver push til standardbranchen og med det konfigurerte intervallet.
  • Lagret legitimasjon: Forgejo krypterer speillegitimasjon i databasen sin (speilpassord er ikke synlige for fremforges operatører).
  • Speiloperasjoner teller med i repositoryets måling på samme måte som vanlige Git-operasjoner.

Trusselmodell og revisjon

  • Hver gang et speil opprettes, oppdateres eller slettes, skrives en revisjonshendelse som du kan se på <org>/_admin/audit-log.
  • Når et speil ikke klarer å hente (for eksempel fordi legitimasjonen er tilbakekalt i kilden), logges det som en advarsel i repositoryets aktivitetsfeed. Vi varsler ikke vakten vår ved feil i kundenes speil.
  • Et push-speil med lekket legitimasjon gir måltjenesten mulighet til å lese repositoryet ditt (og skrive, hvis du har konfigurert push). Behandle tilgangstokenet som all annen legitimasjon: roter det hvis du mistenker at det er kompromittert. Fremgangsmåten for rotasjon er dokumentert hos måltjenesten.

Se også