Certificate missing and is not created when running tools/uci/test_https_local.py #93

Activity

1. JC-000 commented on Aug 14, 2026

   

   JC-000

   on Aug 14, 2026

   Owner

   More actions

   Thank you — that is another real gap, and the second one you have found in two
   days after #90 (the unstated c64-test-harness prerequisite). Both are the same
   shape: things that work fine on a machine where they were already set up, and
   fail on a clean checkout. That is exactly the class of bug a maintainer cannot
   find alone, because our clones have all been working for months. Genuinely
   useful — please keep them coming.

   Unblocks you right now, on your existing clone:

   python3 tools/https_e2e/ensure_certs.py
   

   (That file lands with the fix below; until it is merged, the equivalent one-liner
   against current master is
   python3 tools/package/listener/gen_certs.py --out-dir tools/https_e2e/certs.
   Either way you need pip install cryptography.)

   What was actually wrong. You were right that the README claimed
   auto-generation — and interestingly, that claim was half true, which is
   probably why it went unnoticed for so long. tools/https_e2e/https_listener.py
   really does mint the certs on demand, and every test built on it has always
   worked from an empty directory. But tools/uci/test_https_local.py inlines its
   own listener with its own cert paths, so it never went through that code and
   just exited with ERROR: cert/key not found. You found the one script that
   missed the mechanism the README was describing.

   Fixed in #95:

   • tools/uci/test_https_local.py (and the P-384 sibling) now generate the pair
     on demand, so a fresh clone works with no manual step.
   • One generator instead of three: everything routes through
     tools/https_e2e/ensure_certs.py, which delegates to the same
     gen_certs.py the packaged listener uses, so in-tree tests and the shipped
     listener zip mint identical material.
   • Missing cryptography now produces one actionable line instead of a
     traceback.
   • The certs README is rewritten to describe what actually happens, starting with
     "this directory is empty in a fresh clone, that's fine" — since an empty
     directory looking broken is the thing that cost you the time.
   • The certs stay gitignored. They are throwaway self-signed test material and
     shipping them in the repo would be the wrong fix.

   One more thing your report surfaced: ERROR: PRG not found fires before the
   cert check in that same script and also named no fix, so you would likely have
   hit that next. Six tools/uci/ scripts now say Run: make BACKEND=uci there,
   matching the two that already did.
2. JC-000

   added 2 commits that reference this issue on Aug 14, 2026

   wip: shared helper to generate the gitignored test certs on demand (#93)

   ...

   ffbd34e

   fix(tests): generate the gitignored test certs on demand (#93)

   ...

   07d668c
3. JC-000 commented on Aug 14, 2026

   

   JC-000

   on Aug 14, 2026

   Owner

   More actions

   Small correction to my comment above, since master moved underneath it.

   I said the unblock command needs pip install cryptography. It no longer
   does. A separate change (#96, release packaging) reimplemented cert generation
   in pure Python — no pip, no venv, standard library only — and the fix for this
   issue now rides on that for both cert profiles. So on current master, this is
   the whole thing:

   python3 tools/package/listener/gen_certs.py --out-dir tools/https_e2e/certs
   

   and once #95 lands, equivalently:

   python3 tools/https_e2e/ensure_certs.py
   

   No dependencies either way.
4. JC-000

   closed this as completedin #95on Aug 14, 2026
5. JC-000

   added a commit that references this issue on Aug 14, 2026

   Merge pull request #95 from JC-000/fix/autogen-test-certs-impl

   ...

   d2e82a0