[chromium-dev] Re: SSLClientSocket, TCPClientSocket design choices on linux
On Wed, Sep 17, 2008 at 8:06 PM, Dan Kegel [EMAIL PROTECTED] wrote: On Wed, Sep 17, 2008 at 7:25 PM, Darin Fisher [EMAIL PROTECTED] wrote: One more data point: we'll also need to support SSL over SOCKS one day, and that means that the ClientSocket passed to SSLClientSocket will not be a TCPClientSocket. it will be a SOCKSClientSocket. the SOCKSClientSocket will be layered on top of another ClientSocket, which will be the TCPClientSocket. this extra layering would only happen of course when a SOCKS proxy is enabled. This should clarify why we need to parameterize SSLClientSocket in terms of ClientSocket. Ah, the joys of protocol stacks. (I did a stackable protocol suite once in C++. It even supported nested SSL, i.e. pushing the SSL module twice or three times yielded a doubly or triply nested ssl connection. Not very useful, but fun.) Are there any other layers we might need to support? (And does authentication count? Probably...) - Dan I've been trying to keep things as simple as possible for now. I don't foresee needing any other layers. I haven't finished considering the best solution for SOCKS authentication. Perhaps credentials will just have to be set on the SOCKSClientSocket at construction time. -Darin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: SSLClientSocket, TCPClientSocket design choices on linux
On Wed, Sep 17, 2008 at 11:52 PM, Darin Fisher [EMAIL PROTECTED] wrote: On Wed, Sep 17, 2008 at 8:06 PM, Dan Kegel [EMAIL PROTECTED] wrote: On Wed, Sep 17, 2008 at 7:25 PM, Darin Fisher [EMAIL PROTECTED] wrote: One more data point: we'll also need to support SSL over SOCKS one day, and that means that the ClientSocket passed to SSLClientSocket will not be a TCPClientSocket. it will be a SOCKSClientSocket. the SOCKSClientSocket will be layered on top of another ClientSocket, which will be the TCPClientSocket. this extra layering would only happen of course when a SOCKS proxy is enabled. This should clarify why we need to parameterize SSLClientSocket in terms of ClientSocket. Ah, the joys of protocol stacks. (I did a stackable protocol suite once in C++. It even supported nested SSL, i.e. pushing the SSL module twice or three times yielded a doubly or triply nested ssl connection. Not very useful, but fun.) Are there any other layers we might need to support? (And does authentication count? Probably...) - Dan I've been trying to keep things as simple as possible for now. I don't foresee needing any other layers. I haven't finished considering the best solution for SOCKS authentication. Perhaps credentials will just have to be set on the SOCKSClientSocket at construction time. Also, to be clear, this current design would not support layering SSL on top of SSL. At least there is no support for communicating SSL errors, certificates, or other meta data from the inner layer. -Darin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Automation of web application testing
Came across WebDriver/ChromeDriver http://code.google.com/p/webdriver/ http://groups.google.com/group/webdriver/browse_thread/thread/31f8c7e64f7560aa On Sep 6, 2:23 pm, pow [EMAIL PROTECTED] wrote: Same requirement here. Need to automate web app testing for chrome. Is there an Automation API? Will the Automation API be common for all WebKit based browsers? How does Google test webpages in chrome! On page 9 of Chrome Comic Book (http://www.google.com/googlebooks/chrome/), there is a mention of ChromeBot. Is it comprehensive? is there an open source project for this? Sai also has posted similar requirement for Automation API athttp://groups.google.com/group/chromium-dev/browse_thread/thread/b2bc... Thanks, pow On Sep 4, 6:50 pm, Natesh [EMAIL PROTECTED] wrote: Hi there, We use PAMIE to automate the testing of apps developed by our company for IE. We wish to develop a similar light framework to test apps for Chrome. Any pointers or tips in that direction would really help. Thanks --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Suggestion: Chrome Standalone
Note that with that, you're not going to get automatic updates (e.g. you will be vulnerable to security bugs even after we've patched them for most users). Also, running on a fat32 partition greatly reduces the capabilities of the sandbox model that we use to help prevent the installation of malware and malicious disk access in general. In short, not recommended. 2008/9/18 ph [EMAIL PROTECTED] This may help: http://lifehacker.com/5045439/portable-chrome-puts- chrome-on-your-thumb-drivehttp://lifehacker.com/5045439/portable-chrome-puts-chrome-on-your-thumb-drive (I hope that's what you meant). Paweł On Sep 17, 7:18 pm, Milton Segura [EMAIL PROTECTED] wrote: It would be very useful. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: code style verification/formatting tool
I'll ask around and see if I can find one we can open-source. - Pam On Thu, Sep 18, 2008 at 7:06 AM, Marshall Greenblatt [EMAIL PROTECTED] wrote: Hi All, Does a tool currently exist for verifying and/or formatting source code based on the Google style guide? If not, has any thought been given to developing such a tool? Something like lint, but perhaps more modular, would be a great help to people who don't live and breathe Google style every day. We could then augment gcl to check code changes for style violations and warn/assist users in correcting any problems before the patches are uploaded for code review. Regards, Marshall --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Automation of web application testing
Also take a look at Selenium, which has support for Google Chrome: http://selenium.openqa.org/ Patrick On Thu, Sep 18, 2008 at 7:44 AM, pow [EMAIL PROTECTED] wrote: Came across WebDriver/ChromeDriver http://code.google.com/p/webdriver/ http://groups.google.com/group/webdriver/browse_thread/thread/31f8c7e64f7560aa On Sep 6, 2:23 pm, pow [EMAIL PROTECTED] wrote: Same requirement here. Need to automate web app testing for chrome. Is there an Automation API? Will the Automation API be common for all WebKit based browsers? How does Google test webpages in chrome! On page 9 of Chrome Comic Book (http://www.google.com/googlebooks/chrome/), there is a mention of ChromeBot. Is it comprehensive? is there an open source project for this? Sai also has posted similar requirement for Automation API athttp://groups.google.com/group/chromium-dev/browse_thread/thread/b2bc... Thanks, pow On Sep 4, 6:50 pm, Natesh [EMAIL PROTECTED] wrote: Hi there, We use PAMIE to automate the testing of apps developed by our company for IE. We wish to develop a similar light framework to test apps for Chrome. Any pointers or tips in that direction would really help. Thanks --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: code style verification/formatting tool
On Thu, Sep 18, 2008 at 12:00 PM, Marshall Greenblatt [EMAIL PROTECTED] wrote: Hi Mark/Pam, On Thu, Sep 18, 2008 at 2:48 PM, Mark Mentovai [EMAIL PROTECTED] wrote: Great question. We've been talking about open-sourcing something for this, but so far, we don't have anything yet. We do have something we use internally, but someone needs to go through it and clean up a few things before releasing it so that it runs well in the wild. When it does materialize, it'll show up on the style guide project (http://google-styleguide.googlecode.com/). Do you guys have a timeline in mind of when such a tool might become available? If there are potential code licensing/IP issues, perhaps it could be made available as a web-based service? For instance, something like the w3c validator but returning the corrections in either human-readable format or a format conducive to automation. Everybody's generally in support of open-sourcing the tool, and I don't anticipate any licensing conflicts; it's just a matter of finding the time to go through it. For what it's worth, setting it up as a web-based service wouldn't be any faster. More than days, less than months, would be my guess. - Pam Thanks, Marshall --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: SSLClientSocket, TCPClientSocket design choices on linux
On Wed, Sep 17, 2008 at 3:12 PM, Darin Fisher [EMAIL PROTECTED] wrote: In previous discussion with Darin, it seemed we wanted to use epoll rather than poll. This implies that we want to not use NSPR for our network I/O, and thus implies that we want to write an NSPR I/O layer so we can do our own network I/O rather than letting nss do it via nspr. can't we avoid NSPR? or does the NSS shipped with existing Linux boxes give us no alternative API to get at the SSL state machine? Since we don't have access to the SSL state machine inside NSS's SSL library, we have to use PRFileDesc and PR_Recv and PR_Send, but we don't need to use PR_Poll. We can call the 'poll' method of PRFileDesc directly to get the POLLIN/POLLOUT or EPOLLIN/EPOLLOUT flags we should use with the poll() or epoll() system call. This does require that SSLClientSocket be NOT layered on top of TCPClientSocket on Linux, because SSLClientSocket needs to use the underlying Unix fd (wrapped in a PRFileDesc) directly. If we really need access to the SSL state machine inside NSS's SSL library, we'll need to modify the SSL library. Fortunately, we would only need to build two directories of the NSS source tree, and we can build them against system-provided NSS headers and shared libraries. But that's a lot of work. We should begin with an implementation that uses the current PRFileDesc-based API. Wan-Teh --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Endlessly Checking For Updates
After updating Chrome to 0.2.152.1, heading over to Tools About Chrome, it starts checking for updates. Except this keeps going and going! Any one experiencing this same problem? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: SSLClientSocket, TCPClientSocket design choices on linux
On Thu, Sep 18, 2008 at 2:36 PM, Wan-Teh Chang [EMAIL PROTECTED] wrote: Since we don't have access to the SSL state machine inside NSS's SSL library, we have to use PRFileDesc and PR_Recv and PR_Send, but we don't need to use PR_Poll. We can call the 'poll' method of PRFileDesc directly to get the POLLIN/POLLOUT or EPOLLIN/EPOLLOUT flags we should use with the poll() or epoll() system call. This does require that SSLClientSocket be NOT layered on top of TCPClientSocket on Linux, because SSLClientSocket needs to use the underlying Unix fd (wrapped in a PRFileDesc) directly. I bet you five bucks we can layer SSLClientSocket on top of TCPClientSocket by creating a little nspr i/o layer that talks to a memory buffer. I did this with OpenSSL some time ago, I figure I can do it with nss, too. Plan: 1) stop reading mail and irc. 2) convert the nss demo app tstclnt.c to handle multiple clients and turn it into a little version of strsclnt.c, but using nonblocking io. 3) add the nspr i/o layer I mentioned, and don't let nss or nspr see any real sockets ever; handle all i/o to and from those buffers ourselves. 4) once that works, do the same thing in SSLClientSocket. 5) Profit. - Dan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Unit tests for x509_certificate
I'm happy to review changelists as well as I'm partly to blame for the lack of unit tests. Adam On Thu, Sep 18, 2008 at 12:47 PM, Wan-Teh Chang [EMAIL PROTECTED] wrote: On Thu, Sep 18, 2008 at 11:32 AM, Avi Drissman [EMAIL PROTECTED] wrote: I'm going to land some preliminary work on the x509 support for the Mac (see http://codereview.chromium.org/2963). I want to do some refactoring of the common parts, but there are no unit tests. Amanda and I are going to build some, but wanted to run this by you to make sure that you could have your say. You don't have any tests lying around, do you? No, I don't have any tests laying around. I'll review your changelist. Wan-Teh --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Endlessly Checking For Updates
On Thu, Sep 18, 2008 at 2:51 PM, Jiriteach [EMAIL PROTECTED] wrote: After updating Chrome to 0.2.152.1, heading over to Tools About Chrome, it starts checking for updates. Except this keeps going and going! Any one experiencing this same problem? Yes, everyone using 152.1. A fix is in progress. PK --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Will Chrome use OCSP?
Chrome appears to use CRLs for SSL cert status checking. Are there any plans to use OCSP instead, or primarily use OCSP with a fallback to CRLs? -Rick Andrews --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: SSLClientSocket, TCPClientSocket design choices on linux
On Thu, Sep 18, 2008 at 2:55 PM, Dan Kegel [EMAIL PROTECTED] wrote: I bet you five bucks we can layer SSLClientSocket on top of TCPClientSocket by creating a little nspr i/o layer that talks to a memory buffer. I did this with OpenSSL some time ago, I figure I can do it with nss, too. That'd be nice. Otherwise, we'd need to change http_network_transaction.cc, which now constructs SSLClientSocket with a TCPClientSocket as argument. Plan: 1) stop reading mail and irc. 2) convert the nss demo app tstclnt.c to handle multiple clients and turn it into a little version of strsclnt.c, but using nonblocking io. 3) add the nspr i/o layer I mentioned, and don't let nss or nspr see any real sockets ever; handle all i/o to and from those buffers ourselves. 4) once that works, do the same thing in SSLClientSocket. 5) Profit. I found that I documented the 'poll' method of PRFileDesc two years ago: http://developer.mozilla.org/en/NSPR_Poll_Method Please let me know if you have any questions, and I'll try to clarify it in that wiki page. Wan-Teh --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Will Chrome use OCSP?
On Thu, Sep 18, 2008 at 3:04 PM, Rick Andrews [EMAIL PROTECTED] wrote: Chrome appears to use CRLs for SSL cert status checking. Are there any plans to use OCSP instead, or primarily use OCSP with a fallback to CRLs? We should primarily use OCSP with a fallback to CRLs. If we aren't doing that, it's because 1) the WinHTTP library that we're using doesn't give us this level of control on the revocation checking methods, or 2) we made a mistake in the new HTTP stack (not used by default). For WinHTTP, we only have one option flag, WINHTTP_ENABLE_SSL_REVOCATION, to enable revocation checking: http://msdn.microsoft.com/en-us/library/aa384066(VS.85).aspx So it's all up to WinHTTP to decide whether it should use CRLs or OCSP. In the new HTTP stack, we're passing the flags CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT | CERT_CHAIN_CACHE_END_CERT to the CertGetCertificateChain function. Are those the right flags to use? Should we be using the CERT_CHAIN_REVOCATION_CHECK_OCSP_CERT flag? See http://msdn.microsoft.com/en-us/library/aa376078(VS.85).aspx Wan-Teh --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] conflicting cairo.h
I'm playing with building a no-op test_shell that links in GTK. The GTK header stack pulls in /usr/include/gtk-2.0/gdk/gdkcolor.h, which has #include cairo.h, which picks up our webkit/port/platform/cairo.h , which begins with this comment: // We compile WebKit with PLATFORM(CAIRO) defined. This only affects a few // places in the shared headers. Therefore, we provide this replacement // cairo.h that defines the Cairo types used in these shared headers to be // the types that we desire. Does anyone have plans to remove this file, now that we're unforking from WebKit? Or is it still necessary for some reason? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: conflicting cairo.h
We no longer compile with PLATFORM(CAIRO) on the merge branch. Thus I expect that can be removed. -eric On Thu, Sep 18, 2008 at 4:13 PM, Evan Martin [EMAIL PROTECTED] wrote: I'm playing with building a no-op test_shell that links in GTK. The GTK header stack pulls in /usr/include/gtk-2.0/gdk/gdkcolor.h, which has #include cairo.h, which picks up our webkit/port/platform/cairo.h , which begins with this comment: // We compile WebKit with PLATFORM(CAIRO) defined. This only affects a few // places in the shared headers. Therefore, we provide this replacement // cairo.h that defines the Cairo types used in these shared headers to be // the types that we desire. Does anyone have plans to remove this file, now that we're unforking from WebKit? Or is it still necessary for some reason? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
