| |||||||||||||
The Journal - a proposed syslog replacementThe Journal - a proposed syslog replacementPosted Nov 21, 2011 15:47 UTC (Mon) by johill (subscriber, #25196)In reply to: The Journal - a proposed syslog replacement by nix Parent article: The Journal - a proposed syslog replacement
This is an important observation -- I thought about this too (but never posted), especially wrt. the comparison they make to git. The thing is this though: in git, the HEAD is essentially recorded at many places around the world -- rewriting the tree will be detected by everybody. In a journal, such a forward-running checksum scheme is completely useless as you point out since nobody has a copy of the HEAD sha1sum.
Looks like either we're not being told the full picture or somebody got confused about why exactly this useful in git.
(To make it secure though you don't need to store *all* hashes elsewhere, you just need to send off the most current HEAD hash to secure storage, still the same problem though.)
(Log in to post comments)
The Journal - a proposed syslog replacement Posted Nov 21, 2011 15:50 UTC (Mon) by johill (subscriber, #25196) [Link]
I note that they do say this though in their document, albeit a bit veiled (and the comparison to git was only made at KS I guess): "If the top-most hash is regularly saved to a secure write-only location, the full chain is authenticated by it."
It doesn't seem likely that anyone will ever have as easy ways to do that as with git.
The Journal - a proposed syslog replacement Posted Nov 22, 2011 4:26 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
Actually, you're on the right track!
Make a central PUBLIC server that simply accepts and stores triples of form: <host_id, timestamp, hash> (host_id is UUID).
That's it. You can use this public server to periodically send your hashes. You lose (almost) no privacy, since log messages themselves need not to be replicated.
|
|||||||||||||