I would like to know why the suggested method of installing Meteor is by Curling a script straight into an interpreter instead of using a package manager or other standard distribution method.
I’m asking this because as a software engineering student, I’m working on identifying bad practices or smells in Continuous Integration. One of the smells I have defined is ‘Curling straight into an interpreter’ in the CI configuration because it can cause security problems and make the CI configuration fragile as pointed out by others as well. I observed many instances of this is happening in the wild because of meteor curl https://install.meteor.com/ | sh. (Across 1,406 open source projects using Travis CI, I detected 106 cases of ‘Curling straight into an interpreter’ and 94 of them were for installing meteor.)
So I’d like to know whether these is a specific reason for Meteor core developers to suggest installation via this method instead of using a standard package manager. Thanks.
Do you have specific examples of how it does this in Meteor’s case, other than a link to a snarky article? We’ve gone over this many times (unfortunately I can’t find the previous responses right now) and at the end of the day we haven’t been able to identify a more secure and equally convenient install method. Almost any installation method we’ve seen suggested is susceptible to the same kinds of attacks, none of which are likely to happen without the user’s machine already being compromised. (Note that it’s critical that the website and install script are served over HTTPS, and that the install script is wrapped in a function so that it can’t partially execute)
Thanks @waldgeist@sashko for your response. I’ll take your feedback into account in my write-up on this.
Please let me know (keheliya@gmail.com) if you have come across any other bad practices, smells related to Travis CI in your Meteor/Node.js projects. I’d be happy to know.