1. 9
  1. 4

    I found it interesting how a cryptographer who doesn’t know a lot about JavaScript makes the suggestion of not relying on so many dependencies from a trust and ease of review perspective.

    Also, if this is the way reviewers review code in a language they’re not super-familiar with, it would be very easy to slip in malicious dependencies under the hood; the correct way to check a dependency is to look up the package description file and then look up those names in the npm repository. I mean, in this case it was pretty obvious that the “noble” package was something completely different than what was used. And the name in the import statement matched the name in the package.json file, with the @noble prefix.

    1. 5

      I think the author was pretty up front in his title that this was an “extremely casual”, i.e. low effort, review.

      1. 2

        In a real paid-for review, you’d normally see one of two options: dependencies out of scope - only the first-party code is analysed, or dependencies in scope - the review applies to a very specific set of installed deps, effectively defined by a lock file or delivered all together. Nobody just yolos like in the blog in a real test.

        1. 2

          I suppose you’d never get that kind of feedback then (as in “you’re using deps from too many sources”), in the first place!

          1. 2

            You could, some security people will definitely tell you that.