# Basiese Gitea Inligting

{{#include ../../banners/hacktricks-training.md}}

## Basiese Struktuur

Die basiese Gitea omgewingstruktuur is om repos te groepeer volgens **organisasie(s),** elk van hulle kan **verskeie repositories** en **verskeie spanne** bevat. Let egter daarop dat, net soos in github, gebruikers repos buite die organisasie kan hê.

Boonop kan 'n **gebruiker** 'n **lid** van **verskillende organisasies** wees. Binne die organisasie kan die gebruiker **verskillende toestemmings oor elke repository** hê.

'n Gebruiker kan ook **deel wees van verskillende spanne** met verskillende toestemmings oor verskillende repos.

En uiteindelik **kan repositories spesiale beskermingsmeganismes hê**.

## Toestemmings

### Organisasies

Wanneer 'n **organisasie geskep word** word 'n span genaamd **Eienaars** **geskep** en die gebruiker word daarin geplaas. Hierdie span sal **admin toegang** oor die **organisasie** gee, daardie **toestemmings** en die **naam** van die span **kan nie gewysig word** nie.

**Org admins** (eienaars) kan die **sigbaarheid** van die organisasie kies:

- Publiek
- Beperk (slegs ingelogde gebruikers)
- Privaat (slegs lede)

**Org admins** kan ook aandui of die **repo admins** **toegang kan voeg of verwyder** vir spanne. Hulle kan ook die maksimum aantal repos aandui.

Wanneer 'n nuwe span geskep word, word verskeie belangrike instellings gekies:

- Dit word aangedui watter **repos van die org die lede van die span toegang sal hê**: spesifieke repos (repos waar die span bygevoeg is) of almal.
- Dit word ook aangedui **of lede nuwe repos kan skep** (die skepper sal admin toegang tot dit kry)
- Die **toestemmings** wat die **lede** van die repo **sal hê**:
- **Administrateur** toegang
- **Spesifieke** toegang:

![](<../../images/image (118).png>)

### Spanne & Gebruikers

In 'n repo kan die **org admin** en die **repo admins** (indien toegelaat deur die org) die **rolle** wat aan samewerkers (ander gebruikers) en spanne gegee word, **bestuur**. Daar is **3** moontlike **rolle**:

- Administrateur
- Skryf
- Lees

## Gitea Verifikasie

### Webtoegang

Gebruik **gebruikersnaam + wagwoord** en moontlik (en aanbeveel) 'n 2FA.

### **SSH Sleutels**

Jy kan jou rekening met een of verskeie publieke sleutels konfigureer wat die verwante **private sleutel toelaat om aksies namens jou uit te voer.** [http://localhost:3000/user/settings/keys](http://localhost:3000/user/settings/keys)

#### **GPG Sleutels**

Jy **kan nie die gebruiker met hierdie sleutels naboots nie** maar as jy dit nie gebruik nie, kan dit moontlik wees dat jy **ontdek word vir die stuur van verbintenisse sonder 'n handtekening**.

### **Persoonlike Toegangstokens**

Jy kan 'n persoonlike toegangstoken genereer om **'n toepassing toegang tot jou rekening te gee**. 'n Persoonlike toegangstoken gee volle toegang oor jou rekening: [http://localhost:3000/user/settings/applications](http://localhost:3000/user/settings/applications)

### Oauth Toepassings

Net soos persoonlike toegangstokens **Oauth toepassings** sal **volledige toegang** oor jou rekening en die plekke waar jou rekening toegang het hê, omdat, soos in die [docs](https://docs.gitea.io/en-us/oauth2-provider/#scopes) aangedui, scopes nog nie ondersteun word nie:

![](<../../images/image (194).png>)

### Ontplooi sleutels

Ontplooi sleutels kan lees-slegs of skryf toegang tot die repo hê, so hulle kan interessant wees om spesifieke repos te kompromitteer.

## Takbeskermings

Takbeskermings is ontwerp om **nie volledige beheer van 'n repository aan die gebruikers te gee** nie. Die doel is om **verskeie beskermingsmetodes te plaas voordat jy in staat is om kode binne 'n tak te skryf**.

Die **takbeskermings van 'n repository** kan gevind word in _https://localhost:3000/\<orgname>/\<reponame>/settings/branches_

> [!NOTE]
> Dit is **nie moontlik om 'n takbeskerming op organisasievlak in te stel** nie. So al hulle moet op elke repo verklaar word.

Verskillende beskermings kan op 'n tak toegepas word (soos op master):

- **Deaktiveer Push**: Niemand kan na hierdie tak push nie
- **Aktiveer Push**: Enigeen met toegang kan push, maar nie force push nie.
- **Whitelist Beperkte Push**: Slegs geselekteerde gebruikers/spanne kan na hierdie tak push (maar geen force push nie)
- **Aktiveer Merge Whitelist**: Slegs whitelisted gebruikers/spanne kan PRs saamvoeg.
- **Aktiveer Status kontroles:** Vereis dat status kontroles slaag voordat saamgevoeg word.
- **Vereis goedkeuringe**: Dui die aantal goedkeuringe aan wat vereis word voordat 'n PR saamgevoeg kan word.
- **Beperk goedkeuringe tot whitelisted**: Dui gebruikers/spanne aan wat PRs kan goedkeur.
- **Blokkeer saamvoeg op verwerkte hersienings**: As veranderinge aangevra word, kan dit nie saamgevoeg word nie (selfs as die ander kontroles slaag)
- **Blokkeer saamvoeg op amptelike hersieningsversoeke**: As daar amptelike hersieningsversoeke is, kan dit nie saamgevoeg word nie
- **Verwerp verouderde goedkeuringe**: Wanneer nuwe verbintenisse gemaak word, sal ou goedkeuringe verwerp word.
- **Vereis Onderteken Verbintenisse**: Verbintenisse moet onderteken wees.
- **Blokkeer saamvoeg as die trekversoek verouderd is**
- **Beskermde/Onbeskermde lêerpatrone**: Dui patrone van lêers aan om teen veranderinge te beskerm/onbeskerm.

> [!NOTE]
> Soos jy kan sien, selfs al het jy daarin geslaag om 'n paar akrediteerbare inligting van 'n gebruiker te verkry, **kan repos beskerm wees wat jou verhinder om kode na master te push** byvoorbeeld om die CI/CD-pyplyn te kompromitteer.

{{#include ../../banners/hacktricks-training.md}}
