Signed-commit requirement blocks all 10 open PRs, including the build repair

[srpatcha]

master here requires signed commits. No contributor signs. Every open PR is
therefore unmergeable, including the one that repairs the build.

$ gh api repos/embeddedos-org/eBoot/branches/master/protection
sigs=true  reviews=1  checks=null

Verified commit counts on every open PR:

PR	verified commits	author
#55	0/1	tejasmhadgut
#57	0/1	muhammadburhandevv-hub
#58	0/7	Kartikey1306
#59	0/9	Kartikey1306
#61	0/1	Harshit-Vashisth
#62	0/2	JoaoMorais03
#63	0/1	swayam-2003
#64	0/1	ShrenikMensinkai
#65	1/3	Jayakrishnan9539
#67	0/8	srpatcha

Nine of ten have zero verified commits. #65 has one of three, which still fails —
the rule applies per commit.

Why this is urgent rather than tidy

#58 repairs the eos_crc32 conflicting-types failure that stops master from
building. It cannot merge. So the repository cannot be fixed without either
changing the policy or rewriting a contributor's commits for them.

Everything else queues behind it, including #67, which branches from #58 for
exactly that reason.

The policy is also not doing what it looks like it does

Only eBoot and eNI set it:

eBoot        sigs=true   reviews=1  checks=null
eNI          sigs=true   reviews=1  checks=null
eos          sigs=false  reviews=1  checks=null
ebuild       sigs=false  reviews=1  checks=null
EoSim        sigs=false  reviews=1  checks=null
EoStudio     sigs=false  reviews=1  checks=null
eFirmware    <branch not protected>
eCAD         <no protection>

A signing requirement on two repositories out of nine does not establish
provenance for the platform. It stops contributions to those two. An attacker
targeting the boot chain would go through eos or ebuild, which have no such
requirement and whose output eBoot loads.

Note checks=null everywhere: no repository in the organisation has a required
status check. Nothing verifies that a merge result builds before it becomes the
default branch. That is the gap that actually let broken code onto master here
and in eos (see eos#92), and it is unaddressed while signing is enforced on two
repos.

Options

1. Turn signing off here and in eNI. Consistent with the other seven repos,
   unblocks all ten PRs immediately. Provenance for release artifacts is then
   handled where it belongs — signed tags and signed .efw images, which is a
   supply-chain control over what ships, not over who typed what.

2. Keep it and require it everywhere. Defensible, but it needs contributor
   documentation, and it means no external contribution merges anywhere until
   each author configures signing. Nine PRs from eight different people are
   currently affected in this repo alone.

3. Keep it and have a maintainer re-sign contributor commits. Unblocks
   things, but the signature then attests to the maintainer, not the author,
   which is the opposite of what the control is for.

My recommendation is 1, paired with adding the required status check that
checks=null shows is missing — that is the control that would have caught the
build breakages, and it is the one no repository has.

This needs an owner decision; I have not changed any setting.

[srpatcha]

Resolved — master now reports sigs=false:

eBoot    checks=null reviews=1 sigs=false
ebuild   checks=null reviews=1 sigs=false
eos      checks=null reviews=1 sigs=false

All three repositories are now consistent, which was option 1 in this issue. The
effect is immediate: #64 and #69 have merged, and the rest of the queue is
blocked on review or conflicts rather than on a signature nobody could produce.

Two things that were raised here are not resolved, and I would rather they
did not close silently with this:

required_status_checks is still null on all three. Nothing builds or
imports the merge result before it becomes master. That is the gap that let
non-compiling code land in eos (#92 there) and an unparseable dispatch.py land
in ebuild (#87 there) — both now repaired, both able to recur tomorrow. Marking
the existing workflow required is the durable fix and costs nothing now that the
builds are green.

Release-artifact provenance. Turning off commit signing is the right call for
contributions, but it was doing something, and dropping it leaves nothing in
its place. Signed tags and signed .efw images are the control that actually
matters for a boot chain — they attest to what ships rather than to who typed it
— and neither exists yet. eBoot#66 pins the .efw wire format; signing it is a
separate piece of work that is now unowned.

Closing this as the policy question is settled. The status-check gap is the one
worth picking up next.