fastlane writes certificates into the user's keychain as a side effect of parsing a provisioning profile

fastlane adds certificates to the user's keychain as a side effect of parsing a provisioning profile. Nothing asks it to; it falls out of how the profile is decoded.

security cms -D is used to decode provisioning profiles in verify_build.rb, provisioning_profile.rb and sigh's local_manage.rb. To verify the signature it imports the signing certificate, and that import lands in whichever keychain is default. Nothing calls security import anywhere near this.

The behaviour was isolated while running the spec suite against a home directory the run controls:

security cms -D   real home                  exit 0
                  isolated home, no keychain exit 1, "cert import failed: A default keychain could not be found"
                  isolated home, EMPTY one   exit 0

Any keychain will do, including an empty one, which is what shows the import is incidental to decoding rather than something the caller wanted.

What it costs

A full spec run puts four certificates into the developer's default keychain, three from two match examples and one from verify_build. Measured again on 2026-09-16 across match/spec, fastlane_core/spec/cert_checker_spec.rb and fastlane/spec/actions_specs/create_keychain_spec.rb — 241 examples — the suite makes 45 real /usr/bin/security calls, 19 of them cms.

For a contributor that means running the tests writes to their login keychain. For a user of fastlane it means parsing a profile does, which is the part worth deciding on.

There is already a mechanism

provisioning_profile.rb has a -k <keychain_path> variant of the call, so the import can be directed somewhere chosen rather than at the default keychain.

Note for anyone looking at the specs

Nine examples fail against an isolated home with no keychain, seven in verify_build_spec and two in match/spec/importer_spec, all with a keychain complaint. The obvious reading is that those specs reach into the developer's keychain and should be stubbed. They should not: they are exercising real decoding, and stubbing them would remove real coverage. Seeding an empty keychain in the isolated home is the fix on the test side, and it is separate from the question above.