Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add cpython integration test #1359

Merged
merged 13 commits into from
Jan 31, 2024

Conversation

WillChilds-Klein
Copy link
Contributor

@WillChilds-Klein WillChilds-Klein commented Dec 15, 2023

Issues:

Addresses i/CryptoAlg-2136

Description of changes:

This change adds an integration test for CPython versions 3.10 through tip-of-main. Running all 3.10 python module tests on my AL2 dev machine takes ~5m:

$ time ./tests/ci/integration/run_python_integration.sh
...
== Tests result: FAILURE then SUCCESS ==

404 tests OK.

21 tests skipped:
    test_bz2 test_ctypes test_devpoll test_idle test_ioctl test_kqueue
    test_msilib test_ossaudiodev test_readline test_sqlite
    test_startfile test_tcl test_tix test_tk test_ttk_guionly
    test_ttk_textonly test_turtle test_winconsoleio test_winreg
    test_winsound test_zipfile64

1 re-run test:
    test___all__

However, in CI testing, I found that some tests (unrelated to our ssl module integration) failed on our ubuntu 22.02 docker image:

== Tests result: FAILURE then FAILURE ==

395 tests OK.

9 tests failed:
    test_email test_generators test_multiprocessing_fork
    test_multiprocessing_forkserver test_multiprocessing_spawn
    test_pdb test_regrtest test_signal test_threading

21 tests skipped:
    test_bz2 test_dbm_gnu test_dbm_ndbm test_devpoll test_gdb
    test_idle test_ioctl test_kqueue test_msilib test_ossaudiodev
    test_startfile test_tcl test_tix test_tk test_ttk_guionly
    test_ttk_textonly test_turtle test_winconsoleio test_winreg
    test_winsound test_zipfile64

10 re-run tests:
    test___all__ test_email test_generators test_multiprocessing_fork
    test_multiprocessing_forkserver test_multiprocessing_spawn
    test_pdb test_regrtest test_signal test_threading

As a result, I've narrowed down our python test suite to only the modules that actually use our libssl (this list was discovered by calling abort() in SSL_CTX_new and seeing which module tests failed) as well as hashlib, which is the only other module other than ssl to include libcrypto. From the CPython 3.10 source to discover which modules use libcrypto:

$ ag -l 'include.+crypto' Modules/
Modules/_hashopenssl.c
Modules/_ssl.c

Call-outs:

As we add support for further versions, we may want to parallelize the build and test processes.

Testing:

  • see description section above
  • CI integration tests

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license.

@WillChilds-Klein WillChilds-Klein force-pushed the integration-test-python branch 2 times, most recently from 08a027e to 301fd89 Compare December 15, 2023 03:22
@codecov-commenter
Copy link

codecov-commenter commented Dec 15, 2023

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (67d3e50) 76.83% compared to head (49d9b22) 76.82%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1359      +/-   ##
==========================================
- Coverage   76.83%   76.82%   -0.01%     
==========================================
  Files         425      425              
  Lines       71527    71527              
==========================================
- Hits        54959    54952       -7     
- Misses      16568    16575       +7     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@WillChilds-Klein WillChilds-Klein force-pushed the integration-test-python branch 4 times, most recently from 4e6c584 to 38cda10 Compare December 18, 2023 17:42
@WillChilds-Klein WillChilds-Klein deleted the integration-test-python branch December 19, 2023 15:06
@WillChilds-Klein WillChilds-Klein restored the integration-test-python branch December 19, 2023 20:16
@WillChilds-Klein WillChilds-Klein force-pushed the integration-test-python branch 4 times, most recently from 4702fb3 to 575e69f Compare January 8, 2024 23:40
@WillChilds-Klein WillChilds-Klein force-pushed the integration-test-python branch 4 times, most recently from 97e53fd to fc60492 Compare January 9, 2024 02:26
@WillChilds-Klein WillChilds-Klein force-pushed the integration-test-python branch 4 times, most recently from 014b032 to 1c77609 Compare January 22, 2024 16:55
@WillChilds-Klein WillChilds-Klein marked this pull request as ready for review January 22, 2024 17:05
@WillChilds-Klein WillChilds-Klein requested a review from a team as a code owner January 22, 2024 17:05
@WillChilds-Klein WillChilds-Klein enabled auto-merge (squash) January 22, 2024 17:07
@WillChilds-Klein WillChilds-Klein force-pushed the integration-test-python branch 2 times, most recently from 6376e29 to 7118481 Compare January 22, 2024 21:18
Comment on lines +381 to +378
-# _ssl _ssl.c $(OPENSSL_INCLUDES) $(OPENSSL_LDFLAGS) \
-# -l:libssl.a -Wl,--exclude-libs,libssl.a \
-# -l:libcrypto.a -Wl,--exclude-libs,libcrypto.a
-# _hashlib _hashopenssl.c $(OPENSSL_INCLUDES) $(OPENSSL_LDFLAGS) \
-# -l:libcrypto.a -Wl,--exclude-libs,libcrypto.a
+_ssl _ssl.c $(OPENSSL_INCLUDES) $(OPENSSL_LDFLAGS) \
+ -l:libssl.a -Wl,--exclude-libs,libssl.a \
+ -l:libcrypto.a -Wl,--exclude-libs,libcrypto.a
+_hashlib _hashopenssl.c $(OPENSSL_INCLUDES) $(OPENSSL_LDFLAGS) \
+ -l:libcrypto.a -Wl,--exclude-libs,libcrypto.a
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this diff needed or was this auto-generated

Copy link
Contributor Author

@WillChilds-Klein WillChilds-Klein Jan 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's needed. the diff for each branch is slightly different. each branch's changeset was constructed manually on the relevant branch of my cpython fork, tested, and then git diffed into these patch files.

tests/ci/integration/run_python_integration.sh Outdated Show resolved Hide resolved
samuel40791765
samuel40791765 previously approved these changes Jan 26, 2024
Comment on lines +92 to +93
# - Modify the ssl module's backing C code to set |SSL_MODE_AUTO_RETRY| in
# all calls to |SSL{_CTX}_set_mode|
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this on by default in OpenSSL?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As of 1.1.1, yes.

Comment on lines +76 to +78
# - In |test_bio|handshake|, check whether protocol is TLSv1.3 before testing
# tls-unique channel binding behavior, as channel bindings are not defined
# on that protocol
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a difference in support of channel binding between AWS-LC and OpenSSL, or how OpenSSL and AWS-LC report a failure in attempting to enable channel binding?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe it's a difference in channel binding "support" between AWS-LC and OpenSSL. I re-built my python fork against OSSL 3.0, reverted changes to this test, and dumped the return value of get_channel_binding(). On a TLSv1.3 connection OSSL will actually return a byte array, which is surprising given that channel bindings aren't defined for TLSv1.3. The CPython team has been made aware of this oddity.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dear @andrewhop, @WillChilds-Klein, I am happy to see your comments.

It is possible to talk on the CPython specified tickets, the problems with missing "tls-exporter" RFC9266 support, and "tls-server-end-point" support too?

I have done several tickets here without security solutions:

-> 2 years, no security solutions...

Several projects are impacted, I do not know all, example Slixmpp project has done a recent annnouncement:

Thanks a lot in advance.

Comment on lines 469 to 460
+ size_t unused_idx;
+ if (sk_SSL_CIPHER_find(client_ciphers, &unused_idx, cipher) < 0)
+#else
if (sk_SSL_CIPHER_find(client_ciphers, cipher) < 0)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not add a find that doesn't take an out index that wraps the existing sk_find for better compatibility? Also can our version of find ever return a negative number?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not add a find that doesn't take an out index that wraps the existing sk_find for better compatibility?

I don't think we can do this, as (to my knowledge) C doesn't support function overloading. Or are you proposing that we create a new funciton/symbol altogether that wraps our existing sk_SSL_CIPHER_find implementation and use that here?

I suppose we could also just change the signature to match OpenSSL's, but that might risk breaking any consumers that already use that function.

Also can our version of find ever return a negative number?

Not according to our documentation, no. Good catch! I'll update this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking we could have sk_SSL_CIPHER_find_internal which is our current implementation and sk_SSL_CIPHER_find which matches OpenSSL. I don't have a sense for how common OpenSSL stack usage outside of libcrypto/libssl is.

Copy link
Contributor Author

@WillChilds-Klein WillChilds-Klein Jan 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have a sense for how common OpenSSL stack usage outside of libcrypto/libssl is.

It looks like it's non-zero. What percentage of those projects depend on OSSL's signature vs. BSSL's signature? I don't know, but I would guess it would skew towards OSSL given its ubiquity. If we change the signature of sk_SSL_CIPHER_find, though, it would necessarily become a point of build incompatibility with BSSL. If our ultimate goal is OSSL compatibility, that's probably a trade worth making.

samuel40791765
samuel40791765 previously approved these changes Jan 29, 2024
@WillChilds-Klein WillChilds-Klein merged commit b49958a into aws:main Jan 31, 2024
38 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants