1. 9
  1. 3

    Package repositories really need to add processes for verifying that the code on GitHub matches the code on the package site. npm publish / etc on the developer’s machine shouldn’t be the primary way to publish packages, it should be the “untrusted” way. Telling the package repo to just take a git tag from the git repo should be the “most trusted” way, resulting in a big checkmark on the package page that links to the git tag. If the tag was PGP signed, enlarge the checkmark even more. The second best way — for packages that need processing (codegen/transpile/minify/etc) — would be to ensure the package was built on a public CI service. That would display a smaller checkmark.

    (obviously the UI indication should be better than the size of the checkmark lol)

    And yeah, of course this doesn’t address everything, but it fixes the problem of “everyone is way too lazy to check the actual files on the package repo, everyone will just browse on github” which is IMO a very important problem

    1. 2

      “everyone is way too lazy to check the actual files on the package repo, everyone will just browse on github”

      We actually vendor-ed all node dependencies at work and did my best attempt at auditing it with the team. That’s almost 3k packages clocking well over 30k files.

      We found 3 binaries. Two bundled with a package, one with sources in an external repo (not the package repo), the other without sources and one downloaded off the web doing install.

      Ended up designing a vendoring process for npm dependencies. It makes the life of front-end developers slightly harder but significantly improves the security of the product.

      1. 1

        Any chance of a writeup? I’ve got a few friends who would absolutely use such a thing (and me).

        1. 1

          Without going into too much details.

          1. Have your front-end team provide a package.json and a package-json.lock
          2. The person responsible for vendoring runs npm ci --ignore-scripts to reproduce the package state on a new machine (preferably a jail or a virtual machine). The –ignore-scripts part is really important to prevent automatic builds and additional binary downloads.
          3. On first pass identify suspect files like binaries, you can run file on all the files and see what type of files are there (ie. uniq the output). Keep in mind that file itself is unsafe so do it in a jail or vm.
          4. Remove not needed binaries (like the ones in term-size) or drop dependencies on packages you can’t verify the source of each binary for. Never vendor a binary even if you think you know where it’s sources are from.
          5. At this point audit the code. If you did this before you have a vcs diff which ‘should’ make it easier but since the directory tree inside npm is unstable that is unfortunately rarely the case.
          6. Now some packages need post processing with their scripts. Identify those packages and run npm run install just for them. For node-sass that would be cd ./node_modules/nose-sass && npm run install. However before doing that disable the network connection on the jail/vm. In the example of node-sass it defaults to downloading the binary off the internet. You can force it to always build without trying to download a binary by setting the environment variable SKIP_SASS_BINARY_DOWNLOAD_FOR_CI. This step should be automated in your CI build phase and you should not vendor the binary artifacts in your repository.

          That’s pretty much it.