Just in case for irrational or recurring results, the precision of the
quotient is set to at least more than 2*Float::DIG plus alpha.
[Bug #13754] [Fix GH-94]
99442c75d3
Introduced in 4792a917d8
`rb_absint_size` return the number of bytes needed to fit
the absolute integer, but negative integers need the sign, so one more
bit, and potentially one more byte.
0f3d5d0eb7
OpenSSL 3.0's EVP_PKEY_get0() returns NULL for provider-backed pkeys.
This causes segfault because it was supposed to never return NULL
before.
We can't check the existence of public key components in this way on
OpenSSL 3.0. Let's just skip it for now.
ccdb6f7bfa
The entire ENGINE API is deprecated in OpenSSL 3.0 in favor of the new
"Provider" concept.
OpenSSL::Engine will not be defined when compiled with OpenSSL 3.0.
We would need a way to interact with providers from Ruby programs, but
since the concept is completely different from the ENGINE API, it will
not be through the current OpenSSL::Engine interface.
69a27d8de4
OpenSSL 3.0 made EVP_PKEY immutable. This means we can only have a const
pointer of the low level struct and the following methods can no longer
be provided when linked against OpenSSL 3.0:
- OpenSSL::PKey::RSA#set_key
- OpenSSL::PKey::RSA#set_factors
- OpenSSL::PKey::RSA#set_crt_params
- OpenSSL::PKey::DSA#set_pqg
- OpenSSL::PKey::DSA#set_key
- OpenSSL::PKey::DH#set_pqg
- OpenSSL::PKey::DH#set_key
- OpenSSL::PKey::EC#group=
- OpenSSL::PKey::EC#private_key=
- OpenSSL::PKey::EC#public_key=
There is no direct replacement for this functionality at the moment.
I plan to introduce a wrapper around EVP_PKEY_fromdata(), which takes
all key components at once to construct an EVP_PKEY.
6848d2d969
OpenSSL::PKey::EC#generate_key! will not work on OpenSSL 3.0 because
keys are made immutable. Users should use OpenSSL::PKey.generate_key
instead.
5e2e66cce8
OpenSSL::PKey::DH#generate_key! will not work on OpenSSL 3.0 because
keys are made immutable. Users should use OpenSSL::PKey.generate_key
instead.
8ee6a582c7
Similarly to DH#compute_key, work around it by constructing a
SubjectPublicKeyInfo. This should be considered as a temporary
implementation.
fc9aabc18d
DH#set_key will not work on OpenSSL 3.0 because keys are immutable.
For now, let's reimplement DH#compute_key by manually constructing a
DER-encoded SubjectPublicKeyInfo structure and feeding it to
OpenSSL::PKey.read.
Eventually, we should implement a new method around EVP_PKEY_fromdata()
and use it instead.
46ca47060c
Allocate an EVP_PKEY when the content is ready: when #initialize
or #initialize_copy is called, rather than when a T_DATA is allocated.
This is more natural because the lower level API has been deprecated
and an EVP_PKEY is becoming the minimum unit of handling keys.
74f6c61756
OpenSSL 3.0 has rewritten routines to load pkeys (PEM_read_bio_* and
d2i_* functions) around the newly introduced OSSL_DECODER API.
This comes with a slight behavior change. They now decrypt and parse
each encountered PEM block, then check the kind of the block. This used
to be the reverse: they checked the PEM header to see the kind, and then
decrypted the content. This means that the password callback may now be
called repeatedly.
Let's use the OSSL_DECODER API directly on OpenSSL 3.0 so that the
return value from the password callback will be reused automatically.
a84ea531bb
This `NODE` type was used in pre-YARV implementation, to improve
the performance of assignment to dynamic local variable defined at
the innermost scope. It has no longer any actual difference with
`NODE_DASGN`, except for the node dump.
The old code of IRB still uses this method. The warning is noisy on
rails console.
In principle, Ruby 3.1 deprecates nothing, so let's avoid the
deprecation for the while.
I think It is not so hard to continue to maintain it as it is a trivial
shim.
https://github.com/ruby/ruby/pull/5093
The last element in the `@buf` may be either an array or an `Elem`. In the case it is an `Elem` we iterate over every element, when we do not need to. This check guards that case by ensuring that we only iterate over an array of elements.
When Zlib::Inflate#inflate or Zlib::Deflate#deflate is called
recursively inside the block, a crash can occur because of an
use-after-free bug.
50fb8a0338
After 5680c38c75, postponed job APIs now
expect to be called on native threads not managed by Ruby and handles
getting a NULL execution context. However, in debug builds the change
runs into an assertion failure with GET_EC() which asserts that EC is
non-NULL. Avoid the assertion failure by passing `false` for `expect_ec`
instead as the intention is to handle when there is no EC.
Add a test from John Crepezzi and John Hawthorn to exercise this
situation.
See GH-4108
See GH-5094
[Bug #17573]
Co-authored-by: John Hawthorn <john@hawthorn.email>
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
An almost universal convention for gems is to expose `Namespace::VERSION`
which makes it mcuh easier when debugging etc.
Many gems extracted from ruby don't do this, even though it would be even more
useful because they ship with ruby, so it's less clear which version it is.
fef7ec18d8
20211117T033003Z.log.html.gz
```
installing default gems from ext: /home/chkbuild/chkbuild/tmp/build/20211117T033003Z/lib/ruby/gems/3.1.0
/home/chkbuild/chkbuild/tmp/build/20211117T033003Z/ruby/ext/digest/lib/digest/version.rb:4: warning: already initialized constant Digest::VERSION
/home/chkbuild/chkbuild/tmp/build/20211117T033003Z/ruby/.ext/common/digest/version.rb:4: warning: previous definition of VERSION was here
```
This hack is copied from ext/psych/psych.gemspec
Reverts 2eb3841e9c
because it fails on "update-deps" check in the ruby/ruby CI.
4230891140
```
diff --git a/ext/io/wait/depend b/ext/io/wait/depend
index 7b314b9..449e9fe 100644
--- a/ext/io/wait/depend
+++ b/ext/io/wait/depend
...
```
Maybe now it does not work on Ruby 2.6. This file must be changed for
each Ruby version. I have no good idea to fix this issue.
