Is SquirrelFish Extreme included in latest versions of webkit? On 8/24/09, [email protected] <[email protected]> wrote: > Send webkit-dev mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > To: Dan Bernstein <[email protected]> > Cc: WebKit-Dev <[email protected]> > Subject: Re: [webkit-dev] LayoutTest results choose from which folder? > Message-ID: > <[email protected]> > 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 <[email protected]> > To: Dirk Pranke <[email protected]> > Cc: WebKit-Dev <[email protected]> > Subject: Re: [webkit-dev] LayoutTest results choose from which folder? > Message-ID: <[email protected]> > 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 <[email protected]> > To: [email protected] > Subject: Re: [webkit-dev] Security advice for linux browsers based on > WebKit > Message-ID: <[email protected]> > 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 <[email protected]> > GNOME > > > > ------------------------------ > > Message: 4 > Date: Sun, 23 Aug 2009 21:30:13 -0700 > From: Adam Barth <[email protected]> > To: Gustavo Noronha Silva <[email protected]> > Cc: [email protected] > Subject: Re: [webkit-dev] Security advice for linux browsers based on > WebKit > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > On Sun, Aug 23, 2009 at 9:02 PM, Gustavo Noronha Silva<[email protected]> 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 <[email protected]> > To: Adam Barth <[email protected]> > Cc: [email protected] > Subject: Re: [webkit-dev] Security advice for linux browsers based on > WebKit > Message-ID: <[email protected]> > 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 <[email protected]> > GNOME > > > > ------------------------------ > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > End of webkit-dev Digest, Vol 51, Issue 26 > ****************************************** >
-- Ravi Swami EnMedia Software Technologies _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
