[chromium-dev] Re: Writing tips to our build instructions?
Thank you all those who updated the build instructions. Regards, Hironori Bono E-mail: hb...@chromium.org On Wed, Feb 18, 2009 at 3:09 AM, Evan Martin e...@chromium.org wrote: On Tue, Feb 17, 2009 at 9:37 AM, Pam Greene p...@chromium.org wrote: And I've updated http://sites.google.com/a/chromium.org/dev/developers/how-tos/get-the-code to make the make sure the path has no spaces note apply to all platforms rather than only Windows. (Is it true for Linux too?) It would surprise me if it mattered, but it also surprises me it matters on Win/Mac. Can't hurt, I guess. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Qt now a possibility?
On 17 Gen, 19:45, Ben Goodger (Google) b...@chromium.org wrote: +1 FWIW, the changes I've made in the browser over the past few months (MagicBrowzr) should have made it possible for the front end to be written in any number of native toolkits. Our first test is going to be Cocoa on OS X. -Ben So, different native toolkits for each platform. But while Windows has mfc and Osx uses cocoa/carbon, i wonder what is the 'native toolkit' for linux (?) Or, if you prefer, why did you choose gtk over qt (at least) on linux? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Qt now a possibility?
On 17 Gen, 19:45, Ben Goodger (Google) b...@chromium.org wrote: +1 FWIW, the changes I've made in the browser over the past few months (MagicBrowzr) should have made it possible for the front end to be written in any number of native toolkits. Our first test is going to be Cocoa on OS X. -Ben So, different native toolkits for each platform. But while Windows has mfc and Osx uses cocoa/carbon, i wonder what is THE native toolkit for linux (?) Or, if you prefer, why did you choose gtk over qt (at least) on linux? It's very strange, since google earth uses qt... --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Is there a scroll bar?
OK, Thanks... I'll try to find the slowdown then... BYE MAD On Tue, Feb 17, 2009 at 6:48 PM, Brett Wilson bre...@chromium.org wrote: On Tue, Feb 17, 2009 at 3:43 PM, Marc-Andre Decoste m...@google.com wrote: Salut, I'm looking for a way to know, at the BrowserView (or even at the RenderWidgetHostViewWin) level, if there is one, and only one scroll bar visible. I thought I could ask Windows with ::GetScrollBarInfo, but it doesn't work since the scroll bars are handled by WebKit and not by Windows. Scroll bars a non-native and rendered by WebKit. The browser doesn't know anything about it. I think you will have to do this at the WebKit level. Brett --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: checkdeps failure when a unit test relies on v8.h
Right... I meant the particular vector of faking the proxy auto config file to achieve HTTP interception. That Windows has auto detect proxies enabled by default would seem to make this an easy target for hackers. -Darin On Tue, Feb 17, 2009 at 10:16 PM, Adam Barth aba...@chromium.org wrote: No one else has a sandbox for their JavaScript engine. ACE in their JS engine is game over. Adam On Tue, Feb 17, 2009 at 9:42 PM, Darin Fisher da...@chromium.org wrote: I wonder why this hasn't gotten much attention in other browsers... -Darin On Tue, Feb 17, 2009 at 1:42 PM, Adam Barth aba...@chromium.org wrote: Hi Eric, On Tue, Feb 17, 2009 at 12:47 PM, Eric Roman ero...@chromium.org wrote: My goal is to do all the work necessary to get V8-PAC resolving working in the browser process first. That sounds like a good plan, but I think we should implement the security mitigation as a second step. The logic goes something like: * To exploit V8 you must be running an evil PAC script. * If you are running an evil PAC script, you are already screwed. The situation is a little more subtle than this. Here is how I think about it: Threat Model: 1) You are using the browser on an untrusted network. Likelihood: Routine (users routinely surf the Web on untrusted wireless networks, for example in coffee shops and in airports). 2) V8 has an exploitable arbitrary code execution vulnerability. Likelihood: Will occur at some point. Window of Vulnerability: One patch cycle (exploitable ACEs in V8 are P0 bugs). Designs: 1) PAC in renderer process: Universal cross-site scripting. The attacker can exploit V8, but the sandbox prevents the attacker from reading or writing your hard drive. Severity: High. 2) PAC in browser process: Arbitrary code execution. The malicious PAC script can now install malware on the user's machine. Severity: Critical. Conclusion: Running PAC scripts in the browser process elevates the severity of a reasonable chunk of attack surface (ACE in V8) from high to critical. Recommendation: Ideally, we would run the PAC script in a dedicated sandboxed process. This would prevent a compromised PAC process from doing much of anything. Short of that, we should run PAC scripts in the renderer process. The attacker can now INTERCEPT AND MODIFY all of your HTTP traffic! This is the same as universal cross-site scripting and is a high-severity vulnerability. Being able to install malware on the user's machine is more severe (e.g., critical). All they really need to do is substitute the next EXE you download with the code they want to execute, and voila. This requires user interaction. Specifically, the user has to confirm the corrupted download. Moreover, this attack vector is present regardless of a vulnerability in V8 (i.e., ability 2 above) because an untrusted network can do this already (i.e., just with ability 1 above). Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: checkdeps failure when a unit test relies on v8.h
Hmm... coffee kicking in... to answer my own question, since wpad interception would probably be DNS based, the attacker could also just use the same approach to intercept specific hostnames for plaintext HTTP. even with PAC, the attacker wouldn't have much luck intercepting HTTPS, so the attack surface doesn't seem any larger with PAC than it already is for plaintext HTTP. -Darin On Wed, Feb 18, 2009 at 8:00 AM, Darin Fisher da...@chromium.org wrote: Right... I meant the particular vector of faking the proxy auto config file to achieve HTTP interception. That Windows has auto detect proxies enabled by default would seem to make this an easy target for hackers. -Darin On Tue, Feb 17, 2009 at 10:16 PM, Adam Barth aba...@chromium.org wrote: No one else has a sandbox for their JavaScript engine. ACE in their JS engine is game over. Adam On Tue, Feb 17, 2009 at 9:42 PM, Darin Fisher da...@chromium.org wrote: I wonder why this hasn't gotten much attention in other browsers... -Darin On Tue, Feb 17, 2009 at 1:42 PM, Adam Barth aba...@chromium.org wrote: Hi Eric, On Tue, Feb 17, 2009 at 12:47 PM, Eric Roman ero...@chromium.org wrote: My goal is to do all the work necessary to get V8-PAC resolving working in the browser process first. That sounds like a good plan, but I think we should implement the security mitigation as a second step. The logic goes something like: * To exploit V8 you must be running an evil PAC script. * If you are running an evil PAC script, you are already screwed. The situation is a little more subtle than this. Here is how I think about it: Threat Model: 1) You are using the browser on an untrusted network. Likelihood: Routine (users routinely surf the Web on untrusted wireless networks, for example in coffee shops and in airports). 2) V8 has an exploitable arbitrary code execution vulnerability. Likelihood: Will occur at some point. Window of Vulnerability: One patch cycle (exploitable ACEs in V8 are P0 bugs). Designs: 1) PAC in renderer process: Universal cross-site scripting. The attacker can exploit V8, but the sandbox prevents the attacker from reading or writing your hard drive. Severity: High. 2) PAC in browser process: Arbitrary code execution. The malicious PAC script can now install malware on the user's machine. Severity: Critical. Conclusion: Running PAC scripts in the browser process elevates the severity of a reasonable chunk of attack surface (ACE in V8) from high to critical. Recommendation: Ideally, we would run the PAC script in a dedicated sandboxed process. This would prevent a compromised PAC process from doing much of anything. Short of that, we should run PAC scripts in the renderer process. The attacker can now INTERCEPT AND MODIFY all of your HTTP traffic! This is the same as universal cross-site scripting and is a high-severity vulnerability. Being able to install malware on the user's machine is more severe (e.g., critical). All they really need to do is substitute the next EXE you download with the code they want to execute, and voila. This requires user interaction. Specifically, the user has to confirm the corrupted download. Moreover, this attack vector is present regardless of a vulnerability in V8 (i.e., ability 2 above) because an untrusted network can do this already (i.e., just with ability 1 above). Adam --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: how keyboard input works
On Wed, Nov 12, 2008 at 7:28 PM, Darin Fisher da...@chromium.org wrote: The intent was for WebKeyboardEvent to mirror PlatformKeyboardEvent such that conversion between the two was a simple as copying fields directly. The issue with this approach is that PlatformKeyboardEvent is not a simple POD class, and is not a cross-platform keyboard abstraction as it's touted. It's ifdef-ed all over the place per-platform. We *can* treat it as such, though, and it appears we're already trying to do so (see the #if PLATFORM(CHROMIUM) on the m_isSystemKey member). That means we would haul all the platform code back up from WebCore to glue, and keep a duplicated copy. (We couldn't use it directly for various reasons enumerated elsewhere.) On Wed, Nov 12, 2008 at 2:59 PM, Evan Martin e...@chromium.org wrote: 3) [...]we have code that knows how to serialize those over the IPC layer[...] = reinterpret_castconst char* (see RenderWidgetHost::ForwardInputEvent as an example). It's probably the right idea to promote events to being first-class IPC citizens. Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: how keyboard input works
On Wed, Feb 18, 2009 at 11:22 AM, Darin Fisher da...@chromium.org wrote: Notice that except for a bool, the rest are not part of the structure when PLATFORM(CHROMIUM) is defined, so for us PlatformKeyboardEvent is platform independent. Yes, I just found PlatformKeyboardEventChromium.cpp. Looking at disambiguateKeyDownEvent, I see comments like we lack information... Is there any way we can pass more info along to fix those cases? (Though I'm not certain enough with the code to say what those cases are...) Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: how keyboard input works
On Wed, Feb 18, 2009 at 11:43 AM, Darin Fisher da...@chromium.org wrote: We can extend WebKeyboardEvent if we need to, but what additional information do you need? Don't worry, I've got it now. Avi --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: how keyboard input works
On Wed, Feb 18, 2009 at 8:28 AM, Avi Drissman a...@google.com wrote: On Wed, Feb 18, 2009 at 11:22 AM, Darin Fisher da...@chromium.org wrote: Notice that except for a bool, the rest are not part of the structure when PLATFORM(CHROMIUM) is defined, so for us PlatformKeyboardEvent is platform independent. Yes, I just found PlatformKeyboardEventChromium.cpp. Looking at disambiguateKeyDownEvent, I see comments like we lack information... Is there any way we can pass more info along to fix those cases? (Though I'm not certain enough with the code to say what those cases are...) Avi We can extend WebKeyboardEvent if we need to, but what additional information do you need? Since the eventual DOM keyboard events are platform independent, it seems like we should be able to translate once to a platform independent representation. What am I missing? -Darin --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Using Purify - how to fix the buildbots
I added a page to the wiki that talks about using Purify in the Chromium project: http://sites.google.com/a/chromium.org/dev/developers/how-tos/using-purify For Googlers, this is an updated version of an old page you may have seen before. It has a few important changes however, so I encourage you to read it. Most importantly, the instructions for how to address the bot turning red, and how to filter out errors temporarily have been updated and clarified. For contributors who don't have access to Purify, there's useful information here about how to tackle errors from the buildbot even without having Purify installed. Erik --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [linux] plugin info caching
It appears that Mozilla (maybe for similar reasons) caches this info across browser runs and relies on the file mtime to see when its cache has expired, much to some users' dismay: https://bugzilla.mozilla.org/show_bug.cgi?id=125469 Or at least they did in 2002. ;) yea, they definitely still do this, although I don't know if they changed how they decide to update the cache. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Merge 41017:41057 also needs a clobber for Windows folks
Hi All, Because the latest merge introduces a change to third_party/WebKit/WebCore/css/html4.css, which is only picked up by DerivedSources.make, making that change actually appear in your build requires a clobber. :DG --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Merge 41017:41057 also needs a clobber for Windows folks
As it turns out, the clobber applies to Mac and possibly Linux builds. Basically, clobber all. :DG On Wed, Feb 18, 2009 at 3:11 PM, Dimitri Glazkov dglaz...@google.com wrote: Hi All, Because the latest merge introduces a change to third_party/WebKit/WebCore/css/html4.css, which is only picked up by DerivedSources.make, making that change actually appear in your build requires a clobber. :DG --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Qt now a possibility?
I'm not understanding the animosity shown toward GTK in this thread thus far. A majority of GNU/Linux distros are now using GNOME as the default distro, I use and nearly every Free Software user that I know IRL uses and prefers it. I'm not going to bad mouth QT, I used it predominately a couple years ago in the 3.2 days and used it up until the betas of 3.5. All I want is a fast browser and I for one am happy about the choice to use GTK, not only because I use GNOME but also because I've noticed quite a bit of difference between loading QT in a non-QT environment vs loading GTK in a non-GTK environment, GTK is faster. Try loading Dolphin or Konqueror from GNOME and then Thunar, nautilus or epiphany from KDE and it's apparent. Dolphin is a very fast application, pretty darn slow to load in GNOME, Thunar is comparable directly, fast as hell to load in either environment. All I know is that there shouldn't be this kind of hate in the Free Software community. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Qt now a possibility?
I'm not understanding the animosity shown toward GTK in this thread thus far. A majority of GNU/Linux distros are now using GNOME as the default desktop, I use and nearly every Free Software user that I know IRL uses and prefers it. I'm not going to bad mouth QT, I used it predominately a couple years ago in the 3.2 days and used it up until the betas of 3.5. All I want is a fast browser and I for one am happy about the choice to use GTK, not only because I use GNOME but also because I've noticed quite a bit of difference between loading QT in a non-QT environment vs loading GTK in a non-GTK environment, GTK is faster. Try loading Dolphin or Konqueror from GNOME and then Thunar, nautilus or epiphany from KDE and it's apparent. Dolphin is a very fast application, pretty darn slow to load in GNOME, Thunar is comparable directly, fast as hell to load in either environment. All I know is that there shouldn't be this kind of hate in the Free Software community. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
