The answer is churn, my friend.

There's so much churn in devops space that nobody has time to figure out "the correct way" anymore.

In this case, the individual did it for their own research purposes for security stuff. I looked at their profile. They have a demo running a modded version of Doom on a John Deere tractor display. This person definitely takes the time to figure stuff out :D .

> John Deere

The right to repair and the right to rampage?

It's a berserk pack, jeez. Rampage is by Midway. ;)

Well, the correct path forward would be to wait for a large OSS player, like Red Hat, SUSE, Canonical, ..., and make the build secure.

Typically, Fedora and openSUSE have a policy that distributed packages (which includes container images) have to build with only packages from the repository, or explicitly added binaries during the build. So once you can `dnf/zypper install` something (or pull it from the vendor's container registry), you know the artifacts are trusted.

If you need to be on a bleeding edge, you deal with random internet crap shrug.

Of course a random OSS developer won't create offline-ready, trusted build artifacts. They don't have the infrastructure for it. And this is why companies like Red Hat or SUSE exist - a multi-billion dollar corporation is happy to pay for someone to do the plumbing and make a random artifact from the internet a trusted, reproducible, signed artifact, which tracks CVEs and updates regularly.

if you are pulling from a registry then it's already built, so your ci should not fail on docker build dependencies. Or my understanding is wrong?

I really hate it when projects pull build files from the internet. Usually this happens unexpectedly. Besides the security issues that you mentioned, it also means that packaging software that depends on it becomes much more difficult and prone to unpleasant surprises, like when there is a version issue or when there is simply no internet, and of course the worst nightmare is if the dependency is not available anymore.

Self-contained distribution should be the norm.

The usage of Github within Go projects for dependencies is one of the reasons why I back away from using Go.

I am aware you can bundle them yourself but I don't have the time to.

I am not familiar with Go, but if the package manager doesn't allow for arbitrary script to run(cough NPM cough) I reckon it's fine.

Because if you had large binaries in your repo, it would grow quickly every time they changed, and GitHub would charge you lots of money, right?

Running Mac on linux isn’t even legal* so calm your how are real orgs meant to use this

As long as it's on Apple hardware it's fine right? Or is there something else

People love them some mystery meat.

Probably mostly to retain organization (via separate git repos) - in lieu of cloning stuff in Dockerfile, you end up needing a pre-build instruction of "when you clone use --recursive or do git submodule init to get the other repos into your CWD".

How is this different from JS pulling in tens of thousands of dependencies to display a web page?

In the 80s we envisioned modular, reusable software components you drop in like Lego bricks (we called it CASE then), and here we have it, success! Spoiler, it comes with tradeoffs...