diff options
Diffstat (limited to '_posts/2018-08-01-verifying-npm-ci-reproducibility.md')
| -rw-r--r-- | _posts/2018-08-01-verifying-npm-ci-reproducibility.md | 104 |
1 files changed, 47 insertions, 57 deletions
diff --git a/_posts/2018-08-01-verifying-npm-ci-reproducibility.md b/_posts/2018-08-01-verifying-npm-ci-reproducibility.md index dcfdd75..f1fd1dd 100644 --- a/_posts/2018-08-01-verifying-npm-ci-reproducibility.md +++ b/_posts/2018-08-01-verifying-npm-ci-reproducibility.md @@ -6,33 +6,29 @@ lang: en ref: veryfing-npm-ci-reproducibility updated_at: 2019-05-22 --- -When -[npm\@5](https://blog.npmjs.org/post/161081169345/v500) came bringing +When [npm@5](https://blog.npmjs.org/post/161081169345/v500) came bringing [package-locks](https://docs.npmjs.com/files/package-locks) with it, I was confused about the benefits it provided, since running `npm install` more than once could resolve all the dependencies again and yield yet -another fresh `package-lock.json` file. The message saying \"you should -add this file to version control\" left me hesitant on what to do[^1]. - -However the [addition of -`npm ci`](https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable) -filled this gap: it\'s a stricter variation of `npm install` which -guarantees that \"[subsequent installs are able to generate identical -trees](https://docs.npmjs.com/files/package-lock.json)\". But are they -really identical? I could see that I didn\'t have the same problems of -different installation outputs, but I didn\'t know for **sure** if it +another fresh `package-lock.json` file. The message saying "you should +add this file to version control" left me hesitant on what to do[^1]. + +However the [addition of `npm ci`](https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable) +filled this gap: it's a stricter variation of `npm install` which +guarantees that "[subsequent installs are able to generate identical trees](https://docs.npmjs.com/files/package-lock.json)". But are they +really identical? I could see that I didn't have the same problems of +different installation outputs, but I didn't know for **sure** if it was really identical. -Computing the hash of a directory\'s content --------------------------------------------- +## Computing the hash of a directory's content I quickly searched for a way to check for the hash signature of an -entire directory tree, but I couldn\'t find one. I\'ve made a poor -man\'s [Merkle tree](https://en.wikipedia.org/wiki/Merkle_tree) +entire directory tree, but I couldn't find one. I've made a poor +man's [Merkle tree](https://en.wikipedia.org/wiki/Merkle_tree) implementation using `sha256sum` and a few piped commands at the terminal: -``` {.bash .numberLines startFrom=""} +```bash merkle-tree () { dirname="${1-.}" pushd "$dirname" @@ -47,25 +43,25 @@ merkle-tree () { Going through it line by line: -- \#1 we define a Bash function called `merkle-tree`; -- \#2 it accepts a single argument: the directory to compute the - merkle tree from. If nothing is given, it runs on the current - directory (`.`); -- \#3 we go to the directory, so we don\'t get different prefixes in - `find`\'s output (like `../a/b`); -- \#4 we get all files from the directory tree. Since we\'re using - `sha256sum` to compute the hash of the file contents, we need to - filter out folders from it; -- \#5 we need to sort the output, since different file systems and - `find` implementations may return files in different orders; -- \#6 we use `xargs` to compute the hash of each file individually - through `sha256sum`. Since a file may contain spaces we need to - escape it with quotes; -- \#7 we compute the hash of the combined hashes. Since `sha256sum` - output is formatted like `<hash> <filename>`, it produces a - different final hash if a file ever changes name without changing - it\'s content; -- \#8 we get the final hash output, excluding the `<filename>` (which +- #1 we define a Bash function called `merkle-tree`; +- #2 it accepts a single argument: the directory to compute the + merkle tree from. If nothing is given, it runs on the current + directory (`.`); +- #3 we go to the directory, so we don't get different prefixes in + `find`'s output (like `../a/b`); +- #4 we get all files from the directory tree. Since we're using + `sha256sum` to compute the hash of the file contents, we need to + filter out folders from it; +- #5 we need to sort the output, since different file systems and + `find` implementations may return files in different orders; +- #6 we use `xargs` to compute the hash of each file individually + through `sha256sum`. Since a file may contain spaces we need to + escape it with quotes; +- #7 we compute the hash of the combined hashes. Since `sha256sum` + output is formatted like `<hash> <filename>`, it produces a + different final hash if a file ever changes name without changing + it's content; +- #8 we get the final hash output, excluding the `<filename>` (which is `-` in this case, aka `stdin`). ### Positive points: @@ -77,13 +73,13 @@ Going through it line by line: ### Limitations: 1. it ignores empty folders from the hash computation; -2. the implementation\'s only goal is to represent using a digest +2. the implementation's only goal is to represent using a digest whether the content of a given directory is the same or not. Leaf presence checking is obviously missing from it. ### Testing locally with sample data -``` {.bash .numberLines startFrom=""} +```bash mkdir /tmp/merkle-tree-test/ cd /tmp/merkle-tree-test/ mkdir -p a/b/ a/c/ d/ @@ -104,15 +100,14 @@ It seems to work for this simple test case. You can try copying and pasting it to verify the hash signatures. -Using `merkle-tree` to check the output of `npm ci` ---------------------------------------------------- +## Using `merkle-tree` to check the output of `npm ci` -*I\'ve done all of the following using Node.js v8.11.3 and npm\@6.1.0.* +*I've done all of the following using Node.js v8.11.3 and npm@6.1.0.* -In this test case I\'ll take the main repo of +In this test case I'll take the main repo of [Lerna](https://lernajs.io/)[^2]: -``` {.bash .numberLines startFrom=""} +```bash cd /tmp/ git clone https://github.com/lerna/lerna.git cd lerna/ @@ -128,29 +123,24 @@ merkle-tree node_modules/ # outputs 11e218c4ac32fac8a9607a8da644fe870a25c9982116 Good job `npm ci` :) -\#6 and \#9 take some time to run (21 seconds in my machine), but this -specific use case isn\'t performance sensitive. The slowest step is +#6 and #9 take some time to run (21 seconds in my machine), but this +specific use case isn't performance sensitive. The slowest step is computing the hash of each individual file. -Conclusion ----------- +## Conclusion -`npm ci` really \"generates identical trees\". +`npm ci` really "generates identical trees". -I\'m not aware of any other existing solution for verifying the hash -signature of a directory. If you know any I\'d [like to -know](mailto:eu@euandre.org). +I'm not aware of any other existing solution for verifying the hash +signature of a directory. If you know any I'd [like to know](mailto:eu@euandre.org). -*Edit* ------- +## *Edit* 2019/05/22: Fix spelling. -[^1]: The - [documentation](https://docs.npmjs.com/cli/install#description) +[^1]: The [documentation](https://docs.npmjs.com/cli/install#description) claims `npm install` is driven by the existing `package-lock.json`, - but that\' actually [a little bit - tricky](https://github.com/npm/npm/issues/17979#issuecomment-332701215). + but that's actually [a little bit tricky](https://github.com/npm/npm/issues/17979#issuecomment-332701215). [^2]: Finding a big known repo that actually committed the `package-lock.json` file was harder than I expected. |