# Основна інформація про Gitea

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

## Основна структура

Основна структура середовища Gitea полягає в групуванні репозиторіїв за **організаціями**, кожна з яких може містити **кілька репозиторіїв** та **кілька команд**. Однак, зверніть увагу, що, як і в GitHub, користувачі можуть мати репозиторії поза організацією.

Більше того, **користувач** може бути **членом** **різних організацій**. У межах організації користувач може мати **різні дозволи на кожен репозиторій**.

Користувач також може бути **частиною різних команд** з різними дозволами на різні репозиторії.

І нарешті, **репозиторії можуть мати спеціальні механізми захисту**.

## Дозволи

### Організації

Коли **організація створюється**, команда під назвою **Власники** є **створеною**, і користувач потрапляє до неї. Ця команда надасть **адміністративний доступ** до **організації**, ці **дозволи** та **назва** команди **не можуть бути змінені**.

**Адміністратори організації** (власники) можуть вибрати **видимість** організації:

- Публічна
- Обмежена (тільки для авторизованих користувачів)
- Приватна (тільки для членів)

**Адміністратори організації** також можуть вказати, чи можуть **адміністратори репозиторіїв** **додавати або видаляти доступ** для команд. Вони також можуть вказати максимальну кількість репозиторіїв.

При створенні нової команди вибираються кілька важливих налаштувань:

- Вказується, до яких **репозиторіїв організації члени команди зможуть отримати доступ**: конкретні репозиторії (репозиторії, до яких додана команда) або всі.
- Також вказується, **чи можуть члени створювати нові репозиторії** (творець отримає адміністративний доступ до нього).
- **Дозволи**, які **матимуть** **члени** репозиторію:
- **Адміністративний** доступ
- **Специфічний** доступ:

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

### Команди та користувачі

У репозиторії **адміністратор організації** та **адміністратори репозиторіїв** (якщо це дозволено організацією) можуть **керувати ролями**, наданими співпрацівникам (іншим користувачам) та командам. Є **3** можливі **ролі**:

- Адміністратор
- Запис
- Читання

## Аутентифікація Gitea

### Веб-доступ

Використовуючи **ім'я користувача + пароль** і потенційно (і рекомендовано) 2FA.

### **SSH ключі**

Ви можете налаштувати свій обліковий запис з одним або кількома публічними ключами, що дозволяє відповідному **приватному ключу виконувати дії від вашого імені.** [http://localhost:3000/user/settings/keys](http://localhost:3000/user/settings/keys)

#### **GPG ключі**

Ви **не можете видавати себе за користувача з цими ключами**, але якщо ви їх не використовуєте, може бути можливим, що ви **будете виявлені за відправку комітів без підпису**.

### **Особисті токени доступу**

Ви можете згенерувати особистий токен доступу, щоб **надати додатку доступ до вашого облікового запису**. Особистий токен доступу надає повний доступ до вашого облікового запису: [http://localhost:3000/user/settings/applications](http://localhost:3000/user/settings/applications)

### Додатки Oauth

Так само, як і особисті токени доступу, **додатки Oauth** матимуть **повний доступ** до вашого облікового запису та місць, до яких має доступ ваш обліковий запис, оскільки, як зазначено в [документації](https://docs.gitea.io/en-us/oauth2-provider/#scopes), області ще не підтримуються:

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

### Ключі для розгортання

Ключі для розгортання можуть мати доступ лише для читання або запису до репозиторію, тому вони можуть бути цікавими для компрометації конкретних репозиторіїв.

## Захист гілок

Захист гілок призначений для **не надання повного контролю над репозиторієм** користувачам. Мета полягає в тому, щоб **встановити кілька методів захисту перед тим, як можна буде писати код у деяку гілку**.

**Захист гілок репозиторію** можна знайти за адресою _https://localhost:3000/\<orgname>/\<reponame>/settings/branches_

> [!NOTE]
> **Неможливо встановити захист гілки на рівні організації**. Тому всі вони повинні бути оголошені в кожному репозиторії.

Різні захисти можуть бути застосовані до гілки (наприклад, до master):

- **Вимкнути Push**: Ніхто не може відправити дані в цю гілку
- **Увімкнути Push**: Будь-хто з доступом може відправити дані, але не може примусово відправити.
- **Список дозволених обмежених Push**: Тільки вибрані користувачі/команди можуть відправити дані в цю гілку (але без примусового відправлення)
- **Увімкнути список дозволених для злиття**: Тільки користувачі/команди зі списку дозволених можуть зливати PR.
- **Увімкнути перевірки статусу:** Вимагати, щоб перевірки статусу пройшли перед злиттям.
- **Вимагати схвалення**: Вказати кількість схвалень, необхідних перед злиттям PR.
- **Обмежити схвалення для списку дозволених**: Вказати користувачів/команди, які можуть схвалювати PR.
- **Блокувати злиття на основі відхилених оглядів**: Якщо запитуються зміни, його не можна зливати (навіть якщо інші перевірки проходять)
- **Блокувати злиття на основі офіційних запитів на огляд**: Якщо є офіційні запити на огляд, його не можна зливати
- **Скасувати застарілі схвалення**: Коли є нові коміти, старі схвалення будуть скасовані.
- **Вимагати підписаних комітів**: Коміти повинні бути підписані.
- **Блокувати злиття, якщо запит на злиття застарілий**
- **Захищені/незахищені шаблони файлів**: Вказати шаблони файлів для захисту/незахисту від змін

> [!NOTE]
> Як ви можете бачити, навіть якщо вам вдалося отримати деякі облікові дані користувача, **репозиторії можуть бути захищені, що заважає вам відправляти код у master**, наприклад, для компрометації CI/CD конвеєра.

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