RFT mode not obfuscating local variables with rft-auto-include

[zarbex]

I am obfuscating a package and want the best possible obfuscation.

Using the default rft-auto-exclude and trace_rft enabled, I can see that all local variables are obfuscated as they should be, but not attribute chains, as per the documentation.
Therefore I am now using rft-auto-include and have added manual rulers looking somewhat like some_var.* ?.? and now the attributed chains get transformed into some_var.pyarmor__20.

However, now no local variables are getting obfuscated.
Is this feature unavailable with rft-auto-include or is this a bug?

[jondy]

Could you pick some code to one simple script to show it? Also include what rulers are used.

[jondy]

I have reproduced it and check it.
Anyway, you need not care about local variables, it will be renamed in next obfuscation pipeline unless you disabled this feature by pyarmor cfg mix_localnames = 0

[jondy]

After checking, rft-auto-include will not rename local variables, but the local variables will be renamed in next obfuscation process.

[zarbex]

What do you mean by the next obfuscation process? I know the code gets encrypted afterwards, but unobfuscated local variables are still visible when using the debugger. Is there a way to solve this?

[jondy]

Which Python version is used? Before Python 3.10 local variables should be renamed, but in Python 3.11 it seems they're not renamed. I'm checking this and try to fix it.

[zarbex]

Python 3.12.5, I will try using 3.10, thanks for looking into this.

[zarbex]

Which PyArmor version are you using in combination with Python 3.10? I have not yet gotten the local variable obfuscation to work.

[jondy]

What I used is Pyarmor 8.5.12
The test script is

s = 0
def foo():
    a = 1
    abcedfg_12345 = 3
    print(locals())

foo()

And test it by

pyarmor cfg rft_auto_exclude = 0
pyarmor gen --enable-rft foo.py
python dist/foo.py

I can see the local variable name are changed by print statement

[zarbex]

Using Python 3.10 works indeed. I have only looked at the trace_rft=1 output before. Thanks.