This test occasionally fail because it runs into a String instance
that had its `==` method removed.
I couldn't identify where this String comes from, but in general
when using `each_object` it's best to not assume returned objectd
are functional.
By just inverting the operands of `==` we ensure it's always
`String#==` that is called.
```
1) Error:
TestObjSpace#test_memsize_of_root_shared_string:
NoMethodError: undefined method '==' for #<String:0x00007f9b50e8c978>
/tmp/ruby/src/trunk-random1/test/objspace/test_objspace.rb:35:in 'block in TestObjSpace#test_memsize_of_root_shared_string'
/tmp/ruby/src/trunk-random1/test/objspace/test_objspace.rb:35:in 'ObjectSpace.each_object'
/tmp/ruby/src/trunk-random1/test/objspace/test_objspace.rb:35:in 'TestObjSpace#test_memsize_of_root_shared_string'
```
TestSetTraceFunc#test_tracepoint_disable is a flaky and failing intermittently. Here is an example of failure logs.
```
1) Failure:
TestSetTraceFunc#test_tracepoint_disable [/home/runner/work/ruby/ruby/src/test/ruby/test_settracefunc.rb:857]:
<[:foo, :disable, :foo, :disable]> expected but was
<[:call, :call, :foo, :disable, :foo, :disable]>.
```
3806620854 (step):12:875
I printed values of TracePoint objects as follows, and checked the values when failing intermittently.
7f9a6fc582/test/ruby/test_settracefunc.rb (L848)
Here is the log when the TestSetTraceFunc#test_tracepoint_disable failed intermittently.
`2025-03-05T09:08:37.4075411Z e: call, f: /home/runner/work/ruby/ruby/src/lib/tempfile.rb, l: 386, i: call, d: Tempfile::FinalizerManager` is an unexpected events. Thus, I modified test code so that we can filter out unexpected trace events.
```
2025-03-05T09:08:37.4075411Z e: call, f: /home/runner/work/ruby/ruby/src/lib/tempfile.rb, l: 386, i: call, d: Tempfile::FinalizerManager
2025-03-05T09:08:37.4085009Z e: call, f: /home/runner/work/ruby/ruby/src/test/ruby/test_settracefunc.rb, l: 808, i: foo, d: TestSetTraceFunc
2025-03-05T09:08:37.4086042Z e: call, f: <internal:trace_point>, l: 295, i: disable, d: TracePoint
2025-03-05T09:08:37.4115693Z e: call, f: /home/runner/work/ruby/ruby/src/test/ruby/test_settracefunc.rb, l: 808, i: foo, d: TestSetTraceFunc
2025-03-05T09:08:37.4116734Z e: call, f: <internal:trace_point>, l: 295, i: disable, d: TracePoint
```
[Bug #21170]
st_table reserves -1 as a special hash value to indicate that an entry
has been deleted. So that that's a valid value to be returned from the
hash function, do_hash replaces -1 with 0 so that it is not mistaken for
the sentinel.
Previously, when upgrading an AR table to an ST table,
rb_st_add_direct_with_hash was used which did not perform the same
conversion, this could lead to a hash in a broken state where one if its
entries which was supposed to exist being marked as a tombstone.
The hash could then become further corrupted when the ST table required
resizing as the falsely tombstoned entry would be skipped but it would
be counted in num entries, leading to an uninitialized entry at index
15.
In most cases this will be really rare, unless using a very poorly
implemented custom hash function.
This also adds two debug assertions, one that st_add_direct_with_hash
does not receive the reserved hash value, and a second in
rebuild_table_with, which ensures that after we rebuild/compact a table
it contains the expected number of elements.
Co-authored-by: Alan Wu <alanwu@ruby-lang.org>
Fix: https://github.com/ruby/spec/issues/1249
JRuby and TruffleRuby can't implement this behavior.
While quite a lot of code out there relies on it, if it's
not implemented it will simply result in sligthly less efficient
code, so not the end of the world.
http://ci.rvm.jp/results/trunk-gc-asserts@ruby-sp2-noble-docker/5632508
```
1) Error:
TestEval#test_outer_local_variable_under_gc_compact_stress:
Test::Unit::ProxyError: execution of Test::Unit::CoreAssertions#assert_separately expired timeout (10 sec)
pid 1339179 killed by SIGABRT (signal 6) (core dumped)
```
seems that timeout scale doesn't work even though `RUBY_TEST_TIMEOUT_SCALE`
is specified.
This patch tries to print the timeout with scale information.
Commit aa7f03e18f broke test_minmax_version and test_fallback_scsv
on systems using OpenSSL 1.1.1 with a system-wide configuration file
that specifies MinProtocol=TLSv1.2.
20250228T003003Z.fail.html.gz
20250228T003003Z.fail.html.gz
These test cases were already broken before the commit, but they were
being skipped because check_supported_protocol_versions failed to detect
TLS 1.1 support. To avoid affected by the configuration file, explicitly
reset SSLContext#min_version when TLS 1.1 or older is required.
The test cases are also broken with OpenSSL 3.0 or later, but this is
not currently visible because it still fails to detect TLS 1.1 support.
This is caused by the default SSLContext#security_level value, as
OpenSSL 3.0 changed TLS 1.1 to be disabled at level 1.
6d0ea81b5e
As reported in <https://github.com/ruby/ruby/pull/12823>,
check_supported_protocol_versions is unstable and occasionally fails
with Errno::ECONNABORTED during SSLSocket#connect on Windows.
When the server-side SSLContext specifies an unsupported SSL/TLS
protocol version, start_server accepts a TCP connection but closes it
without reading ClientHello, as SSLSocket#accept immediately raises an
exception. With Winsock, this can cause the client-side
SSLSocket#connect to raise Errno::ECONNABORTED.
While the simplest fix is to add rescue Errno::ECONNABORTED, this method
can be simplified. Instead, let's set up a server that accepts all
protocol versions and test client connections with different settings.
aa7f03e18f
The "pend" are no longer necessary, as they work with all OpenSSL
variants we currently support. They were added in OpenSSL 1.1.1 and
LibreSSL 3.8.0. They are also supported by the current AWS-LC release.
This makes the SHA-3 tests run with AWS-LC correctly. AWS-LC does not
report SHA-3 in OpenSSL::Digest.digests.
e1a6e9c081
Starting with LibreSSL 3.5, OpenSSL::X509::ExtensionFactory refuses to
create SAN extensions that are not valid according to RFC 6125. While
this behavior makes sense, we need such invalid extensions to test our
own validation routine. Let's construct SAN extensions manually instead.
b420d6d739
As OpenSSL::OPENSSL_FIPS always returns true on OpenSSL >= 3.0.0, we cannot use
this constant as a flag to check whether the OpenSSL is FIPS or not.
See <d725783c5c/ext/openssl/ossl.c (L994-L1004)>.
Skip the test_fips_mode_get_with_fips_mode_set test in AWS-LC case.
Because we don't test `OpenSSL.fips_mode=` on AWS-LC for now. We cannot change
the value of the `OpenSSL.fips_mode` on AWS-LC.
The `OpenSSL.fips_mode` in AWS-LC behaves as follows.
On AWS-LC non-FIPS:
```
$ bundle exec ruby -I ./lib -ropenssl.so -e 'p OpenSSL.fips_mode'
false
$ bundle exec ruby -I ./lib -ropenssl.so -e 'OpenSSL.fips_mode = true; p OpenSSL.fips_mode'
-e:1:in 'OpenSSL.fips_mode=': Turning on FIPS mode failed (OpenSSL::OpenSSLError)
from -e:1:in '<main>'
$ bundle exec ruby -I ./lib -ropenssl.so -e 'OpenSSL.fips_mode = false; p OpenSSL.fips_mode'
false
```
On AWS-LC FIPS:
```
$ bundle exec ruby -I ./lib -ropenssl.so -e 'p OpenSSL.fips_mode'
true
$ bundle exec ruby -I ./lib -ropenssl.so -e 'OpenSSL.fips_mode = false; p OpenSSL.fips_mode'
-e:1:in 'OpenSSL.fips_mode=': Turning off FIPS mode failed (OpenSSL::OpenSSLError)
from -e:1:in '<main>'
$ bundle exec ruby -I ./lib -ropenssl.so -e 'OpenSSL.fips_mode = true; p OpenSSL.fips_mode'
true
```
fd3e3e722f
Fix: https://github.com/ruby/json/issues/755
Error messages now include a snippet of the document
that doesn't parse to help locate the issue, however
the way it was done wasn't UTF-8 aware, and it could
result in exception messages with truncated characters.
It would be nice to go a bit farther and actually support
codepoints, but it's a lot of complexity to do it in C,
perhaps if we move that logic to Ruby given it's not a
performance sensitive codepath.
e144793b72
I want to add new node types to the parser translator, for example `itblock`. The bulk of the work is already done by prism itself. In the `parser`
builder, this would be a 5-line change at most but we don't control that here.
Instead, we can add our own builder and either overwrite the few methods we need,
or just inline the complete builder. I'm not sure yet which would be better.
`rubocop-ast` uses its own builder for `parser`. For this to correctly work, it must explicitly choose to extend the
prism builder and use it, same as it currently chooses to use a different parser when prism is used.
I'd like to enforce that the builder for prism extends its custom one since it will lead to
some pretty weird issues otherwise. But first, I'd like to change `rubocop-ast` to make use of this.
b080e608a8
The SSL SESSION files we were originally testing against use DHE and
SSLv3. AWS-LC happens to have no support for either and we have newer
possible alternatives available, so I've updated the respective
files to use ECDHE-RSA-AES256-SHA with TLS 1.1 and 1.2. I've verified
that these work as expected with all libcryptos we support.
There are also a few SSL session discrepencies in AWS-LC when
compared to OpenSSL.
1. AWS-LC has no support for internal session caching on the
client-end.
2. AWS-LC supports internal session caching on the server, but
SSL_get1_session does not return a resumable session with TLS 1.3
in AWS-LC. Users have to use the SSL_CTX_sess_set_new_cb
(ctx.session_new_cb in Ruby) to retrieve the resumable session
ticket.
3. AWS-LC has no current support for external session caching in TLS
1.3.
ca384b8e2f
There are a few SSL discrepencies in AWS-LC when compared to OpenSSL.
1. AWS-LC has slightly different error messages (in all-caps).
2. AWS-LC has no support for DHE ciphersuites.
3. There are no concepts of SSL security levels within AWS-LC.
4. Similar to LibreSSL, there is no support for OPENSSL_CONF.
a60d050342
We reecently tweaked some break tests in test_pkey_dh.rb due to
different behavior with OpenSSL in FIPS mode.
AWS-LC does not inherit the same specific behavior, so tests
have been adjusted accordingly.
3117897dbc
EVP_DigestVerify in OpenSSL returns 0 to indicate a signature
verification failure and can return -1 to indicate other
failures, such as invalid ASN1 contents. ruby/openssl also
reflects that by returning false with 0 and raising an error
with -1.
EVP_DigestVerify in AWS-LC simply returns 0 for any failure.
be8ba76dc1
OpenSSL allows invalid EC keys or DH params to be parsed. The consuming
application can then run parameter/key checks to check the validity of
the parameters. We happen to run tests to verify that this behaves as
expected.
AWS-LC on the other hand, directly raises an error and disallows the
invalid state to be parsed, rather than making it parsable and checking
the validity later. Relevant tests have been adjusted accordingly to
reflect this.
febe50be1b
1. AWS-LC has no support for SMIME with PKCS7. That may change in the
near future, so I've marked that with "pend" for now.
2. AWS-LC doesn't support printing of PKCS7 contents with
PKCS7_print_ctx.
3. OpenSSL traditionally used indefinite-length encoding with
ASN1_TFLG_NDEF in its implementation for PKCS7 EncryptedContent.
AWS-LC uses explicit OCTET STRING headers to encode instead,
which leads to a slight difference in serialized ASN1 contents
from the two libraries.
78c585a9c2
AWS-LC's ASN1 parsing capabilities led to us examine some of our
ASN1 tests. One test in test_asn1.rb happens to use a tag number
of 8224. There are concerns with larger UNIVERSAL tags being
ambiguous with negative ASN1 Integers, so I've adjusted the test
to use CONTEXT_SPECIFIC instead with the same tag number (8224).
c73d9985ab
AWS-LC has a few minor functionalities removed from NCONF_get_string.
1. Expanding of $foo to a previously-parsed value was removed.
2. OpenSSL falls back to using "default" with an unknown "section".
AWS-LC does not support this behavior.
3. AWS-LC does not support parsing environment variables with "ENV"
like LibreSSL.
e8de3bbd1e
