gh-120762: make_ssl_certs: Don't set extensions for the CSR
`openssl req` fails with openssl 3.2.2 because the config line
authorityKeyIdentifier = keyid:always,issuer:always
is not supported for certificate signing requests (since the issuing
certificate authority is not known).
David von Oheimb, the OpenSSL dev that made the change, commented in:
https://github.com/openssl/openssl/issues/22966#issuecomment-1858396738 :
> This problem did not show up in older OpenSSL versions because of a bug:
> the `req` app ignored the `-extensions` option unless `-x505` is given,
> which I fixed in https://github.com/openssl/openssl/pull/16865.
(I assume `-x505` is a typo for `-x509`.)
In our `make_cert_key` function:
If `sign` is true:
- We don't pass `-x509` to `req`, so in this case it should be safe to
omit the `-extensions` argument. (Old OpenSSL ignores it, new OpenSSL
fails on it.)
- The extensions are passed to the `ca` call later in the function.
There they take effect, and `authorityKeyIdentifier` is valid.
If `sign` is false, this commit has no effect except rearranging the
CLI arguments.
* Spill the evaluation around escaping calls in the generated interpreter and JIT.
* The code generator tracks live, cached values so they can be saved to memory when needed.
* Spills the stack pointer around escaping calls, so that the exact stack is visible to the cycle GC.
This allows direct intersphinx references to APIs via references
like `` :func:`importlib.metadata.version` ``.
---------
Co-authored-by: Sviatoslav Sydorenko (Святослав Сидоренко) <wk.cvs.github@sydorenko.org.ua>
Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>
Co-authored-by: Sergey B Kirpichev <skirpichev@gmail.com>
Co-authored-by: Carol Willing <carolcode@willingconsulting.com>
* gh-117151: increase default buffer size of shutil.copyfileobj() to 256k.
it was set to 16k in the 1990s.
it was raised to 64k in 2019. the discussion at the time mentioned another 5% improvement by raising to 128k and settled for a very conservative setting.
it's 2024 now, I think it should be revisited to match modern hardware. I am measuring 0-15% performance improvement when raising to 256k on various types of disk. there is no downside as far as I can tell.
this function is only intended for sequential copy of full files (or file like objects). it's the typical use case that benefits from larger operations.
for reference, I came across this function while trying to profile pip that is using it to copy files when installing python packages.
* add news
---------
Co-authored-by: rmorotti <romain.morotti@man.com>
Cache in C PEG-generator reworked:
we save artificial rules in cache by Node string representation as a key instead of Node object itself.
As a result total count of artificial rules in parsers.c is lowered from 283 to 170.
More natural number ordering is used for the names of artificial rules.
Auxiliary method CCallMakerVisitor._generate_artificial_rule_call is added.
Its purpose is abstracting work with artificial rules cache.
Explicit using of "is_repeat1" kwarg is added to visit_Repeat0 and visit_Repeat1 methods.
Its slightly improve code readabitily.
Instead of surprise crashes and memory corruption, we now hang threads that attempt to re-enter the Python interpreter after Python runtime finalization has started. These are typically daemon threads (our long standing mis-feature) but could also be threads spawned by extension modules that then try to call into Python. This marks the `PyThread_exit_thread` public C API as deprecated as there is no plausible safe way to accomplish that on any supported platform in the face of things like C++ code with finalizers anywhere on a thread's stack. Doing this was the least bad option.
Co-authored-by: Gregory P. Smith <greg@krypto.org>