You can clone with
No one assigned
I've been able to confirm this bug on several occasions myself. Even if a script is disabled, the script is checked for an update and if one is found it installs. Disabled scripts should never be checked for updates automatically.
At a minimum, this will happen:
Firefox will check all add-ons for updates. This will include disabled extensions. It will the update for install, if found, in both cases. It's harder to reproduce, but I suspect it may be the same for scheduled (rather than interactively triggered) checks. Given that it's standard Firefox behavior, I'd vote to leave it as-is.
I'm curious about what reasoning (substitute instinct, gut feel, mere opinion, or so, as applicable) is behind "Disabled scripts should never be checked for updates automatically." as your usually have rather good input. (Server-side is-installed-and-enabled user base stats?)
As I see it, user scripts suffer the same kind of security bugs normal add-ons do and may need all sorts of updates, whether they are on or off at the moment, before being turned on again in the future. Doing it as soon as the update is available seems more robust than postponing the upgrade until the moment it's turned on next time.
The way I see it, when a user disables a script they are actively stating they don't care about that script right now. I have a lot of scripts installed that I rarely enable and if I wanted them updated I'd enable them. Constantly going behind users' backs and installing updates for scripts a user probably doesn't care about right now just doesn't seem right to me. I'd be fine if manually checking for updates in the manager installed updates for disabled scripts, but right now it seems like they update whenever (as I reported in #1481).
Edit: Sorry accidentally pressed the sumbit button too early on my phone.
As I see it, disabling (but not installing) means that you don't care right now. But, of course, you do care at some later point. At that point, you'd be likely to appreciate having the latest working version.
Having thought about this some more still, my security argument is flawed, for the specific case of auto-update + http: download URLs, such as, specifically, userscripts.org. Silently updating disabled scripts to whatever you get down the wire over a (maybe shady) café wifi is rather more likely to get you trojans than fix script security bugs, when there is no guarantee of the site's authenticity.
That considered: how about disabling script updates and freshness checks while a script is disabled, and doing one the moment it gets re-enabled (conceptually synchronously – check and update before injecting it), if re-enablement time is greater than one update check cycle after it was disabled?
It gets a bit more complex, but does some security good, lowers update traffic volumes, especially on scripts that somehow were not good enough to remain enabled at all times (thus not casting any "install votes" on likely-sub-par scripts, on sites that track it, such as us.o) and still accomplishes the full intent of the auto update system.
I like the feel of it, but it is a bit of a mouthful to implement, as always.
I don't buy any of this. This is not security related.
If, ever, any script updates (or installs) over http (no S), the user can be theoretically owned, on an insecure link. If your argument is that a user will remember 100% of the time to disable exactly those scripts which have http (no S) update URLs every time they move onto an insecure link, then I could see some sort of twisted tiny security benefit.
Special-casing a synchronous update at enable time seems too expensive to be worth it. It will be checked as soon as it runs, anyway. So if it needs an update, the next run will be fine.
I don't feel strongly either way. This is one line to implement. So it's done. If you'd like any behavior besides "scripts don't auto update when disabled, but will update when manually checked regardless" please file another ticket describing what you want.
Don't (auto) update scripts that aren't enabled.