-
-
Notifications
You must be signed in to change notification settings - Fork 256
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
conversion between struct types from different packages breaks #310
Comments
Tricky one. We hash field names depending on the package defining the type. Conversions from T1 to T2 will then break, if the two types are defined in different packages, as fields with the same name will end up having different names after obfuscation. It was obvious we'd have this issue with exported method names, but I never thought about this edge case with exported field names. |
Simpler repro:
This example is even worse, because |
We could treat this like we treat reflected types, obfuscate exported struct fields by default unless the parent struct type is converted to/from another type... |
We could, but it wouldn't catch all cases. A package A can convert from exported types B1.T1 and B2.T2, for example. The protobuf case is an example of what we wouldn't catch naively, because one of the types is declared in a dependency. I think a first step here could be to use a global salt for exported field names, similar to what is proposed for methods in #3. Then the only remaining issue would be converting from a non-obfuscated type to an obfuscated type, but that's a bit of an open question in itself. |
Could the field name be a hash of information from the field and the type itself? If the entropy there is too low, perhaps you can include the other fields in the struct since they need to be identical in order for a conversion to work, right? |
That's a good point :) I'll give that a try. |
Packages P1 and P2 can define identical struct types T1 and T2, and one can convert from type T1 to T2 or vice versa. The spec defines two identical struct types as: Two struct types are identical if they have the same sequence of fields, and if corresponding fields have the same names, and identical types, and identical tags. Non-exported field names from different packages are always different. Unfortunately, garble broke this: since we obfuscated field names differently depending on the package, cross-package conversions like the case above would result in typechecking errors. To fix this, implement Joe Tsai's idea: hash struct field names with the string representation of the entire struct. This way, identical struct types will have their field names obfuscated in the same way in all packages across a build. Note that we had to refactor "reverse" a bit to start using transformer, since now it needs to keep track of struct types as well. This failure was affecting the build of google.golang.org/protobuf, since it makes regular use of cross-package struct conversions. Note that the protobuf module still fails to build, but for other reasons. The package that used to fail now succeeds, so the build gets a bit further than before. burrowers#240 tracks adding relevant third-party Go modules to CI, so we'll track the other remaining failures there. Fixes burrowers#310.
Reproduction:
This occurs on protobuf@v1.26.0, but I doubt the exact version matters.
The text was updated successfully, but these errors were encountered: