Max Fisher
Max Fisher
We should have a "boring" outer dict containing very basic metadata such as schema version, time that the data was generated, perhaps data that triggered the job. Inside the outer...
At the very least, having a README for the schema.json where you can see the schema at a glance and make notes about this kind of stuff would make it...
I had it this way initially, but then the CI pipeline fails because the unit tests require calling the JS code. I'm not sure how to solve this - thoughts?
A possible refactoring strategy (from @calebbrown) - internal/analysis renamed to internal/dynamicanalysis - internal/analysis becomes new generalized API for all analysis - internal/staticanalysis is new static analysis work
There is still common code to be refactored
Found some documentation [here](https://github.com/google/gvisor/blob/master/pkg/sentry/seccheck/sinks/remote/README.md) and an example implementation of a monitoring server [here](https://cs.opensource.google/gvisor/gvisor/+/master:pkg/sentry/seccheck/sinks/remote/server/server.go)
This may be blocked by https://github.com/google/gvisor/issues/7449
Could this be done dynamically in the sandbox by doing an `adduser`/`useradd` and then `su` or `sudo -l` to that user before installing and running the package?
Issues to consider (from discussion with @calebbrown): - If the username is randomised, then the home directory will be randomised, and we want to be able to replace the randomised...