Re: Validation (OCSP) Preferences
Kai Engert wrote: 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). Ah, I had overlooked that version; I thought it was all done via the pref observer in nsNSSComponent.cpp, but I think I have an idea that might resolve that: setting the security.OSCP.enabled pref to zero should also set the new pref appropriately. 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? The UI code removal should be easy to port. -- Warning: May contain traces of nuts. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Validation (OCSP) Preferences
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.) 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. 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. -- Warning: May contain traces of nuts. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
