I don't really understand the use case for this. Despite all the details in the README, there are only a couple sentences devoted to describing what it's actually for, and they don't make much sense to me.
You're assuming that an attacker already has access to your system, and you want to detect any changes they make to certain files.
If you are dealing with a relatively unsophisticated attacker, surely it would be easier to just mount the data that shouldn't be changed on a read-only filesystem, or set the immutable bit?
And if the attacker is sophisticated, surely they could just disable the verifier? Or replace it with a no-op that doesn't actually check hashes?
> Many web apps (PHP, Ruby, Python, etc.) on AWS EC2 need a lightweight way to confirm their code hasn’t been changed.
I don't think this is true, any more than the square-root function needs a way to confirm that its argument hasn't been tampered with. You're solving the problem in the wrong place. It seems like security theater.
You're assuming that an attacker already has access to your system, and you want to detect any changes they make to certain files.
If you are dealing with a relatively unsophisticated attacker, surely it would be easier to just mount the data that shouldn't be changed on a read-only filesystem, or set the immutable bit?
And if the attacker is sophisticated, surely they could just disable the verifier? Or replace it with a no-op that doesn't actually check hashes?
> Many web apps (PHP, Ruby, Python, etc.) on AWS EC2 need a lightweight way to confirm their code hasn’t been changed.
I don't think this is true, any more than the square-root function needs a way to confirm that its argument hasn't been tampered with. You're solving the problem in the wrong place. It seems like security theater.