4 ms·

It strikes me as the classic NPM disease. Do we really need a reusable action for disabling a firewall, uploading files, etc.? I mean if it comes from GitHub th

It strikes me as the classic NPM disease. Do we really need a reusable action for disabling a firewall, uploading files, etc.? I mean if it comes from GitHub that's fine, but for anything else I would rather verify the solution and copy the code. It works like a low-tech lock file, except changes are always visible inline in Git history, so less chance of lazy programmers missing changes. I almost laughed when GitHub suggested me an Action for Makefile based projects. The entire build process in my case consists of "make package"...

jacquesm 3y ago
> if it comes from GitHub that's fine No it isn't. It's become normalized but it isn't fine. Whoever thought it was a good idea to download massive amounts of unaudited code at build time to then run it behind your defensive lines should have thought about that a bit longer. CI/CD is great. GitHub/GitLab are great. But combining the two has substantial risks. More so for languages that have broken package management and namespace issues.
- PhilipRoman 3y ago
  You are of course right. I was thinking more in terms of "how do we save clueless developers (and their users) from themselves". They will probably find more ways to shoot themselves in the foot, but any percentage of prevented vulnerabilities is a positive result. Kind of like people trust Google/Apple with their phones.
  - jacquesm 3y ago
    I think it's safe to say that you can just about give up on that. The IT landscape is a horrific mess and it doesn't look like there is any change in direction on the horizon that will help to rectify that. If you trust Google or Apple with your phone then I'm fine with that, it's your phone, your life. But I've found that trusting companies to have their incentives aligned with your own or with what's good for the world in general is a structural mistake that will find you disappointed each and every time given a long enough engagement. You can't trust that which you don't own and can't verify.
    - eastbound 3y ago
      As a startup delivering executables to customers, I decently trust most programs running in the company: Gimp, Libreoffice, Docker, IntelliJ… There are only 4 major things that download unchecked stuff and run them: - IntelliJ plugins, - Maven, - NPM, - GitHub Actions. Jetbrains says it carefully reviews the source code of all versions of all plugins, and Maven has a somewhat decent dependency tree that you can restrict to major actors (Spring-Apache-Google). Maybe the key to trust would be to have larger pieces of code (such as Spring) with quite a lot of process to check-in code, rather than a thousand NPM packages. The parcellization of OSS didn’t do good for trust.

jacquesm 3y ago

> if it comes from GitHub that's fine No it isn't. It's become normalized but it isn't fine. Whoever thought it was a good idea to download massive amounts of unaudited code at build time to then run it behind your defensive lines should have thought about that a bit longer. CI/CD is great. GitHub/GitLab are great. But combining the two has substantial risks. More so for languages that have broken package management and namespace issues.

PhilipRoman 3y ago
You are of course right. I was thinking more in terms of "how do we save clueless developers (and their users) from themselves". They will probably find more ways to shoot themselves in the foot, but any percentage of prevented vulnerabilities is a positive result. Kind of like people trust Google/Apple with their phones.
- jacquesm 3y ago
  I think it's safe to say that you can just about give up on that. The IT landscape is a horrific mess and it doesn't look like there is any change in direction on the horizon that will help to rectify that. If you trust Google or Apple with your phone then I'm fine with that, it's your phone, your life. But I've found that trusting companies to have their incentives aligned with your own or with what's good for the world in general is a structural mistake that will find you disappointed each and every time given a long enough engagement. You can't trust that which you don't own and can't verify.
  - eastbound 3y ago
    As a startup delivering executables to customers, I decently trust most programs running in the company: Gimp, Libreoffice, Docker, IntelliJ… There are only 4 major things that download unchecked stuff and run them: - IntelliJ plugins, - Maven, - NPM, - GitHub Actions. Jetbrains says it carefully reviews the source code of all versions of all plugins, and Maven has a somewhat decent dependency tree that you can restrict to major actors (Spring-Apache-Google). Maybe the key to trust would be to have larger pieces of code (such as Spring) with quite a lot of process to check-in code, rather than a thousand NPM packages. The parcellization of OSS didn’t do good for trust.