Question: current maturity and production-readiness of control flow obfuscation

[aaydin-tr]

Hi, thanks for maintaining garble.

I'm evaluating garble for a project where control flow obfuscation would be valuable, and I'd like to better understand the current state of the GARBLE_EXPERIMENTAL_CONTROLFLOW=1 feature before depending on it.

The CONTROLFLOW.md doc clearly labels it as experimental, and I noticed one documented caveat (lazy map iteration breaking via the ssa2ast/polyfill.go workaround). I wanted to ask the maintainers a few specific questions rather than guess from the code:

1. Stability — Roughly how often do users hit miscompilations or runtime breakage on real-world code with control flow enabled? Are there known categories of Go constructs (generics, closures over loop variables, defer/recover, goroutines, channels, type switches, etc.) that are known to misbehave beyond the lazy-map caveat?

2. Scope — Is the //garble:controlflow directive the only intended entry point, or is there any plan for a package-level or build-wide opt-in?

3. Roadmap — Is there a rough sense of what would need to land for the GARBLE_EXPERIMENTAL_ prefix to come off? Is it blocked on specific bugs, more test coverage, design questions, or just bake time?

4. Production usage — Are you aware of users running it on non-trivial codebases in production today, or is it still mostly at the "try it and report bugs" stage?

5. Reversibility — Does garble reverse still produce useful output when control flow obfuscation is applied, or is that one of the trade-offs?

Happy to move this to Discussions if that's the preferred venue for open-ended questions like this. Thanks!

[mvdan]

Moved this to a discussion.

The project doesn't provide support. Noone is working on control flow obfuscation that I am aware. git and the issue tracker represent the current state of things.

[aaydin-tr]

Thanks for the quick reply, that's helpful to know.