71–80 of 125 posts
Earlier quoted context omitted.
If I'm not mistaken, then very well could revoke the intermediate certificate if they wanted. This wasn't a case of that, but it seems it could happen.
Usually the whole certificate chain is distributed as a bundle, and most software don't bother checking revocations.
> Turns out an unrelated 3rd party can suddenly remotely disable Tor anonymity protections at their whim Am I the only one annoyed by people pushing this "they flicked a switch" narrative? No. They provided shitty software that didn't work under certain conditions (in this case date related) and thus broke your shitty software. A third party having remote control capability is something entirely different.
Earlier quoted context omitted.
Usually the whole certificate chain is distributed as a bundle, and most software don't bother checking revocations.
Are we talking about Firefox extensions or something else?
If Mozilla hadn't locked down Firefox so much, the fix could have been as simple as going into about:config and flipping a switch to allow unsigned plugins.
FWIW, since the original intent of the change to block unsigned plugins was to prevent third party software installers from adding malicious plugins without user consent, leaving a preference to toggle it back would have been pretty pointless as the third party installers could have just toggled the preference themselves (about:config is just some sort of easily modifiable data format on disk). TBH it’s not hard for…
This feature uses SHA-1. [1]
> Why not allow the master password to also protect the settings and store them encrypted so a third party can’t modify them?
It cannot protect against such. It can protect against a household adversary such as a 4 year old, and that's about it.
[1] https://palant.de/2018/03/10/master-password-in-firefox-or-t...
Somewhat related to this ongoing Mozilla plugin saga, are there any infamous stories I should look up that involve huge mistakes leading to unfixable clients? Ie. Imagine bricking your customer's devices with an irreversible buggy update. In Mozilla's case they were able to deploy a hotfix for many, and an update for others. But I imagine there's got to be some great stories about completely bricking countless device…
0: https://blog.zeppelin.solutions/on-the-parity-wallet-multisi...
Somewhat related to this ongoing Mozilla plugin saga, are there any infamous stories I should look up that involve huge mistakes leading to unfixable clients? Ie. Imagine bricking your customer's devices with an irreversible buggy update. In Mozilla's case they were able to deploy a hotfix for many, and an update for others. But I imagine there's got to be some great stories about completely bricking countless device…
Earlier quoted context omitted.
FWIW, since the original intent of the change to block unsigned plugins was to prevent third party software installers from adding malicious plugins without user consent, leaving a preference to toggle it back would have been pretty pointless as the third party installers could have just toggled the preference themselves (about:config is just some sort of easily modifiable data format on disk). TBH it’s not hard for…
If the malicious plugin or executable can write to disk it's probably to late anyway?
Under the Unix security model, for example, that would be pretty likely: your profile's owned by your account, the executable & its containing folder are owned by root & go-w, so code running as you can tamper with the former but not the latter.
Earlier quoted context omitted.
FWIW, since the original intent of the change to block unsigned plugins was to prevent third party software installers from adding malicious plugins without user consent, leaving a preference to toggle it back would have been pretty pointless as the third party installers could have just toggled the preference themselves (about:config is just some sort of easily modifiable data format on disk). TBH it’s not hard for…
If you have disk access, why even bother with a malicious plugin that has to follow all the plugin rules? You could just modify the executable itself and do whatever you wanted with no use visibility.
Earlier quoted context omitted.
If the malicious plugin or executable can write to disk it's probably to late anyway?
The malicious code may well have the necessary permissions to write to the profile folder, but not to modify the executable. Under the Unix security model, for example, that would be pretty likely: your profile's owned by your account, the executable & its containing folder are owned by root & go-w, so code running as you can tamper with the former but not the latter.