3 ms·
Many thanks for the feedback on the site, perhaps we need to get some more dense technical details either on there directly or adding to the existing docs on th
by droptical 6y ago
Many thanks for the feedback on the site, perhaps we need to get some more dense technical details either on there directly or adding to the existing docs on the github repo.
Command pattern is definitely one pattern we've seen these tamper-evident logs applied to; you can easily imagine a system where, say, config update "commands" are packaged off and written to a TE log, and then workers apply those commands to a system if and only if they are convinced that the commands were properly logged. If the admins/command-workers/auditors etc. can all prove they're looking at the same set of logged commands (which is the property that these tamper-evident logs are intended to provide), then you have a reliable and tamper-evident audit trail of all changes to your system.
There are a bunch of other scenarios we think these things might be useful for too, and we're trying to explore (and help others explore) these and provide mechanisms for reasoning about the properties of such systems.
[Disclaimer: I work on CT, Trillian, and other related projects]
- jacques_chester 6y ago> Command pattern is definitely one pattern we've seen these tamper-evident logs applied to; you can easily imagine a system where, say, config update "commands" are packaged off and written to a TE log, and then workers apply those commands to a system if and only if they are convinced that the commands were properly logged. Tip: call it LogOps and engage in an exercise-yard shiv-fight with GitOps folks. I prefer to think of both as examples of WAL or intent logs. It's a useful pattern and it's nice to have a narrowly-focused tool for it.