Thanks @gregory-demay for the detailed guidelines, and thanks @Pete for your response.
I think it’s right that anyone should be able to submit SCM proposals (when their intention is actually to update the binary that a system canister is running). I’m not suggesting otherwise.
Which leads me to think it’s better to normalize the process which we will need to safeguard the system, than rely on it not happening and being a rare event which catches people off guard.
I respect where you’re coming from. I’d just like to make sure that I’m clear on this philosophy if that’s okay. You’re suggesting keeping the potential attack surface of proposals for NNS canister configuration updates unnecessarily large, intentionally, to keep the community on it’s toes and train greater due diligence?
Here's a slightly more detailed description of my concerns
Unless I’m mistaken, as it stands the configuration update process requires the proposer to build and deploy the canister WASM despite the fact that the WASM hasn’t changed (hence why the hashes are the same for the last two canister upgrades - 658c5786cf89ce77a0bb3b17fe855c30f00171de0dc946cc463c9f19c348cb5e).
If this type of proposal becomes greater in frequency (which hopefully they will given that the intention is to encourage community participation), can’t you imagine members of the community getting used to the fact that the WASM doesn’t change for these types of proposals and just eyeballing it (visually checking that the first few and last few digits look right), and spending the majority of their time reviewing the more salient aspects of the proposal?
There’s a low chance of the first few and last few digits in the hash matching by chance. But a bad actor could code any sort of nefarious behaviour into the WASM, then tweak the binary at a point that strategically doesn’t alter the intended behaviour, and keep computing the SHA2-256 until a handful of the first few and last few digits look close enough to the one that the community is expecting (the longer they’re willing to go at this, the more similar they can make the hash look).
Rest assured that DFINITY will always be reviewing any SCM proposals
Wouldn’t it be better to not rely on that?
If a new NNS function that has a smaller blast radius is out of the question, why not make the WASM and hash in SCM proposals optional? When they’re not provided, then the proposal just restarts the canister and passes along the payload.
This would be much easier to verify correctness of the proposal and reduces potential for reviewer fatigue (if there are to be many of these proposals in the future). Probably more importantly, it means the proposal will no longer misleadingly indicate that it’s updating the WASM when it’s not (with terms like ‘New compressed Wasm hash’, and ‘Upgrade Nns Canister: … to wasm with hash …’ when in fact that’s not at all what the proposal is really about).
Thanks for taking the time to read this if you got this far 