glab(1)

πŸ“¦
version 1.128.0 Β· 2 versions
, in arch rolling

πŸ¦‹ glab(1) β€” the manual, but make it make sense

okay bestie, so this is the page for glab(1) β€” the GitLab CLI β€” and specifically we're deep-diving the dependency-firewall go situation. it's giving "security guard but for your Go modules" πŸ’…


✨ NAME ✨

glab-dependency-firewall-go β€” run go through the GitLab Dependency Firewall. (BETA)

yes, BETA. check the vibe below. πŸ”₯

πŸŽ€ SYNOPSIS πŸŽ€

glab dependency-firewall go  [flags]

(yes there are two spaces, that's just how it is, no cap)


πŸ’– DESCRIPTION πŸ’–

okay so here's the whole thing: this command runs the go binary through the GitLab Dependency Firewall. What it actually does is check every single module download against the policy for your current project, refuses the blocked ones (rude but necessary), and then summarizes the results after the run. periodt.

Module downloads go through a Go module proxy that the command spins up on 127.0.0.1 for the run. No certificate is involved at all, so your system trust store is not changed β€” ngl that's a relief, we're not touching your trust store today 🫢

For the run, GOPROXY points at that proxy, GONOPROXY is none, and GO111MODULE is on β€” so literally every module download gets checked. Private modules matched by GOPRIVATE are also checked, and then fetched the way your configuration fetches them. iconic behaviour.

If you set GOPROXY=off, the command keeps it. respectful king πŸ‘‘

Allowed modules are downloaded through your configured GOPROXY, from the environment or the go env file, in list order and with its fallbacks. Credentials for that proxy come from your .netrc file, GOAUTH, or the URL itself. A GOSUMDB with its own URL is reached through the proxy the command starts β€” and heads up, credentials for that URL must be in the URL itself, because .netrc and GOAUTH apply only to GOPROXY. that's the rule, iykyk.

the part where it only checks some modules πŸ™ˆ

bestie, listen β€” the command checks only modules that go downloads during the run:

  • Modules already in your module cache are not checked. In CI, point GOMODCACHE at an empty directory to check every module. (empty cache = clean slate = main character energy ✨)
  • Vendored code and replace directives that point at a local path are not checked.
  • Go toolchain downloads are not checked by policy. go verifies them against the checksum database.

the privacy tea β˜•

Module paths and versions β€” including private ones β€” are sent to the policy API and written to .gitlab/df/ci-log.json. CI jobs that upload that file publish them with the job's artifacts. so like... just know that's happening, okay? πŸ’€

⚠️ also: tests that make HTTPS requests can fail certificate checks under this command. Run go test outside the firewall if your tests reach the network. learn from my mistakes fr fr 😭

All arguments are forwarded to go verbatim. no editing, no vibes-checking, just straight through.

beta warning, read this part 🚨

This feature is in beta and might not be ready for production use. It might be unstable and breaking changes can occur outside of major releases. For more information, see https://docs.gitlab.com/policy/development_stages_support/.

like... it's giving "we're still cooking" πŸ“


🌸 OPTIONS INHERITED FROM PARENT COMMANDS 🌸

  • -h, --help[=false] β€” Show help for this command. (your little escape hatch 🧚)

⭐ EXAMPLE ⭐

# Download modules through the Dependency Firewall
glab dependency-firewall go mod download

# Add a dependency, checking it against the policy first
glab dependency-firewall go get github.com/pkg/errors@v0.9.1

see? checked first, added after. that's the whole plot 🌈


πŸ‘‘ SEE ALSO πŸ‘‘

glab-dependency-firewall(1) β€” go say hi to the parent command, she's lovely.


and that's the page!! πŸ’œ this was auto generated by spf13/cobra, dated Nov 2026, and it lives under glab(1) β€” mwah, go forth and firewall responsibly πŸ’…βœ¨

πŸ“¦ where this page comes from