Secure project local kakrc with trusted hashes

So I know most people already have something in their config that can load configuration (like a file called .kakrc) that’s stored in certain projects. However, this has some security problems, because Kakoune can execute arbitrary shell commands. So I created a plugin called secure-local-kakrc to solve the problem.

My plugin (besides checking for and loading a .kakrc file) actually maintains a simple trust database. When an unknown .kakrc is found, it’s never loaded, and the user is notified. The user can easily review the file and then add it to the trust database. Better yet, trust entries are associated with the file’s hash, meaning that if the .kakrc in a trusted project changes, it won’t be loaded until the user has re-trusted it.

I’ve also written an accompanying blog post that contains a security analysis and documents my thought process, available on my website. I welcome any feedback and contributions!

4 Likes

nice

also, there are tools like direnv, ondir, autoenv could help on this

Yes, but I wanted something that was integrated into my kakoune config and without any external dependencies.

1 Like

This is what I use, I have Kakoune source a $KAKOUNE_LOCAL_RC file that’s defined in the per-project .envrc. Direnv handles the .envrc authorization.

I wonder if this plugin would be better. I always forget to use the above env variable.

The direnv approach makes sense. However I don’t think it does anything to account for the local RC file changing since the last trust. My implementation stores the hash of the last trusted version, so if the file has changed at all the user needs to explicitly :trust it.

2 Likes

That’s a good point! I never considered that limitation of direnv.

Direnv could use some option to do something similar. Maybe watch_file (from direnv-stdlib) should make direnv re-ask for allowing (by storing the file’s hash/checking if it changes), or maybe there should be a watch_file_strict variant that does the same.

EDIT: Found a relevant issue in direnv’s GitHub repo

you are right.

+1 for security