Hi, Thanks for the bug report. Normally, such bugs should be reported to secur...@debian.org with the package maintainer in CC instead of in a public bug tracker, but let's deal with it now that it's public...
I can confirm the bug: doing a checkout or a reset exposes private files in `/etc` to all users, bypassing metadata saved in `/etc/.etckeeper`. A workaround is to setup the `20restore-etckeeper` script as a post-checkout, post-merge and post-commit hooks: ln -s /etc/etckeeper/init.d/20restore-etckeeper /etc/.git/hooks/post-checkout ln -s /etc/etckeeper/init.d/20restore-etckeeper /etc/.git/hooks/post-commit ln -s /etc/etckeeper/init.d/20restore-etckeeper /etc/.git/hooks/post-merge Unfortunately, no git hook is ran when you do git reset: https://stackoverflow.com/questions/17247402/is-there-a-git-hook-that-runs-on-git-reset So basically, we are screwed: there's no way for etckeeper to fix this bug for all git commands. This would be a git bug, I believe... I'm hesitant in doing an upload that "fixes" this because it will give a false sense of security: some commands will work, others won't. I'd love to hear from Joey, the upstream author, about how to fix this better. The only other thing i could think of that may fix this are smudge filters, that run whenever code is checked out. In any case, any of those hacks will make any working tree operations much slower because the above hook runs *all* the permission changes, not only the relevant ones... Any other bright ideas? A. -- Imagination is more important than knowledge - Albert Einstein -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
