5 ms·

Somewhat off topic but still highly relevant for people who actually want to use projects like this: why oh why do so many build recipes such as Dockerfiles ins

by acka 2y ago

Somewhat off topic but still highly relevant for people who actually want to use projects like this: why oh why do so many build recipes such as Dockerfiles insist on pulling random stuff off the internet as part of the build process? For example, the Dockerfile in this project pulls in two Git repositories and a script at build time. Besides the obvious build failures on heavily sandboxed build servers with no access to the internet, this forces anyone with even a little concern for security to do a full audit of any build recipes before using them, as merely studying and making available the dependencies listed in READMEs and build manifests like requirements.txt, package.json etc., is no longer enough. I find this a very worrying development, especially given the rise in critical computer infrastructure failures and supply chain attacks we've seen lately.

dbtablesorrows 2y ago
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.
- nstart 2y ago
  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 .
  - lostlogin 2y ago
    > John Deere The right to repair and the right to rampage?
    - eropple 2y ago
      It's a berserk pack, jeez. Rampage is by Midway. ;)
BossingAround 2y ago
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.
nsonha 2y ago
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?
amelius 2y ago
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.
- doublerabbit 2y ago
  The usage of Github within Go projects for dependencies is one of the reasons why I back away from using Go.
  - iforgotmysocks 2y ago
    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.
01HNNWZ0MV43FF 2y ago
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?
idunnoman1222 2y ago
Running Mac on linux isn’t even legal* so calm your how are real orgs meant to use this
- IAmLiterallyAB 2y ago
  As long as it's on Apple hardware it's fine right? Or is there something else
dboreham 2y ago
People love them some mystery meat.
judge2020 2y ago
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".
imglorp 2y ago
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...

by acka 2y ago

dbtablesorrows 2y ago

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.

nstart 2y ago
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 .
- lostlogin 2y ago
  > John Deere The right to repair and the right to rampage?
  - eropple 2y ago
    It's a berserk pack, jeez. Rampage is by Midway. ;)

BossingAround 2y ago

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.

nsonha 2y ago

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?

amelius 2y ago

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.

doublerabbit 2y ago
The usage of Github within Go projects for dependencies is one of the reasons why I back away from using Go.
- iforgotmysocks 2y ago
  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.

01HNNWZ0MV43FF 2y ago

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?

idunnoman1222 2y ago

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

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

dboreham 2y ago

People love them some mystery meat.

judge2020 2y ago

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".

imglorp 2y ago

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...