xz, gh: deny network access

[alebcay]

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

Expected to fail without Homebrew/brew#17081.

[MikeMcQuaid]

Thanks @alebcay!

Would be nice to see a usage of when this also e.g. only denies some methods.

[SMillerDev]

I'd suggest blocking cURL from network in the build step and not in the others

[MikeMcQuaid]

Expected to fail without Homebrew/brew#17081.

It was merged so rerunning CI now.

[SMillerDev]

I guess the stable tap_syntax is cancelling the normal one

[alebcay]

Indeed, looks like test-bot is using latest brew tag (not latest master) so this CI will not pass until the aforementioned PR lands in a tag.

[SMillerDev]

I think that label only applies to OS testing, we need the stable syntax check to be continue-on-error to fix this

[MikeMcQuaid]

I think that label only applies to OS testing, we need the stable syntax check to be continue-on-error to fix this

Should be able to have it just not kill the main tap syntax job without a fail fast in the matrix or similar.

[SMillerDev]

Should be able to have it just not kill the main tap syntax job without a fail fast in the matrix or similar.

Since I don't see any reason to ever kill the main syntax job because of the stable one, I ignored this and made a fix with my comment: #169867

[alebcay]

N.B.: resources used by the test block that need download will fail when network access is blocked; unlike for package build, where resources are downloaded before entering the sandbox, the download for test resources occur inside the sandbox.

[MikeMcQuaid]

Looks good, let's try this out!

N.B.: resources used by the test block that need download will fail when network access is blocked; unlike for package build, where resources are downloaded before entering the sandbox, the download for test resources occur inside the sandbox.

I think there's probably a DSL addition required to indicate a test-only resource and brew fetch --include-test or similar can download it in advance.