Feature Request: Add binary artifact to Releases section

[scottbrown]

This is a great tool!

To help increase adoption of this tool, consider tagging the project when it is at a stable point and building binary artifacts in multiple OSes and architectures, then adding these binary artifacts to the Releases section of this repository. Then people don't need to compile the project with Go in order to use this tool. All they have to do is go to https://github.com/Threagile/threagile/releases and download the ZIP for their os/arch.

[cschneider4711]

Thx for the feedback. Yep, binary releases are important, very valid point. 👍🏻

For releasing binaries we've to consider two things:

• Some users don't trust binary downloads and rather want to build themselves from the source (still possible, users can choose).
• As Threagile makes use of other open-source tools like dot/graphviz etc. these dependencies must be taken into account for a non-docker-container based Go binary release. Eventually via configurable paths where to find/call these.

Currently the docker container is built from the project's source using the provided Dockerfile and it already includes dot/graphviz dependencies and such, so that's currently the most convenient way of using it. So for the docker-favoring users, that's already the "binary" with batteries included, ready to run: docker run --rm -it threagile/threagile

For the non-docker-favoring users, we should consider releasing Go binaries here as the feature request suggests and consider the dependency configuration outside of docker.

[ffe4]

Some users don't trust binary downloads and rather want to build themselves from the source (still possible, users can choose).

Note that this also applies to the pre-built docker image. We could improve trust by publishing all artifacts from an automated build pipeline.

As Threagile makes use of other open-source tools like dot/graphviz etc. these dependencies must be taken into account for a non-docker-container based Go binary release. Eventually via configurable paths where to find/call these.

I'm quite new to Go but I can look into starting the refactoring for that if you'd like. Bundling graphviz might also be an option, for example using go-graphviz.

[gtudan]

I would really love to see a binary distribution (and a homebrew formula for Mac as well?). This would improve the user experience a lot - the commands required to get going are pretty long and having to spin up docker for running a CLI tools feels odd - especially since it's written in go.

Compiling it from source is straight forward, but - bummer - all the paths are hardcoded to "/app" 😞

Still great work! I really love the idea and the concepts behind threagile 👍

[cschneider4711]

Thx for the feedback. Always looking for nice ideas and feature requests!

Yep, targeting the soon to arrive 1.0.0 tagged release, a pure binary version (for all major OS of course) would be excellent, so that it easily runs without Docker. This implies that the dependency on Graphviz is somewhat "baked-in" into the binary release. The interesting looking go-graphviz project seems to still require the graphviz libs locally (as it's more of a binding)? Have to test this with some big models (have some nice examples of them) and with different operating systems. Currently having Linux Intel, Windows Intel and Mac Intel as well as Mac Apple Silicon for testing. This needs to be tested carefully and provided as an option with the Docker container still being available.

[MaSven]

I created a rpm file from this go module. https://build.opensuse.org/package/show/home:MaSven/threagile. On opensuse you can install it with opi threagile

[cschneider4711]

Did some tests with go-graphviz and it looks quite promising: it ships the Graphviz C code as well and it just requires CGO to be enabled during build to integrate with Go. Will test further with some Threagile models, but first (simple) results on Linux & Mac look promising (even Apple Silicon). Windows tests will happen soon, had currently some gcc issues with the CGO stuff there, but that might be solved... Having direct binaries with everything in it would be worth it... ;) Nevertheless the default container-based variant should as well be an option for users (then no CGO required)...

[dAnjou]

Hi, I'm evaluating Threagile right now for our project at work and I'd really like to use it, it finally makes agile threat modeling approachable.

I'd like to run it in our CI/CD agents though but these are containers and in our setup we can't run containers inside containers. So, a binary would much appreciated! 🙏

[Lupus]

Same feature request - single no-external-deps binary would greatly help increase the adoption. Security folks on Windows are not quite happy with a docker image, docker for windows is license-based. Threagile compiles happily to an .exe, but dies with obscure errors trying to find some assets which it expects to find in \app :( Probably those can be bundled into the application? There were some solutions to bundle static files into go binary. Requirements on external tools like dot.exe are understandable and would probably not be much of a problem if there was a clean and convenient way to configure those in some user-wide config file...

With single binary it could be possible to run the tool in watch mode alongside your IDE to get live preview of diagrams, and this intimidating .yaml could be edited during a meeting with some dev team, security specialist adds some elements, adjusts the attributes, etc, and then everyone can look at the updated diagram and/or risk table in .xlsx to continue iterating.