I see. Also I saw libsoup's developer citation earlier, but I thought that this issue has been already solved earlier by Google or Apple.
I have two more sugesstions: [1] Currently, Google is under heavy development of Google OS which will be Linux-based OS for netbooks. I'm sure they are going to implement libsoup as underlying layer for WebKit's HTTPS communication. I based my idea having that in my mind. Just ask them how they did such resolution. [2] Let we extend libsoup with additional interfaces capable to deal with this issue, or to change actual implementation of interface we have conflict with. Keep in mind that you are SUN guys which means we should deliver better software than Linux world. Also, maybe I could help since I'm basically Telecommunications Engineer but I do programming too. I came from the country where we have faculties based on Russian style educational system :). Best, Uros Nedic, MSc ---------------------------------------- > Date: Sat, 8 Aug 2009 18:32:31 +0800 > From: Alfred.Peng at Sun.COM > Subject: Re: [desktop-discuss] WebKit 1.1.x [LSARC/2009/409 FastTrack timeout > 08/04/2009] > To: urosn at live.com > CC: Darren.Moffat at Sun.COM; desktop-discuss at opensolaris.org; > storycrafter at gmail.com; lsarc-ext at Sun.COM > > Hi Uros, > > Chrome browser does depend on WebKit. From its source code (788M source > tarball, HUGE) and ChangeLog, I don't think Chrome uses libsoup for > HTTPS support on Win and Mac. From the libsoup developer (link below), > "there is not currently any way to let the application decide on a > case-by-case basis whether or not to accept a certificate" with libsoup. > I doubt whether the way Google/Apple engineers used to solve this HTTPS > support problem can apply to our case. > > Thanks, > -Alfred > > On 08/ 8/09 12:20 AM, Uros Nedic wrote: >> As a pure observer of this communication I would like to >> add one suggestion which, maybe, could be helpful. >> >> As far as I know Google's Chrome browser uses WebKit as >> well as Apple's Safari on both platforms (Win and Mac). >> >> You could ask Google and Apple engineers how they solved >> this problem. >> >> In Chrome when one certificate is not certified by some >> 'well known' CA browser just ask user what he would like >> to do. So it *is* possible to deal with this issue. >> >> I did not have time digging more deeply through Google's >> mailing lists on code.google.com nor to see Apple's but >> as far as I saw there they solved this issue. >> >> Hope it helps! >> >> Uros Nedic, MSc >> Belgrade, Serbia >> >> P.S: Please do not disable HTTPS. I'd be big mistake, from >> my perspective. >> >> ---------------------------------------- >> >>> Date: Fri, 7 Aug 2009 15:27:08 +0800 >>> From: Alfred.Peng at Sun.COM >>> To: Darren.Moffat at Sun.COM >>> CC: desktop-discuss at opensolaris.org; storycrafter at gmail.com; >>> LSARC-ext at Sun.COM >>> Subject: Re: [desktop-discuss] WebKit 1.1.x [LSARC/2009/409 FastTrack >>> timeout 08/04/2009] >>> >>> Hi Darren/Mark, >>> >>> Before I started the arc case, I sent a query with regards to this HTTPS >>> support issue to the WebKit community. Dan Winship, the libsoup >>> developer, gave me some insight into the problem: >>> http://lists.macosforge.org/pipermail/webkit-dev/2009-June/008566.html. >>> >> >>> Roughly there are two points from the reply: >>> >>> - An x509 file containing the certificate can be passed to SoupSession >>> for verification. In this way, only the "correctly-named non-expired >>> certificates signed by one of those CAs" will be accepted, all others >>> will be rejected. From the libsoup client howto: >>> http://library.gnome.org/devel/libsoup/stable/libsoup-client-howto.html, >>> I think it's possible to make WebKit accept user-specified certificate >>> with some coding. On the other hand, we could point the >>> SOUP_SESSION_SSL_CA_FILE to the system bundled certificates if that's >>> available. >>> >>> - "There is not currently any way to let the application decide on a >>> case-by-case basis whether or not to accept a certificate." With >>> Firefox, users can decide whether they want to accept a certificate. >>> Users won't be able to do this with WebKit. >>> >>> As for the current status of the WebKit HTTPS support, I've verified >>> with the WebKit test Program, named GtkLauncher. It's a very simple >>> browser GUI. GtkLauncher can accept all the https request by default. If >>> I patch the code as Dan suggested, it denies all the https website instead. >>> >>>>From the source code: >>> http://svn.webkit.org/repository/webkit/trunk/WebCore/platform/network/soup/ResourceHandleSoup.cpp, >>> you can notice that WebKit uses soup_session_async_new to create the >>> SoupSession without setting any additional options. That's the reason >>> why WebKit ignores all certificate validation and accepts all >>> certificates by default I think. >>> >>> On 08/ 6/09 10:47 PM, Darren J Moffat wrote: >>> >>>> Mark Martin wrote: >>>> >>>> >>>>> I don't think the only issue is the lack of a handy, well known cert >>>>> repository; the fact that the underlying implementation doesn't >>>>> validate properly would probably surprise folks. >>>>> >>>>> >>>> That really depends on what you mean by "validate properly", sure there >>>> are standards that define how this is done but one persons proper >>>> validation is also over the top for other cases and highly in sufficient >>>> for others. >>>> >>>> >>>> >>>>> The choices that I saw were: >>>>> a) Deliver with HTTPS disabled by default. Principle of least >>>>> astonishment. >>>>> >>>>> >>>> By disabled by default is it available to consumers of WebKit easily or >>>> do they have to rebuild it ? >>>> >>>> >>> A possible workaround is that we could patch the code to enable >>> environment variable checking so that consumers of WebKit can switch on >>> the https support easily (no need to rebuild). By doing this, the HTTPS >>> support of WebKit 1.1.x will be consistent with the last WebKit arc >>> case. Just need to note that WebKit will still ignore the certificate >>> verification in this case. >>> >>>>> b) Deliver with (incomplete and ostensibly unsafe) HTTPS enabled by >>>>> default. >>>>> >>>>> If you're insisting on B, how do you advise managing the gap? Log a >>>>> bug? Document a warning? Assume developers will be diligent or just know? >>>>> >>>>> >>>> To be able to answer that I need to understand if this gap exists on >>>> other platforms delivering WebKit or is it somehow unique to OpenSolaris ? >>>> >>> There is an old version of WebKit in Ubuntu repository: >>> http://packages.ubunut.com/jaunty/libwebkit-1.0-1. It still uses libcURL >>> from the dependency list. With package "ca-certificates" installed on >>> Ubuntu by default, WebKit can accept the authorized certificates. >>> However, it won't accept the server certificates that can't be match >>> with the system bundled ones. That's to say, some of the https website >>> will fail to load. Since WebKit 1.1.x is targeted for GNOME 2.28, I >>> think it'll be probably available for the next Ubuntu release. We'll >>> know how Ubuntu handles HTTPS support with libsoup then. >>> >>> Personally I'd propose to disable the HTTPS support for now and push the >>> integration of certificates to OpenSolaris. When it's ready, we can >>> enable the HTTPS support. >>> >>> Thanks, >>> -Alfred >>> _________________________________________________________________ Share your memories online with anyone you want. http://www.microsoft.com/middleeast/windows/windowslive/products/photos-share.aspx?tab=1
