From bfd02eec6d0335d139bf1ee34c00d6fd30a0df0b Mon Sep 17 00:00:00 2001 From: EuAndreh Date: Tue, 31 Jul 2018 07:33:44 -0300 Subject: Renamed npm ci file --- ...01-testing-npm-ci-reproducible-dependencies.org | 83 ---------------------- ...2018-08-01-verifying-npm-ci-reproducibility.org | 83 ++++++++++++++++++++++ 2 files changed, 83 insertions(+), 83 deletions(-) delete mode 100644 site/posts/2018-08-01-testing-npm-ci-reproducible-dependencies.org create mode 100644 site/posts/2018-08-01-verifying-npm-ci-reproducibility.org (limited to 'site/posts') diff --git a/site/posts/2018-08-01-testing-npm-ci-reproducible-dependencies.org b/site/posts/2018-08-01-testing-npm-ci-reproducible-dependencies.org deleted file mode 100644 index 73db53e..0000000 --- a/site/posts/2018-08-01-testing-npm-ci-reproducible-dependencies.org +++ /dev/null @@ -1,83 +0,0 @@ ---- -title: Verifying npm ci reproducibility -date: 2018-08-01 ---- -When [[https://blog.npmjs.org/post/161081169345/v500][npm@5]] came bringing [[https://docs.npmjs.com/files/package-locks][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 =package-lock.json= fresh file. The message saying "you should add this file to version control" left me hesitant on what to do[fn:npm-install]. - -However the [[https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable][addition of =npm ci=]] filled this gapped: it's a stricter variation of =npm install= which guarantees that "[[https://docs.npmjs.com/files/package-lock.json][subsequent installs are able to generate identical trees]]". 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 -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 [[https://en.wikipedia.org/wiki/Merkle_tree][Merkle tree]] implementation using =sha256sum= and a few piped comands at the terminal: -#+BEGIN_SRC bash -n - merkle-tree () { - dirname="${1-.}" - pushd "$dirname" - find . -type f | \ - sort | \ - xargs -I{} sha256sum "{}" | \ - sha256sum | \ - awk '{print $1}' - popd - } -#+END_SRC -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 filesystems 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 scape it with quotes; -- #7 we compute the hash of the combined hashes. Since =sha256sum= output is formatted like = =, 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 == (which is =-= in this case, aka =stdin=). -*** Positive points: -1. ignore timestamp: running more than once on different installation yields the same hash; -2. the name of the file is included in the final hash computation. -*** Limitations: -1. it ignores empty folders from the hash computation; -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 -#+BEGIN_SRC bash -n - mkdir /tmp/merkle-tree-test/ - cd /tmp/merkle-tree-test/ - mkdir -p a/b/ a/c/ d/ - echo "one" > a/b/one.txt - echo "two" > a/c/two.txt - echo "three" > d/three.txt - merkle-tree . # output is be343bb01fe00aeb8fef14a3e16b1c3d1dccbf86d7e41b4753e6ccb7dc3a57c3 - merkle-tree . # output still is be343bb01fe00aeb8fef14a3e16b1c3d1dccbf86d7e41b4753e6ccb7dc3a57c3 - echo "four" > d/four.txt - merkle-tree . # output is now b5464b958969ed81815641ace96b33f7fd52c20db71a7fccc45a36b3a2ae4d4c - rm d/four.txt - merkle-tree . # output back to be343bb01fe00aeb8fef14a3e16b1c3d1dccbf86d7e41b4753e6ccb7dc3a57c3 - echo "hidden-five" > a/b/one.txt - merkle-tree . # output changed 471fae0d074947e4955e9ac53e95b56e4bc08d263d89d82003fb58a0ffba66f5 -#+END_SRC -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= -/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 [[https://lernajs.io/][Lerna]][fn:js-repos]: -#+BEGIN_SRC bash -n - cd /tmp/ - git clone https://github.com/lerna/lerna.git - cd lerna/ - git checkout 57ff865c0839df75dbe1974971d7310f235e1109 - npm ci - merkle-tree node_modules/ - rm -rf node_modules/ - npm ci - merkle-tree node_modules/ - npm ci # test if it also works with an existing node_modules/ folder - merkle-tree node_modules/ -#+END_SRC -Good job =npm ci= :) - -#6 and #9 take some time to run (21s in my machine), but this specific use case isn't performance sensitive. The slowest step is computing the hash of each individual file. -** Conclusion -=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 [[mailto:eu@euandre.org][like to know]]. - -[fn:npm-install] The [[https://docs.npmjs.com/cli/install#description][documentation]] claims =npm install= is driven by the existing =package-lock.json=, but that' actually [[https://github.com/npm/npm/issues/17979#issuecomment-332701215][a little bit tricky]]. -[fn:js-repos] Finding a big known repo that actually committed the =package-lock.json= file was harder than I expected. diff --git a/site/posts/2018-08-01-verifying-npm-ci-reproducibility.org b/site/posts/2018-08-01-verifying-npm-ci-reproducibility.org new file mode 100644 index 0000000..73db53e --- /dev/null +++ b/site/posts/2018-08-01-verifying-npm-ci-reproducibility.org @@ -0,0 +1,83 @@ +--- +title: Verifying npm ci reproducibility +date: 2018-08-01 +--- +When [[https://blog.npmjs.org/post/161081169345/v500][npm@5]] came bringing [[https://docs.npmjs.com/files/package-locks][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 =package-lock.json= fresh file. The message saying "you should add this file to version control" left me hesitant on what to do[fn:npm-install]. + +However the [[https://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable][addition of =npm ci=]] filled this gapped: it's a stricter variation of =npm install= which guarantees that "[[https://docs.npmjs.com/files/package-lock.json][subsequent installs are able to generate identical trees]]". 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 +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 [[https://en.wikipedia.org/wiki/Merkle_tree][Merkle tree]] implementation using =sha256sum= and a few piped comands at the terminal: +#+BEGIN_SRC bash -n + merkle-tree () { + dirname="${1-.}" + pushd "$dirname" + find . -type f | \ + sort | \ + xargs -I{} sha256sum "{}" | \ + sha256sum | \ + awk '{print $1}' + popd + } +#+END_SRC +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 filesystems 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 scape it with quotes; +- #7 we compute the hash of the combined hashes. Since =sha256sum= output is formatted like = =, 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 == (which is =-= in this case, aka =stdin=). +*** Positive points: +1. ignore timestamp: running more than once on different installation yields the same hash; +2. the name of the file is included in the final hash computation. +*** Limitations: +1. it ignores empty folders from the hash computation; +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 +#+BEGIN_SRC bash -n + mkdir /tmp/merkle-tree-test/ + cd /tmp/merkle-tree-test/ + mkdir -p a/b/ a/c/ d/ + echo "one" > a/b/one.txt + echo "two" > a/c/two.txt + echo "three" > d/three.txt + merkle-tree . # output is be343bb01fe00aeb8fef14a3e16b1c3d1dccbf86d7e41b4753e6ccb7dc3a57c3 + merkle-tree . # output still is be343bb01fe00aeb8fef14a3e16b1c3d1dccbf86d7e41b4753e6ccb7dc3a57c3 + echo "four" > d/four.txt + merkle-tree . # output is now b5464b958969ed81815641ace96b33f7fd52c20db71a7fccc45a36b3a2ae4d4c + rm d/four.txt + merkle-tree . # output back to be343bb01fe00aeb8fef14a3e16b1c3d1dccbf86d7e41b4753e6ccb7dc3a57c3 + echo "hidden-five" > a/b/one.txt + merkle-tree . # output changed 471fae0d074947e4955e9ac53e95b56e4bc08d263d89d82003fb58a0ffba66f5 +#+END_SRC +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= +/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 [[https://lernajs.io/][Lerna]][fn:js-repos]: +#+BEGIN_SRC bash -n + cd /tmp/ + git clone https://github.com/lerna/lerna.git + cd lerna/ + git checkout 57ff865c0839df75dbe1974971d7310f235e1109 + npm ci + merkle-tree node_modules/ + rm -rf node_modules/ + npm ci + merkle-tree node_modules/ + npm ci # test if it also works with an existing node_modules/ folder + merkle-tree node_modules/ +#+END_SRC +Good job =npm ci= :) + +#6 and #9 take some time to run (21s in my machine), but this specific use case isn't performance sensitive. The slowest step is computing the hash of each individual file. +** Conclusion +=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 [[mailto:eu@euandre.org][like to know]]. + +[fn:npm-install] The [[https://docs.npmjs.com/cli/install#description][documentation]] claims =npm install= is driven by the existing =package-lock.json=, but that' actually [[https://github.com/npm/npm/issues/17979#issuecomment-332701215][a little bit tricky]]. +[fn:js-repos] Finding a big known repo that actually committed the =package-lock.json= file was harder than I expected. -- cgit v1.2.3