carlos / contra Public

🤖 CI is live on the shared runner and green as of 12b61f4. Getting there took three runs and found two real things; this is the one that is not fixed, only relocated.

What happened

The shared box's python3 is a bare Python 3.12.3 with no pip module and no ensurepip — not a missing package, a missing package manager:

make oracles: this python3 can neither create a venv nor run pip.
  python3: Python 3.12.3
  venv   :
  pip    : /usr/bin/python3: No module named pip

So test/qroracle.py and test/pdforacle.py cannot get numpy, zxing-cpp, qrcode, pillow, pymupdf or pypdf there, by any means the repo controls. The box is immutable-boot, so installing them is a launch-template version and an instance replacement.

What I did, and what it costs

make ci now runs the crypto twin only — crypto, ecies, items — which needs nothing but node. make test-oracles holds qr and kit and is out of CI, for the same reason test-webkit already is, in the Makefile's own words: a gate that cannot run everywhere is a gate that teaches people to ignore red. Permanently red CI would cost more than defending this check in the wrong place is worth.

This is a downgrade. Labelling it rather than smoothing it over, because the oracles catch a class of fault nothing else does. The reversed format-information bits in the QR encoder were twelve wrong modules that scanned perfectly — a decode-only check calls that a pass. Only drawing the same payload with python-qrcode and comparing matrices module by module found it. That is now a manual step:

make oracles && make test-oracles

before trusting a change to qr.js, qrtables.js, qrgf.js, pdf.js or kit.js. They still fail rather than skip, and a missing package now names the command that fixes it instead of dumping a ModuleNotFoundError.

The fix

One line of python3-pip in the runner's user-data, next to the existing package installs, then revert the split: put qr and kit back in test-js and delete test-oracles. make oracles already handles both a venv and pip --target, so either would then work with no further change.

The alternatives I rejected: vendoring numpy (platform-specific binary wheels, tens of megabytes, in a repo whose whole discipline is that a person can read what is in it), and curling get-pip.py in CI (a bootstrap script fetched from the network and executed, inside the job that builds a password manager — no).

Also found on the way

test/ecies.test.mjs was never in the gate. It was added with the device handoff and never listed in the test-js target, so the six tests pinning the one place a secret crosses the server — Go against JS against the C generator — had never run anywhere but by hand. Now in; make ci's JS suite went from 29 tests to 35, then to 28 when the five oracle tests moved out.

That is the argument for turning CI on, rather than for any particular thing it found: a gate nobody runs is a gate that quietly stops covering things.