>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.
"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):
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.
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.
>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.
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.