Friday I was happily developing my next killer app. This morning meteor add stopped working.
mamluk@Thinkpad-X1:~/Projects$ meteor create test
test: created.
To run your new app:
cd test
meteor
mamluk@Thinkpad-X1:~/Projects$ cd test/
mamluk@Thinkpad-X1:~/Projects/test$ ls
test.css test.html test.js
mamluk@Thinkpad-X1:~/Projects/test$ meteor add fortawesome:fontawesome
This morning @ 10:12 my automatic deployment tool reported some errors on my machine. Errors which were not present on Friday.
At 10:48 I concluded that nothing was wrong with my Ubuntu or routing, and I started testing on our cloud, both in Europe and US. It was not working.
At 11:18 I posted here.
At 11:25 I bought a VPS. I was waiting for activation when things got back to normal.
Anyone else ever experienced this? It’s not the first time for me, but for the first time I have been able to document and replicate it. What could have happened?
Meteor is not mission critical yet. We all know this.
A forum search didn’t reveal similar issues in the past, so it’s not widespread yet.
The solution is to be able to mirror atmosphere and meteor servers. I’m willing to host a free public mirror. Can MDG help us by providing us the software needed to run a clone?
If atmosphere (package server) being offline breaks development workflow (which we should get confirmed before jumping to a conclusion) then I think this is very well mission critical.
Meteor is 1.0, and some very serious apps are using it for multi million dollar businesses, and Meteor itself is providing paid support subscriptions, therefore, yeah, meteor definitely is mission critical. At least for quite a number of us.
Also, I know for a fact that there has been availability issues with both atmosphere and the package server in the past. You can search the old forums for that.
I agree that Meteor should provide means to mitigate such issues, I really like and appreciate your idea (and offer to chip in) of mirror servers. That has proven itself quite successful with other package ecosystems like ubuntu’s.
But I guess it is not a very trivial task to tackle. You need to bake that support into the meteor tool. Also, you need to make sure packages on the mirrors are both up to date and that they are authentic. There’s a huge potential for a security issue there and it needs to be addressed very carefully.
But, if MDG opts in to support mirrors, that also means that there will very likely be support for private package servers as well (basically the same idea) and that I would applaud on foot
Right now, package security suffers from the tacit assumption that the code we see on GitHub for a package, is the code we get when we meteor add it. But that might not be the case. An attacker can publish a useful package on GitHub, then after getting enough users, they can meteor publish on MDG’s servers a version with malicious code added. Auditing done against the code published on GitHub will never catch the malicious code.
I hope those serious about security look at the code added by meteor add, but this potential discrepancy is a little disturbing and could be solved on Atmosphere with a badge indicating that the code in the GitHub repo for a package mismatches the code on MDG’s package server.
In fact, apart from those package authors for whom I’ve built some degree of trust, I don’t meteor add packages, but instead clone it to a local package directory, and use it from there, sometimes even take out the pieces of code that I need for a project, make it a local part of the project itself and discard the package all together.
But, then again, package security has been a long standing argument both over at the old forums and here. I’m guessing there still is huge ground to cover.
