Automated Build Process
The following graph shows what happens between a PKGBUILD getting changed in git and the built package being available in the pacman repo.
sequenceDiagram participant GIT as MSYS2/<br>MINGW-packages participant API as packages.msys2.org participant GHA as GitHub Actions participant DT as msys2-autobuild participant DEV as Developer participant REPO as Pacman Repo GIT->>GHA: GIT push trigger GHA->>GHA: parse PKGBUILDs GHA-->>GIT: upload parsed PKGBUILDs loop Every 5 minutes API->>GIT: fetch parsed PKGBUILDs GIT-->>API: end loop Every 2 hours DT->>GHA: cron trigger GHA->>API: fetch TODO list API-->>GHA: GHA->>GIT: fetch PKGBUILDs GIT-->>GHA: GHA->>DT: fetch staging DT-->>GHA: GHA->>GHA: build packages GHA-->>DT: upload packages end DEV->>DT: fetch packages DT-->>DEV: DEV->>DEV: sign packages DEV->>REPO: push to repo Security Considerations
Assuming changes to PKGBUILDs are properly reviewed, the pacman signature checking works, the upstream source is OK and all MSYS2 organization members are trusted we need to consider a bad actor controlling some part of the building process between the PKGBUILD getting changed and the package ending up signed in the pacman repo.
A bad actor would need to get a package on the machine of the developer signing the package and adding it to the pacman repo. We take the following precautions:
- We only build packages automatically with GitHub Actions without third party actions, excluding the official GitHub ones. We assume the GHA images and official actions are safe.
- The download tool used by the person signing the package checks that the binaries where uploaded by a restricted set of GitHub users or GHA. We assume the bad actor doesn't have git push rights.
- Packages too large for GHA get built/signed by MSYS2 developers on their machines. We assume the developer machines are safe.
- We enforce 2FA for the MSYS2 organization to make account takeovers of existing MSYS2 developers harder.
Feedback and ideas on how to improve this welcome.