Re: [chromium-dev] seeking c++ expertise for a tiny tricky bit of code
On Wed, Jan 13, 2010 at 9:42 AM, Evan Martin e...@chromium.org wrote: With that in mind I think we should explicitly use -fno-strict-aliasing until someone is willing to take the time to run buildbots, track down regressions, etc. for the other configuration. I tend to agree. Many programmers, including myself, don't fully understand the ANSI C strict aliasing rules. I'm afraid this is a language feature that few people can master and the loss in developer productivity is not worth the potential compiler optimizations it enables. Wan-Teh -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
[chromium-dev] http://build.chromium.org/buildbot/continuous/LATEST/REVISION has changed
If you're using the safesync URL http://build.chromium.org/buildbot/continuous/LATEST/REVISION in your .gclient file, your gclient sync command should be failing now. This is because the URL has been replaced by three platform-specific URLs: http://build.chromium.org/buildbot/continuous/linux/LATEST/REVISION http://build.chromium.org/buildbot/continuous/mac/LATEST/REVISION http://build.chromium.org/buildbot/continuous/win/LATEST/REVISION Please change the safesync_url field in your .gclient file to one of the new platform-specific URLs. I've updated the documentation at http://sites.google.com/a/chromium.org/dev/developers/how-tos/get-the-code#TOC-Continuous-build Wan-Teh -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Compiler version used for official Windows builds?
On Wed, Nov 25, 2009 at 4:22 AM, Ted Mielczarek ted.mielcza...@gmail.com wrote: Hi, I couldn't find this info anywhere on the dev site (maybe I just wasn't looking hard enough), but I'm curious as to what version of Visual C++ you're using for the official Chrome builds. It's Visual C++ 2005. (The official build does whole program optimization and must be done on a 64-bit Windows machine with lots of memory.) I don't know if we'd seen similar problems with Breakpad symbols. Wan-Teh -- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev
Re: [chromium-dev] Any interest in command line tools for network stack?
On Fri, Nov 13, 2009 at 11:58 AM, Chris Bentzel cbent...@gmail.com wrote: I'm using them as a learning exercise for the network stack - and I'm guessing that they will help debug behavior in the future as well. I don't intend to add additional functionality over the standard tools - in fact, I promise you they'll be less functional than the standard tools. For example, my hresolv executable just takes a hostname and a port as options for now. I'll spend a bit more time getting them to a reasonable point and send a patch out for review - figure decision will be easier then over a vague description. I also like the idea. These tools can serve as sample code for other projects that are considering taking our network stack. It can also be easier to debug a simple command line tool than a full-blown browser if a network stack bug can be reproduced using a command line tool. Wan-Teh -- 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: FreeBSD port, take 2
On Thu, Aug 27, 2009 at 3:02 AM, Ben Laurieb...@google.com wrote: I forgot to mention - there's a single file that may not be complete, base/crypto/signature_verifier_nss.cc - this is because the FreeBSD port of NSS is too old and doesn't have a function it needs. I'll get to that at some point soon, but I don't anticipate it being a problem. Our code can be built with NSS 3.12, but we should now use NSS 3.12.3 or later for fixes of the security vulnerabilities in the PKI Layer Cake paper. Wan-Teh --~--~-~--~~~---~--~~ 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 dev channel crashing on first login to gmail today?
On Wed, Aug 19, 2009 at 12:20 PM, Evan Martine...@chromium.org wrote: I got a crash on an SSL site today. It was http://code.google.com/p/chromium/issues/detail?id=18907 Fumitoshi Ukai just fixed that crash in r23696 last night. Wan-Teh --~--~-~--~~~---~--~~ 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: url_request document
On Fri, Aug 14, 2009 at 1:49 PM, Marshall Greenblattmagreenbl...@gmail.com wrote: Hi All, I've been using url_request for a while now, and I find myself consistently forgetting the relationship between the various managers/handlers and order in which the asynchronous calls take place. Does anyone currently have a document/diagram for url_request that we can put up under Design Documents on the developer wiki? Eric Roman has a diagram that shows the relationship between URLRequest and the classes below it. He may not have published it on our website, but it is in his YouTube video on the Chromium network stack. But I suspect you're more interested in the relationship between URLRequest and its consumers. The order in which the asynchronous calls take place is documented in url_request.h, in the block comment above the Delegate class. If you find that comment unclear or out of date, please create a changelist to update it with your findings. Wan-Teh --~--~-~--~~~---~--~~ 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: new hunspell has tons of valgrind warnings... revert?
On Sat, Aug 1, 2009 at 2:54 PM, Dan Kegeld...@kegel.com wrote: http://build.chromium.org/buildbot/waterfall/builders/Chromium%20Linux%20(valgrind)/builds/1671/steps/valgrind%20test:%20unit/logs/stdio introduces 26 new unintialized memory references and two leaks. That's a big enough batch that it might be a good idea to revert it and commit something later that isn't full of warnings. Or we could just go la la la la la and suppress them all. Our Coverity static analyais on Aug 1 (Run 43, based on the LATEST revision at 2009-08-01 00:00:00 US Pacific Time) also reported many new defects in Hunspell. If you're on Google's intranet, you can look at these Coverity defects by logging into Coverity and clicking the Hist. New Defects link (it should say 75) for Run ID 43. Wan-Teh --~--~-~--~~~---~--~~ 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: [BUG][PATCH] Small compilation issue on Linux
On Thu, Jul 30, 2009 at 12:13 PM, LivioSoareslivi...@gmail.com wrote: Hi, I'm running Debian, with GCC 4.3.3 and am current getting a compilation error while compiling Chromium: cc1plus: warnings being treated as errors chromium/src/net/base/net_util.cc: In function 'boolunnamed::IsIDNComponentSafe(const char16*, int, const std::wstring)': chromium/src/net/base/net_util.cc:641: error: suggest parentheses around assignment used as truth value scons: *** [chromium/src/sconsbuild/Release/obj/net/base/net_util.o] Error 1 The code in question was introduced at revision 21963. The obvious patch (below) fixes the issue for me. However, without understanding the code, I can't be sure the typo as actually to change = to ==. Since we return 'safe', I assumed that the assignment was what was intended. Thanks a lot for the patch. I think your patch is correct. I will convert it to a changelist and ask jshin to review it. Wan-Teh --~--~-~--~~~---~--~~ 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: Compiler warnings?
Ben, I believe the GCC warning you want is -Wreturn-type, which is enabled if we specify -Wall: http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Warning-Options.html#Warning-Options Are we not compiling with -Wall? Wan-Teh --~--~-~--~~~---~--~~ 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: HTTP POST via net package?
On Mon, Jun 8, 2009 at 2:02 PM, Daniel Cowxdaniel.c...@gmail.com wrote: How can I upload multipart form data (including a file) via HTTP POST? Is there something already written in the net package (or elsewhere) for this task? If so, can someone please point me to what class to use. You can use the URLRequest class in the net package to do HTTP POST. The URLFetcher class in chrome/browser/net is good example code. You can also use url_request_unittest.cc as example code. Wan-Teh --~--~-~--~~~---~--~~ 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: UI_test.exe fails to complete (please help)
On Mon, May 25, 2009 at 7:18 PM, nakro yoav.zilberb...@gmail.com wrote: but still this is what i get : (in hebrew it gets stuck, so this is an improvement) [ FAILED ] UnloadTest.BrowserCloseTabWhenOtherTabHasListener [ FAILED ] LoginPromptTest.TestBasicAuth [ FAILED ] LoginPromptTest.TestDigestAuth [ FAILED ] LoginPromptTest.TestTwoAuths [ FAILED ] SSLUITest.TestMixedContentsFilterAll If you see the Chromium isn't your default browser. info bars (they are right below the location bar) when you run the LoginPromptTest tests, then the three LoginPromptTest.* test failures are this issue: http://code.google.com/p/chromium/issues/detail?id=12668 Try setting Chromium as your default browser and see if that make those three tests pass. Wan-Teh --~--~-~--~~~---~--~~ 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: cryptoht.h not found
On Sat, May 16, 2009 at 12:13 AM, Mohamed Mansour m0.interact...@gmail.com wrote: Weird, I just received this error while compiling a fresh build on linux. Downloaded the tarball, and hammer (clean). The first error I saw on the screen was: cd: 1: can't cd to /auto/filer28.mtvvolmtvhome51/chrome-svn/tarball/chromium/src/base Then it stated: /home/m0/chromium/src/base/crypto/signature_verifier.h:11:22: error: cryptoht.h: No such file or directory I checked my pkg-config --cflags nss which returned: -I/usr/include/nss -I/usr/include/nspr I looked into it further and grep'd the gyp with mtvvolmtvhome51 and it appeared in couple. I had to do runhooks: gclient runhooks --force So my question, why does the tarball come with bad .scons files? Why doesn't the gclient sync regenerate them? Maybe add another step to the linux process that will tell the user to regenerate them after initial build. Many users having this problem it seems. I guess it's because when we used gclient sync to check out the source tree in the tarball, and that gclient sync command did runhooks at the end and generated .scons files that are only good on that computer. I don't know why another gclient sync didn't regenerate them. Perhaps because the timestamps of the .scons files were newer than the timestamps of the .gyp files? Wan-Teh --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Unexpected PDB error; ACCESS_DENIED (15) while building browser_tests_launcher
I am using Visual Studio 2005 SP1 with hotfix 935225 on Windows XP SP3. I checked out a chromium source tree from scrash, using http://build.chromium.org/buildbot/continuous/LATEST/REVISION as the safesync_url, and did a Release build. I got the following link error while building browser_tests_launcher. Does anyone know what's wrong? 172-- Build started: Project: browser_tests_launcher, Configuration: Releas e Win32 -- 172Compiling... 172browser_tests_launcher.cc 171 Creating library E:\chromium.latest\src\chrome\Release\lib\browser_tests. lib and object E:\chromium.latest\src\chrome\Release\lib\browser_tests.exp 172Linking... 172LINK : fatal error LNK1318: Unexpected PDB error; ACCESS_DENIED (15) 'e:\chr omium.latest\src\chrome\Release\browser_tests.pdb' 172Build log was saved at file://E:\chromium.latest\src\chrome\Release\obj\bro wser_tests_launcher\BuildLog.htm 172browser_tests_launcher - 1 error(s), 0 warning(s) Wan-Teh --~--~-~--~~~---~--~~ 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: Unexpected PDB error; ACCESS_DENIED (15) while building browser_tests_launcher
On Fri, May 8, 2009 at 11:06 AM, Marc-Antoine Ruel mar...@chromium.org wrote: /MP ? If so, that's normal. Make sure you also kill mspdbsrv.exe. No, I didn't add /MP to essential.vsprops because I know it doesn't work well with Visual Studio 2005. I did a web search for the linker error message LINK : fatal error LNK1318: Unexpected PDB error; ACCESS_DENIED (15) and the only thing I found is your checkin to remove /MP from essential.vsprops :) http://src.chromium.org/viewvc/chrome?view=revrevision=7603 I don't have any mspdbsrv.exe process running (but I'm not doing a build right now). Wan-Teh --~--~-~--~~~---~--~~ 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: Fwd: Friend who works on Chrome
On Wed, May 6, 2009 at 1:26 PM, Nick Baum nickb...@chromium.org wrote: -- Forwarded message -- Kirill - thanks for the intro. Nick - I just wanted to follow up on that strange issue with Chrome I mentioned when we last talked. When I load Chrome, the favorites boxes load instantly, though when I click on any of them, or go to any site in the first open Chrome tab, it takes about 45 seconds for that site to fully load. 80% of the page's content will load immediately, but the page will be frozen, in the sense that you can't click on any of the links on it, for about 45 seconds. Sites opened subsequently in the same tab, and different tabs, load instantly. It's just the first tab that freezes for 45 seconds. I thought this could be http://code.google.com/p/chromium/issues/detail?id=9258, but bug 9258 doesn't affect just the first tab, and also can't explain the problem of Outlook freezing at the same time. In any case, bug 9258 has been fixed in the current Dev channel release and will be fixed in the next Beta channel release (expected this week). Wan-Teh --~--~-~--~~~---~--~~ 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: BUG= formatting
On Thu, Apr 30, 2009 at 1:50 PM, Ben Goodger (Google) b...@chromium.org wrote: Hint: If you write your changelist bug line like this: http://crbug.com/7991 instead of like this: BUG=7991 your bug line will be linkified and clickable in numerous places (like the buildbot pages, Rietveld, the issue tracker, etc). Does our bugdroid1 script recognize the http://crbug.com/7991; format, too? Should we start using bugs.chromium.org now? Wan-Teh --~--~-~--~~~---~--~~ 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: GSoC: Network Stack in Chromium
On Wed, Apr 22, 2009 at 7:20 PM, Smita vsmi...@gmail.com wrote: Hello, I am not sure if this is the correct forum to put in this question, but I was just curious to know where my application lacked, and why it did not qualify. Your feedback is greatly appreciated! Hi Smita, Our product manager Brian suggested that we contact the students whose proposals were not accepted on Monday. I forgot to do that. I apologize. Many of the students who applied submitted good proposals. It's clear that they put in a lot of effort in preparing the proposals. This year the Summer of Code program only allocated 5 slots to the Chromium project, much fewer than the number of slots we requested. As a result we had to decline some good proposals. I hope you will be able to contribute to Chromium in your spare time. Thank you very much for your interest and application. Wan-Teh --~--~-~--~~~---~--~~ 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: GSoC: Providing Client Certificate using PKCS#11
On Tue, Mar 24, 2009 at 3:21 PM, Smita vsmi...@gmail.com wrote: Hello, I am putting forth the problem of client authentication handling in Chrome, as I understand it. Kindly correct me if this isn't correct. I understand that SSL handshake fails when a server asks for the client certificate. Currently there is no provision to extract the PKCS#11 certificate of the client from a specified DB. The task requires that the PKCS#11 certificate be extracted from the DB and sent to the server. Yes, your description of the problem is basically correct. The inaccuracy is in the use of the term PKCS #11. The correct terms are X.509 certficate and NSS DB. Questions that arises here: how is the DB specified? Will it be a specified path on the disk? Also, will the PKCS#11 be encrypted in the DB? Hence, the application will have to decrypt it into plaintext and then send it to the server. Chromium is not yet using an NSS DB, but we will need to use an NSS DB for the SSL client certificates. We will choose a path either in Chromium's user data directory or in a directory that can be shared with other applications. The latter is preferred. Certificates contain public information, so they don't need to be encrypted on disk. However, the associated private keys are encrypted with password-based encryption and stored in the NSS DB. Also note that the certificate and associated private key could be stored in a smart card, in which case NSS will talk to the smart card using the PKCS #11 API. Wan-Teh --~--~-~--~~~---~--~~ 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: NSS and NSPR
On Fri, Feb 27, 2009 at 5:38 PM, Mark Mentovai m...@chromium.org wrote: Wan-Teh Chang wrote: Another idea is to work harder with Ubuntu to provide the ia32 NSPR/NSS libs for x86_64 in Ubuntu 8.04 LTS. That'd be the best solution but require a lot of red tape. It sounds like the red tape is the real problem here. Are we attacking the problem on this front at all? It seems like all of this becomes moot if we can get it resolved from that angle. Yes, red tape is the real problem. I'm planning to write to Alexander Sack (who seems to maintain the NSS package in Ubuntu) this weekend. Wan-Teh --~--~-~--~~~---~--~~ 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: Reviewing commit messages
Dean, I agree with all your suggestions. Re: typos/spelling errors: I recently started to fix typos/spelling errors in the description of a CL I'm reviewing by clicking Edit Issue. (Rietveld allows a reviewer to edit the description of a CL.) Wan-Teh --~--~-~--~~~---~--~~ 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: Windows SDK requirement change : v6.1 is required
On Wed, Jan 7, 2009 at 2:12 PM, Jungshik Shin (신정식, 申政湜) js...@chromium.org wrote: Therefore, the only thing necessary to do is to download Windows SDK 6.1 at http://www.microsoft.com/downloads/details.aspx?FamilyID=e6e1c3df-a74f-4207-8586-711ebe331cdcDisplayLang=en and install it (and integrate it with Visual Studio) I found Windows SDK 6.1 in the Chromium source tree under third_party/platformsdk_win2008_6_1. Do we still need to download Windows SDK 6.1 and install it? Wan-Teh --~--~-~--~~~---~--~~ 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: HTTP BASIC/DIGEST BUG - Has it been fixed yet?
On Mon, Jan 5, 2009 at 12:28 PM, Evan Martin e...@chromium.org wrote: It would help if you link to the bug in the bug tracker. I believe this message is in reference to http://code.google.com/p/chromium/issues/detail?id=1629 which has been marked fixed. This bug has been fixed on the trunk of the Chromium source tree. But the fix isn't in the latest Google Chrome release yet because it is based on a branch created in November. We didn't backport the bug fix to the official branch because it's a big patch so there's a risk that we may introduce other bugs when we adapt it for the official branch, which uses a completely different HTTP stack. Hopefully the fix will appear in a Dev Channel release as part of our new HTTP stack very soon. Note: the bug is not that Chromium doesn't support HTTP BASIC and DIGEST authentication. The bug is that Chromium will only send a HTTP Authorization header after receiving a 401 Authorization Required response to the first attempt of the request. Wan-Teh Chang --~--~-~--~~~---~--~~ 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: 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] 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 -~--~~~~--~~--~--~---
