python-trio/trustme

Failure on 32 bit Linux

asvetlov opened this issue · 7 comments

asvetlov commented

When building aiohttp binary wheels we run tests on built files.
On 32 bit Linux it produces the following error:


    @pytest.fixture
    def tls_certificate_authority():
>       return trustme.CA()

io/tests/conftest.py:25: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
opt/_internal/cpython-3.5.6/lib/python3.5/site-packages/trustme/__init__.py:212: in __init__
    backend=default_backend(),
opt/_internal/cpython-3.5.6/lib/python3.5/site-packages/cryptography/x509/base.py:595: in sign
    return backend.create_x509_certificate(self, private_key, algorithm)
opt/_internal/cpython-3.5.6/lib/python3.5/site-packages/cryptography/hazmat/backends/openssl/backend.py:804: in create_x509_certificate
    self._lib.X509_get_notAfter(x509_cert), builder._not_valid_after
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = <cryptography.hazmat.backends.openssl.backend.Backend object at 0xf6e759ec>
asn1_time = <cdata 'struct asn1_string_st *' 0x90f5ab0>
time = datetime.datetime(3000, 1, 1, 0, 0)

    def _set_asn1_time(self, asn1_time, time):
        timestamp = calendar.timegm(time.timetuple())
>       res = self._lib.ASN1_TIME_set(asn1_time, timestamp)
E       OverflowError: integer 32503680000 does not fit '32-bit int'

opt/_internal/cpython-3.5.6/lib/python3.5/site-packages/cryptography/hazmat/backends/openssl/backend.py:840: OverflowError

@njsmith do you have an idea how to fix it?

webknjaz commented

From the trace, it looks like it's a problem with cryptography...

But given the comment @ https://github.com/python-trio/trustme/blob/fb7ef8b/trustme/__init__.py#L61-L65 it looks like platform limitations exist with Windows as well.

I think this could be addressed within trustme by issuing the certificate a year or ten years ahead. This could be a solution for another 19-87 years.

Timestamp of 2147483647 corresponds to GMT Tuesday, January 19, 2038 3:14:07 AM
and 4294967294 (unsigned int32) is GMT Sunday, February 7, 2106 6:28:14 AM.

njsmith commented

Yeah, this is a cryptography bug, and actually someone else ran into it 2 weeks ago and has a PR in progress: pyca/cryptography#4658

In the mean time though I guess we should restrict expiration dates to 2038.

njsmith commented

Here's a curious note: signed 32-bit time_t fails on January 19, 2038. The Windows gmtime function starts failing on January 19, 3001. Why on earth are they both January 19? Is it just a coincidence?

The Windows docs don't give any clue... they claim that it only works until December 31, 3000, which is empirically not true.

It looks like the last second where Windows gmtime succeeds is 3001-01-19 20:59:59, so it's not exactly 963 years later, but still... weird!

This is totally off-topic but now that I noticed it's bugging me.

webknjaz commented

@njsmith on that M$ page you referred there's a note about 32bit platforms:

We recommend that you do not do this, because it is not allowed on 64-bit platforms and in any case your application may fail after January 18, 2038.

So I'd say it's documented.

njsmith commented

@webknjaz the part that isn't documented is the actual range of the 64-bit gmtime (the one that works until the year 3000).

webknjaz commented

Oh