What's coming in Meteor 1.2, and beyond • Hacker News Board

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

#41

Post by chopman » Wed, Jul 01, 2015, 3:26 PM UTC

logicallee wrote: post #20

joepie91_ wrote: post #9

Earlier quoted context omitted.

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?

That's exactly what docker notary is.

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

#42

Post by grandalf » Wed, Jul 01, 2015, 3:32 PM UTC

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…

In the meantime check out this for data sync:

https://github.com/charlieschwabacher/ultrawave

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

#43

Post by joepie91_ » Wed, Jul 01, 2015, 3:56 PM UTC

logicallee wrote: post #40

joepie91_ wrote: post #36

Earlier quoted context omitted.

> compromising the server wouldn't be enough, because that doesn't give you the SSL key But it does. The server needs to have the SSL key to be able to serve requests over HTTPS. It may be encrypted with a password, but at that point you're severely degrading your integrity assurances (compared to offline executable/archive signing). Might as well do it right with offline signing, right off the bat.

interesting. What if a script just uses the SSL infrastructure to get the private key associated with a domain name, without actually needing anything at that domain name to come over SSL? Then the private key does not have to be live/online at all, but could be used to verify the shell script. This is getting complicated, but if there is infrastructure, it should be possible to use it. Personally I think curl of an…

I think you need to read up a bit more on how asymmetric key cryptography works :) Verification is done using the public key, the private key is used to sign something. That's why it's so useful. This is a good read if you want to learn more: https://www.crypto101.io/

Basically, the separation between 'server serving the downloads' and 'machine signing the release' is intentional, and should be maintained. Consider it an 'airgap' of sorts, although it usually isn't one in the strictest sense of the word.

Making release signing depend on the SSL infrastructure (which is already rather broken in a number of ways) in any way, is a bad idea. Verification is a different story, but secure code delivery is a hard problem anyhow.

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

#44

Post by waterfowl » Wed, Jul 01, 2015, 4:12 PM UTC

Is anyone else unable to log into meteor.com forums? I click log in, the popup tells me I'm already logged in, click "use this account" and it drops me back where I was with a modal(ugh) about making an account.

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

#45

Post by joshburgess » Wed, Jul 01, 2015, 4:19 PM UTC

"We're going to support React and Angular!"

Translation: We're going to support the big JS names the general public is most aware of, because... well... please, use Meteor.

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

#46

Post by sanderjd » Wed, Jul 01, 2015, 4:21 PM UTC

davnicwil wrote: post #14

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 tha…

You ask a really good question. With all the myriad javascript libraries coming out weekly, you'd think we would all know of four different optimistic synch libraries off the tops of our heads, but I don't think I've seen any. Perhaps that's because in order to get it to work, Meteor has a bunch of code that (I think) watches Mongo's write-ahead-log, so you can't just make a front-end library for it. I think this is also why SQL support has been slow to come.

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

#47

Post by Rezo » Wed, Jul 01, 2015, 4:22 PM UTC

It is highly encouraging to me that Meteor is acknowledging the larger trends in the Javascript ecosystem and promoting React to an officical frontend layer instead of doubling down on their homegrown solution. Likewise for seamless Babel integration and planning the move to official ES6 modules.

Buying into a full-stack solution like Meteor is a scary proposition; you're giving up a large amount of control for a promised big increase in immediate productivity (which I do feel Meteor delivers on). This blog post goes a long way to alleviate my fears and makes it more likely I'll use Meteor for certain future projects.

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

#48

Post by joshburgess » Wed, Jul 01, 2015, 4:25 PM UTC

Siyfion wrote: post #29

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.

It's completely different from ES6, it's a full-stack framework, so it does SO much more than just a front-end framework. Meteor's main selling point is the reactivity; you can call `Books.insert({ name: "test" });` on the client, in-browser and it then updates the UI optimistically, updates the DB on the server AND propagates the change to all other clients, which in turn updates their UIs. All with one line of code…

Is DDP or Meteor really needed though? Couldn't you easily set this up with RethinkDB using its Changefeeds killer feature for real-time + socket.io along with whatever other library/frameworks you want to use without ever touching Meteor?

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

#49

Post by porker » Wed, Jul 01, 2015, 4:26 PM UTC

> Meteor goes with Angular/React like peanut butter goes with jelly.

Terribly, then. ;)

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

#50

Post by maratd » Wed, Jul 01, 2015, 4:37 PM UTC

sarciszewski wrote: post #17

joepie91_ wrote: post #9

Earlier quoted context omitted.

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.

Downvoting because it's a non-issue. If I'm copying and pasting something from the web into my terminal, it's because I trust the source.

It's not any less secure than downloading a tarball and running scripts inside of it. That's equally insecure and people have been doing that since the dawn of the internet.