You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In our old build system, having each architecture *only* able to potentially "poison" builds of itself was an important aspect of our approach to Principle of Least Privilege / mitigating the compromise of any of our per-architecture build workers.
In the new system, part of replicating that was having these "deploy" jobs that move images from the (per-architecture) staging repositories to the final per-architecture organization repositories *also* ran on the per-architecture build machines. When we had a small number of images in the system, these jobs were fast and this was fine. Now that our numbers have grown, these jobs are no longer fast and one mitigation we can apply is to run these "deploy" jobs on generic workers instead (which are much more readily available / safer to multiplex jobs on).
The changes I made in 3dcc133 were to help me feel more comfortable making this change (such that we are more actively preventing "crossing the streams" -- that is an extra layer on top of all the other places we do similar things to help ensure that, for example, images from the riscv64 staging area will only ever be tagged as `"platform":{"os":"linux","architecture":"riscv64"}`).
*Additionally*, we have had a number of issues related to making sure our Go code works on all our architectures, which is less necessary if we make this change (and avoid writing more custom Go in the future that needs to run on *all* workers).
I have not done so here, but this should *also* mean we can safely/successfully remove the hacks for building on those architectures/platforms from `.go-env.sh` (and could even remove the Windows support).
0 commit comments