openSUSE:ALP/Workgroups/Git-Packaging-Workflow/WorkPackages/Reviews

We have a lot of checks, CI, and reviews that happen in a submit requests to Factory. Some of the reviews also happen in other tools and then get forwarded to OBS requests. Maybe some things, at the choice of the package managers, should also happen in a request that submits to a package.

There is a proof of concept tool at https://gitlab.com/source-security/git-verify/ that can notate reviews in git commits secured with cryptographic signatures whose certificates are included in the git repo. That the required reviews happened can then be checked client side on git pull, instead of only remaining in the git hosting service. This extends the reproducible-builds.org idea further into the sources. Thus even if the git hosting service would be compromised, the integrity of the sources would not be. The git hosting service would run this as a CI on merge requests and as a hook to verify pushes of merges. If the build service would also run it to verify before building.

While some reviews could happen as an added commit in the merge request or in the merge, the idea is to also support only referencing external results (of reviews or automated tests). This is both to have compacter history representation, but also easier independent working.

Such external results should come in the form of a signature over the appropriate data, see e.g. the in-toto project. This needs to at least be the git commit ID and any other inputs relevant to the result. For automated tests the results should be reproducible to support independent verification. For human reviews it should be made with their personal key instead of some central servers, but as tools need to be adapted it will take some time for the signing to be pushed further to where the information is created.

Such external results will be sent as a Build Status which is shown on the merge request. When it is time to merge git-verify will fetch each status, follow it to obtain the signature, verify it and include it in the merge. The merge is either done and signed by the last necessary human reviewer or it is done and signed by a bot that produces a reproducible merge.

Some part of this as an example in more detail: To not need human review for results of osc client side services, they would be made reproducible. openSUSE-release-tools is one of the automated tests currently run for Factory, it does some verification at https://github.com/openSUSE/openSUSE-release-tools/blob/205e07a9d442993b842f0d5dcf1dc49d1093b8c5/check_source.py#L536 . This would be extended to verify the output of client side services. openSUSE-release-tools would be made to be reproducible itself and to produce a signature and send its result as a status, for it to end up in the merge of a merge request.

Factory might become a branch of a git repository with the packages being submodules. This will need to be expanded on and explained in https://github.com/aplanas/openSUSE-git/blob/main/notes-about-git.md .