>Thinking of supporting package.json and bower files?
Definitely! We're building a service to monitor your app and server's dependencies, and we currently support Ubuntu and Ruby.
Our goal is to cover basically all of open source :).
5,445 karma · joined June 21, 2009
phillmv [at] okayfail.com https://hachyderm.io/@phillmv
formerly appcanary (S15)
Definitely! We're building a service to monitor your app and server's dependencies, and we currently support Ubuntu and Ruby.
Our goal is to cover basically all of open source :).
It seems like a lot of people would love to have an easy way to integrate this into their continuous integration services, for instance - and we're working on making that a Real Thing That Exists.
If you want to get a personal email when it comes out, put "API" in the platform field in the email form on the link above.
We figured we could do a better job all around if we managed to productize it.
It is a service! Visit https://appcanary.com for more deets.
We're expanding platforms, so do tell us what to support next :).
No, of course not! We desperately want to bring people into best practices.
Most people are simply unaware of what they're doing wrong - or have no good means of knowing what to improve.
It's our great hope we can improve everybody's security.
>An SSL when transferring over these files
Yup! All communication happens over SSL :D.
We have elaborate plans to even add certificate pinning to the agent but that's on pause until we sort out larger infrastructure architecture.
Thanks for pointing that out as well. I've noted this elsewhere, but communicating how much effort we've poured into this is hard!
We'll likely add a check to beg you to change this in the near future should it show up.
It does! So long as you've installed it via the package manager. Right now we support Ubuntu, and Debian will be out soon and RHEL systems in the very near future.
In the near future we'll add the ability to scan hand-compiled binaries, but that's a technical challenge that depends on solving the first part of the equation (knowing what's vulnerable) really well.
1. We only send files you tell us to send in the configuration, and you're not going to be storing any sensitive information in your Gemfile.locks or package.jsons.
It's not functionally any different from us parsing it client side - but allows us to support new platforms without having to update the agent.
>CRC is not a hashing algorithm.
2. You're absolutely correct! Which is why we're not using it as a cryptographic hash, i.e. as part of an HMAC.
We're only using CRCs to determine if a file has changed, which is the purpose of CRCs :).
Do you have any other concerns? We've spent a lot of time being paranoid, and we know it's a hard communication problem.
We used to work as security consultants, so we're more experienced than most, and we're working hard to be transparent and above board.
As we grow, we'll definitely be conducting regular audits of our infrastructure.
But! We're not yet launched, and I'm pretty easy to google :).
We'll probably end up sitting on your host and taking a peek inside your container filesystems.
If you can handle the downtime, unattended-upgrades will work just dandy. If your postgres restarting in the middle of the night gives you pause, our service can help you choose how to roll out your security upgrades.
2. We cover app dependencies as well! For now just Ruby, but others as well pretty soon.
I'm one of the maintainers of the Ruby Advisory Database https://github.com/rubysec/ruby-advisory-db/ - and we know all about the effort involved.
It's definitely a leg up over just being spammed by pkg audit.
Further, we also cover your app dependencies :).
It's on the roadmap! Others have mentioned that before. First we need to get really good at knowing about CVEs :).
You always have to leave a little room for the holy spirit.
Ya, that's fair and a good suggestion. I think we may very well end up doing something like that. We're still trying to figure out what kind of model best suits the server fleets people have.
We'll be keeping the first server free, and probably have a not for profit tier.
We currently support Ruby, and in the next three months we'll have Javaland and Python and Node.
Right now most of our data is oriented around patch releases, so it can vary, but in near future we'll be reducing that distance.
If you're a random company, you have an engineer sitting around whose job involves reading a dozen mailing lists - and we want to save everyone from that redundancy.
We understand how some people might have problems / have plans to improve upon it - maybe we run a proxy or some kind of enterprise edition.
But we think the main pain relief comes from knowing what you have deployed is now fixed.
appCanary monitors the software on your servers and notifies you when you have to take action. In a previous life, we spent a lot of time worrying about what needs to be updated where and so we built this.
We currently let you know about Ruby vulns deployed on any linux, and vulnerable packages if you run Ubuntu. Support for Docker and other vuln sources is just around the corner.
We'd love to hear your feedback!
No, most of the value in a home comes from the land underneath it. The point being made above is that the availability of credit leads to asset inflation, as more people are able to compete for the same scarce things (desirable living locations).
Mind you, credit does have a purpose - if your income and your house's value appreciate faster than the interest rate being charged to you, then you were able to gather the resources for it.
Just that it will be doing better than if don't forgive its debt.
Of course. You earn more than enough Francs to cover your expenses; it's just cheaper to borrow money right now than to convert from Pesos.
> If yes, is there any reason to keep the peso account locked up (for lack of a better term) in liquid assets? Perhaps you'd be better served by taking risks with that money?
The problem is precisely that: there's no good place to put that much money. Apple literally can't think of enough things to put all that money to use. Interest inflation rates are pretty low, so keeping it in TBills or whatever isn't really hurting them.
That at least, is my understanding.
Cabinet members for instance make about $200,000 - which is not comparable to executive salaries in 2015.
1. My understanding is that by the time Minecraft _utterly_ blew up they had a full fledged company going. Some people were probably there from the "a million or two" to "hundreds of millions" of dollars transition.
2. Notch didn't really have a lot of risk going. He wrote a game and it blew up and he hired people off the preorders.
3. Notch got lucky. It's not clear that he's an especially savvy business person, or manager, or etc. He owned most of the IP, but… he had an idea that was waiting to happen, and then it went supernova and infected the minds of most children in the western hemisphere.
If you sacrificed nights and weekends to get the thing to ship, and massaged it into production, and wrote most of the code, and strung most of the deals together, and basically made it work beyond a crashy demo… and it was all just dumb luck anyways, I think it's perfectly natural, human reaction to be resentful that your boss made an insane killing when he rage quit and didn't share much of it.
¯\_(ツ)_/¯ tricky to navigate
"Speed" as determined by rendering stuff to a page is actually something we can determine. Is it not possible to simply trace the framework execution? What's the point of having silly hype pieces back and forth when we're debating trivial examples that ought to be not too difficult to measure?
Finally, wrt to React: it's just a view layer. Comparing it to Ember or Angular as if it were a fully fledged, swappable alternative doesn't really make sense.