Repository navigation
ci: import the signing certificate as a named .p12 - #21043
Conversation
The first nightly after #20996 failed at Import signing cert with "SecKeychainItemImport: Unknown format in import": the decoded certificate file had no .p12 extension, and security import infers the format from it. This case now requires a .p12 file and -f pkcs12; the next commit fixes it. Refs cmuxterm-hq#2053. Bead cx-yzoow.
signing-keychain.sh create decoded the certificate into a file without an
extension, and security import refused it ("Unknown format in import"),
which failed Import signing cert in every nightly variant after #20996. The
file is now certificate.p12 in a private directory, the import passes
-f pkcs12, and the decode keeps the trailing newline of the old inline step.
Refs cmuxterm-hq#2053. Bead cx-yzoow.
|
All contributors have signed the CLA ✍️ ✅ |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
|
Correctness review (subagent): approve, no blocking finding.
|
74e9809 to
1f8dfb8
Compare
|
Probably yours: CI failed on
Matched log linesNot re-run automatically: Written by |
|
Agents: |
|
Merge receipt for
Labeled |
* ci: real macOS import test for the signing keychain tool tests/test_signing_keychain_real_import.sh runs the real signing-keychain.sh create, a codesign with the imported identity, and delete on macOS with a throwaway self-signed identity and a random password (no secret), in the new signing-keychain-macos.yml workflow on a fresh runner. The fake-security case alone did not catch the import format failure fixed in #21043. Refs cmuxterm-hq#2053. Bead cx-yzoow. * ci: real import test runs only in CI or by opt-in; push trigger only on main Review findings on #21142. Refs cmuxterm-hq#2053. Bead cx-yzoow. * ci: select the pinned Xcode in the real import job; push on both trunks The macOS-jobs guard requires scripts/select-ci-xcode.sh in every macOS job. Refs cmuxterm-hq#2053. Bead cx-yzoow.
The certificate secret's .p12 carries Apple's Developer ID G2 intermediate, so security import adds it and import-apple-developer-id-intermediates.sh then failed on "already in build.keychain" in every signing job (first main nightly with #21043, run 38857402565). The helper now accepts a certificate that is already in the keychain; its count check still requires both intermediates. Refs cmuxterm-hq#2053. Bead cx-yzoow.
…added (#21143) * ci: accept a Developer ID intermediate that the signing .p12 already added Since a2380e7 / #21043 the .p12 import works (named certificate.p12, -f pkcs12), and it adds the Developer ID G2 intermediate that the certificate carries. Then import-apple-developer-id-intermediates.sh ran security add-certificates for the same certificate, which exits 1 with "already in build.keychain", and every Import signing cert step failed (main nightly run 38857402565 on d16b03c, all 3 arches). add_intermediate now treats only that "already in" result as success; any other add-certificates error still fails. The existing count check still requires both Developer ID intermediates in the keychain. * ci: accept an already-present intermediate only when its SHA-1 matches Review follow-up: "already in" alone is error text. The keychain must hold the exact vendored certificate (SHA-1 fingerprint from openssl, compared with security find-certificate -Z), else the import still fails. The hash list is captured first, so grep -q cannot end security early under pipefail. * ci: require a 40-hex SHA-1 before the fingerprint match, and match it as a fixed string Security review P3 (hq-84).
…added (#21145) * ci: accept a Developer ID intermediate that the signing .p12 already added Since a2380e7 / #21043 the .p12 import works (named certificate.p12, -f pkcs12), and it adds the Developer ID G2 intermediate that the certificate carries. Then import-apple-developer-id-intermediates.sh ran security add-certificates for the same certificate, which exits 1 with "already in build.keychain", and every Import signing cert step failed (main nightly run 38857402565 on d16b03c, all 3 arches). add_intermediate now treats only that "already in" result as success; any other add-certificates error still fails. The existing count check still requires both Developer ID intermediates in the keychain. * ci: accept an already-present intermediate only when its SHA-1 matches Review follow-up: "already in" alone is error text. The keychain must hold the exact vendored certificate (SHA-1 fingerprint from openssl, compared with security find-certificate -Z), else the import still fails. The hash list is captured first, so grep -q cannot end security early under pipefail. * ci: require a 40-hex SHA-1 before the fingerprint match, and match it as a fixed string Security review P3 (hq-84).
Summary
Fix forward for #20996. The first nightly on main after it (https://github.com/manaflow-ai/cmux/actions/runs/38723131700) failed in
Import signing certfor all three variants:scripts/ci/signing-keychain.sh createdecoded the certificate intocertificate.XXXXXX(no extension).security importinfers the format from the file name; the old inline step used/tmp/cert.p12. The file is nowcertificate.p12inside a privatemktemp -ddirectory, the import passes-f pkcs12, and the decode usesprintf '%s\n'like the oldecho. The directory is removed right after the import and again bydelete.The run published nothing (the failure is before any signature).
Testing
tests/test_notarize_nightly_dmg.shnow requires a.p12file and-f pkcs12in thesecurity importcall. First commit: fails. Second commit: passes (Linux VM, fakesecurity).tests/test_ci_self_hosted_guard.shkeychain checks pass.Changelog
none
Summary by cubic
Fixes the nightly CI failure in
Import signing certwheresecurity importcouldn't infer the format of the decoded certificate because it lacked a.p12extension.certificate.p12in a privatemktemp -ddirectory, and the import passes-f pkcs12..p12file name and the explicit format flag.Written for commit 1f8dfb8. Summary will update on new commits.
Summary by CodeRabbit