CI Changes
1. I've split the original patch up to make it easier to digest, but
that forces my hand to turn off testing in the AWS-LC CI for the time
being. However, do let me know if you would prefer to review the test
adjustments in the same PR and I can remove the temporary CI workaround.
2. AWS-LC has a few no-op functions and we use -Wdeprecated-declarations
to alert the consuming application of these. I've leveraged the
skip-warnings CI option so that the build doesn't fail.
Build Adjustments
1. AWS-LC FIPS mode is decided at compile time. This is different from
OpenSSL's togglable FIPS switch, so I've adjusted the build to account
for this.
2. AWS-LC does not support for the two KEY_SIG or KEY_EX flags that were
only ever supported by old MSIE.
3. AWS-LC has no current support for post handshake authentication in
TLS 1.3.
4. EC_GROUP structures for named curves in AWS-LC are constant, static,
and immutable by default. This means that the EC_GROUP_set_* functions
are essentially no-ops due to the immutability of the structure. We've
introduced a new API for consumers that depend on the OpenSSL's default
mutability of the EC_GROUP structure called
EC_GROUP_new_by_curve_name_mutable. Since Ruby has a bit of
functionality that's dependent on the mutability of these structures,
I've made the corresponding adjustments to allow things to work as
expected.
https://github.com/ruby/openssl/commit/e53ec5a101
We can just always return the jit_entry since it will be initialized to
NULL. There is no reason to specifically return NULL if yjit / rjit are
disabled
RUBY_TEST_TIMEOUT_SCALE is set for debug builds because they are slower
to run. We should respect this environment variable in MMTk tests too.
https://github.com/ruby/mmtk/commit/0a66c518bf
The `ids` array and `dsymbol_fstr_hash` were pinned because they were
kept alive by rb_vm_register_global_object. This prevented the GC from
moving them even though there were reference updating code.
This commit changes it to be marked movable by marking it as a root object.
assert_handshake_error is useful for checking handshake failures
triggered by the peer, as the underlying socket may be closed
prematurely, leading to different exceptions depending on the platform
and timing.
However, when the local end aborts a handshake, the only possible
exception is OpenSSL::SSL::SSLError. Use stricter assertions in such
cases.
https://github.com/ruby/openssl/commit/637ba65818
The list of NPN protocols is validated in SSLContext#setup.
The assert_handshake_error is misleading. The client is unable to start
a handshake at all because the server is not running.
https://github.com/ruby/openssl/commit/e8db6ffd9e
Use start_server instead of start_server_version.
start_server_version is a wrapper around start_server that forces the
server to a specific protocol version using the now-deprecated method
SSLSocket#ssl_version=, but it does more than that. The slightly
different method signature and default values are confusing. Let's
use start_server directly.
https://github.com/ruby/openssl/commit/22ed31d77e
The default timeout on GitHub Actions is 360 minutes, the job usually takes
around 20 to 30 minutes to complete. This commit sets the timeout to be
40 minutes so jobs that hang will timeout faster.
I think we need this to silence the following warning when running
`bin/console` with Ruby 3.4
```
./bin/console:10: warning: irb was loaded from the standard library, but will no longer be part of the default gems starting from Ruby 3.5.0.
You can add irb to your Gemfile or gemspec to silence this warning.
```
https://github.com/rubygems/rubygems/commit/c46230c856
For installed specifications, we can ignore any constraints they may
have, since we know they match the current version of Ruby or otherwise
would not be installed.
For remote specifications, we already resolve optimistically without
metadata and retry force-fetching it if necessary.
If in the future we support resolving against a Ruby version different
that the one being run, we'll probably need to change this but now it's
unnecessary and saves some memory.
### Before
Total allocated: 262.99 MB (3177437 objects)
Total retained: 115.91 MB (1297821 objects)
### After
Total allocated: 259.89 MB (3134199 objects)
Total retained: 115.05 MB (1283779 objects)
https://github.com/rubygems/rubygems/commit/201c1863fc
They use less memory that way.
When resolving from scratch a Gemfile including only `"gem "rails", "~>
8.0.1"`, I get the following results:
### Before
Total allocated: 265.06 MB (3186053 objects)
Total retained: 116.98 MB (1302280 objects)
### After
Total allocated: 262.99 MB (3177437 objects)
Total retained: 115.91 MB (1297821 objects)
https://github.com/rubygems/rubygems/commit/a4ef9c5f56
Sometimes we'll resolve using bare `Gem::Dependency` instances rather
than `Bundler::Dependency` instances, which is fine, simpler, and saves
some memory.
When resolving from scratch a Gemfile including only `"gem "rails", "~>
8.0.1"`, I get the following results:
### Before
Total allocated: 277.48 MB (3384318 objects)
Total retained: 117.53 MB (1338657 objects)
### After
Total allocated: 265.06 MB (3186053 objects)
Total retained: 116.98 MB (1302280 objects)
https://github.com/rubygems/rubygems/commit/c6dc2966c5
When resolving from scratch a Gemfile including only `"gem "rails", "~>
8.0.1"`, I get the following results:
### Before
Total allocated: 288.21 MB (3498515 objects)
Total retained: 119.10 MB (1357976 objects)
### After
Total allocated: 277.44 MB (3383182 objects)
Total retained: 117.55 MB (1338622 objects)
https://github.com/rubygems/rubygems/commit/2d3d6e5015
Since not every dependency gets referenced.
When resolving from scratch a Gemfile including only `"gem "rails", "~>
8.0.1"`, I get the following results:
### Before
Total allocated: 295.01 MB (3624335 objects)
Total retained: 119.31 MB (1364474 objects)
### After
Total allocated: 288.21 MB (3498515 objects)
Total retained: 119.10 MB (1357976 objects)
https://github.com/rubygems/rubygems/commit/61eee39d81
Co-authored-by: Samuel Giddins <segiddins@segiddins.me>
Currently evenn if the require actually fails, they suggest that the
file was actually loaded, which is confusing. I reworded them to reduce
this confusion.
