diff options
| author | rsleevi@chromium.org <rsleevi@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-07-23 14:17:15 +0000 |
|---|---|---|
| committer | rsleevi@chromium.org <rsleevi@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2010-07-23 14:17:15 +0000 |
| commit | 23633b659e6bc5f672197eb90eb6ee50b843ba4a (patch) | |
| tree | 4617f2efe95cd16cba64242c42b128941b63ed6e /ipc/sync_socket_unittest.cc | |
| parent | c1fa0025cc83f4a625830a1c91d8ab2c80c7be32 (diff) | |
| download | chromium_src-23633b659e6bc5f672197eb90eb6ee50b843ba4a.zip chromium_src-23633b659e6bc5f672197eb90eb6ee50b843ba4a.tar.gz chromium_src-23633b659e6bc5f672197eb90eb6ee50b843ba4a.tar.bz2 | |
Fix FLAKY X509CertificateParseTest.CanParseFormat on OS X 10.5 when decoding PEM-encoded PKCS#7 certificates that are marked with PEM pre-encapsulation boundary of BEGIN CERTIFICATE.
OS X ignores the caller-supplied format if it determines that the incoming data is PEM encoded, attempting to parse using an internal routine that determines the incoming format based on the PEM block header. On 10.5, this results in invalid certificate handles being returned, because the data is not actually a certificate, and this propagates into invalid X509Certificates. By sanity checking the returned handles using the same method as CreateOSCertHandleFromBytes, the problem can be caught and the data can be decoded by PEMTokenizer into a format that 10.5 will respect.
R=wtc
BUG=49887
TEST=X509CertificateParseTest.CanParseFormat no longer fails on OS X 10.5 for variations /5 and /11
Review URL: http://codereview.chromium.org/3019019
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@53467 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'ipc/sync_socket_unittest.cc')
0 files changed, 0 insertions, 0 deletions