Why are you sending the full file contents from the agent to the client?
https://github.com/appcanary/agent/blob/master/agent/agent.g... agent.client.SendFile(file.Path, file.Kind, contents)
Extremely insecure design with a ton of unnecessary overhead. What if those files are configuration files with sensitive data embedded?
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.
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?
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.
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...
We'll likely add a check to beg you to change this in the near future should it show up.
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.
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!