The signature verifier reads the ` security.content.signature.root_hash` to get the hash of the root of the certificates chain. Remote Settings data updates, which relies on this verifier, can thus be "disabled" by changing the value of this pref. In Bug 1702759, we are removing the ability to flip critical configuration from preferences on beta and release (tagged as `[sec-want]`). We read from hardcoded value unless the environment variable `MOZ_REMOTE_SETTINGS_DEVTOOLS` is set at runtime (to use our addon running priviledged code). Should we apply the same logics and hardcode the root hash or does the security model assume that anything can be disabled/broken when preferences are owned? Seeing there's a pref called `security.turn_off_all_security_so_that_viruses_can_take_over_this_computer`, we may be tilting at windmills here.
Bug 1769669 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
The signature verifier reads the ` security.content.signature.root_hash` to get the hash of the root of the certificates chain. Remote Settings data updates, which rely on this verifier, can thus be "disabled" by changing the value of this pref. In Bug 1702759, we are removing the ability to flip critical configuration from preferences on beta and release (tagged as `[sec-want]`). We read from hardcoded value unless the environment variable `MOZ_REMOTE_SETTINGS_DEVTOOLS` is set at runtime (to use our addon running priviledged code). Should we apply the same logics and hardcode the root hash or does the security model assume that anything can be disabled/broken when preferences are owned? Seeing there's a pref called `security.turn_off_all_security_so_that_viruses_can_take_over_this_computer`, we may be tilting at windmills here.
The signature verifier reads the ` security.content.signature.root_hash` to get the hash of the root of the certificates chain. Remote Settings data updates rely on this verifier, and can thus be "disabled" by changing the value of this pref. In Bug 1702759, we are removing the ability to flip critical configuration from preferences on beta and release (tagged as `[sec-want]`). We read from hardcoded value unless the environment variable `MOZ_REMOTE_SETTINGS_DEVTOOLS` is set at runtime (to use our addon running priviledged code). Should we apply the same logics and hardcode the root hash or does the security model assume that anything can be disabled/broken when preferences are owned? Seeing there's a pref called `security.turn_off_all_security_so_that_viruses_can_take_over_this_computer`, we may be tilting at windmills here.
The signature verifier reads the ` security.content.signature.root_hash` to get the hash of the root of the certificates chain. Remote Settings data updates rely on this verifier, and can thus be "disabled" by changing the value of this pref. In Bug 1702759, we are removing the ability to flip critical configuration from preferences on beta and release (tagged as `[sec-want]`). We read from hardcoded value unless the environment variable `MOZ_REMOTE_SETTINGS_DEVTOOLS` is set at runtime (to be able to let our addon running priviledged code toggle stuff). Should we apply the same logics and hardcode the root hash or does the security model assume that anything can be disabled/broken when preferences are owned? Seeing there's a pref called `security.turn_off_all_security_so_that_viruses_can_take_over_this_computer`, we may be tilting at windmills here.
The signature verifier reads the ` security.content.signature.root_hash` to get the hash of the root of the certificates chain. Remote Settings data updates rely on this verifier, and can thus be "disabled" by changing the value of this pref. In Bug 1702759, we are removing the ability to flip critical configuration from preferences on beta and release (tagged as `[sec-want]`). We read from hardcoded value unless the environment variable `MOZ_REMOTE_SETTINGS_DEVTOOLS` is set at runtime (to be able to let our addon toggle stuff using priviledged code). Should we apply the same logics and hardcode the root hash or does the security model assume that anything can be disabled/broken when preferences are owned? Seeing there's a pref called `security.turn_off_all_security_so_that_viruses_can_take_over_this_computer`, we may be tilting at windmills here.