Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Consider hard-coding git{lab,hut} ssh keys instead of determining them at runtime #43

Open
tlater-famedly opened this issue Jan 23, 2025 · 0 comments

Comments

@tlater-famedly
Copy link
Contributor

tlater-famedly commented Jan 23, 2025

Currently we use ssh-keyscan at runtime to make ssh not bother us about ssh keys.

This is technically not safe, since the ssh security model inherently relies on us receiving those ssh keys from a known-good point; TOFU is considered acceptable for general use, since MITM attacks are not that common and if they occur you will find out eventually, which is why ssh-keyscan exists.

In this case, however, because our keys do not persist between runs, we don't TOFU as much as we TOEU. This is much more risky.

The downside of hardcoding the keys is that if they rotate our builds will fail until we update them. That said, assuming key rotations are uncommon enough that this isn't a real burden, it may be a worthwhile trade-off for supply chain security, especially if we start publishing our binaries.

Bonus points if servers use DNSSEC and publish an SSHFP, then we should just use that instead.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant