Update SPM and CI setup to fetch the private WordPress-rs repo

[mokagio]

Builds on top of #23412.

[dangermattic]

	1 Warning
⚠️	Modules/Package.swift was changed without updating its corresponding Package.resolved. Please resolve the Swift packages in Xcode.

Generated by 🚫 Danger

[wpmobilebot]

📲 You can test the changes from this Pull Request in WordPress Alpha by scanning the QR code below to install the corresponding build.

	App Name	WordPress Alpha
	Configuration	Release-Alpha
	Build Number	pr23424-c895955
	Version	25.1
	Bundle ID	org.wordpress.alpha
	Commit	c895955
	App Center Build	WPiOS - One-Offs #10304

Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

[wpmobilebot]

📲 You can test the changes from this Pull Request in Jetpack Alpha by scanning the QR code below to install the corresponding build.

	App Name	Jetpack Alpha
	Configuration	Release-Alpha
	Build Number	pr23424-c895955
	Version	25.1
	Bundle ID	com.jetpack.alpha
	Commit	c895955
	App Center Build	jetpack-installable-builds #9350

Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

[mokagio]

This is tidied up version of what Pocket Casts iOS does, too.

See Automattic/a8c-ci-toolkit-buildkite-plugin#102 to track the possibility of DRYing at the CI plugin level.

[mokagio]

SwiftLint picked this and the ones below in CI, so I addressed them because I like the look of a green build 🤓

[AliSoftware]

We might want to discuss the security aspect of this approach 🤔 Maybe this is OK but still wanted to open the debate.

This means that if one of our non-trusted agent got compromised, anyone could get access to this bot private key and do stuff with it. I don't know which of our bots this private SSH you used belongs to, and thus which permissions it has, but if that key also has eg push/write access, that could be quite problematic.

This is exactly why, for the case of CI commands that require push access (eg when we need to du version bumps for Release-on-CI) we developed our secure approach of only running those git push operations on one of our trusted agents and only store the bot private key on those agents (instead of via secrets installed on all agents), to ensure the key is never accessible to non-trusted agents. See paaHJt-6EP-p2 for more details.

---

If the bot SSH key you're using here only has read only access to private repos and doesn't have write permissions (to git push nor comment or open/close issues/PR etc) then we might still be ok with that approach. But if it has too much permissions we might want to be wary of the security implications (even if our CI agents are not really accessible to an external actor as we have other protections in place, for these kind of things better add more layers of security in case one gets compromised)

Wdyt?

[AliSoftware]

If I'm not mistaken, technically speaking this doesn't change the SSH key (as in: replacing it) but adds it to the agent? (Meaning SSH will still try other keys in the agent if the first one(s) it tries fails?)

[jkmassel]

It changes GIT_SSH_COMMAND so I think it's an accurate comment

[AliSoftware]

Ah, right 👍

I think I conflated the use of -i alone (which would add the identity but, if used alone, still let ssh try other identities registered in the agent or the config file) with when -i is used in association with -o IdentitiesOnly=yes (like here) to ask the ssh-agent not to offer any keys, and only use the keys provided by -i on the command line, or by the config files.

To be even stricter we should also add -F /dev/null to also tell ssh not to use any keys configured in the config file either, to be sure that the only key it will proposed is the one provided via -i and not try any other key boforehand; but in the case of CI and how Buildkite works wrt to exposing keys to SSH, I don't think any Identity would be configured in the ~/.ssh/config of our agents and risk being used and tried before the bot's private key provided here… so ultimately -F /dev/null would probably unnecessary in this context.

[jkmassel]

@AliSoftware – great points all around, and as a rule I'd agree.

In this narrow case it's fine because it's going to be an open-source project in a month or two anyway, at which point we'll remove this.

Thanks for contributing to a strong security posture with this!

[AliSoftware]

Btw, instead of using the SSH key of one of our bot account, couldn't we create a read-only deploy key on wordpress-rs and use that instead?

Deploy Keys are limited to the repo they are declared on, and for SPM cloning we only need read-only, so that seems ideal for the use case we have here, and way safer than using a bot's private SSH key which will have write access to many repos…

(And even if there happen to be multiple private repos that SPM needs to reach at some point (which isn't the case for WPiOS here but could be for other projects on which @mokagio have started to use that approach too already), I think we can just create one deploy key for each, and then either use insteadOf with more specific URL prefixes than just the host (one for each repo to rewrite), or alternatively use the same generic insteadOf that is used in this PR but then ssh-agent add each of the read-only deploy keys to the agent, or provide them all thru multiple -i options, so that SSH will try each key in turn on each of the requests until it finds the one that is accepted.)

[mokagio]

@jkmassel @AliSoftware thank you for the suggestions and for merging at the same time. I like the iterative approach. Make it work, make it right, make it fast...

As a followup I:

• Switched to a read-only deploy key defined in the WordPress-rs repo
• Updated the script name and implementation to make it clear the setup up is only for that particular repo Remove redundant add_host_to_ssh_known_hosts command #23427
• Removed the SSH key swap from Pocket Casts iOS, because it's no longer needed there Remove private key swap for private repos — No longer needed Automattic/pocket-casts-ios#1919

Remaining things I haven't yet done because I need to hop offline:

• Cleanup: Delete the ad hoc SSH key I created for this from wpmobilebot and from mobile-secrets
• Drop a note about what other projects are doing with PTA instead of keys and why (for clarity)