Heads needs to change co-maintaining/reviewing/merging policies

[tlaurion]

As of now, there is 4 reviewers per github policies

• @osresearch (founder of project, not active)
• @JonathonHall-Purism (purism)
• @nestire (nitrokey)
• @tlaurion (was Insurgo, not selling hardware anymore); project is currently under funded. I'm basically a volonteer myself)

Recently, the most active contributors are:

• @Tonux599
• @gaspar-ilom

I would suggest to
1- Change github merging policies to have 2 reviewers to unlock merging possibility (so no "king" merger)
2- Add @Tonux599 @gaspar-ilom to reviewers with merge rights (to review what are the rights needed)
3- Review proposed candidates for co-maintainership (Heads is not a full-time paid job for @tlaurion for a while now)
4- Review alternative propositions by community

[Tonux599]

@tlaurion thanks for this. I'm supportive of what you suggest, and I'm happy to review and contribute what I can in my spare time.

[gaspar-ilom]

@tlaurion I think about it. Will let you know...

[gaspar-ilom]

@tlaurion thanks for this. I take this as an appreciation of my contributions and first want to return the favor by saying thank you for all the maintenance work you have done for the project!

I really consider Heads an important project and would like to play my part in keeping it going. However, I have some doubts about how well I will be able to do the maintenance work continuously and promptly. Meaning there might be times where I will contribute very little time. Also, so far I have mostly helped with porting boards or updating coreboot and have worked very littler with the actual Heads payload. I can become familiar with that, though. If these are not an issue, I would be happy to try it out and we can evaluate it after some time.

Let's move on to the not so personal part about this issue. I have a few questions.

• Are there some (review/ commit/ merge/ coding) guidelines that reviews and merge decisions can be based on to ensure consistency between different maintainers?
• How easy should becoming a maintainer be and how can the community hold them accountable if they act maliciously on purpose? I think maintainerships comes with great responsibility as the heads users put a lot of trust into the maintainers, that no malicious code is introduced, critical security bugs etc. Heads is not just any project but for users with a high profile threat model. Things like the XZ Utils backdoor have shown that it is not too far fetched that resourceful attackers might go through the trouble of becoming a co-maintainer of a project. (Of course, the scope of Heads is very different from my example, but still it is worth thinking about it.)
  • This is partially mitigated by requiring two reviews. It should somehow be clarified what exactly to expect from a review, though.
• I would like to hear more feedback from other members of the community. Did you ask about that in matrix? I am currently not in the heads matrix chat room.

Probably more things will come, but I will leave it at this for now.

[tlaurion]

Sorry for lack of updates, been cogiting on this myself. Looking at other repo, while as up now (touching wood) this project has had contributions from amazing people coming and going, while Heads might be a little different of other projects since it's flow is controlled from init to its policy (since ~2018 gui-init) that doesn't permit a lot of place for fuzzing nor input not being cleaned or invalidated by the host program actually using it. Not perfect, but different from other use cases, because of whiptail for TUI and where recovery console access where toolstack being exposed is nothing different then minimal Linux OS it aims to provide without possibility of unsealing TPM secrets.

But. I'm not done reflecting. No, this has not have been publicized much over matrix, but your presence there @gaspar-ilom wiuld be expected, at least so that you can be directly tagged when needed without SLA expectation (you are not paid after all).

[tlaurion]

To be tweaked : perplexity AI proposition I don't dislike

Project Governance and Co-Maintainer Guidelines

Purpose

This document outlines the governance, co-maintainership roles, and policies for the project to ensure transparency, reproducibility, and security in firmware development.

Co-Maintainership Structure

• List of current co-maintainers with GitHub handles and areas of responsibility:
  • e.g. Security and TPM integration: @Maintainer1
  • e.g. Build system and reproducible builds: @maintainer2
  • e.g. Documentation and community engagement: @maintainer3
• Scope of responsibilities and decision-making authority for each area.
• Process for onboarding new maintainers: open nomination, peer endorsement, and community consensus.
• Process for removing or stepping down maintainers.

Contribution Guidelines

• All contributions require peer review and passing reproducible build verification.
• Use automated CI pipelines for testing every pull request, including build reproducibility checks.
• All changes must be documented, including rationale and reproducibility status.
• Encourage detailed issue and pull request descriptions for auditability.

Release and Reproducibility Policy

• Releases are made from CI pipelines with reproducible build artifacts publicly logged.
• All firmware and related artifacts must have publicly verifiable source or build scripts.
• Cryptographic signatures and checksums accompany every release for integrity verification.
• Any binary blobs must be disclosed with detailed provenance and build steps.

Security and Vulnerability Disclosure

• Follow a published SECURITY.md for responsible vulnerability reporting.
• Define embargo periods and public disclosure policies.
• Maintain transparency in security patches and updates with public changelogs.

Decision-Making and Governance

• Decisions on major features or policy changes require public RFCs or discussions.
• Maintain logs of meetings, votes, and major decision rationales.
• Governance may follow consensus or designated technical council leadership.
• Provide clear dispute resolution and escalation paths.

Transparency and Auditability

• All discussions, decisions, and meeting notes should be public.
• Maintain reproducibility and audit logs accessible to the community.
• Regularly update maintainership and governance documents for accuracy.

---

For more details on contributing, see CONTRIBUTING.md.
For code of conduct and community standards, see CODE_OF_CONDUCT.md.

[tlaurion]

@gaspar-ilom @Tonux599 @nestire @JonathonHall-Purism @osresearch need a plan B here. Cannot be "king" forever here. Pressure from CRA compliance timeline(and respondants when AI finds vulns), related, SBOM and bumping modules is unbearable now.

[gaspar-ilom]

@gaspar-ilom @Tonux599 @nestire @JonathonHall-Purism @osresearch need a plan B here. Cannot be "king" forever here. Pressure from CRA compliance timeline(and respondants when AI finds vulns), related, SBOM and bumping modules is unbearable now.

I agree that it would be great to find more maintainers. However, as you may have assumed from the fact that I haven't been active in this project for the entire year so far, it is unrealistic for me right now to contribute a lot of time reliably. Sorry about that. I really appreciate the work you have been putting into Heads @tlaurion !

I can work issues with a limited scope from time to time (like I did in the past: coreboot update, add support for a board, some maintenance and testing work), but I also feel I still do not know the project well enough to make good decisions in many areas.