(DO BE DELETED when #296 is in) Stack Evidence types#261
Conversation
…y break evidence postprocessing down the line
aarontp
left a comment
There was a problem hiding this comment.
LG in general, but I think there's one method invocation that still needs to change. I'll take a closer look at your state management code tomorrow to see if there's something similar we can do. Another option might be to keep a chain of Evidence, and when new Evidence is created we can pass in the previous evidence as a linked parent. There's gotta be a way we can use blockchains to solve this, ;)
| google_cloud.PostprocessDetachDisk(self.disk_name, self.local_path) | ||
| mount_local.PostprocessUnmountPath(self.mount_path) | ||
| mount_local.PostprocessDeleteLosetup(self.loopdevice_path) | ||
| super(GoogleCloudDiskRawEmbedded, self).post() |
There was a problem hiding this comment.
Shouldn't this be postprocess()?
There was a problem hiding this comment.
yest it should. fixed
|
Sorry, I didn't get a chance to review this today. I got side tracked by
writing some test code to see what linking evidence chains together might
look like, and passing the whole chain around instead. What do you think
of that idea? I can't remember if we had talked about that before. Maybe
if you're going to be around tomorrow morning my time we could chat about
it?
…On Wed, Oct 3, 2018, 6:54 AM Romain Gayon ***@***.***> wrote:
@rgayon <https://github.com/rgayon> requested your review on:
google/turbinia#261 <#261> Stack
Evidence types.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#261 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ACiyuy9sLO9s3YYP2NB-ZHDLxSzc57YBks5uhMF7gaJpZM4W3Gbp>
.
|
|
That's also one other approach I had in mind for sharing context, but then there has to be a way to make sure an "Evidence consuming & generating task" doesn't post process an input Evidence until the new output evidence has been analyzed by all the other tasks. |
|
This is obsolete now, replaced by #296 |
Evidence types are "stacked". As in, Evidence1 inheriting Evidence2, will call its parent's pre & post processor.
We also add a "copy context" method, that should be called when a new Evidence "Child" is generated in a Task that is currently analyzing Evidence "Parent", that will be processed by other types. This method ensures the state of Parent is passed down to Children, so that all required post&pre processing will be done properly, to access data in Children.
The problem with the current solution is that new Evidence types are expected to properly implement this method, while making sure to not overwrite its parent attribute.
One solution I found is https://gist.github.com/rgayon/f1af6b32c316a67f72a37697a3c7e4c9 albeit quite disgusting :(