Skip to content
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

Feature: Show and print variable taint info #15

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

shrugal
Copy link

@shrugal shrugal commented Sep 30, 2024

Getting information about taint can be tricky as a dev. I think DevTool could help here, by providing a way to drill down on Blizz variables and check which parts have been tainted.

So this PR adds:

  • A small 4th column to the table that shows if a variable is tainted. It's empty if not, and shows "Tainted" if it is.
  • A 2nd line to the right-click print that outputs the name of the addon tainting the variable.

It works on child variables of added table data, as well as top level data that has a value in the global table with the same name.

@brittyazel
Copy link
Owner

Hrm, I'm testing it now and the code seems to be working well, though it's seeming to show every addon as tainted. Looking at the DevTool table, every entry is tainted, along with DBM and Details as well. Looking at this function isSecure, taint = issecurevariable([tbl,] variable), it seems like if a variable isn't 'secure' i.e. Blizzard owned, then it will be reported back as tainted. Is this the desired functionality that you were going for? Maybe I'm misunderstanding taint, but if every addon is, by definition, going to report back as tainted, what utility does it provide showing this information as such. (Not trying to be argumentative, I'm genuinely curious.) Right now, this functionality mainly seems to act as a flag if table entries are addon-owned or blizzard-owned.

Further, the attribution of the taint doesn't seem to always be reliable, as all my DevTools's taint was being attributed to Details. I'm assuming this is due to LibStub and library loading. Whichever addon's included libraries get used for that session will take the blame for all taint coming from those libraries, and it's likely just alphabetical order of which addon's libraries get chosen.

@shrugal
Copy link
Author

shrugal commented Oct 4, 2024

Yep this is my understanding as well. Everything from Blizzard is secure unless changed by an addon, and all addon code and data is always considered tainted. I get that it could be a bit confusing showing all addon data as tainted, but that's actually how taint works, and I don't think there is a way to distinguish between Blizz data getting tainted and addon data starting out as tainted.

Similarly with taint attribution, what you said is correct afaik. It's just how Blizz set up the system, and why taint can be so confusing and frustrating.

Maybe it would be better to show secure variables as "Secure" instead of tainted variables as "Tainted"? It would make addon data appear as "normal" and Blizz data as "special" instead of the other way around. And I could also add a "(Possibly)" after the taint attribution output, to make it more clear that it's not 100% reliable. What do you think?

@brittyazel
Copy link
Owner

I like the idea of marking the "secure" variables rather than the tainted ones. Likewise, maybe there's a way to do so with an icon instead of text. I.e. a "lock" icon or something of the sort next to the name, rather than having a whole column listed for just the word "secure". I'm sure there's a lock icon in the game somewhere that would fit the bill.

How does that sound? A lock icon next to secure items, and the absence of a lock against insecure items.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants