net_unittests failures on Gentoo Linux

[Paweł Hajdan, Jr.]

I made www-client/chromium package run net_unittests on Gentoo Linux in the src_test phase, and I noticed some failures (they are suppressed in the ebuild checked to the portage tree, i.e. the failing tests do not run).

It is not obvious to me what causes those failures or whether they can be "reasonably safely" ignored, so any help is appreciated.

Some tests fail with system ICU but pass with the bundled one: http://bugs.gentoo.org/show_bug.cgi?id=361885

The test server fails to start for HTTPS/SSL tests (really weird, tried both with system and bundled tlslite):

http://bugs.gentoo.org/show_bug.cgi?id=361939

[ RUN      ] URLRequestTestHTTP.HTTPSToHTTPRedirectNoRefererTest
Traceback (most recent call last):
  File
"/var/tmp/portage/www-client/chromium-12.0.712.0/work/chromium-12.0.712.0/net/tools/testserver/testserver.py",
line 1465, in <module>
    sys.exit(main(options, args))
  File
"/var/tmp/portage/www-client/chromium-12.0.712.0/work/chromium-12.0.712.0/net/tools/testserver/testserver.py",
line 1342, in main
    options.ssl_bulk_cipher)
  File
"/var/tmp/portage/www-client/chromium-12.0.712.0/work/chromium-12.0.712.0/net/tools/testserver/testserver.py",
line 82, in __init__
    self.private_key = tlslite.api.parsePEMKey(s, private=True)
  File
"/var/tmp/portage/www-client/chromium-12.0.712.0/work/chromium-12.0.712.0/third_party/tlslite/tlslite/utils/keyfactory.py",
line 146, in parsePEMKey
    key = OpenSSL_RSAKey.parse(s, passwordCallback)
  File
"/var/tmp/portage/www-client/chromium-12.0.712.0/work/chromium-12.0.712.0/third_party/tlslite/tlslite/utils/OpenSSL_RSAKey.py",
line 141, in parse
    raise SyntaxError()
SyntaxError: None
[28665:28665:0404/184910:371811130277:ERROR:test_server_posix.cc(146)] Could
not read server_data_len
net/url_request/url_request_unittest.cc:337: Failure
Value of: https_test_server.Start()
  Actual: false
Expected: true
[  FAILED  ] URLRequestTestHTTP.HTTPSToHTTPRedirectNoRefererTest (1357 ms)

[Ryan Sleevi]

From the right address this time...

I wouldn't expect system tlslite to work, just because the tlslite bundled does include patches that the tests rely on that aren't upstream (nb: upstream tlslite hasn't seen a release for 6 years, AFAICT)

The issue appears to be because tlslite is stricter in checking the input in OpenSSL_RSAKey than it is in Python_RSAKey, which are the two implementations it ships with for parsing keys, the underlying logic of tlslite.api.parsePEMKey(). At least on my Windows dev box, the Python_RSAKey.py path (src/third_party/tlslite/tlslite/utils/PYTHON_RSAKey.py) is the path taken when reading keys, but I suspect this is the case as well for the other platforms in the build waterfall, given that none of them are having this problem.

The data being parsed is a joint certificate + private key in PEM form (see src/net/data/ssl/certificates/[ok|expired]_cert.pem). The certificate and private key are marked by PEM header blocks BEGIN/END CERTIFICATE and BEGIN/END RSA PRIVATE KEY. Python_RSAKey.py locates a private key by using s.find() for BEGIN PRIVATE KEY and BEGIN RSA PRIVATE KEY in order to determine the private key data before trying to parse, while OpenSSL_RSAKey.py uses s.startswith().

Since the certificate appears before the private key in both files, s.startswith() fails (and the SyntaxError() is raised), while s.find() works, since the key is there. It's not immediately clear whether this bug is a bug in testserver.py relying on unexpected behaviour or in tlslite for the differing implementation behaviour. From the tlslite documentation in parsePEMKey(), I get the feeling the root "bug" is in testserver.py for expecting tlslite to behave like Python_RSAKey, even though that is the commonly-expected behaviour with PEM parsers.

I can see at least three distinct ways to deal with this, each with their own merits, although there are probably solutions I'm overlooking.

1) Patch tlslite so that OpenSSL_RSAKey is as lenient/flexible as Python_RSAKey when reading the key data, switching to s.find() instead of s.startswith().

2) Swap the certificate and private key in [ok|expired]_cert.pem, so that s.startswith() will return true for OpenSSL_RSAKey. tlslite.X509 uses s.find() to locate the BEGIN CERTIFICATE, so it should be unaffected. This will cause both the private key and certificate to be passed to OpenSSL to parse as a private key. However, IIRC, OpenSSL is also very lenient in parsing PEM private keys, so it should safely ignore the certificate, as the PEM headers won't be molested before passing to OpenSSL.

3) Change testserver.py to take a certificate and private key as separate arguments, update testserver.cc to pass the separate arguments, and split [ok|expired]_cert.pem into separate certificate and key files.

Hope that helps,

   Ryan

[Paweł Hajdan, Jr.]

On Wed, Apr 6, 2011 at 08:43, Ryan Sleevi <rsl...@chromium.org> wrote:

I wouldn't expect system tlslite to work, just because the tlslite bundled does include patches that the tests rely on that aren't upstream (nb: upstream tlslite hasn't seen a release for 6 years, AFAICT)

Right, the upstream seems to be dead.

 

The issue appears to be because tlslite is stricter in checking the input in OpenSSL_RSAKey than it is in Python_RSAKey, which are the two implementations it ships with for parsing keys, the underlying logic of tlslite.api.parsePEMKey(). At least on my Windows dev box, the Python_RSAKey.py path (src/third_party/tlslite/tlslite/utils/PYTHON_RSAKey.py) is the path taken when reading keys, but I suspect this is the case as well for the other platforms in the build waterfall, given that none of them are having this problem.

The data being parsed is a joint certificate + private key in PEM form (see src/net/data/ssl/certificates/[ok|expired]_cert.pem). The certificate and private key are marked by PEM header blocks BEGIN/END CERTIFICATE and BEGIN/END RSA PRIVATE KEY. Python_RSAKey.py locates a private key by using s.find() for BEGIN PRIVATE KEY and BEGIN RSA PRIVATE KEY in order to determine the private key data before trying to parse, while OpenSSL_RSAKey.py uses s.startswith().

Since the certificate appears before the private key in both files, s.startswith() fails (and the SyntaxError() is raised), while s.find() works, since the key is there. It's not immediately clear whether this bug is a bug in testserver.py relying on unexpected behaviour or in tlslite for the differing implementation behaviour. From the tlslite documentation in parsePEMKey(), I get the feeling the root "bug" is in testserver.py for expecting tlslite to behave like Python_RSAKey, even though that is the commonly-expected behaviour with PEM parsers.

Thank you, that's a great analysis! I'll add some more bits from our IRC conversation:

- there is some autodetection of libraries ("from M2Crypto import m2"), and indeed it detected dev-python/m2crypto package on my system
- that triggers the usage of OpenSSL_RSAKey instead of the Python variant

- the autodetection logic is in src/third_party/tlslite/tlslite/utils/cryptomath.py

The easy fix that should work would be to disable the unwanted autodetection (that means another local patch for tlslite; the upstream seems to be dead so it is justified).

Swapping the certificate and private key also sounds good and simple.

I'll test those solutions and I'm going to send some patches then.

[Wan-Teh Chang]

On Wed, Apr 6, 2011 at 12:21 AM, Paweł Hajdan, Jr.
<phajd...@chromium.org> wrote:
>
> Swapping the certificate and private key also sounds good and simple.
> I'll test those solutions and I'm going to send some patches then.

Yes, either swapping the certificate and private key in the PEM files
or splitting the PEM files into separate certificate and private key
files is fine by me. Which one is more common in real OpenSSL-based
servers?

Ryan, thank you for your analysis of the problems.

Wan-Teh