[webkit-dev] webkit-dev Digest, Vol 51, Issue 26

Mon Aug 24 21:26:47 PDT 2009

Is SquirrelFish Extreme included in latest versions of webkit?

On 8/24/09, webkit-dev-request at lists.webkit.org
<webkit-dev-request at lists.webkit.org> wrote:
> Send webkit-dev mailing list submissions to
> 	webkit-dev at lists.webkit.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> or, via email, send a message with subject or body 'help' to
> 	webkit-dev-request at lists.webkit.org
>
> You can reach the person managing the list at
> 	webkit-dev-owner at lists.webkit.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of webkit-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: LayoutTest results choose from which folder? (Dirk Pranke)
>    2. Re: LayoutTest results choose from which folder? (Dan Bernstein)
>    3. Re: Security advice for linux browsers based on WebKit
>       (Gustavo Noronha Silva)
>    4. Re: Security advice for linux browsers based on WebKit
>       (Adam Barth)
>    5. Re: Security advice for linux browsers based on WebKit
>       (Gustavo Noronha Silva)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 23 Aug 2009 11:28:37 -0700
> From: Dirk Pranke <dpranke at chromium.org>
> To: Dan Bernstein <mitz at apple.com>
> Cc: WebKit-Dev <webkit-dev at lists.webkit.org>
> Subject: Re: [webkit-dev] LayoutTest results choose from which folder?
> Message-ID:
> 	<3726d1bf0908231128t470f0f29n7fab1a791dcbea05 at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
>> Hi Chris,
>> In layout test results, we make the latest Mac OS X version the rule, and
>> earlier versions the exception. Tiger will look for results in mac-tiger
>> first, then in mac-leopard, then in mac-snowleopard, then in mac, then
>> finally in cross-platform results. Leopard will begin the search in
>> mac-leopard, continue to mac-snowleopard, then mac, the cross-platform.
>> As you can see, there are no expected results in mac-snowleopard (other
>> than
>> the ones you just added), because it?s the latest Mac OS X version. We
>> will
>> only start putting expected results in mac-snowleopard when the ?latest?
>> version (for which we put results in mac) will be something different.
>> You should put the expected results for Snow Leopard in platform/mac (or,
>> if
>> they are cross-platform, alongside the test), and you should put the
>> results
>> for Leopard and earlier in platform/mac-leopard.
>> ?Dan
>
> Does this imply that if you've moved results from 'platform/mac' to
> 'platform/mac-leopard' when you switched from 10.5 to 10.6? (Since,
> presumable, some results that were in platform/mac were actually
> specific to 10.5?)
>
> I would've expected a different model, where if the output differed by
> version, then you had results in 'mac-leopard' and 'mac-snowleopard',
> and the presence in 'mac' meant it should be the same across both
> (this was the approach I was planning to use for Chromium, which is
> just starting to run into this problem with XP/Vista/Win 7). I can see
> some advantages to your approach, but it seems more confusing in the
> long run.
>
> -- Dirk
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 23 Aug 2009 12:23:09 -0700
> From: Dan Bernstein <mitz at apple.com>
> To: Dirk Pranke <dpranke at chromium.org>
> Cc: WebKit-Dev <webkit-dev at lists.webkit.org>
> Subject: Re: [webkit-dev] LayoutTest results choose from which folder?
> Message-ID: <ECC55AB8-992E-4708-B1FF-1E4E29123AED at apple.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed;
> 	delsp=yes
>
>
> On Aug 23, 2009, at 11:28 AM, Dirk Pranke wrote:
>
>>> Hi Chris,
>>> In layout test results, we make the latest Mac OS X version the
>>> rule, and
>>> earlier versions the exception. Tiger will look for results in mac-
>>> tiger
>>> first, then in mac-leopard, then in mac-snowleopard, then in mac,
>>> then
>>> finally in cross-platform results. Leopard will begin the search in
>>> mac-leopard, continue to mac-snowleopard, then mac, the cross-
>>> platform.
>>> As you can see, there are no expected results in mac-snowleopard
>>> (other than
>>> the ones you just added), because it?s the latest Mac OS X version.
>>> We will
>>> only start putting expected results in mac-snowleopard when the
>>> ?latest?
>>> version (for which we put results in mac) will be something
>>> different.
>>> You should put the expected results for Snow Leopard in platform/
>>> mac (or, if
>>> they are cross-platform, alongside the test), and you should put
>>> the results
>>> for Leopard and earlier in platform/mac-leopard.
>>> ?Dan
>>
>> Does this imply that if you've moved results from 'platform/mac' to
>> 'platform/mac-leopard' when you switched from 10.5 to 10.6? (Since,
>> presumable, some results that were in platform/mac were actually
>> specific to 10.5?)
>
> Yes, when the expected results of an existing test change under a new
> version of Mac OS X, legacy expected results are moved from platform/
> mac to platform/mac-<last version with legacy behavior> and current
> expected results are put in platform/mac.
> <http://trac.webkit.org/changeset/47052
>  > is an example.
>
>> I would've expected a different model, where if the output differed by
>> version, then you had results in 'mac-leopard' and 'mac-snowleopard',
>> and the presence in 'mac' meant it should be the same across both
>> (this was the approach I was planning to use for Chromium, which is
>> just starting to run into this problem with XP/Vista/Win 7).
>
> Having platform/mac represent ?latest and future versions of Mac OS X?
> means that when the next version appears, there is no need to do
> anything with tests whose results in the new version are the same as
> in the previous version. This model is analogous to how version-
> checking macros are used in WebKit code, by making exceptions for the
> past, not for the present: there is no BUILDING_ON_<latest version>
> macro.
>
>> I can see
>> some advantages to your approach, but it seems more confusing in the
>> long run.
>
> I hope my explanation clears up the confusion.
>
> ?Dan
>
> ------------------------------
>
> Message: 3
> Date: Mon, 24 Aug 2009 01:02:22 -0300
> From: Gustavo Noronha Silva <gns at gnome.org>
> To: webkit-dev at lists.webkit.org
> Subject: Re: [webkit-dev] Security advice for linux browsers based on
> 	WebKit
> Message-ID: <1251086542.6026.31.camel at goiaba.horta>
> Content-Type: text/plain
>
> On Sat, 2009-08-22 at 22:05 -0700, Adam Barth wrote:
>> which disables this behavior.  For legacy reasons, we default this
>> setting to "true," but I'd like to encourage to use the "false"
>> setting by default in your browser, especially if your browser runs on
>> Linux.
>>
>> This issue is particularly important on Linux because many Linux users
>> use a network file system, such as AFS or NFS, which maps the entire
>> world into the local file system.  For example, if I made my home
>> directly world-readable, it's quite likely that I would be able to
>> control this URL on your user's machines:
>
> I notice that WebKitGTK+ disables this by default, good =).
>
> I think, though, that the AFS/NFS issue you mention is more general and
> shouldn't be a motivating factor. We have many GNU/Linux users not in
> corporate networks, these days, as well, and I think we should not be
> designing everything for big installations (those usually have admins
> who can worry about this kind of issue).
>
> Also, it looks like you can access windows shares using
> file://server/folder/file.html, so this doesn't seem to be UNIX-specific
> in any way. I also bet Mac can be made to use NFS, and AFS, so, again, I
> fail to see this as particularly important on non-Mac UNIX-likes.
>
> See you,
>
> --
> Gustavo Noronha Silva <gns at gnome.org>
> GNOME
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 23 Aug 2009 21:30:13 -0700
> From: Adam Barth <abarth at webkit.org>
> To: Gustavo Noronha Silva <gns at gnome.org>
> Cc: webkit-dev at lists.webkit.org
> Subject: Re: [webkit-dev] Security advice for linux browsers based on
> 	WebKit
> Message-ID:
> 	<7789133a0908232130r44ef4956u4bc59c0aeba19f02 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Sun, Aug 23, 2009 at 9:02 PM, Gustavo Noronha Silva<gns at gnome.org> wrote:
>> On Sat, 2009-08-22 at 22:05 -0700, Adam Barth wrote:
>>> which disables this behavior. ?For legacy reasons, we default this
>>> setting to "true," but I'd like to encourage to use the "false"
>>> setting by default in your browser, especially if your browser runs on
>>> Linux.
>>>
>>> This issue is particularly important on Linux because many Linux users
>>> use a network file system, such as AFS or NFS, which maps the entire
>>> world into the local file system. ?For example, if I made my home
>>> directly world-readable, it's quite likely that I would be able to
>>> control this URL on your user's machines:
>>
>> I notice that WebKitGTK+ disables this by default, good =).
>
> Awesome.  :)
>
>> I think, though, that the AFS/NFS issue you mention is more general and
>> shouldn't be a motivating factor. We have many GNU/Linux users not in
>> corporate networks, these days, as well, and I think we should not be
>> designing everything for big installations (those usually have admins
>> who can worry about this kind of issue).
>>
>> Also, it looks like you can access windows shares using
>> file://server/folder/file.html, so this doesn't seem to be UNIX-specific
>> in any way. I also bet Mac can be made to use NFS, and AFS, so, again, I
>> fail to see this as particularly important on non-Mac UNIX-likes.
>
> I'm not sure I quite followed your line of reasoning here.  Are you
> suggesting that everyone should use the more secure setting or are you
> saying that you don't think this is an important security measure in
> non-enterprise settings?
>
> I agree that everyone should disable universal access for file URLs.
> In fact, I think we should make it the default because the current
> default is pretty dangerous.
>
> Adam
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 24 Aug 2009 10:11:19 -0300
> From: Gustavo Noronha Silva <gns at gnome.org>
> To: Adam Barth <abarth at webkit.org>
> Cc: webkit-dev at lists.webkit.org
> Subject: Re: [webkit-dev] Security advice for linux browsers based on
> 	WebKit
> Message-ID: <1251119479.6026.47.camel at goiaba.horta>
> Content-Type: text/plain
>
> On Sun, 2009-08-23 at 21:30 -0700, Adam Barth wrote:
>> > I think, though, that the AFS/NFS issue you mention is more general and
>> > shouldn't be a motivating factor. We have many GNU/Linux users not in
>> > corporate networks, these days, as well, and I think we should not be
>> > designing everything for big installations (those usually have admins
>> > who can worry about this kind of issue).
>> >
>> > Also, it looks like you can access windows shares using
>> > file://server/folder/file.html, so this doesn't seem to be UNIX-specific
>> > in any way. I also bet Mac can be made to use NFS, and AFS, so, again, I
>> > fail to see this as particularly important on non-Mac UNIX-likes.
>>
>> I'm not sure I quite followed your line of reasoning here.  Are you
>> suggesting that everyone should use the more secure setting or are you
>> saying that you don't think this is an important security measure in
>> non-enterprise settings?
>
> I am saying that we should be careful not to design things with 'Linux
> is mostly used in enterprise settings' in mind. There is no reason to
> treat it differently than the other desktops; I myself have never used
> NFS or AFS, nor have many people I know, even though I've been using
> GNU/Linux for ~10 years now. And, as I pointed out, the same potential
> problem with networked file systems may happen with Windows or Mac.
>
>> I agree that everyone should disable universal access for file URLs.
>> In fact, I think we should make it the default because the current
>> default is pretty dangerous.
>
> So, to clear up my position regarding the actual meat of the proposal: I
> agree this is an important security concern. Doing that in libraries
> right now will break API expectations, though, so I think if it is done,
> this should be done first by documenting the intent to change, and then
> changing after a reasonable amount of time. Of course browser
> applications can do it right now, though =)
>
> See you,
>
> --
> Gustavo Noronha Silva <gns at gnome.org>
> GNOME
>
>
>
> ------------------------------
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
> End of webkit-dev Digest, Vol 51, Issue 26
> ******************************************
>

-- 
Ravi Swami
EnMedia Software Technologies