Generate client certs dynamically#1725
Conversation
sethmlarson
left a comment
There was a problem hiding this comment.
Looks pretty good, a couple questions for you
test/conftest.py
Outdated
There was a problem hiding this comment.
Hate to be nit-picky about names but can we call this certs_dir or something shorter? :)
There was a problem hiding this comment.
Don't worry, I love nitpicks! You're right, certs_dir would be better.
test/with_dummyserver/test_https.py
Outdated
There was a problem hiding this comment.
This will be changed once we move to generating server certs as well?
There was a problem hiding this comment.
Yes, it will change. I'm not sure yet how that will look. Ideally I'll be able to get the hash programmatically, maybe via trustme. It's also possible that it will stay static because it depends only on the name which could stay static. Not sure, really. I've spend quite some time trying to figure this out but don't have a satisfying answer here yet. :(
Codecov Report
@@ Coverage Diff @@
## master #1725 +/- ##
=======================================
Coverage 99.65% 99.65%
=======================================
Files 22 22
Lines 2006 2006
=======================================
Hits 1999 1999
Misses 7 7Continue to review full report at Codecov.
|
This was not possibly until now because of functool.wraps for older Pythons.
Instead of storing it in git.
In order to support older Python versions.
We keep the existing client_intermediate.pem because it's used in the password tests. And we still rely on the existing root CA to generate the client certificate because it's still used for the server certificate. Since the CA uses a 1024-bit key, those client_intermediate tests still don't work on macOS 10.15, but this commit still is a step forward.
9cf5fae to
1c8bc1e
Compare
Opening this pull request to get a review of the last commit: pquentin@22da6fd
I'll rebase it if/when the other pull requests get merged.