Ashirt Client Application Communication about ashirt HOT 3 CLOSED

• Do you need to use multiple ashirt servers?
  • It's helpful for development, and there's probably a subset of users that will eventually need to do this anyway, if this application gets more community adoption. But that's more a suggestion that we would need multiple server support in the future. A lot of the code needed to do this is already written, but if it were not, it might make more sense to wait until the community asks for it.
• Do operators require only aterm, and will not use ashirt for other reasons not considered?
  • Maybe if the application they're testing is CLI only? A screenshot doesn't seem like a great use case there. Other than that, I can't think of any compelling reasons, though I'm sure some exist.
• Are there other approaches that can be taken to simplify the interaction between ashirt and aterm?
  • Another approach is to move all of the logic of making network connections out of ashirt/aterm and putting them into a sidecar application. This can have it's own configuration (either hand generated, or have a small CLI to interact with it, or if we want to get fancy, a mechanism for other applications to provide edits to this config via a "native" experience (e.g. a GUI form for a GUI application). Each level of this can get fairly complicated, but a basic solution should be fairly straight forward. One advantage to this approach is that it will likely be easier to maintain than the ashirt application. One downside to this approach is that, if it's going to handle file creation and what not, ashirt and aterm could use a fair amount of refactoring to simplify their approaches and lean on the side car application. Really though, aterm is likely to require some refactoring to make this all function as expected.
  • Another possible approach is exactly what you mentioned, but with aterm being the source of truth, and ashirt being the "client" of aterm.

from ashirt.

The plan currently is to shelve the work on #57 which means this this is less important because we can safely rely on the current behavior of aterm where it simply reads the config of ashirt and pulls out the server information without having to make it, or any other evidence producers, aware of multiple servers or deal with them getting out of sync. I think for now we can close this ticket and maybe we'll want to make a revision in the future to the config anyway that shifts the server information out into a separate file, like we have in the multi-server branch, so that evidence producers don't need to keep up to date with the complete config format of ashirt? We also may find that this actually does make sense as we start to build more evidence producers in more languages and constantly have to build http clients to talk to the backend in each language.

Maybe it makes sense to adopt gRPC or some other sort of system where we can generate clients or revisit GraphQL again once we know more about how to design and secure it well.

from ashirt.

Closing due to complexity and lack of perceived value

from ashirt.