Alfred Peng wrote: > Firefox depends on NSS for certs verification. Besides, it provides a > way for users to add exception when the server side certificate fails to > verify. I doubt WebKit, as a library, should do the work to pop up a > dialog. Maybe the applications which depend on WebKit should implement > this.
I agree with this (consuming apps need to do any dialogs). More importantly though: it's not in scope for this case for you to need to implement the missing certificate functionality. That's for the upstream WebKit folks. All you need to make sure is that as shipped by default (and without $WEBKIT_IGNORE_SSL_ERRORS being set) that WebKit won't load any insecure HTTPS pages. "Provide a way for users to add an exception" is the difficult bit because the user wants to be able to see the certificate contents in order to decide, and this makes it trickier to design the API. > verification. But there is a bug: /etc/sfw/openssl/certs has no well > known CA certificates (bugster CR#6661895) so that certificate > verification isn't supported. > To enable the certs verification, either the bug #6661895 needs to be > fixed first, or the certs are shipped in WebKit or libcurl. I'm > personally not a fan for the second choice. I don't get a vote on the ARC, but I think you're fine to close this case and ship a version of WebKit which just does not support HTTPS in the first version by default. I.e. "https pages only get loaded if you pass verification, and there's no way verification can pass because of missing certs". Whether and/or where you document WEBKIT_IGNORE_SSL_ERRORS is up to you, provided that if you document this then IMHO you should warn the user that this breaks security. and possibly also say this option is declared obsolete and may go away. Hugh.
