Hacker News Reader

Comment by phillmv | Hacker News Reader

>Why are you sending the full file contents from the agent to the client?

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.

View on HN

"You're not going to be storing any sensitive information in your Gemfile.locks"

That's not accurate. When using private gems hosted on github one of the common approaches is to use this in your Gemfile (which shows up in the lock):

gem 'my_private_gem', :git => 'https://github_user:cool_password@github.com/organization/my...

Right. I should've been prepared for this response. I can't confirm whether that shows up in your Gemfile.lock but I can say that you really shouldn't be doing this and switch to keys.

We'll likely add a check to beg you to change this in the near future should it show up.

I agree with you there but to this point at least, I haven't seen another good way to handle this with something like Heroku. It does show in the Gemfile.lock though (just verified).

Looking around I did just find a buildpack that tries to solve the problem. That doesn't really apply when using your service on my own servers though.

https://github.com/siassaj/heroku-buildpack-git-deploy-keys

I guess the bigger question is simply, are you going to limit your audience only to people already following best practices?

An SSL when transferring over these files, just based on the rest of the responses in this thread, would seem to make a lot of people feel better about the service.

>I guess the bigger question is simply, are you going to limit your audience only to people already following best practices?

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!

So is the idea here that you're just monitoring the libraries my web application is using? So for example:

1. I have library X version 1.2.3 in package.json.

2. My package.json file gets sent to you

3. You parse this file, and tell me library X version 1.2.3 has a vulnerability, and that I should upgrade

AppCanary then doesn't monitor for the fact I have an outdated version of httpd for example?

>AppCanary then doesn't monitor for the fact I have an outdated version of httpd for example?

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.

Reply on news.ycombinator.com