# Code owners for hmailserver/hmailserver, in GitLab's CODEOWNERS format
# (https://docs.gitlab.com/user/project/codeowners/).
#
# GitLab reads this file from the root, docs/ or .gitlab/; it is here. Code
# Owners is a GitLab Premium and Ultimate feature: on the Free tier GitLab does
# not use the file at all, and on a paid tier it names who is asked to review a
# merge request and gates the merge only when master's protected-branch rule
# turns on "Require approval from code owners". The group hmailserver has
# Ultimate's features through GitLab for Open Source, so GitLab uses this file.
#
# The owner below is @Progressiverobot, the maintainer's GitLab account. The
# project is in the group hmailserver (gitlab.com/hmailserver/hmailserver since
# 29 September 2026; the project's API answer gives its namespace's kind as
# "group"), not in that account's personal namespace. GitLab ignores a name here
# that has no access to the project, and only a member with at least the
# Developer role can approve as a code owner. GitLab does not let an author
# approve their own merge request here, nor anyone who added a commit to it,
# the user who rebases it among them (the project's approval settings give
# merge_requests_author_approval as false and
# merge_requests_disable_committers_approval as true), so while one account is
# the only owner, no code owner may approve that account's merge requests, nor
# one it has rebased or added a commit to, and GitLab counts the code-owner rule
# on them as optional: "Require approval from code owners" would hold back none
# of that owner's changes, only a merge request someone else opens that he has
# neither rebased nor added a commit to (a fast-forward merge, the project's
# merge method, needs a rebase once master has moved), which would wait for his
# approval, and it would add no second person's approval to his own. It stays
# off while a second person's approval is left unmet (GOVERNANCE.md, "Review").
# The second maintainer, Zain
# Ul Abidin, is named among the default owners by his GitLab username,
# @zainulabidin1990: he was a member from 24 September 2026 (a Developer from 26
# September 2026, the owner's decision) and since 13 October 2026 holds no role
# in the project (GOVERNANCE.md, "Maintainers"), so GitLab ignores the name;
# only as a member with at least the Developer role could he approve as a code
# owner. The supply-chain paths below stay with @Progressiverobot, who alone
# creates release tags (GOVERNANCE.md).
#
# Until 18 September 2026 this was .github/CODEOWNERS on GitHub, naming the two
# maintainers' GitHub accounts; the paths are the same.
#
# The LAST matching pattern wins, as in .gitignore, so a later, narrower pattern
# replaces the owners of an earlier one rather than adding to them. A pattern
# that matches nothing is silently ignored, so each path below is one that
# exists in the tree.

# Default owners for everything in the repository.
*                                   @Progressiverobot @zainulabidin1990

# Supply chain and CI. A change here can alter what ships or what is trusted
# without touching a line of server code, so it deserves the same scrutiny as
# the protocol handlers.
/.gitlab/                           @Progressiverobot
/.gitlab-ci.yml                     @Progressiverobot
/.gitlab/CODEOWNERS                 @Progressiverobot
/.gitlab/allowed_signers            @Progressiverobot
# What may pass the release's security gate (build/ci/security-gate.py), and what the
# secret scans take for not a secret: accepting a finding is the owner's.
/.gitlab/security-exceptions.yml    @Progressiverobot
/.gitleaksignore                   @Progressiverobot
/SECURITY.md                        @Progressiverobot
/renovate.json                      @Progressiverobot
/hmailserver/docs/ThirdPartyBinaries.md   @Progressiverobot
/hmailserver/docs/third-party-binaries.json @Progressiverobot

# Where the third-party executables and libraries used to be committed. Since
# 11 September 2026 the build fetches, gathers or copies them instead
# (build/get-installer-binaries.ps1 and hmailserver/docs/third-party-binaries.json,
# both owned in this file); these paths still hold the installer scripts and
# library build scripts that use them.
/libraries/                         @Progressiverobot
/hmailserver/installation/          @Progressiverobot
/hmailserver/source/Tools/Interop/  @Progressiverobot

# Security-relevant server code: TLS, certificate and DANE verification, and
# the crypto helpers that the security policy names as in scope.
/hmailserver/source/Server/Common/TCPIP/        @Progressiverobot
/hmailserver/source/Server/Common/Util/Crypt.cpp @Progressiverobot
/hmailserver/source/Server/Common/Util/Crypt.h  @Progressiverobot
/hmailserver/source/Server/Common/LDAP/         @Progressiverobot

# Release and signing.
/RELEASE.md                         @Progressiverobot
/build/                             @Progressiverobot
