y2038: some tests are failing if system date is set to 2040

[kanavin]

To test the readiness of Yocto stack for Y2038 we run qemu virtual machines with RTC set to some day in 2040. This causes some tests to fail on both 32 bit and 64 bit systems: the reason is that test certificates seemto set their expiry date to earlier than that or so.

I would propose to set the expiry date to far enough in the future that it won't have to be tweaked in our lifetimes: this way real Y2038 issues in python-cryptography (or in things it depends on) can be exposed and fixed (it's well possible there are none, but that needs confirmation too).

Failure observed (this is one of several similar failures, all of them in test_pkcs7 and relying on _load_cert_key()).

self = <tests.hazmat.primitives.test_pkcs7.TestPKCS7Builder object at 0x7f94f0863610>, backend = <OpenSSLBackend(version: OpenSSL 3.1.1 30 May 2023, FIPS: False, Legacy: True)>

    def test_smime_sign_detached(self, backend):
        data = b"hello world"
        cert, key = _load_cert_key()
        options = [pkcs7.PKCS7Options.DetachedSignature]
        builder = (
            pkcs7.PKCS7SignatureBuilder()
            .set_data(data)
            .add_signer(cert, key, hashes.SHA256())
        )
    
        sig = builder.sign(serialization.Encoding.SMIME, options)
        sig_binary = builder.sign(serialization.Encoding.DER, options)
        assert b"text/plain" not in sig
        # We don't have a generic ASN.1 parser available to us so we instead
        # will assert on specific byte sequences being present based on the
        # parameters chosen above.
        assert b"sha-256" in sig
        # Detached signature means that the signed data is *not* embedded into
        # the PKCS7 structure itself, but is present in the SMIME serialization
        # as a separate section before the PKCS7 data. So we should expect to
        # have data in sig but not in sig_binary
        assert data in sig
        # Parse the message to get the signed data, which is the
        # first payload in the message
        message = email.parser.BytesParser().parsebytes(sig)
        signed_data = message.get_payload()[0].get_payload().encode()
>       _pkcs7_verify(
            serialization.Encoding.SMIME,
            sig,
            signed_data,
            [cert],
            options,
            backend,
        )

tests/hazmat/primitives/test_pkcs7.py:307: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
tests/hazmat/primitives/test_pkcs7.py:142: in _pkcs7_verify
    backend.openssl_assert(res == 1)
../../python3.11/site-packages/cryptography/hazmat/backends/openssl/backend.py:173: in openssl_assert
    return binding._openssl_assert(self._lib, ok, errors=errors)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

lib = <module 'lib'>, ok = False, errors = [<OpenSSLError(code=276824181, lib=33, reason=117, reason_text=certificate verify error)>]

    def _openssl_assert(
        lib,
        ok: bool,
        errors: typing.Optional[typing.List[openssl.OpenSSLError]] = None,
    ) -> None:
        if not ok:
            if errors is None:
                errors = openssl.capture_error_stack()
    
>           raise InternalError(
                "Unknown OpenSSL error. This error is commonly encountered when "
                "another library is not cleaning up the OpenSSL error stack. If "
                "you are using cryptography with another library that uses "
                "OpenSSL try disabling it before reporting a bug. Otherwise "
                "please file an issue at https://github.com/pyca/cryptography/"
                "issues with information on how to reproduce "
                "this. ({!r})".format(errors),
                errors,
            )
E           cryptography.exceptions.InternalError: Unknown OpenSSL error. This error is commonly encountered when another library is not cleaning up the OpenSSL error stack. If you are using cryptography with a)

../../python3.11/site-packages/cryptography/hazmat/bindings/openssl/binding.py:29: InternalError
FAIL: tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_smime_sign_detached

[alex]

The relevant file is vectors/cryptography_vectors/x509/custom/ca/ca.pem, we could extend the not-after to 2138 or something similarly obscene.

Not sure if there's any tests that'll need to be updated for this.

[kanavin]

If you can tell how to regenerate that file, I can run tests locally with that.

[alex]

Unfortunately there's no script or anything to regenerate it, and it looks like several other test vectors embed this cert, so this is going to be more involved than I feared.

…

On Mon, Aug 7, 2023 at 8:44 AM Alexander Kanavin ***@***.***> wrote: If you can tell how to regenerate that file, I can run tests locally with that. — Reply to this email directly, view it on GitHub <#9370 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBHF4L2OYCRP2J3VFFTXUDPLDANCNFSM6AAAAAA3G5GZOE> . You are receiving this because you commented.Message ID: ***@***.***>

-- All that is necessary for evil to succeed is for good people to do nothing.

[kanavin]

FWIW, the list of failing tests is:

Failed ptests:
{'python3-cryptography': ['tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_smime_sign_detached',
                          'tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_sign_byteslike',
                          'tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_sign_pem',
                          'tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_sign_alternate_digests_der[hash_alg0-\\x06\\t`\\x86H\\x01e\\x03\\x04\\x02\\x01]',
                          'tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_sign_alternate_digests_der[hash_alg1-\\x06\\t`\\x86H\\x01e\\x03\\x04\\x02\\x02]',
                          'tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_sign_alternate_digests_der[hash_alg2-\\x06\\t`\\x86H\\x01e\\x03\\x04\\x02\\x03]',
                          'tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_sign_attached',
                          'tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_sign_binary',
                          'tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_sign_smime_canonicalization',
                          'tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_sign_text',
                          'tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_sign_no_capabilities',
                          'tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_sign_no_attributes',
                          'tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_multiple_signers',
                          'tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_multiple_signers_different_hash_algs']}

[alex]

These almost certainly all use the same certificate.

…

On Mon, Aug 7, 2023 at 9:41 AM Alexander Kanavin ***@***.***> wrote: FWIW, the list of failing tests is: Failed ptests: {'python3-cryptography': ['tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_smime_sign_detached', 'tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_sign_byteslike', 'tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_sign_pem', 'tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_sign_alternate_digests_der[hash_alg0-\\x06\\t`\\x86H\\x01e\\x03\\x04\\x02\\x01]', 'tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_sign_alternate_digests_der[hash_alg1-\\x06\\t`\\x86H\\x01e\\x03\\x04\\x02\\x02]', 'tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_sign_alternate_digests_der[hash_alg2-\\x06\\t`\\x86H\\x01e\\x03\\x04\\x02\\x03]', 'tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_sign_attached', 'tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_sign_binary', 'tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_sign_smime_canonicalization', 'tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_sign_text', 'tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_sign_no_capabilities', 'tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_sign_no_attributes', 'tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_multiple_signers', 'tests/hazmat/primitives/test_pkcs7.py:TestPKCS7Builder.test_multiple_signers_different_hash_algs']} — Reply to this email directly, view it on GitHub <#9370 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBANWSX4EPHUULMQABDXUDWAJANCNFSM6AAAAAA3G5GZOE> . You are receiving this because you commented.Message ID: ***@***.***>

-- All that is necessary for evil to succeed is for good people to do nothing.

[reaperhulk]

Regenerating this is a bit of a pain, but definitely doable. However, why set it to 2040? The 2038 bug is triggered for anything past 2038-01-19 and this certificate expires end of December 2038. So you should be able to confirm 2038 readiness without triggering expiry failures.

[kanavin]

It's more about not having to think about what date to set (as long as it's this century), and also about fixing this just once, so this never has to be looked again in our lifetimes.

Where I can submit fixes, I set the expiry date to 2525 ( https://en.wikipedia.org/wiki/In_the_Year_2525 ):
curl/curl#11610
python/cpython#107594