Hacker News Reader

Comment by jgaa | Hacker News Reader

I really don't understand why you use someones else's computer to compile and test your stuff.

When their computers are compromised, by internal or external crooks, the crooks have full access to your code, and - in some cases - your data. If they wanted, they could inject their own shit into your binaries, totally ruining your reputation.

As a bonus, you get to pay a premium!

I still compile and test my code on my own machines, in my own network. It's much faster than CircleCI, cheaper, and it's ∞ safer.

View on HN

You do need to trust someone else’s computer if they’re going to build and run your code. I think Google is doing some good work here in helping champion things like Supply-chain Levels for Software Artifacts (SLSA) [0][1]. I’d argue your build/CI/CD system should never have access to production data, but it would indirectly by being able to mutate your production environment (to deploy things). Compiling and testing on your own machine it’s necessarily safer though. Compare a typical CI/CD build instance which is usually a VM or container that has been freshly booted, or is being reused from a recent build, with your own machine that you likely also use to browse the internet and run many other apps. The (ideal of the) former is a reproducible on-demand environment with a specific toolchain, while the latter is a bespoke assortment of different toolchains, software, and unfinished projects. Not to mention your machine will not be the same as someone else on your team. I think as an industry we still have a lot of work to do around establishing trusted computing environments for CI/CD and enabling the level of auditability and observability to verify that. There are also CI/CD providers that you can run on your own infrastructure.

[0] https://cloud.google.com/blog/products/application-developme...

[1] https://slsa.dev (edit: fixed this link)

I don't like to run my code on someone else's machine either, but having a separate build system allows you to run full, long running tests while you continue with your work.

I can see why you would use GitHub actions if you already host your code there, but I don't feel comfortable sharing my signing keys

It's nice you can do that, it doesn't work for large distributed teams.

Sure it does. Do engineers not compile their code locally constantly as a part of the process of writing it? Store deterministic hashes of expected binaries with signed commits in PRs. Then untrusted CI merely needs to generate and sign -matching- hashes and now we are good as long as the engineer and CI system are not compromised at the same time.

What about testing? In my company, before any code goes to production it has to go through hundreds if not thousands of unit tests. This can't be done on a dev laptop (see XKCD #303)

Testing is a separate concern than supply chain security. Testing should also never require any secrets useful to an adversary, so third party hosted CI is low risk here.

You're talking about creating reproducible builds - which is a good idea, but in most cases you will still need to deliver that binary somewhere.

That typically requires authentication, whether you're deploying to kubernetes or copying the files somewhere using scp, etc

So either your laptop or the ci system needs some level of secrets present to put the artifact in the correct place

Engineers simply commit artifacts with Git LFS as a signed commit. Totally unprivileged build systems can append reproducible build signatures via git tags. That repo can be webhook triggered to be -pulled- by a lambda job or similar in the target environment that will the verify tags and signatures to assert if it is valid, and deploy artifacts to signature approved environments using ephemeral role credentials.

A VCS system or CI system should never have secrets or be trusted in any way. Doing this is always dramatically increases attack surface for no reason.

I run a security consulting firm and this is often one of the first things I help my clients to fix.

I think that depends entirely on the priorities and incentives driving the company.

Reply on news.ycombinator.com