Open pagran opened 1 year ago
This is an easy fix just need to typecheck after literal obfuscation, this does add some overhead so I don't know if it's worth it.
Copying my response from #790:
Personally I don't think typechecking again from scratch is the right approach - it's far too expensive. Typechecking once is already slow enough :)
We could consider having the literals code update the type information as it changes the syntax tree. I'm not sure if that's feasible with
go/types
, and it might be a bit complex, but it would be faster for sure.An alternative would be for the literal obfuscation to happen with the syntax tree alone - before we have typechecked. This would be the simplest fix, but it might also make literal obfuscation less useful in cases like
"foo" + "bar"
.
I just realised we have another option, which might be the simplest: have the literal obfuscator generate its code with obfuscated identifiers directly, rather than normal identifiers like data
and fullData
. This will probably require some integration between the literal obfuscator package and the root package to share the logic to obfuscate Go names, but that is probably a lot easier than trying to typecheck a second time or updating the typechecking information with the inserted identifiers.
Right, sometimes the easiest solution is overlooked....
What version of Garble and Go are you using?
What environment are you running Garble on?
go env
OutputWhat did you do?
Build "hello world":
Command:
What did you expect to see?
All local variable names inside the generated lambda (for "hello world" string) must be obfuscated
What did you see instead?
data/fullData
not obfuscated:In current version of garble this bug does not affect anything, but it blocks implementation of literals benchmark. To implement a benchmark, it needs a reference to an external dependency and without renaming inside generated lambda, it will cause error