> On Nov 5, 2014, at 3:43 PM, crodenb...@gmail.com wrote: > > On Thursday, October 16, 2014 3:04:59 PM UTC-5, treb...@gmail.com wrote: >> On Monday, April 7, 2014 6:33:50 PM UTC-4, Kathleen Wilson wrote: >>> All, >>> >>> >>> >>> We have been working on a new certificate verification library for >>> >>> Gecko, and would greatly appreciate it if you will test this new library >>> >>> and review the new code. >>> >>> >>> >>> Background >>> >>> >>> >>> NSS currently has two code paths for doing certificate verification. >>> >>> "Classic" verification has been used for verification of non-EV >>> >>> certificates, and libPKIX has been used for verification of EV >>> >>> certificates. >>> >>> >>> >>> As many of you are aware, the NSS team has wanted to replace the >>> >>> "classic" verification with libPKIX for a long time. However, the >>> >>> current libPKIX code was auto-translated from Java to C, and has proven >>> >>> to be very difficult to maintain and use. Therefore, Mozilla has created >>> >>> a new certificate verification library called mozilla::pkix. >>> >>> >>> >>> Request for Testing >>> >>> >>> >>> Replacing the certificate verification library can only be done after >>> >>> gaining sufficient confidence in the new code by having as many people >>> >>> and organizations test it as possible. >>> >>> >>> >>> We ask that all of you help us test this new library as described here: >>> >>> https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Testing >>> >>> >>> >>> Testing Window: The mozilla::pkix certificate verification library is >>> >>> available for testing now in Nightly Firefox builds. We ask that you >>> >>> test as soon as possible, and that you complete your testing before >>> >>> Firefox 31 exits the Aurora branch in June. >>> >>> (See https://wiki.mozilla.org/RapidRelease/Calendar) >>> >>> >>> >>> Request for Code Review >>> >>> >>> >>> The more people who code review the new code, the better. So we ask all >>> >>> of you C++ programmers out there to review the code and let us know if >>> >>> you see any potential issues. >>> >>> https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Code_Review >>> >>> >>> >>> >>> >>> We look forward to your help in testing and reviewing this new >>> >>> certificate verification library. >>> >>> >>> >>> Mozilla Security Engineering Team >> >> Mozilla::pkix includes some changes in support of current best practices and >> policies, as listed below. If you notice an issue due to any of these >> changes, please feel free to let us know. However, we believe that in most >> cases, the simplest resolution will be to update the SSL certificate in your >> webserver. >> >> >> YOU F**KTARDS.. SOMETIMES WE HAVE ABSOLUTELY ZERO F**KING CONTROL OVER THE >> SSL CERT PRESENTED.. WE **know** IT SHOULD BE TRUSTED BECAUSE ITS AN >> INTERNAL F**KING DEVICE, AND DON'T GIVE ONE FLYING F**K IF THE CERT IS VALID >> OR NOT.. >> >> WE **SHOULD** BE ALLOWED REGARDLESS OF THE F**KING CAUSE, TO ADD AN >> EXCEPTION.. TAKE THE SAME F**KING URL TO ANY OTHER BROWSER, AND AT WORST YOU >> GET CHROME WHICH NOW WON'T REMEMBER USER/PASS COMBOS TO GET INTO THOSE SITES >> >> >> **** BUT IT STILL F**KING LETS YOU GET TO THE GOD DAMNED F**KING SITE! >> >> WHY IS IT THAT YOU SMART A** F**KERS CAN'T UNDERSTAND YOU **CAN NOT FORCE >> THIS ON PEOPLE** YOU **MUST** ALLOW THEM TO ADD AN EXCEPTION EVEN IF >> TEMPORARY! OTHERWISE BY NOT ALLOWING US TO DO SO YOU FORCE US TO USE >> ANOTHER BROWSER.. FOR SOME OF US AS PART OF OUR JOB.. AND WHAT THEN IS THE >> POINT OF HAVING FIREFOX IF YOU CAN'T USE IT TO DO YOUR F**KING WORK? >> >> F**KTARD DEVELOPERS you think you're so smart, you think you know everything >> and that because YOU think vendors of broken hardware should be forced to >> fix.. or what.. buy something new? ... F U devs.. you fix this.. or see >> people abandon you and loose what little cred you had in the browser war! > > I agree with the opinion this user is trying to get across. We end users must > have an option to completely circumvent security measures when we know a > connection is trusted. Otherwise, like the poster indicated, we have to ditch > Firefox and use a browser that gives us that capability. > > We, the end users, don't want to make a statement of how global security > practices should theoretically work. We want to use a browser that we have > control of and can use as a tool to accomplish a task. Removing some of the > functionality of the browser and forcing us into a rigid security model only > makes us install a second browser. Over time, I can imagine that the second > browser would usurp Firefox's position as "Preferred browser". > > Just an opinion, from an end-user.
Just to let you know, we hear you. We're having some internal discussions about how to better balance the considerations here. On the one hand, for most people in most situations, the browser needs to make an intelligent choice on behalf of the user. Sometimes, that's going to involve not connecting at all. On the other hand, we also need to enable power users, who have done their homework, to get their work done. Look for some proposals here soon. --Richard > -- > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
