Discontinue npm and pypi "installers"?

[chadlwilson]

IMHO, the mechanisms these use are considered extremely insecure as they rely on execution of arbitrary code during installation to download appropriate binaries.

Constant supply chain breaches come from arbitrary code executed on install/postinstall - and people should be disabling this entirely where they can (as pnpm and bun do by default).

I don't think we should be promoting this practice, especially for a small project like gauge with limited maintainer time to keep everything "safe". Python is an even bigger mess because of its abysmal packaging setup.

Further to that

• there is no mechanism to lock/check shas of binaries
• adds yet another confusing entrypoint to gauge to test/validate against (script shims)
• they require constant additional maintenance to keep working (build, publish, platform detection, publishing portal creds and security)
• the python one uses EOL setuptools and improper legacy dependency locking techniques
  • this repo shouldn't require python packaging knowledge to maintain, that's insane imo given state of the ecosystem

The pros of as-is

• convenient for users of those ecosystems
• automatic update management/discovery via dependabot/renovate etc
• security/vuln publishing and discovery via those ecosystems if we ever have such an issue

There are better ways to install simple single binary software like gauge, including homebrew, Choco (🤮), curl + sha-check - or cross-platform tool managers such as Aqua or Mise (the latter of which supports lockfiles). For the YOLO uses we still have our own (as dodgy as npm/pypi) curl | sh script installer.

WDYT @zabil , @sriv , @haroon-sheikh ?

I can collect some info on usage and trends if this is worth exploring. Last I looked the npm installer has 4,000-6,000 weekly downloads which isn't insignificant but haven't looked at the history in depth or by way of comparison to direct downloads.

[haroon-sheikh]

I completely agree with you and happy for us to not support these any longer, there isn't much benefit when users are able to install it using homebrew/choco.

[zabil]

Makes sense. Too many breaches in npm, plus having an npm makes the maintainers a target.
Some js functional tests (i think for taiko too) rely on the npm package installs so that might need fixing.

[chadlwilson]

Hmm, now you mention it, it does make it quite convenient for taiko, in particular. I'll dig around and have more of a think about it at some point.

I wonder if the middle-ground here is to keep the npm package, but change it to a shim which downloads the implied version during first use (intentional user execution, not background npm script magic) and caches it, kinda like corepack - but without relying on install/postinstall.

Alternatively, if we wanted to go more hardcore to do things verifiably at install-time and do this the "proper" way, rather than at runtime (albeit away from the spirit of simplicity) the "way" would be to change it to a meta-package like sass-embedded/dart-sass, where the entry-point is a wrapper to the platform/arch-specific optional dependencies that use conditional resolution based on os/arch:

https://github.com/gocd/gocd/blob/43ae94b3b6e08be3d636e5d92939dffca9516ad2/server/src/main/webapp/WEB-INF/rails/yarn.lock#L7936-L8013

Maybe makes more sense for a library-with-js-api-wrapping-a-native-tool than a CLI though.