Ping @anntzer - I personally think this would be a great feature for 3.0.... (once you are done expunging any py2-isms that have been driving you nuts).

Good point. I do wonder about MPL arbitrarily loading a config file, without the opportunity to turn that convenience off, or even better to have it turned off by default. I think it makes sense that downstream packages should never load any matplotlibrc file.

I am not particularly interested in relitigating this question (although I will state once again that 1) did you know that np.load can also execute arbitrary code? 2) the "proper parser" proposed has been in a state of vaporware for quite a while), but given that both @tacaswell and @efiring consider that this is a good approach, I'll let them present their thoughts (if any) on the security implications.

As for the implementation strategy I think I quite like @tacaswell's suggestion of requiring an apply_style hook.

Just to throw in my 2 cents: From what I see none of the arguments against YAML mentioned in the linked discussion apply here (any more). The ruamel.yaml implementation is actively maintained (forget about PyYAML) and does safe parsing by default, i.e. there is no security risk of importing/constructing arbitrary objects by default. You just explicitly add the constructors for the custom types (like cycler) to be supported.

In my personal opinion YAML currently is the most human-readable, human-editable configuration language out there. And having a parser/dumper with round-trip support (like ruamel.yaml) makes it machine-readable/writable too.

I guess I'm +0 on using yaml (if it is indeed possible to define custom type loaders), I don't like the language but it's not too bad and most importantly at least it has a spec...

Given how it shows up in my conda updates, I think ruamel is used by conda for parsing its config.

I agree some with @WeatherGod here--as a library, we need to tread differently than an application. In theory, the same level of permissions required to modify the config would be used to run the script (baring misconfiguration), so no security risk. On the other hand, we're literally talking about adding a hook to trigger arbitrary code execution, which screams out CVE to me (as irrational as that might be). (I think I've changed my feeling from in the past.)

In theory, the same level of permissions required to modify the config would be used to run the script (baring misconfiguration), so no security risk.

Thanks for pointing that out. At that point I'm genuinely curious about what is the threat model that we're talking about avoiding. As in, can you present any way in which such a patch (say e.g. matplotlib executes ~/.config/matplotlibrc.py on import, just to pick a concrete case) actually makes things more dangerous?

Note also that you can opt out: just set the MATPLOTLIBRC environment variable to os.devnull (/dev/null) before importing matplotlib. (Well, if that doesn't work, then there should be a patch that makes it work.)

I'm not a security expert, nor do I want to pretend to be, so I feel really uncomfortable trying to decide what's "safe".

There's also a difference between what's actually safe and what our user community would perceive as safe.

I guess it's good that the discussion restarted there, because I got to think about the issue again and am going to renege on my "uninterest in relitigating it" mentioned above.

Let's, again, use a concrete proposal as basis of discussion: at import time, matplotlib tries to import a module named matplotlibrc(.py) from the normal config path (possibly modified by MATPLOTLIBRC), and tries to call the apply_style(rc) function defined there. It is possible to disable this feature (for example) by setting MATPLOTLIBRC to os.devnull. Note that neither eval nor exec appear in this proposal :-)

The fear appears to be that that module can be modified by an attacker or an oblivious user to execute arbitrary code, e.g. os.system("rm -rf /"), and we don't want to be responsible for that. But wait! An attacker or an oblivious user had a much simpler way to achieve the same thing: they could just write this into six.py and put that in the user's cwd (or ~/.local/lib/python3.6/site-packages), and we do import six (and other dependencies) without any kind of validation (just as nearly all Python packages in the world do).

From this I conclude that we (and nearly all other Python packages that have external dependencies) are already vulnerable to arbitrary code execution (in that model), and can essentially do nothing about it.

Edit: for improved impact, replace six.py by some stdlib module name, of course.

Just my 2 cents, I think this conversation should have input from somebody with experience in security issues who can vet the proposal. Security vulnerabilities are hard to spot and, as suggested in this thread, can be a deal-breaker for some groups. I'd feel more comfortable moving forward on this if a trusted voice said that it was OK from a security standpoint.