Neil wrote:
Bug 110161 turned on OCSP by default. It also followed this up by changing the UI from a group of three radio buttons to a checkbox and a pair of radiobuttons. However these three controls fight over the same preference. This makes for some hairy preference code, but also I noticed that if you used to use a specific signer, then if you turn OCSP off and close preferences then it will forget that fact, so you can't just turn it back on again. (With the old triple radiobutton this was obvious behaviour.)Independently of our final decision, having both an "enabled" and "disabled" preference seems very ambiguos, so if we agreed to go that path, I'd vote for a stronger name for your new override preference.My suggestion is to create a new boolean security.OCSP.disabled pref that defaults to false and therefore does not affect existing behaviour but can be toggled through appropriate UI to override the security.OCSP.enabled pref.
It will also mean that at runtime, each time the browser verifies a web site cert, we'll have to query two preferences instead of just one (see implementation of and callers to function GetIsOcspOn).
This will mean that the current checkbox and radiobuttons can by updated to refer to the separate preferences and the linked preference updating code can be removed. Assuming that nobody has any objections I hope to work on the backend later this week.
I think you work primarily on SeaMonkey. Given that the backend code is shared amongst multiple apps, what are your plans wrt Firefox, Thunderbird, etc?
I think your intention is to simplify some (working) UI code, with the disadvantage of having to support an additional preference in the backend. My personal preference is to avoid the additional pref.
Thanks, Kai
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
