ASN.1 UTCTime uses two-digit years. While X.680 does not specify how to
map them as far as I can tell, X.509/PKIX uses this type to represent
dates between year 1950-2049.
OpenSSL::ASN1.decode has used 1969-2068 since the initial
implementation. Given that ASN1::UTCTime#to_der relies on OpenSSL
ASN1_UTCTIME type, which assumes the 1950-2049 range, this was likely
unintentional.
Use the range 1950-2049 consistently, and fix decoding of X.509
certificates with dates in 1950-1968.
b8b38e1438
This change addresses the following ASAN error:
```
==1973462==ERROR: AddressSanitizer: heap-use-after-free on address 0x5110002117dc at pc 0x749c307c8a65 bp 0x7ffc3af331d0 sp 0x7ffc3af331c8
READ of size 4 at 0x5110002117dc thread T0
#0 0x749c307c8a64 in rb_getaddrinfo /tmp/ruby/src/trunk_asan/ext/socket/raddrinfo.c:564:14
#1 0x749c307c8a64 in rsock_getaddrinfo /tmp/ruby/src/trunk_asan/ext/socket/raddrinfo.c:1008:21
#2 0x749c307cac48 in rsock_addrinfo /tmp/ruby/src/trunk_asan/ext/socket/raddrinfo.c:1049:12
#3 0x749c307b10ae in init_inetsock_internal /tmp/ruby/src/trunk_asan/ext/socket/ipsocket.c:62:23
#4 0x562c5b2e327e in rb_ensure /tmp/ruby/src/trunk_asan/eval.c:1080:18
#5 0x749c307aafd4 in rsock_init_inetsock /tmp/ruby/src/trunk_asan/ext/socket/ipsocket.c:1318:12
#6 0x749c307b3b78 in tcp_svr_init /tmp/ruby/src/trunk_asan/ext/socket/tcpserver.c:39:12
```
Fixed to avoid accessing memory that has already been freed after calling `free_getaddrinfo_arg`.
[Bug #21506] Fix timeout in Addrinfo.getaddrinfo to actually take effect
This change fixes an issue where the timeout option in `Addrinfo.getaddrinfo` was not functioning as expected.
It also addresses a related issue where specifying `fast_fallback: false` with `resolv_timeout` for `Socket.tcp` and`TCPSocket.new` would have no effect.
The timeout option was originally introduced in:
6382f5cc91
However, the value was noy used in current implementation:
3f0e0d5c8b/ext/socket/raddrinfo.c (L1282-1308)
Therefore, even if a timeout is specified and the duration elapses during name resolution, nothing happens. This is clearly not the intended behavior.
`Addrinfo.getaddrinfo` has been made interruptible as of Feature #19965.
This change uses that feature to interrupt name resolution when the specified timeout period elapses, raising a user-specified timeout error.
The timeout can be specified in milliseconds.
The same issue affects `Socket.tcp` and `TCPSocket.new` when `resolv_timeout` is set along with `fast_fallback: false`.
`resolv_timeout` was introduced in the following commits:
6382f5cc91511fe23fa2
The reason is that with `fast_fallback: false`, these methods internally call the same `rsock_getaddrinfo()` as `Addrinfo.getaddrinfo`.
This change addresses that as well.
the gem a noop on Rubies older than
2.6"
This reverts commit 75fcb74c32.
The version that does nothing with pre-ruby 2.6 has already been
released, so there is no longer need to consider older rubies in newer
versions.
930d2f0d07
io-wait became a default gem at ruby 3.0.
Even it can be installed on earlier versions, but the standard library
will be loaded instead of the installed gem.
15b96736cd
io-nonblock became a default gem at ruby 3.0.
Even it can be installed on earlier versions, but the standard library
will be loaded instead of the installed gem.
c86d0d37af
Compare by the VALUE value instead of ID. Calling SYM2ID() on a dynamic
symbol will pin a permanent ID.
These methods only accept known static symbols, and passing anything
else is an incorrect usage that results in an exception. Nonetheless,
avoiding SYM2ID() seems to be a good idea since there is no runtime
cost.
0d66296cdc
TLS 1.3 renamed the "elliptic_curves" extension to "supported_groups"
to reflect that it now covers more than just ECDH groups. OpenSSL 1.1.1
followed this change by renaming the corresponding API from
SSL_CTX_set1_curves_list() to SSL_CTX_set1_groups_list().
Update ruby/openssl to use the new name, too. The current method name
SSLContext#ecdh_curves= is retained as an alias for #group=.
59e98604e0
otherwise, gcc 15 will complain:
> init.c:573:19: error: too many arguments to function ‘Rconnect’; expected 0, have 3
> 573 | return (VALUE)Rconnect(arg->fd, arg->sockaddr, arg->len);
> | ^~~~~~~~ ~~~~~~~
> In file included from init.c:11:
> rubysocket.h:294:5: note: declared here
> 294 | int Rconnect();
> | ^~~~~~~~
> sockssocket.c:33:9: error: too many arguments to function ‘SOCKSinit’; expected 0, have 1
> 33 | SOCKSinit("ruby");
> | ^~~~~~~~~ ~~~~~~
> In file included from sockssocket.c:11:
> rubysocket.h:293:6: note: declared here
> 293 | void SOCKSinit();
> | ^~~~~~~~~
Signed-off-by: Z. Liu <zhixu.liu@gmail.com>
See the results of `have_type` and `try_compile` in addition to
`have_header` for NEON as well as x86_64. The former results were
just ignored, and `HAVE_TYPE_` macros are unused too.
fdbb6062c2
Algorithms implemented only in OpenSSL 3 providers may not have a
corresponding NID. The *_ex() variants have been added in OpenSSL 3.0
to handle such algorithms, by taking algorithm names as a string.
e730e457cc
For algorithms implemented solely in an OpenSSL 3 provider, without an
associated EVP_PKEY_METHOD, EVP_PKEY_id() returns a special value
EVP_PKEY_KEYMGMT.
Let OpenSSL::PKey::PKey#oid raise an exception as necessary.
Update PKey#inspect to include the string returned by
EVP_PKEY_get0_type_name(), if available.
bd3e32270e
Move the #include from ossl_provider.c to ossl.h. As OpenSSL 3 provider
functions will be used in multiple source files, having it in the
common header file is convenient.
f831bb66bc
There are few legitimate use cases for duplicate keys, and can
in some case be exploited.
Rather to always silently accept them, we should emit a warning,
and in the future require to explictly allow them.
06f00a42e8
Add methods for setting supported signature algorithms, corresponding
to SSL_CTX_set1_sigalgs_list() and SSL_CTX_set1_client_sigalgs_list(),
respectively.
6bbe58c492
Co-authored-by: Markus Jung <markus.jung@vivavis.com>
Followup: https://github.com/ruby/ruby/pull/13589
This simplify a lot of things, as we no longer need to manually
manage the memory, we can use the Read-Copy-Update pattern and
avoid numerous race conditions.
Co-Authored-By: Étienne Barrié <etienne.barrie@gmail.com>
- Put shell commands in code blocks so they can easily be copied from
the GitHub UI directly
- Fix a few typos
- Fix a dead link to MSDN
Signed-off-by: Tim Smith <tsmith84@gmail.com>
61a4672df7
Issue - https://bugs.ruby-lang.org/issues/21436
Apparently, the lower bound check is missing, which results in overflow & wrapping later on in RB_INT2FIX
Signed-off-by: Dmitry Dygalo <dmitry.dygalo@workato.com>
67d75e8423
* Add `open_timeout` as an overall timeout option for `Socket.tcp`
[Background]
Currently, `TCPSocket.new` and `Socket.tcp` accept two kind of timeout options:
- `resolv_timeout`, which controls the timeout for DNS resolution
- `connect_timeout`, which controls the timeout for the connection attempt
With the introduction of Happy Eyeballs Version 2 (as per [RFC 8305](https://datatracker.ietf.org/doc/html/rfc8305)) in[ Feature #20108](https://bugs.ruby-lang.org/issues/20108) and [Feature #20782](https://bugs.ruby-lang.org/issues/20782), both address resolution and connection attempts are now parallelized.
As a result, the sum of `resolv_timeout` and `connect_timeout` no longer represents the total timeout duration. This is because, in HEv2, name resolution and connection attempts are performed concurrently, causing the two timeouts to overlap.
Example:
When `resolv_timeout: 200ms` and `connect_timeout: 100ms` are set:
1. An IPv6 address is resolved after the method starts immediately (IPv4 is still being resolved).
2. A connection attempt is initiated to the IPv6 address
3. After 100ms, `connect_timeout` is exceeded. However, since `resolv_timeout` still has 100ms left, the IPv4 resolution continues.
4. After 200ms from the start, the method raises a `resolv_timeout` error.
In this case, the total elapsed time before a timeout is 200ms, not the expected 300ms (100ms + 200ms).
Furthermore, in HEv2, connection attempts are also parallelized.
It starts a new connection attempts every 250ms for resolved addresses. This makes the definition of `connect_timeout` even more ambiguous—specifically, it becomes unclear from which point the timeout is counted.
Additionally, these methods initiate new connection attempts every 250ms (Connection Attempt Delay) for each candidate address, thereby parallelizing connection attempts. However, this behavior makes it unclear from which point in time the connect_timeout is actually measured.
Currently, a `connect_timeout` is raised only after the last connection attempt exceeds the timeout.
Example:
When `connect_timeout: 100ms` is set and 3 address candidates:
1. Start a connection attempt to the address `a`
2. 250ms after step 1, start a new connection attempt to the address `b`
3. 500ms after step 1, start a new connection attempt to the address `c`
4. 1000ms after step 3 (1000ms after starting the connection to `c`, 1250ms after starting the connection to `b,` and 1500ms after starting the connection to `a`) `connect_timeout` is raised
This behavior aims to favor successful connections by allowing more time for each attempt, but it results in a timeout model that is difficult to reason about.
These methods have supported `resolv_timeout` and `connect_timeout` options even before the introduction of HEv2. However, in many use cases, it would be more convenient if a timeout occurred after a specified duration from the start of the method. Similar functions in other languages (such as PHP, Python, and Go) typically allow specifying only an overall timeout.
[Proposal]
I propose adding an `open_timeout` option to `Socket.tcp` in this PR, which triggers a timeout after a specified duration has elapsed from the start of the method.
The name `open_timeout` aligns with the existing accessor used in `Net::HTTP`.
If `open_timeout` is specified together with `resolv_timeout` and `connect_timeout`, I propose that only `open_timeout` be used and the others be ignored. While it is possible to support combinations of `open_timeout`, `resolv_timeout`, and `connect_timeout`, doing so would require defining which timeout takes precedence in which situations. In this case, I believe it is more valuable to keep the behavior simple and easy to understand, rather than supporting more complex use cases.
If this proposal is accepted, I also plan to extend `open_timeout` support to `TCPSocket.new`.
While the long-term future of `resolv_timeout` and `connect_timeout` may warrant further discussion, I believe the immediate priority is to offer a straightforward way to specify an overall timeout.
[Outcome]
If `open_timeout` is also supported by `TCPSocket.new`, users would be able to manage total connection timeouts directly in `Net::HTTP#connect` without relying on `Timeout.timeout`.
aa0f689bf4/lib/net/http.rb (L1657)
---
* Raise an exception if it is specified together with other timeout options
> If open_timeout is specified together with resolv_timeout and connect_timeout, I propose that only open_timeout be used and the others be ignored.
Since this approach may be unclear to users, I’ve decided to explicitly raise an `ArgumentError` if these options are specified together.
* Add doc
* Fix: open_timeout error should be raised even if there are still addresses that have not been tried
