Not unless we make the configuration declarative, and even then I don't think this would stop a CVE like this from popping up.
Why not just add a cell that runs appropriate settings via %run?

I'm not an expert in security best practices, so there may be some great, clean solution I'm overlooking. But as much as I sympathize with @mgeier about the major loss of convenience from this, I worry just as much about the point @MrMino makes. Ultimately (and I bear a lot of responsibility for this, as I argued pretty strongly ages ago for having this design in our config system, with .py files at its core for the convenience and power they provide), a configuration system that is based on executing arbitrary code seems like a really hard beast to tame from a security standpoint. Its power and convenience for the legitimate user are wonderful, but it's very easy for that same power to be hijacked in a million subtle, and hard to predict ways.

I don't know - I'd love to hear of ideas for clean solutions that let us have our cake and eat it here, but I don't see an easy one. @Carreau, you've been on top of a lot of security work lately, any ideas? Also @rcthomas and others from the security team might have input? Our entire traitlets-based config approach is predicated on giving users the full power of python to manage their ipython/jupyter tools, but it opens the door to these problems.

An idea just popped into my head: could Jupyter add a synthetic cell, which would allow the user to opt-into running a config file, based on its hash?

Excuse my pathetic attempts at mocking this up:

You could then keep a database of what configs are enabled for which notebooks. When starting a notebook with enabled config, the config cell would be loaded automatically. Each update of a config file would require a reauthorization by the user.

This would prevent execution of untrusted code - the user is responsible for ensuring that they are running code that is safe. More importantly (IMO), it makes the whole mechanism explicit - a quality the lack of which made the original mechanism more exploitable.

This is much more complicated than it looks as even declarative configuration can somehow execute arbitrary code, and even with signed configuration one could do the same.

I thought about this as traitlets also support json config file, but the problem is that those config files can manipulate sys.path, which extensions are loaded, or even dynamic subclass for some things (historymanager, etc).

SO I could perfectly append . to sys path, and say create a pandas.py file in CWD. And boom , I have arbitrary execution.

The secondary problem with the cell that @MrMino suggest, is that not all configuration parameters are changeable after startup, so while those cells could be made, they would cover only a subset of parameters.

Really the only viable solution is an explicit list of configuration options we would allow in CWD.