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

25 Aug 2009


      Is SquirrelFish Extreme included in latest versions of webkit?

On 8/24/09, webkit-dev-request@lists.webkit.org
<webkit-dev-request@lists.webkit.org> wrote:
...
Send webkit-dev mailing list submissions to
  webkit-dev@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@lists.webkit.org
You can reach the person managing the list at
  webkit-dev-owner@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@chromium.org>
To: Dan Bernstein <mitz@apple.com>
Cc: WebKit-Dev <webkit-dev@lists.webkit.org>
Subject: Re: [webkit-dev] LayoutTest results choose from which folder?
Message-ID:
  <3726d1bf0908231128t470f0f29n7fab1a791dcbea05@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@apple.com>
To: Dirk Pranke <dpranke@chromium.org>
Cc: WebKit-Dev <webkit-dev@lists.webkit.org>
Subject: Re: [webkit-dev] LayoutTest results choose from which folder?
Message-ID: <ECC55AB8-992E-4708-B1FF-1E4E29123AED@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@gnome.org>
To: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Security advice for linux browsers based on
  WebKit
Message-ID: <1251086542.6026.31.camel@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@gnome.org>
GNOME
------------------------------
Message: 4
Date: Sun, 23 Aug 2009 21:30:13 -0700
From: Adam Barth <abarth@webkit.org>
To: Gustavo Noronha Silva <gns@gnome.org>
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Security advice for linux browsers based on
  WebKit
Message-ID:
  <7789133a0908232130r44ef4956u4bc59c0aeba19f02@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Sun, Aug 23, 2009 at 9:02 PM, Gustavo Noronha Silva<gns@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@gnome.org>
To: Adam Barth <abarth@webkit.org>
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Security advice for linux browsers based on
  WebKit
Message-ID: <1251119479.6026.47.camel@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@gnome.org>
GNOME
------------------------------
_______________________________________________
webkit-dev mailing list
webkit-dev@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

ravi swami

tags

participants (1)