Basic Gitea Information

支持 HackTricks

基本结构

基本的 Gitea 环境结构是通过 组织 来分组仓库,每个组织可以包含 多个仓库多个团队。但是,请注意,正如在 GitHub 中,用户可以在组织外拥有仓库。

此外,用户 可以是 不同组织的成员。在组织内,用户可能对每个仓库拥有 不同的权限

用户也可以是 不同团队的一部分,对不同仓库拥有不同的权限。

最后,仓库可能具有特殊的保护机制

权限

组织

组织被创建 时,会创建一个名为 Owners 的团队,并将用户放入其中。该团队将提供对 组织管理员访问,这些 权限 和团队的 名称 无法修改

组织管理员(所有者)可以选择组织的 可见性

  • 公开

  • 限制(仅限登录用户)

  • 私有(仅限成员)

组织管理员 还可以指示 仓库管理员 是否可以 添加或移除 团队的访问权限。他们还可以指示最大仓库数量。

创建新团队时,会选择几个重要设置:

  • 指定 团队成员可以访问的组织仓库:特定仓库(团队被添加的仓库)或所有仓库。

  • 还指示 成员是否可以创建新仓库(创建者将获得管理员访问权限)

  • 成员 在仓库中将 拥有的权限

  • 管理员 访问

  • 特定 访问:

团队与用户

在仓库中,组织管理员仓库管理员(如果组织允许)可以 管理 分配给合作者(其他用户)和团队的角色。可能的 角色3 种:

  • 管理员

  • 写入

  • 读取

Gitea 认证

网络访问

使用 用户名 + 密码,并可能(推荐)使用 2FA。

SSH 密钥

您可以使用一个或多个公钥配置您的帐户,允许相关的 私钥代表您执行操作http://localhost:3000/user/settings/keys

GPG 密钥

无法使用这些密钥冒充用户,但如果您不使用它,可能会因为 发送未签名的提交而被发现

个人访问令牌

您可以生成个人访问令牌,以 授予应用程序访问您的帐户。个人访问令牌对您的帐户具有完全访问权限:http://localhost:3000/user/settings/applications

Oauth 应用程序

与个人访问令牌一样,Oauth 应用程序 将对您的帐户及其访问的地方具有 完全访问权限,因为如 文档 所示,范围尚不支持:

部署密钥

部署密钥可能对仓库具有只读或写入访问权限,因此它们可能对特定仓库的妥协很有趣。

分支保护

分支保护旨在 不将仓库的完全控制权授予用户。目标是在能够在某些分支中写入代码之前 设置几种保护方法

仓库的分支保护 可以在 https://localhost:3000/<orgname>/<reponame>/settings/branches 中找到。

无法在组织级别设置分支保护。因此,所有保护必须在每个仓库中声明。

可以对分支(例如主分支)应用不同的保护:

  • 禁用推送:无人可以推送到此分支

  • 启用推送:任何有访问权限的人都可以推送,但不能强制推送。

  • 白名单限制推送:只有选定的用户/团队可以推送到此分支(但不能强制推送)

  • 启用合并白名单:只有白名单中的用户/团队可以合并 PR。

  • 启用状态检查:要求状态检查在合并之前通过。

  • 要求批准:指示在 PR 可以合并之前所需的批准数量。

  • 限制批准给白名单:指示可以批准 PR 的用户/团队。

  • 在拒绝审查时阻止合并:如果请求更改,则无法合并(即使其他检查通过)

  • 在官方审查请求时阻止合并:如果有官方审查请求,则无法合并

  • 撤销过期的批准:当有新提交时,旧的批准将被撤销。

  • 要求签名提交:提交必须签名。

  • 如果拉取请求过时则阻止合并

  • 受保护/不受保护的文件模式:指示要保护/不保护的文件模式

正如您所看到的,即使您设法获得了用户的一些凭据,仓库可能受到保护,避免您将代码推送到主分支,例如,以妥协 CI/CD 管道。

支持 HackTricks

Last updated