What's coming in Meteor 1.2, and beyond(info.meteor.com)
info.meteor.com
What's coming in Meteor 1.2, and beyond
http://info.meteor.com/blog/whats-coming-in-meteor-12-and-beyond
97 comments
Honestly I'm very likely to stick with Blaze for the time being, as I've found it easier to follow & understand than Angular (haven't tried React yet).
I just like the sticking with general modularity approach (that really reminds me of Ruby).
I don't think the Meteor proposition is any scarier than getting into Rails, Django, or even Laravel. You're basically trusting a growing ecosystem that will prevent you from re-inventing the wheel.
I just like the sticking with general modularity approach (that really reminds me of Ruby).
I don't think the Meteor proposition is any scarier than getting into Rails, Django, or even Laravel. You're basically trusting a growing ecosystem that will prevent you from re-inventing the wheel.
Rails, Django, and Laravel are all server-side frameworks. You could replace one with another, without having to rewrite any client code.
Meteor is all-encompassing, covering both the client and server. That means you have much less agility in terms of swapping out components, but of course its convenience is unparalleled.
Actually this has me wondering, is there anything else out there like Meteor that covers both client and server development at the same time? Maybe GWT?
Meteor is all-encompassing, covering both the client and server. That means you have much less agility in terms of swapping out components, but of course its convenience is unparalleled.
Actually this has me wondering, is there anything else out there like Meteor that covers both client and server development at the same time? Maybe GWT?
> Actually this has me wondering, is there anything else out there like Meteor that covers both client and server development at the same time?
There's also Derby.js and Socketstream which arose around the same time as Meteor:
http://derbyjs.com
http://www.socketstream.org
There's also Derby.js and Socketstream which arose around the same time as Meteor:
http://derbyjs.com
http://www.socketstream.org
Maybe Volt http://voltframework.com/ but I didn't use it and it's hardly mainstream.
It doesn't have to be a full stack solution.
From meteor's article about the DDP protocol [1]:
"...a mobile client written in pure Objective C, with no Meteor code, can connect to a Meteor server (say, by using the ObjectiveDDP library), and the server doesn't see it as different from any other client."
[1] https://www.meteor.com/ddp
From meteor's article about the DDP protocol [1]:
"...a mobile client written in pure Objective C, with no Meteor code, can connect to a Meteor server (say, by using the ObjectiveDDP library), and the server doesn't see it as different from any other client."
[1] https://www.meteor.com/ddp
Anyone out there using Angular and Firebase? That's been my go-to "stack" for achieving 3-way binding of the UI, javascript model, and remote database. The only downside is that you're locked into using firebase as a service, can't host it locally, and you're limited to what their API supports. It's amazingly fast in terms of ability to churn out features.
Meteor seems to be the only thing that comes close to giving offering the same amount of productivity as I can get using Angularfire.
Has anyone used both, that can comment?
Meteor seems to be the only thing that comes close to giving offering the same amount of productivity as I can get using Angularfire.
Has anyone used both, that can comment?
I've used that combo for many projects. I gave a talk on it last year at a local AngularJS Meetup:
https://www.youtube.com/watch?v=vCExKhJCUM8
https://www.youtube.com/watch?v=vCExKhJCUM8
Just curious, was the "hack" in the Live AMA someone just incrementing the upvote endpoint with a larger int or an actual exploit someone found.
I didn't bother implementing any validation rules on the backend so it was free for people to change whatever they wanted using the debugger console.
I did the design of a project that used Angular inside Ionic with Firebase as backend. They integrated well, no particular problem. Just be careful not to keep websockets open unless those you really need. Close the others. They'll keep the CPU busy and bleed the battery.
The only major problem was with Firebase itself, when we had to start duplicating data because it's a tree and it doesn't have joins. But it would be unfair to complain because it's like that by design and we knew what was expecting us. Is there any service like Firebase but with joins?
The only major problem was with Firebase itself, when we had to start duplicating data because it's a tree and it doesn't have joins. But it would be unfair to complain because it's like that by design and we knew what was expecting us. Is there any service like Firebase but with joins?
I really wish there was. I tried Firebase + Angular and liked it well enough, but I found the security rules kind of hard to grasp.
I've been using Meteor, and I like it quite a bit. There are a lot of things I wish were different but it's made me pretty productive.
I really wish it had Clojurescript integration for instance. But that's a really minor and personal thing I just want to use clojurescript.
I'd dig a Postgres as a service style firebase alternative that'd be nifty.
I've been using Meteor, and I like it quite a bit. There are a lot of things I wish were different but it's made me pretty productive.
I really wish it had Clojurescript integration for instance. But that's a really minor and personal thing I just want to use clojurescript.
I'd dig a Postgres as a service style firebase alternative that'd be nifty.
I've tried Angular and Firebase for a few small protoypes, it's incredibly fast to create something to present. I really like the User authentication.
Are you currently using both in production, do you have maybe an link to your app?
Are you currently using both in production, do you have maybe an link to your app?
So when is Meteor going to start sending actual web pages? I ask here, because seeing a blank page that consists of
<body>
</body>
There is a difference between web pages and web applications, and Meteor is built for the latter. There is no such thing as a progressive enhancement path in many cases. If your firewall (?) strips out JS, then you are on a broken network.
How does it do that anyway? Most sites are HTTPS.
How does it do that anyway? Most sites are HTTPS.
Yes, there is a difference between pages and apps. You should still not send only empty body tag. Click link, see blank page - how am I to know what kind of page it is? I'm really only referring to documents (like www.meteor.com, I presume - I can't actually read it from this computer as it's a blank page). Even on "web apps", there should really be at least an error indicating that the app only works with JS, or maybe a link to a fallback/alternative if appropriate.
Note: a search page is not an "app". Progressive enhancement works just fine in almost every case that isn't a purely interactive app (i.e. google maps or a game). It is trivial to render, as needed, the HTML template with the header/footer, or a layout-free snippit, or simplee JSON, or whatever else is needed. This was basically zero extra work in Rails years ago, so I don't see why it can't be done now.
As for stripping JS, that is easy, and done for security reasons. Yes, this requires a custom cert so the firewall can MITM the connection, which most businesses do anyway. No, this does not make it a broken network. Javascript is optional, and always has been. ( http://www.sitepoint.com/javascript-dependency-backlash-myth... )
Note: a search page is not an "app". Progressive enhancement works just fine in almost every case that isn't a purely interactive app (i.e. google maps or a game). It is trivial to render, as needed, the HTML template with the header/footer, or a layout-free snippit, or simplee JSON, or whatever else is needed. This was basically zero extra work in Rails years ago, so I don't see why it can't be done now.
As for stripping JS, that is easy, and done for security reasons. Yes, this requires a custom cert so the firewall can MITM the connection, which most businesses do anyway. No, this does not make it a broken network. Javascript is optional, and always has been. ( http://www.sitepoint.com/javascript-dependency-backlash-myth... )
There is actually nothing in meteor which states that you have to have only a body tag in your html. In fact, you can very simply render html headers, footers, and other static html without javascript. You can also handle 404 and send static pages for such appropriately. If someone has misinformed you, do take their opinion as nothing more than nonsense.
Now if you happen to run across a site which does not handle this properly, that is not shocking in any way. I have found that generally speaking those who disable javascript often complain about sites which extensively use javascript. They say things like "you can't assume that everyone has javascript enabled", "javascript is a security hazard and you can't expect me or anyone else to run a site with such a blatant vulnerability", and "how dare sites use such shotty technology to give an experience, they need to realize we need the same experience but without all of the vulnerabilities". The list of complaints go on and on.
The reality of the situation is this: as someone who makes consumer applications for profit, most of us don't care about you. If you are willing to turn off javascript, you are probably not my target user. If you work in an organization which does something so stupid as to break ssl in order to commit mitm attacks on your own employees in the name of security, you are probably not my target user. I do this for profit, not to cover ever last edge case known to man for every "security conscious" consumer of the Web. I worry about the security of my actual users. I worry about giving them the best possible experience. I care that they can use the product and enjoy it and will come back again and again. Javascript is optional for you, but it is not option for my applications. Hundreds of thousands of my users don't seen to mind.
Now if you happen to run across a site which does not handle this properly, that is not shocking in any way. I have found that generally speaking those who disable javascript often complain about sites which extensively use javascript. They say things like "you can't assume that everyone has javascript enabled", "javascript is a security hazard and you can't expect me or anyone else to run a site with such a blatant vulnerability", and "how dare sites use such shotty technology to give an experience, they need to realize we need the same experience but without all of the vulnerabilities". The list of complaints go on and on.
The reality of the situation is this: as someone who makes consumer applications for profit, most of us don't care about you. If you are willing to turn off javascript, you are probably not my target user. If you work in an organization which does something so stupid as to break ssl in order to commit mitm attacks on your own employees in the name of security, you are probably not my target user. I do this for profit, not to cover ever last edge case known to man for every "security conscious" consumer of the Web. I worry about the security of my actual users. I worry about giving them the best possible experience. I care that they can use the product and enjoy it and will come back again and again. Javascript is optional for you, but it is not option for my applications. Hundreds of thousands of my users don't seen to mind.
> nothing in meteor
That's actually very informative. ?I guess www.meteor.com is one of those sites that doesn't handle it properly? I? have no idea.
> Hundreds of thousands of my users don't seen to mind.
Really? Have you asked them?
Hundred of thousands of your users probably have no idea whatsoever what their browser is doing, and it is disingenuous to say that they "don't mind" - especially when javascript is used for things like tracking reading times and other things probably call "analytics" and a lot of us call "spying".
> I worry about the security of my actual users.
Apparently not - you just make sure your users can only be people who know nothing about modern network security.
Remember, I'm not saying javascript applications are bad or that you shouldn't write them[1]. I'm saying you shouldn't leave your precious "user experience" in the case where javascript is not available as a totally-useless, non-informative blank page. Which many sites have started to do, www.meteor.com included. Thqt''S IT. All this arguing about javascript is missing the point.
[1] At most, I only suggested that a lot of the time what is being made is not an application", but a fairly simple document. The only reason javascript could be needed (isntead of progressively enhanced) on something like a simple search page is if you are trying to run spyware (such as google-analytics) in the background, behind the user's back.
That's actually very informative. ?I guess www.meteor.com is one of those sites that doesn't handle it properly? I? have no idea.
> Hundreds of thousands of my users don't seen to mind.
Really? Have you asked them?
Hundred of thousands of your users probably have no idea whatsoever what their browser is doing, and it is disingenuous to say that they "don't mind" - especially when javascript is used for things like tracking reading times and other things probably call "analytics" and a lot of us call "spying".
> I worry about the security of my actual users.
Apparently not - you just make sure your users can only be people who know nothing about modern network security.
Remember, I'm not saying javascript applications are bad or that you shouldn't write them[1]. I'm saying you shouldn't leave your precious "user experience" in the case where javascript is not available as a totally-useless, non-informative blank page. Which many sites have started to do, www.meteor.com included. Thqt''S IT. All this arguing about javascript is missing the point.
[1] At most, I only suggested that a lot of the time what is being made is not an application", but a fairly simple document. The only reason javascript could be needed (isntead of progressively enhanced) on something like a simple search page is if you are trying to run spyware (such as google-analytics) in the background, behind the user's back.
Pretty sure there's a package you can add that automatically does this for you. Not sure if it still works, has been awhile.
Great news that ES6 support is shipping this summer. You can already use Babel, but having everything set up by default, with examples using ES6 will be great.
BTW, I wish there would also be built in support for Typescript. I have done some simple experiments with Meteor and Typescript but it has a do-it-yourself feel abut it. As much as I like Typescript, I will probably just use ES6.
BTW, I wish there would also be built in support for Typescript. I have done some simple experiments with Meteor and Typescript but it has a do-it-yourself feel abut it. As much as I like Typescript, I will probably just use ES6.
Awesome!! never saw this link they've mentioned -
http://react-in-meteor.readthedocs.org/en/latest/
I've been playing with meteor just recently and am totally loving it. I really like Blaze, but love React's component system, so not really sure which way I want to turn now... I'm almost thinking of just implementing a React-like dictionary in Blaze to keep it more 'component' like , because I really dislike the jsx transpiling.
Anyway these announcements are definitely making me more convinced that I should try Meteor in a production app. I see many good things coming for this project.
I've been playing with meteor just recently and am totally loving it. I really like Blaze, but love React's component system, so not really sure which way I want to turn now... I'm almost thinking of just implementing a React-like dictionary in Blaze to keep it more 'component' like , because I really dislike the jsx transpiling.
Anyway these announcements are definitely making me more convinced that I should try Meteor in a production app. I see many good things coming for this project.
Really glad to see React Native mentioned here, albeit briefly.
Hybrid mobile apps like the ones currently supported by Meteor always feel kind of clunky, and the 3rd party implementations of DDP for iOS/Android feel like a workaround and not the Meteor-way of doing things.
Would be interesting to see how React Native is integrated into Meteor.
Though what I really want to see is Blaze Native.
I never used Meteor but I was impressed by this framework 3-4 years ago.
In the last years with the javascript client/side logic growing it looked obsolete in some components.
But now with this new support of the two most popular framework js and the support of Sql I think that is could be get more developers and contributors 'than ever' :)
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.
(I work at Meteor)
I'm sorry! I haven't heard any other reports of an issue like this; what browser/system are you on?
I'm sorry! I haven't heard any other reports of an issue like this; what browser/system are you on?
No worries, really a minor thing but is happening for me on both chrome latest(43.0.2357.130 64bit) and firefox developer 40.0a2 on OS X 10.10.4.
Click log in, pops up a window where I either login or it says "use this account you're logged into?" and then drops me back at the forums with a signup modal(and when I close that, still logged out).
Meteor has been great for me though, you guys are building(have built) a really cool thing.
Click log in, pops up a window where I either login or it says "use this account you're logged into?" and then drops me back at the forums with a signup modal(and when I close that, still logged out).
Meteor has been great for me though, you guys are building(have built) a really cool thing.
> Meteor goes with Angular/React like peanut butter goes with jelly.
Terribly, then. ;)
Terribly, then. ;)
Wow, when did they add database support? I'm pretty surprised it's been done before this release.
"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.
Translation: We're going to support the big JS names the general public is most aware of, because... well... please, use Meteor.
Yeah! I knew it wasn't just my gut feeling when I went ALL THE WAY with Meteor :)
tldr: ES6 = standard, SQL support is coming, faster builds and mobile toolchain development a priority. Reactive rendering with Blaze, Angular or React + Meteor is available.
SQL support has always been "coming." It's been on their Trello roadmap for more than a year. The specific messaging in this post is that the new version of Meteor is coming late this summer, will not include SQL support, but that SQL support is something on their radar for the future (late in the year? next year?)
That bit is not news or anything new.
That bit is not news or anything new.
I think the intention is to signal that SQL is likely to be one of the things we work on immediately after 1.2 is released.
I started to use meteor a month or so ago.
For a person like me, from Java Enterprise land, this tool is refreshing. Glad to see new goodness is coming, especially SQL support.
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.
Take a look at DDP, one of the core building-blocks of Meteor: https://www.meteor.com/ddp
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.
Take a look at DDP, one of the core building-blocks of Meteor: https://www.meteor.com/ddp
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?
Yes, you totally can, but I found running one command:
curl https://install.meteor.com/ | sh
so much quicker (in the short term and long term) than reading a myriad of tutorials and then bashing my head against this configuration of several products for multiple weeks to get what Meteor provides as part of a single maintained and updated system.
curl https://install.meteor.com/ | sh
so much quicker (in the short term and long term) than reading a myriad of tutorials and then bashing my head against this configuration of several products for multiple weeks to get what Meteor provides as part of a single maintained and updated system.
If you're willing to wait for a client-server round trip to visibly see your changes, then sure. Otherwise, you'll need a way to temporarily (optimistically) change your in-browser data model with the updates while waiting for the server to commit your changes, then figure out a way to reconcile the server commit of v2 while you might have done v3 on the client in the meantime... Optimistic updates are not at all trivial. Meteor has a ton of code that basically runs an in-RAM version of MongoDB and keeps it in sync with the server.
It turns out to not be that simple. My coworker Slava has a talk about exactly this question: http://info.meteor.com/blog/what-does-it-mean-to-be-a-real-t...
(I work at Meteor)
(I work at Meteor)
You'll still miss out on the client side optimistic updates.
I think the main benefit of Meteor is not that it's impossible to do what it does with other libraries/frameworks, but how easy it makes those things for you.
I think the main benefit of Meteor is not that it's impossible to do what it does with other libraries/frameworks, but how easy it makes those things for you.
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.
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.
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.
There's Simperium (disclaimer: I was a cofounder, YC S10). It's powering optimistic sync for millions of users of Simplenote and WordPress.com. It has JavaScript[1] and Python[2] libs, but its strength is iOS[3] and Android[4].
The team focused on internal use though, and hasn't had a chance to open source the backend and flesh out the web side of things. I hope they get a chance to do another iteration (we were bought by Automattic/WordPress and I'm no longer there).
[1] https://github.com/Simperium/simperium-ios
[2] https://github.com/Simperium/simperium-android
[3] https://github.com/Simperium/simperium-js
[4] https://github.com/Simperium/simperium-python
The team focused on internal use though, and hasn't had a chance to open source the backend and flesh out the web side of things. I hope they get a chance to do another iteration (we were bought by Automattic/WordPress and I'm no longer there).
[1] https://github.com/Simperium/simperium-ios
[2] https://github.com/Simperium/simperium-android
[3] https://github.com/Simperium/simperium-js
[4] https://github.com/Simperium/simperium-python
Neat. Thanks for the pointer!
I had a good look for a library that does this for the app I'm currently working on, before giving up and creating a custom solution myself. My implementation is very much custom-fitted to my particular backend api and the way I'm rendering the view layer with React.
I think a large part of the reason such standalone libraries might not exist yet, is that it's really difficult to make a general, flexible, tech agnostic solution to this problem - as you've highlighted this is probably why Meteor's implementation is so tightly coupled with Mongo and why SQL integration is taking a while (assuming, surely, it must be a pretty high-priority feature on their roadmap).
In other words such a library is likely to be so prescriptive on how the rest of the stack, particularly the backend, fits around it that it only really makes sense as part of a full-stack framework, or at the very least a prescriptive full-stack architecture.
I think a large part of the reason such standalone libraries might not exist yet, is that it's really difficult to make a general, flexible, tech agnostic solution to this problem - as you've highlighted this is probably why Meteor's implementation is so tightly coupled with Mongo and why SQL integration is taking a while (assuming, surely, it must be a pretty high-priority feature on their roadmap).
In other words such a library is likely to be so prescriptive on how the rest of the stack, particularly the backend, fits around it that it only really makes sense as part of a full-stack framework, or at the very least a prescriptive full-stack architecture.
That's basically my take on it, and we also have a bunch of custom code to do similar things piecemeal, but it doesn't work very well and I envy Meteor's solution, while remaining unprepared to jump onto the framework in its entirety. But lots of "really difficult" things have been accomplished in the past, so I'm still hoping to come across a "general, flexible, tech agnostic solution to this problem" at some point!
The web components spec is starting to look like a huge mess in comparison with modern JS framework component models. I think it's unlikely web components will much traction as a first tier approach to application development.
Sure. Meteor can be used to implement your backend, frontend, or both frontend & backend. Web components are a frontend concept only [from what I understand]. Meteor's frontend code can "bind" to your backend, and render real time data updates.... while web components have no concept of "backend" at all.
There could also be a desire to wrap multiple web components into an Angular directive, or wrap multiple Angular directives into a meteor module, etc.
There could also be a desire to wrap multiple web components into an Angular directive, or wrap multiple Angular directives into a meteor module, etc.
Meteor isn't MVC.
And yet they still tell people to install Meteor by piping to their shell. Incredible.
http://curlpipesh.tumblr.com/
https://paragonie.com/files/blog/pipeshell.jpg
http://curlpipesh.tumblr.com/
https://paragonie.com/files/blog/pipeshell.jpg
There's nothing it can do more than downloading a binary and running it and it asking you to run it as root.
Except piping to shell is more convenient.
Except piping to shell is more convenient.
That's a pretty common thing. I don't see the problem.
Docker addressed this last week at dockercon, announcing Docker Notary to securely publish and verify content.
https://github.com/docker/notary
https://github.com/docker/notary
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?
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?
> 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.
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 https URL is not the worst thing in the world.
Personally I think curl of an https URL is not the worst thing in the world.
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.
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.
I understand exactly how it works. How do you get a code-signing paradigm down to something as simple as curl | sh though? (Well not as simple, but still a human-readable one-liner that works on nearly all Linux systems.)
I thought maybe a single-line invocation might piggy-back on SSL as follows:
- get a server's public key that is not online or able to answer requests (because if it were it couldn't be airgapped)
- but still use the key to verify the script that's downloaded from the server that is online.
- only pass the code to sh if it was properly signed by the offline server.
Then the offline server could be "https://key.meteor.com" and the private key wouldn't have to be anywhere but an airgapped machine.
I don't know if there is more of the SSL infrastructure that I'm missing though (I'm not an expert) or if this could practically be reduced down to a tamper-evident one-liner (a la curl https://install.meteor.com | sh). It would be a marked improvement over just passing anything from a potentially compromised server straight to bash though!
I thought maybe a single-line invocation might piggy-back on SSL as follows:
- get a server's public key that is not online or able to answer requests (because if it were it couldn't be airgapped)
- but still use the key to verify the script that's downloaded from the server that is online.
- only pass the code to sh if it was properly signed by the offline server.
Then the offline server could be "https://key.meteor.com" and the private key wouldn't have to be anywhere but an airgapped machine.
I don't know if there is more of the SSL infrastructure that I'm missing though (I'm not an expert) or if this could practically be reduced down to a tamper-evident one-liner (a la curl https://install.meteor.com | sh). It would be a marked improvement over just passing anything from a potentially compromised server straight to bash though!
> How do you get a code-signing paradigm down to something as simple as curl | sh though? (Well not as simple, but still a human-readable one-liner that works on nearly all Linux systems.)
You don't, really. Not currently anyway. Retrieving a binary/archive and doing out-of-band verification are two logically separate steps.
The problem with your suggestion is that SSL is about transport security. It verifies that you are talking to the right server, but does not provide any guarantees beyond that.
It's not really possible to shoehorn release signing into that, without additional infrastructure.
It doesn't matter how you combine things - the server and the signing system are (and should be!) two separate entities, and you cannot rely on the server to tell you who the signing system is (because that'd give you no better security than not having a signing system at all).
> It would be a marked improvement over just passing anything from a potentially compromised server straight to bash though!
It wouldn't, because as far as I can tell, you're still relying on the server to tell you what the correct release signing key is. How else would you obtain it?
You don't, really. Not currently anyway. Retrieving a binary/archive and doing out-of-band verification are two logically separate steps.
The problem with your suggestion is that SSL is about transport security. It verifies that you are talking to the right server, but does not provide any guarantees beyond that.
It's not really possible to shoehorn release signing into that, without additional infrastructure.
It doesn't matter how you combine things - the server and the signing system are (and should be!) two separate entities, and you cannot rely on the server to tell you who the signing system is (because that'd give you no better security than not having a signing system at all).
> It would be a marked improvement over just passing anything from a potentially compromised server straight to bash though!
It wouldn't, because as far as I can tell, you're still relying on the server to tell you what the correct release signing key is. How else would you obtain it?
thanks - drop me a line and I'll reply, this thread is getting old and deep. thanks for your thoughts though and hope you do write.
That's exactly what docker notary is.
sarciszewski(2)
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.
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.
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.
> What do you want them to do?
I want them to not use a one-liner. Step-by-step:
1. Download the files
2. Download the public key
2a. verify the public key if you've never seen it before (publish in the blockchain, have lots of high profile technologists sign it, etc)
3. If the verification matches, then proceed.
Teaching developers to value "clever one-liner hack" over "secure, dependable solution" will lead to bad habits.
I want them to not use a one-liner. Step-by-step:
1. Download the files
2. Download the public key
2a. verify the public key if you've never seen it before (publish in the blockchain, have lots of high profile technologists sign it, etc)
3. If the verification matches, then proceed.
Teaching developers to value "clever one-liner hack" over "secure, dependable solution" will lead to bad habits.
if you're going to include "2a" you can refactor all of your steps into:
1. Google "meteor.com compromised" and decide whether it's currently compromised. If it isn't:
2. Run curl https://install.meteor.com|sh
It saves a few steps and is equally secure - you know, since you're just going to go based on what other people think and include no programmatic check whatsoever. (your 2a).
1. Google "meteor.com compromised" and decide whether it's currently compromised. If it isn't:
2. Run curl https://install.meteor.com|sh
It saves a few steps and is equally secure - you know, since you're just going to go based on what other people think and include no programmatic check whatsoever. (your 2a).
2a can be swapped out for a better PKI system at any time. Relying on whether it's public knowledge that Meteor is compromised or not is not nearly as resilient.
so swap it out for a better PKI system. There is literally nothing in any of your steps that can't be automated, except for the totally nebulous 2a "publish in the blockchain, have lots of high profile technologists sign it" which 9/10 people are not qualified to judge.
There is no reason you couldn't automate your whole suggestion, except for that one, which makes it infeasible and open to all manner of social engineering.
There is no reason you couldn't automate your whole suggestion, except for that one, which makes it infeasible and open to all manner of social engineering.
[deleted]
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.
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)
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)
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 ?
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.
https://github.com/paragonie/password_lock/blob/master/run-t...
^- For the record, I keep scripts like this in my Git repositories.
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 on another server it would be a piece of cake.
An example file of code for the records overview (dashboard was a bit tabby-spacey): https://github.com/liamzebedee/metric/blob/master/client/fea...
An example file of code for the records overview (dashboard was a bit tabby-spacey): https://github.com/liamzebedee/metric/blob/master/client/fea...
Oh man, mixing tabs and spaces...
React and Meteor work really well together. It's a lot less painful than trying to use Flux with an API backend. Super productive. Can't wait for SQL support and for them to FINALLY fix the build speed.
React and Meteor work really well together. It's a lot less painful than trying to use Flux with an API backend. Super productive. Can't wait for SQL support and for them to FINALLY fix the build speed.
You caught my attention with this "alot less painful than trying to use Flux with an API backend" Can you elaborate a bit on how you architect your apps with Meteor and React?
I've typically tied my Flux Action layer to my api backend (where my ajax code goes) which then dispatches to the Store layer, then the View (react components) listens to that...
With Meteor where are you hooking your api backend into the react components? I'm a little lost looking for decent examples of different Meteor/React architectures.
I've typically tied my Flux Action layer to my api backend (where my ajax code goes) which then dispatches to the Store layer, then the View (react components) listens to that...
With Meteor where are you hooking your api backend into the react components? I'm a little lost looking for decent examples of different Meteor/React architectures.
In fact, there was a blog post just written about this! http://info.meteor.com/blog/meteor-the-missing-infrastructur...
Cool Thanks! Do you know if there are any plans to make a sample app on github for us to follow?
I'll try to do a rewrite of the example todo app using this for practice. Seems like I have a bit to read since this would seem to change the standard flow I'm currently using in my Flux pattern. Actually stumbled across this thread which gives some good reading as well - https://forums.meteor.com/t/meteorflux-flow/920/63.
I'll try to do a rewrite of the example todo app using this for practice. Seems like I have a bit to read since this would seem to change the standard flow I'm currently using in my Flux pattern. Actually stumbled across this thread which gives some good reading as well - https://forums.meteor.com/t/meteorflux-flow/920/63.
How are they mixed? It looks like only tabs to me.
Yeah, they were fixed after my comment. Actually, not sure why it isn't in the history for the file, but I know for a fact that the link provided mixed them.
How is the performance ? For me something like Atom feels very sloppy compared to Textmate / Sublime
Have you tried Atom since they shipped version 1.0? It's been sped up a LOT.
However, I don't really think that this topic has much to do with React / Meteor, as Meteor is a full-stack web-solution, Atom is a desktop text-editor built with web technologies (and specifically React)... It's like saying my Ferrari goes faster than your boat, yup, on land.
However, I don't really think that this topic has much to do with React / Meteor, as Meteor is a full-stack web-solution, Atom is a desktop text-editor built with web technologies (and specifically React)... It's like saying my Ferrari goes faster than your boat, yup, on land.
I know but i have commented on a guy's post talking about building desktop web apps.
Also yes i have tried the latest Atom's version. I am not bashing it's just that i feel that the performance is still worse than the native solution (obviously).
Also yes i have tried the latest Atom's version. I am not bashing it's just that i feel that the performance is still worse than the native solution (obviously).
Well I think it's a different - my app really only deals with very simple form inputs and interactive views, there's no performance issue to think of. Text editors deal with file systems, buffers, displaying text, plugins, a bunch of other things.
That being said, I get two threads inherently as a result of the client-server separation, and on the Meteor server you can properly parallelize the work as a result of its Node foundations.
That being said, I get two threads inherently as a result of the client-server separation, and on the Meteor server you can properly parallelize the work as a result of its Node foundations.
Why do you ask about Atom performance?
Not sure if I understand the reasons, BTW FYI they recently stripped off react in favor of plain DOM for performane reasons: https://news.ycombinator.com/item?id=9117028
Not sure if I understand the reasons, BTW FYI they recently stripped off react in favor of plain DOM for performane reasons: https://news.ycombinator.com/item?id=9117028
In the meantime check out this for data sync:
https://github.com/charlieschwabacher/ultrawave
https://github.com/charlieschwabacher/ultrawave
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.