What does HackerNews think of tripwire-open-source?

Open Source Tripwire®

Language: C++

#38 in Security
#5 in Security
I'm looking at current options, this[1] for example is packaged for Fedora, which is my daily driver.

But then I got to thinking, if I'm going to do a clean Fedora install for the tripwire (it's best practice) I might as well try Fedora Silverblue[2]. Silverblue is an immutable system so it kinda makes a tripwire less useful because no one can change any system files. Only files in your home directory and /etc can be modified statefully.

1. https://github.com/Tripwire/tripwire-open-source/

2. https://silverblue.fedoraproject.org/

This reminds me of the general idea behind Tripwire[1] for macOS. I last looked into it back in 2005 (we went with other approaches), so it may have changed since then, but it monitors for changes, and allow you to revert them or deploy them to other computer (as in a lab, etc).

[1] https://github.com/Tripwire/tripwire-open-source

You could also use a generic File integrity monitor for something like this (e.g. tripwire https://github.com/Tripwire/tripwire-open-source )
You can just set up Tripwire to do this sort of thing. It's in most distro package managers.

https://github.com/Tripwire/tripwire-open-source/#open-sourc...

What that won't do is save you from malicious code inserted into 3rd party content (script libraries, etc.) that you load from a CDN. If you're worried about that, you should make a copy of a verified version and serve it yourself.

It's a little odd to not benchmark backup over the network - a backup taken to the same physical disk as the source of the data isn't very useful - for that use-case taking a filesystem snapshot[s] would probably be faster and more useful. Perhaps in combination with a checksumming tool, like [c], or with a filesystem like ZFS.

Also, it can be difficult in a lot of environments to sustain more than 100mbps write to a remote, off-site system - halving the stored data can be a much bigger win then.

All that said, it's interesting to see that a) duplicity seems slow, and b) very consistent in terms of speed. I wonder if there's some low-hanging fruit for optimization there.

Personally I've had some luck using backupninja[b] in combination with duplicity. It's one of the few Free alternatives that allow the backup-system to encrypt "one-way" - so that compromising the backup-system doesn't immediately give read access to encrypted backups. It's a bit complicated to set it up for separate encrypt-to and signing keys though :/

[s] Today I would probably recommend ZFS - but I've always wanted to give NILFS2 a real test, especially on solid-state disks: http://nilfs.osdn.jp/en/

[c] https://github.com/Tripwire/tripwire-open-source

http://aide.sourceforge.net/

https://github.com/integrit/integrit (Speaking of projects that might be fun/useful to redo in a safe language like rust or go - it would appear this would be a prime example, btw. On the whole moving integrity to the fs, as with zfs might be the better option, though).

[b] https://0xacab.org/riseuplabs/backupninja