This seems to imply that since only dunder methods are blocked, one could call.lower(). Indeed, this does work currently:

>>>mpl.rcParams['axes.prop_cycle']='cycler("color", [x.lower() for x in "RGB"])'>>>mpl.rcParams['axes.prop_cycle']cycler('color', ['r','g','b'])

This doesn't appear on thesuccess list however, so I'm not sure it'sintended to work.

In this PR it now fails, with a bit of an inscrutable error:

ValueError: Key axes.prop_cycle: 'cycler("color", [x.lower() for x in "RGB"])' is not a valid cycler construction: malformed node or string on line 1: <ast.ListComp object at 0x7fb87f6074d0>

I think that’s ok. I consider the cycler spec in matplotlibrc as purely declarative. You should write out the lists explicitly.

non-dunder methods of literals were intended to work. You are right, I should have added that to the list. So, some people may have discovered that and used it.

Please keep in mind all of the valid ways cyclers can be composed:https://matplotlib.org/cycler/#composition. We didn't test all of it here because it was tested in that project.

Thanks, I had missed that link.

It seems like the operations that were missing were integer multiplication, concat, and slicing. I believe all of those should be safe, so added them in here explicitly with some tests.

Arbitrary non-dunder methods on the other hand I don't think we should allow here given the security risk. I'm a little skeptical that their use would be widespread, but we could always add back in specific safe methods (e.g. lower()) if people complain.

methods from standard types that derive from literals are "safe" in that they won't provide a mechanism to modify state or chain to arbitrary code execution. At least, that was the view we had when we originally designed this.

Had Claude tackle this for 20 minutes and found an exploit to execute arbitrary code with the original implementation using non-dunder methods. Can import modules, write to file, etc. I'll dm you on discourse instead of posting it publicly.

Edit: Don't see you on discourse@WeatherGod! Can email you if you'd like, if you reach out with contact info.

I'm going to raise this with cpython core, since the__builtins__ approach is (incorrectly) advertised as limiting the scope:
https://docs.python.org/3/library/functions.html#eval

Good idea to raise this with cpython devs because that would be a significant security issue. No need to inform me what the exploit is, I'd rather not have that knowledge. Just rather know if it can be fixed from cpython's end.

Given that you were able to find a possible exploit validates the effort here to move away from the old appraoch. I did something similar to this for an employer, so I need to go back over my notes and see if there is anything else to watch out for.

Found a good amount of prior art on this method since yesterday so it's not new... my ask to the cpython security team was to update the eval docs because "you can control what builtins are available to the executed code" is incorrect security guidance.

cpython docs PR:python/cpython#145773

if I am reading this right we support the binary ops between any valid expressions?

Yes, do you see any issues with that?

I don't see an issue, but just thinking through exactly how locked down we can make it. For example, can we check that at least one side of this is a Cycler?

Would it be better to utilizeast.walk() to walk the tree nodes? It should help prevent any recursion errors or other oddities that can happen with trees.

The validation on each node withcycler is needed, tests fail withccycler.