How we prevented security fixes leaking into our public repositories

GitLab encountered a security issue where commits from their private security repository were inadvertently exposed in the public repository due to a design flaw in their mirroring feature. This flaw was rooted in the fetch-based behavior of GitLab's push mirror setup, which made private Git objects known to the public repository. The initial solution involved pausing the mirroring during security fixes, but this caused the private repository to lag behind public development, risking merge conflicts. A more effective solution was proposed by using Git's ls-remote command for branches, similar to how it was used for tags, preventing the commits from being stored on-disk in the public repository. This change was cautiously tested with a feature flag, and after successful experiments, it was implemented without any reported errors. However, an annoying bug arose when ls-remote's execution order caused transient errors due to the time taken to complete, which was resolved by swapping the order of reference gathering. This fix finally closed the issue, ensuring a secure and efficient mirroring process.

No tracked trend matches for this post yet.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.