Thanks! I already emailed unicorn-public@yhbt.net.

My message is in the public archive here: https://yhbt.net/unicorn-public/20251227071714.D9328160070@m...

That’s a great real-world story. Exactly the kind of unexpected modification FIM can help surface—not only security incidents, but also operational surprises.

Compliance is definitely one use case, but not the only one. It’s also useful for catching unexpected local changes in real-world operations. The goal is to provide a lightweight FIM that can be added to existing apps without too much friction.

Conceptually it’s the same as sha256sum, but Kekkai automates the workflow:

hashes recorded automatically at deploy,

stored in S3 with write/read separation,

verification runs regularly. It saves you from scripting all of that by hand.

By fast I mean two things:

Files are hashed in parallel, so large sets can be processed quickly.

On repeated runs, unchanged files skip hashing with a default 90% probability using a cache. This keeps checks lightweight even at scale

You’re right that this doesn’t prevent compromise—it’s a detection control, not prevention. Things like read-only mounts or immutable bits are great, but in practice issues like command injection or misconfigured deployments still happen. FIM helps you know when files were changed and provides evidence for investigation or compliance.

AIDE is a solid and mature tool. Kekkai focuses on being lightweight:

content-only hashing to avoid false positives,

S3 integration with strict write/read separation,

a single Go binary with minimal dependencies. It’s designed to be easy to deploy and run in production.

Thank you for your reply.

I was thinking about whether to return an error. If we can’t find a UTF-8 start byte in the nearby 4 bytes, it’s unclear what to return. I thought maybe we could ignore this problem.

I don’t return the string itself because I don’t know if users want the start or the end of the string. Also, I want to avoid copying large strings. It’s up to the users how they use this function.

Since no one is using this package yet, we might consider changing the interface.

> I was thinking about whether to return an error. If we can’t find a UTF-8 start byte in the nearby 4 bytes, it’s unclear what to return. I thought maybe we could ignore this problem.

This highly depends on the use case, and your stated use case doesn't seem to need any sort of error.

> Also, I want to avoid copying large strings.

Go strings are not copied in that way; they are implemented like immutable slices [1].

[1] https://research.swtch.com/godata

Thank you for your feedback. The current implementation of purl uses Go's regexp package for regex operations, which ensures consistent behavior across platforms. I acknowledge the README does not specify this yet, and I plan to update it to clarify the regex implementation used.

Thank you for trying out purl! Currently, the file name needs to be placed at the end of the command like this: purl -filter func main.go. This format helps purl understand which part of the command specifies the options and which part specifies the file.

I appreciate your feedback and understand that a more flexible command structure might be easier for users. We will consider making this change in future versions to accommodate different usage preferences.