4 ms·

It's worse than I suspected. Rails 6.0, when generating a new app: - installs 102 ruby gems (without being asked) - installs yarn & 602 yarn dependencies (wi

It's worse than I suspected. Rails 6.0, when generating a new app: - installs 102 ruby gems (without being asked) - installs yarn & 602 yarn dependencies (without being asked) The modern programming industry is a joke. We call ourselves "engineers" without any certification or oaths of responsibility, and basically ignore security beyond user credentials at best. Someone please tell me `yarn list | wc` showing 2,800 transient packages is incorrect. [0]: https://gist.github.com/azah/c219844f95243cdfdb3b352ad3dee2ff https://gist.github.com/azah/c219844f95243cdfdb3b352ad3dee2f...

ChrisCinelli 8y ago
We definitely trust more than we should. And it is worse that what you just found out. Did you think about all the software and dependencies that are installed just to get to the point where you can install Rails 6 (ex: Linux)? What about your coworkers? Are you sure that you can trust all of them and nobody will not sneak anything in? If you are too paranoid on who and what you can trust, you may end up tossing all your electronic devices and go living in a desert island.
- intertextuality 8y ago
  Those attack vectors you mentioned are already known, and we essentially have to live with them. When it comes to "reflecting on trusting trust", we already know that it's basically impossible. However, this does not mean we should by default be installing heaps of packages upon generating new packages. This is practically begging for a security exploit, particularly the JS packages. [0]: https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p7...
  - ChrisCinelli 8y ago
    I am not sure why the npm packages in yarn should be more exploitable than Linux. - Linux is more ubiquitous than Node.js. If somebody exploits Linux, they get at least one order of magnitude more machines. So there is a higher motivation. - Funny code in C is harder to spot than in Javascript. Furthermore ... - A binary is harder to inspect than any module written in Javascript (even if minified). - The code in the Linux default installation has at least 2 orders of magnitudes of the code that yarn installs. I was very conservative in my estimations. Considering these kind of attacks, Linux seems more likely to be already exploited by a few organizations in multiple ways. We have been trusting too much. As more code gets written and many more people come to learn to program, the number of supply chain attacks will increase. And at the same time, as the security know-how is easier to be accessed on the Internet, we will get smarter exploiters capable of hiding their wrong doing.
gkemmey 8y ago
`bundle install` outputs `Bundle complete! 17 Gemfile dependencies, 78 gems now installed.` Just doing some eyeballing: - These look like the 62 gems in the production group: https://gist.github.com/gkemmey/6d6fcd381596b1b355d16e1e3120fb31#file-production_gems-txt https://gist.github.com/gkemmey/6d6fcd381596b1b355d16e1e3120... - Of those 62, how many are first party (by rails or other trusted vendors)? Looks like the vast majority... - These look like the other 16 (dev / test groups): https://gist.github.com/gkemmey/6d6fcd381596b1b355d16e1e3120fb31#file-dev_or_test_gems-txt https://gist.github.com/gkemmey/6d6fcd381596b1b355d16e1e3120... - On the JavaScript side, rails adds 5 top-level dependencies. 4 of those 5 have one external dependency between them: https://gist.github.com/gkemmey/6d6fcd381596b1b355d16e1e3120fb31#file-yarn_list-txt https://gist.github.com/gkemmey/6d6fcd381596b1b355d16e1e3120... Of course, the fifth is `@rails/webpacker` which has `webpack`, `babel`, and friends as dependencies. And the node ecosystem is what it is, but I think `yarn list | wc` is going to double count shared dependencies, so 2800 is high. TL;DR - I think new rails is about as minimal a footprint as possible...

ChrisCinelli 8y ago

We definitely trust more than we should. And it is worse that what you just found out. Did you think about all the software and dependencies that are installed just to get to the point where you can install Rails 6 (ex: Linux)? What about your coworkers? Are you sure that you can trust all of them and nobody will not sneak anything in? If you are too paranoid on who and what you can trust, you may end up tossing all your electronic devices and go living in a desert island.

intertextuality 8y ago
Those attack vectors you mentioned are already known, and we essentially have to live with them. When it comes to "reflecting on trusting trust", we already know that it's basically impossible. However, this does not mean we should by default be installing heaps of packages upon generating new packages. This is practically begging for a security exploit, particularly the JS packages. [0]: https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p7...
- ChrisCinelli 8y ago
  I am not sure why the npm packages in yarn should be more exploitable than Linux. - Linux is more ubiquitous than Node.js. If somebody exploits Linux, they get at least one order of magnitude more machines. So there is a higher motivation. - Funny code in C is harder to spot than in Javascript. Furthermore ... - A binary is harder to inspect than any module written in Javascript (even if minified). - The code in the Linux default installation has at least 2 orders of magnitudes of the code that yarn installs. I was very conservative in my estimations. Considering these kind of attacks, Linux seems more likely to be already exploited by a few organizations in multiple ways. We have been trusting too much. As more code gets written and many more people come to learn to program, the number of supply chain attacks will increase. And at the same time, as the security know-how is easier to be accessed on the Internet, we will get smarter exploiters capable of hiding their wrong doing.

gkemmey 8y ago

`bundle install` outputs `Bundle complete! 17 Gemfile dependencies, 78 gems now installed.` Just doing some eyeballing: - These look like the 62 gems in the production group: https://gist.github.com/gkemmey/6d6fcd381596b1b355d16e1e3120fb31#file-production_gems-txt https://gist.github.com/gkemmey/6d6fcd381596b1b355d16e1e3120... - Of those 62, how many are first party (by rails or other trusted vendors)? Looks like the vast majority... - These look like the other 16 (dev / test groups): https://gist.github.com/gkemmey/6d6fcd381596b1b355d16e1e3120fb31#file-dev_or_test_gems-txt https://gist.github.com/gkemmey/6d6fcd381596b1b355d16e1e3120... - On the JavaScript side, rails adds 5 top-level dependencies. 4 of those 5 have one external dependency between them: https://gist.github.com/gkemmey/6d6fcd381596b1b355d16e1e3120fb31#file-yarn_list-txt https://gist.github.com/gkemmey/6d6fcd381596b1b355d16e1e3120... Of course, the fifth is `@rails/webpacker` which has `webpack`, `babel`, and friends as dependencies. And the node ecosystem is what it is, but I think `yarn list | wc` is going to double count shared dependencies, so 2800 is high. TL;DR - I think new rails is about as minimal a footprint as possible...