# Informazioni di Base su Gitea

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

## Struttura di Base

La struttura di base dell'ambiente Gitea è quella di raggruppare i repo per **organizzazione(i),** ognuna delle quali può contenere **diversi repository** e **diversi team.** Tuttavia, nota che proprio come in github, gli utenti possono avere repo al di fuori dell'organizzazione.

Inoltre, un **utente** può essere un **membro** di **diverse organizzazioni**. All'interno dell'organizzazione, l'utente può avere **diverse autorizzazioni su ciascun repository**.

Un utente può anche essere **parte di diversi team** con diverse autorizzazioni su diversi repo.

E infine, **i repository possono avere meccanismi di protezione speciali**.

## Autorizzazioni

### Organizzazioni

Quando un'**organizzazione viene creata**, viene **creato** un team chiamato **Owners** e l'utente viene inserito al suo interno. Questo team darà **accesso admin** sull'**organizzazione**, tali **autorizzazioni** e il **nome** del team **non possono essere modificati**.

**Org admins** (proprietari) possono selezionare la **visibilità** dell'organizzazione:

- Pubblica
- Limitata (solo utenti con accesso)
- Privata (solo membri)

**Org admins** possono anche indicare se gli **admin dei repo** possono **aggiungere o rimuovere accesso** per i team. Possono anche indicare il numero massimo di repo.

Quando si crea un nuovo team, vengono selezionate diverse impostazioni importanti:

- Viene indicato ai **repo dell'org a cui i membri del team potranno accedere**: repo specifici (repo a cui il team è aggiunto) o tutti.
- Viene anche indicato **se i membri possono creare nuovi repo** (il creatore otterrà accesso admin a esso)
- Le **autorizzazioni** che i **membri** del repo **avranno**:
- Accesso **Amministratore**
- Accesso **Specifico**:

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

### Team e Utenti

In un repo, l'**org admin** e gli **admin dei repo** (se consentito dall'org) possono **gestire i ruoli** assegnati ai collaboratori (altri utenti) e ai team. Ci sono **3** possibili **ruoli**:

- Amministratore
- Scrittura
- Lettura

## Autenticazione Gitea

### Accesso Web

Utilizzando **nome utente + password** e potenzialmente (e raccomandato) un 2FA.

### **Chiavi SSH**

Puoi configurare il tuo account con una o più chiavi pubbliche che consentono alla relativa **chiave privata di eseguire azioni per tuo conto.** [http://localhost:3000/user/settings/keys](http://localhost:3000/user/settings/keys)

#### **Chiavi GPG**

Non **puoi impersonare l'utente con queste chiavi**, ma se non le usi potrebbe essere possibile che tu **venga scoperto per aver inviato commit senza una firma**.

### **Token di Accesso Personali**

Puoi generare un token di accesso personale per **dare a un'applicazione accesso al tuo account**. Un token di accesso personale fornisce accesso completo al tuo account: [http://localhost:3000/user/settings/applications](http://localhost:3000/user/settings/applications)

### Applicazioni Oauth

Proprio come i token di accesso personali, le **applicazioni Oauth** avranno **accesso completo** al tuo account e ai luoghi a cui il tuo account ha accesso perché, come indicato nella [documentazione](https://docs.gitea.io/en-us/oauth2-provider/#scopes), gli scope non sono ancora supportati:

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

### Chiavi di Distribuzione

Le chiavi di distribuzione possono avere accesso in sola lettura o scrittura al repo, quindi potrebbero essere interessanti per compromettere repo specifici.

## Protezioni dei Branch

Le protezioni dei branch sono progettate per **non dare il controllo completo di un repository** agli utenti. L'obiettivo è **mettere in atto diversi metodi di protezione prima di poter scrivere codice all'interno di un certo branch**.

Le **protezioni dei branch di un repository** possono essere trovate in _https://localhost:3000/\<orgname>/\<reponame>/settings/branches_

> [!NOTE]
> Non è **possibile impostare una protezione del branch a livello di organizzazione**. Quindi tutte devono essere dichiarate su ciascun repo.

Diverse protezioni possono essere applicate a un branch (come a master):

- **Disabilita Push**: Nessuno può pushare su questo branch
- **Abilita Push**: Chiunque abbia accesso può pushare, ma non forzare il push.
- **Whitelist Restricted Push**: Solo utenti/team selezionati possono pushare su questo branch (ma non forzare il push)
- **Abilita Merge Whitelist**: Solo utenti/team in whitelist possono unire PR.
- **Abilita Controlli di Stato:** Richiedere che i controlli di stato passino prima di unire.
- **Richiedi approvazioni**: Indica il numero di approvazioni richieste prima che una PR possa essere unita.
- **Restrict approvals to whitelisted**: Indica utenti/team che possono approvare PR.
- **Blocca unione su revisioni rifiutate**: Se vengono richiesti cambiamenti, non può essere unita (anche se gli altri controlli passano)
- **Blocca unione su richieste di revisione ufficiali**: Se ci sono richieste di revisione ufficiali non può essere unita
- **Annulla approvazioni obsolete**: Quando ci sono nuovi commit, le vecchie approvazioni saranno annullate.
- **Richiedi Commit Firmati**: I commit devono essere firmati.
- **Blocca unione se la richiesta di pull è obsoleta**
- **Modelli di file protetti/non protetti**: Indica modelli di file da proteggere/non proteggere contro le modifiche

> [!NOTE]
> Come puoi vedere, anche se sei riuscito a ottenere alcune credenziali di un utente, **i repo potrebbero essere protetti impedendoti di pushare codice su master** per esempio per compromettere il pipeline CI/CD.

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