1. 25
  1.  

  2. 12

    A bit prescient of him to be talking about writing a colors npm module, hmm?

    1. 4
      1. 4

        I’m afraid it’s perfectly possible to ship one version of your code to GitHub and a different version to npm.

        Is anyone aware of any cool cryptography that might help assert code on Github matches the code on NPM? Or asserting code on Github matches code running on a server?

        1. 3

          If the builds are reproducible, you can, by simply comparing your own build results (assuming you trust your own compiler chain, and with webpack having 780 dependencies, I’m not so sure about that) and the ones you get from NPM. I’m not sure how viable setting up reproducible builds is in JS ecosystem though.

          1. 2

            This is what Code Transparency is intended to do. You run your builds in a known environment in a confidential computing environment that gives you an attestation over the initial state of the environment (VM image contents plus git hash of the repo). The VM is configured so that the only thing it will do is your build (no accepting incoming connections, for example) and produce the output. The output is signed with a key derived from the attestation. You then append this hash into a public ledger. Anyone else can then audit your build system and VM image and can verify that running the same build gives the same output.

            Whether anyone will actually do that auditing is an open question. If your VM image has a custom container with a load of stuff that you’ve built then that’s all in the TCB and who knows what’s going on there.

            This is all predicated on reproduceable builds, of course. If running the same build twice gives different output then there’s no automated way of verifying the process.

            1. 2

              Cryptography can make it easier to simply trust an authority’s signature on a compiled blob, but besides that, I don’t think it will help much. You can certainly download all the source code for each module and run the build for each module yourself. To be honest I don’t know if npm or yarn support that type of operation out of the box. Something tells me even if they did, it would probably fail on many packages for unforeseen reasons; you would have to fix a bunch of “broken builds”.

              I do feel like this is kind of silly though. This isn’t a problem unique to JavaScript and npm. Will say regarding javascript and analytics however; IMO malicious or “criminal” intent is not even required for these kinds of “bad things” to happen. It can also happen straight through the front door without having to hide anything, without doing all this silly malware style stuff like changing the behavior based on the time of day.

              1. 1

                Plugging my own project, but: the fact that we don’t have a good answer to this is why I made xray.computer which lets you view the code that’s actually published to npm. It’s only a plaster on a major wound, though – npm packages often include pre-minified/compiled code, which is what your project will actually use, and it’s almost impossible to review since it’s essentially obfuscated.

                Reproducible builds and/or a cryptographically signed web of trust are the best proposals I know of, though it’s worth noting that npm does appear to do some relatively advanced work on detecting malicious packages behind the scenes.

                1. 1

                  I’ve heard of https://github.com/in-toto/demo and was able to find it after I made this comment. Haven’t used it, but seems interesting. Apparently datadog uses it: https://www.datadoghq.com/blog/engineering/secure-publication-of-datadog-agent-integrations-with-tuf-and-in-toto/

                  1. 1

                    Related: it seems that something fishy is going on with the nose package on PyPi: https://zaitcev.livejournal.com/263602.html

                    The code for [nose] in its source repository was fine, only PyPI was bad.

                    […]

                    [The maintainers] disclaimed any knowledge of what went on.

                    So, an unknown entity was able to insert a certain code into a package at PyPI, and pip(1) was downloading it for years. This only came to light because the inserted code failed on my Fedora test box.

                    1. 1

                      The author provides no details of what difference existed between what they saw in the repo and what they saw in the package, what effect it actually had, or anything else that would allow readers to verify or investigate for themselves, and simply declares the only possible conclusion to be that PyPI itself has been silently and completely compromised. Not that a maintainer’s account for an unmaintained (coming up on 7 years since last release) package could have been. Not that it’s possible the last release legitimately wasn’t generated from what the author saw in the GitHub repo. Not any of the other many possible explanations. And I haven’t seen this allegedly huge “PyPI compromise” mentioned anywhere else despite that post being over a week old.

                      Smells an awful lot like FUD, and until the author chooses to provide some more information that will be my stance.