Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What's coming in Meteor 1.2, and beyond

info.meteor.com

Post reply on HN
Print view View original

11–20 of 98 posts

Re: What's coming in Meteor 1.2, and beyond

#11

Post by honest_joe »

liamzebedee wrote: post #8

Official React support - woohoo! I've been using React and Meteor together to build a desktop web app for quantified self, and I have to say, the combination is magnificent for productivity. The app is 90% JS and a little CSS, and reactively updates with no extra code. MongoDB and server logic is separated from the client-side view rendering, so if I wanted to make it a thin client and remotely host the computations…

How is the performance ? For me something like Atom feels very sloppy compared to Textmate / Sublime

Re: What's coming in Meteor 1.2, and beyond

#12

Post by sarciszewski »

honest_joe wrote: post #10
sarciszewski wrote: post #7

Earlier quoted context omitted.

Hack their webserver, replace the contents of https://install.meteor.com/ with malware, instantly pwn anyone who pipes that to their shell. Worse: the people who are most likely to curl|sh are DevOps folks with the keys to their company's kingdom.

Commit a race condition to glibc,musl,uclibc and fuck up almost every software on the planet. It's convenient and that does not mean it's a good practice but i doubt using an other method would minimize a risk when the meteor.com would actually get owned.

> i doubt using an other method would minimize a risk when the meteor.com would actually get owned.

GPG signing, keep the private key offline, publish the public key in the blockchain and have a lot of high profile technologists sign it so it can be independently verified.

See also: PHPUnit. https://phpunit.de/manual/current/en/installation.html#insta...

(They provide an example shell script for quickly downloading and verifying the latest versions of their install)

Re: What's coming in Meteor 1.2, and beyond

#13

Post by bsbechtel »

matthewbauer wrote: post #4

When ES6 and web components come out, are we even going to need frameworks like Meteor? It seems like all of the advantages of MVC frameworks go away once you can create controllers and models in native Javascript and views in native HTML.

Meteor isn't MVC.

Re: What's coming in Meteor 1.2, and beyond

#14

Post by davnicwil »

matthewbauer wrote: post #4

When ES6 and web components come out, are we even going to need frameworks like Meteor? It seems like all of the advantages of MVC frameworks go away once you can create controllers and models in native Javascript and views in native HTML.

I've not used Meteor, but I understand one of its big selling points is 'optimistic UI', i.e. it alters models locally when changes are made, and syncs those changes with the server in the background, only changing the local model back again on failure to sync with the server.

I don't know if this can be (or has been) extracted to a separate library or if this is part of the web components spec, but its something that's pretty nice to have baked into the framework.

In fact the only reason I'm not using Meteor now is that it's still got a hard dependency on Mongo. I was disappointed to see that SQL support has not begun to come in yet with this update. Once SQL support is there, I will definitely be looking at using Meteor, particularly now it's got first-class React support.

Re: What's coming in Meteor 1.2, and beyond

#15

Post by honest_joe »

sarciszewski wrote: post #12
honest_joe wrote: post #10

Earlier quoted context omitted.

Commit a race condition to glibc,musl,uclibc and fuck up almost every software on the planet. It's convenient and that does not mean it's a good practice but i doubt using an other method would minimize a risk when the meteor.com would actually get owned.

> i doubt using an other method would minimize a risk when the meteor.com would actually get owned. GPG signing, keep the private key offline, publish the public key in the blockchain and have a lot of high profile technologists sign it so it can be independently verified. See also: PHPUnit. https://phpunit.de/manual/current/en/installation.html#insta... (They provide an example shell script for quickly downloading a…

I completely understand your point.

But at the end it's about people ...your example with PHPUnit can be abused like this https://thejh.net/misc/website-terminal-copy-paste How many people do you think will bother to paste the script to a text editor and check for evil parts ?

Re: What's coming in Meteor 1.2, and beyond

#16

Post by sarciszewski »

honest_joe wrote: post #15
sarciszewski wrote: post #12

Earlier quoted context omitted.

> i doubt using an other method would minimize a risk when the meteor.com would actually get owned. GPG signing, keep the private key offline, publish the public key in the blockchain and have a lot of high profile technologists sign it so it can be independently verified. See also: PHPUnit. https://phpunit.de/manual/current/en/installation.html#insta... (They provide an example shell script for quickly downloading a…

I completely understand your point. But at the end it's about people ...your example with PHPUnit can be abused like this https://thejh.net/misc/website-terminal-copy-paste How many people do you think will bother to paste the script to a text editor and check for evil parts ?

Anybody who runs unverified code, through any medium, when the option to run trusted code is available, deserves to get pwned.

https://github.com/paragonie/password_lock/blob/master/run-t...

^- For the record, I keep scripts like this in my Git repositories.

Re: What's coming in Meteor 1.2, and beyond

#17

Post by sarciszewski »

joepie91_ wrote: post #9
ruswick wrote: post #6

Earlier quoted context omitted.

That's a pretty common thing. I don't see the problem.

It being a common thing is the problem. It's teaching insecure habits.

People are downvoting this and being too much of a coward to state why they are.

Re: What's coming in Meteor 1.2, and beyond

#18

Post by logicallee »

sarciszewski wrote: post #7
ruswick wrote: post #6

Earlier quoted context omitted.

That's a pretty common thing. I don't see the problem.

Hack their webserver, replace the contents of https://install.meteor.com/ with malware, instantly pwn anyone who pipes that to their shell. Worse: the people who are most likely to curl|sh are DevOps folks with the keys to their company's kingdom.

What do you want them to do? The obvious solution is to change it from "curl|sh" to "curl|{something about whetehr PGP says this is properly signed by the private key belonging to public key blahblahblahblahbalhMETEOR.COMkey. If yes:}|sh"

But the problem is anyone compromising the site can just change the line from "blahblahblahblahbalhMETEOR.COMkey" to "attackerchangedblahblahblahblahbalhMETEOR.COMkey" right on the web page, and people will copy the one verified against the wrong key. So that doesn't work.

Nor do clients have caches of PGP signatures, nor is there some totally obvious third-party that you can verify it with. You can't just go:

curl|{check_if_signed_with_www.this-site.com}|sh (which would pass visual inspection - the attacker would have to change www.this-site.com to something else) because there is no obvious mechanism to do that. Who will tell you whether https://install.meteor.com/ has signed it?

Well, HTTPS will kind of tell you. So "https://install.meteor.com/" is a lot better than nothing...

If you're going to entertain the idea of the HTTPS site being compromised to serve whatever they want, well, there is precious little you can do about it.

Re: What's coming in Meteor 1.2, and beyond

#19

Post by [deleted] »

sarciszewski wrote: post #7
ruswick wrote: post #6

Earlier quoted context omitted.

That's a pretty common thing. I don't see the problem.

Hack their webserver, replace the contents of https://install.meteor.com/ with malware, instantly pwn anyone who pipes that to their shell. Worse: the people who are most likely to curl|sh are DevOps folks with the keys to their company's kingdom.

[deleted]

Re: What's coming in Meteor 1.2, and beyond

#20

Post by logicallee »

joepie91_ wrote: post #9
ruswick wrote: post #6

Earlier quoted context omitted.

That's a pretty common thing. I don't see the problem.

It being a common thing is the problem. It's teaching insecure habits.

What do you think about this solution: introduce a layer on top of SSL that just verifies whether the private key of a certain explicitly stated site has signed a file?

In other words, compromising the server wouldn't be enough, because that doesn't give you the SSL key, so it would still fail "curl|is_signed_by site.com|sh", which they can only pass if they compromise the private key?

Better than the current system?

Post reply on HN