gate: the PKCS#1 arm of github_app key parsing loses all coverage on OpenSSL 3.x — the fixture-generation step asserts a toolchain default #8

scripts/gate.sh fails at the workspace unit + integration arm on this host, and the interesting part is not the failure — it is that the failure removes coverage from the exact regression the test was written to prevent, while reporting itself as an openssl problem.

Verified at 0bac65b in a clean worktree (isolated build tree, siblings pinned to the versions Cargo.lock names).

The failure

---- refresh_adapters::github_app::tests::both_pem_containers_parse_because_github_issues_the_one_openssl_does_not_default_to ----
panicked at crates/credentials-core/src/refresh_adapters/github_app.rs:512:9:
openssl genrsa should emit PKCS#1; got: -----BEGIN PRIVATE KEY-----
test result: FAILED. 282 passed; 1 failed

Mechanism

The test builds its PKCS#1 fixture by shelling out to openssl genrsa 2048 (github_app.rs:507-511), then asserts the container at :512-516 before the parser is reached.

On OpenSSL 3.x genrsa emits PKCS#8. Measured here:

$ openssl version
OpenSSL 3.6.3 9 Jun 2026
$ openssl genrsa 2048 | head -1
-----BEGIN PRIVATE KEY-----
$ openssl genrsa -traditional 2048 | head -1
-----BEGIN RSA PRIVATE KEY-----

-traditional was added in OpenSSL 3.0 precisely because the default changed. So the assertion at :512 is a statement about the local toolchain, not about the code under test.

Why this is worse than one red arm

private_key_der_from_pem is correct — both arms are present (github_app.rs:301-304) and both dispatch (:87-88). Nothing in production is broken. The problem is what stops being checked.

The PKCS#1 arm's only coverage is this test, and it dies at :512 — three lines before private_key_der_from_pem is first called. The vendored fixture cannot cover the gap:

$ head -1 crates/credentials-core/tests/fixtures/github_app/test_private_key.pem
-----BEGIN PRIVATE KEY-----     # PKCS#8

So on any OpenSSL 3.x machine, the PKCS#1 path — the format GitHub actually issues from an App's settings page — has zero coverage. Per this test's own doc comment (:497-501), a PKCS#8-only parser is what caused "21 deposited App keys all failed with a decode error before any HTTP call." That regression could return on an OpenSSL 3.x box and this suite would report a red arm blaming openssl, not a coverage hole.

The docstring at :494-495 states the intent exactly, and the test is caught by the inverse of its own rule:

The key format GitHub ACTUALLY issues must sign, not merely the one our fixtures were generated with.

The fixture-generation step is itself toolchain-dependent.

Disposition ask

1. ["genrsa", "-traditional", "2048"] fixes the arm in one flag — but it keeps the fixture dependent on the local openssl, which is what broke. Would you rather vendor a PKCS#1 golden fixture alongside the existing PKCS#8 one, so the property is asserted against bytes in the repo and the test stops shelling out? That is the pattern this repo already chose for data_home (vendored golden fixture + assert), and the reasoning transfers.
2. If the shell-out stays, is it worth asserting the container of BOTH generated keys, so a future default flip on genpkey fails loudly rather than silently re-testing PKCS#8 twice?
3. Does CI pin an openssl version? If CI runs a 1.x image it is green today and would go red on an image bump, with the PKCS#1 arm having been the only thing covering the 21-key regression in the meantime.

Scope note

Not a blocker for anything deployed here: this host holds no github_app: credential, so the adapter is not exercised. Reported because the coverage consequence outlives the red arm.