Created attachment 717756 [details] build.log > In file included from ../.././include/ruby.h:33, > from ossl.h:16, > from ossl_pkey_rsa.c:10: > ossl_pkey_rsa.c: In function ‘Init_ossl_rsa’: > ossl_pkey_rsa.c:877:58: error: ‘RSA_SSLV23_PADDING’ undeclared (first use in this function); did you mean ‘RSA_PKCS1_PADDING’? > 877 | #define DefRSAConst(x) rb_define_const(cRSA, #x, INT2NUM(RSA_##x)) > | ^~~~ > ../.././include/ruby/ruby.h:261:33: note: in definition of macro ‘RB_INT2FIX’ > 261 | #define RB_INT2FIX(i) (((VALUE)(i))<<1 | RUBY_FIXNUM_FLAG) > | ^ > ../.././include/ruby/ruby.h:1594:20: note: in expansion of macro ‘RB_INT2NUM’ > 1594 | #define INT2NUM(x) RB_INT2NUM(x) > | ^~~~~~~~~~ > ossl_pkey_rsa.c:877:50: note: in expansion of macro ‘INT2NUM’ > 877 | #define DefRSAConst(x) rb_define_const(cRSA, #x, INT2NUM(RSA_##x)) > | ^~~~~~~ > ossl_pkey_rsa.c:942:5: note: in expansion of macro ‘DefRSAConst’ > 942 | DefRSAConst(SSLV23_PADDING); > | ^~~~~~~~~~~ > ossl_pkey_rsa.c:877:58: note: each undeclared identifier is reported only once for each function it appears in > 877 | #define DefRSAConst(x) rb_define_const(cRSA, #x, INT2NUM(RSA_##x)) > | ^~~~ > ../.././include/ruby/ruby.h:261:33: note: in definition of macro ‘RB_INT2FIX’ > 261 | #define RB_INT2FIX(i) (((VALUE)(i))<<1 | RUBY_FIXNUM_FLAG) > | ^ > ../.././include/ruby/ruby.h:1594:20: note: in expansion of macro ‘RB_INT2NUM’ > 1594 | #define INT2NUM(x) RB_INT2NUM(x) > | ^~~~~~~~~~ > ossl_pkey_rsa.c:877:50: note: in expansion of macro ‘INT2NUM’ > 877 | #define DefRSAConst(x) rb_define_const(cRSA, #x, INT2NUM(RSA_##x)) > | ^~~~~~~ > ossl_pkey_rsa.c:942:5: note: in expansion of macro ‘DefRSAConst’ > 942 | DefRSAConst(SSLV23_PADDING); > | ^~~~~~~~~~~ > make[2]: *** [Makefile:313: ossl_pkey_rsa.o] Error 1 > make[2]: Leaving directory '/var/tmp/portage/dev-lang/ruby-2.6.6-r2/work/ruby-2.6.6/ext/openssl' > make[1]: *** [exts.mk:252: ext/openssl/all] Error 2 > make[1]: Leaving directory '/var/tmp/portage/dev-lang/ruby-2.6.6-r2/work/ruby-2.6.6' > make: *** [uncommon.mk:286: build-ext] Error 2 > * ERROR: dev-lang/ruby-2.6.6-r2::gentoo failed (compile phase): > * emake failed Same failure for =dev-lang/ruby-2.7.3-r2 and =dev-lang/ruby-3.0.1-r1.
https://github.com/ruby/openssl/commit/2dfc1779d3 patch with this commit makes it work for me with ruby-2.6.8
Created attachment 739626 [details, diff] ruby-3.0.2-openssl-3.0-p1.patch Backported from upstream commit: commit 2dfc1779d3ffd1a62f8053362c3b98321c3dc083 Author: Kazuki Yamaguchi <k@rhe.jp> Date: Mon May 18 20:24:08 2020 +0900 pkey/rsa: port RSA#{private,public}_{encrypt,decrypt} to the EVP API Implement these methods using the new OpenSSL::PKey::PKey#{encrypt,sign} family. The definitions are now in lib/openssl/pkey.rb. Also, recommend using those generic methods in the documentation.
Created attachment 739629 [details, diff] ruby-3.0.2-openssl-3.0-p2.patch Patch backported from upstream commit: commit c055938f4ba6da868f2e61c8935c197bae7c295f Author: Kazuki Yamaguchi <k@rhe.jp> Date: Tue Aug 4 23:14:44 2020 +0900 require OpenSSL >= 1.0.2 and LibreSSL >= 3.1 Clean up old version guards in preparation for the upcoming OpenSSL 3.0 support. OpenSSL 1.0.1 reached its EOL on 2016-12-31. At that time, we decided to keep 1.0.1 support because many major Linux distributions were still shipped with 1.0.1. Now, nearly 4 years later, most Linux distributions are reaching their EOL and it should be safe to assume nobody uses them anymore. Major ones that were using 1.0.1: - Ubuntu 14.04 is EOL since 2019-04-30 - RHEL 6 will reach EOL on 2020-11-30 LibreSSL 3.0 and older versions are no longer supported by the LibreSSL team as of October 2020. Note that OpenSSL 1.0.2 also reached EOL on 2019-12-31 and 1.1.0 also did on 2018-08-31.
Created attachment 739632 [details, diff] ruby-3.0.2-openssl-3.0-p3.patch Patch by me. With the 3 patches dev-lang/ruby-3.0.2 compiles with dev-libs/openssl-3.0.0. Other openssl versions were not tested.
To set expectations here I really don't want to backport individual patches so that this compiles, because that may miss changes that are important for e.g. the secure use of openssl. Quoting from the upstream pull request: "Currently, as of 2021-05-25, it compiles with OpenSSL's master branch (3.0.0-alpha17), but many things are known to be broken and test suite does not pass." An approach we can consider at some point is to introduce dev-ruby/openssl as a package and let it overrule the vendored version in dev-lang/ruby, especially if backporting to earlier ruby versions is taking too long. That would at least allow us to provide a complete snapshot of all the current work.
*** Bug 830010 has been marked as a duplicate of this bug. ***
Created attachment 761214 [details] ruby-2.6.9 ebuild updated to install a no sslv23_padding patch
Created attachment 761215 [details, diff] Delete SSLV23_Padding patch If anyone else is plagued by the SSLV23_Padding problem in ruby-2.6.9 blocking emerge ruby-2.6.9 and then having to find workarounds for regular emerge's and emerge --depclean try: --- replace ruby-2.6.9.ebuild with the ebuild attached, add the attached SSLV23.patch to the /usr/portage/dev-lang/ruby directory, then: cd /usr/portage/dev-lang/ruby ebuild ruby-2.6.9.ebuild manifest cd emerge -1 =dev-lang/ruby-2.6.9 this ruby-2.6.9 sslv23_padding problem should vanish until a rebuild/source code reload occurs. If the problem was mine alone, sorry for the noise.
@donahue95 Consider using /etc/portage/patches or pre_/post_ hooks in /etc/portage/env to apply patches/modifications without modifying the ebuilds in-place. If you really have to modify the ebuild, create a local overlay as described in https://wiki.gentoo.org/wiki/Handbook:AMD64/Portage/CustomTree#Defining_a_custom_ebuild_repository . Direct changes to your tree will be overwritten whenever the repository is synced.
@Esteve Varela Colominas Totally true but the executable ruby 2.6.9 produced and the ruby26_target executables produced should persist (are persisting) which meets my desires for the present -- My daily world updates and depcleans run normally.
(In reply to Hans de Graaff from comment #5) > To set expectations here I really don't want to backport individual patches > so that this compiles, because that may miss changes that are important for > e.g. the secure use of openssl. > > Quoting from the upstream pull request: "Currently, as of 2021-05-25, it > compiles with OpenSSL's master branch (3.0.0-alpha17), but many things are > known to be broken and test suite does not pass." > > An approach we can consider at some point is to introduce dev-ruby/openssl > as a package and let it overrule the vendored version in dev-lang/ruby, > especially if backporting to earlier ruby versions is taking too long. That > would at least allow us to provide a complete snapshot of all the current > work. Would you consider revisiting this please?
Aim is to unmask OpenSSL 3 by end of year.
(In reply to Sam James from comment #12) > Aim is to unmask OpenSSL 3 by end of year. Current default Ruby targets do not build with 3 which is going to be a problem.
We discussed this in #gentoo-dev a bit, but for the record. Ruby 2.7 and 3.0 are not (going to be) compatible with openssl 3. Their dependencies have been updated to reflect that. Once openssl 3 is unmasked that means only ruby 3.1 (and ruby 3.2 to be added EOY) will not force a downgrade to openssl 1.1. The aim is to move to first making 3.0 stable and then quickly move on to 3.1, so that we will have 3.1 stable once openssl 3 will be marked stable. All this has a tentative deadline of June 2023.
Well, a bit silly question, but is it possible to link during compile-time ruby against openssl-compat rather than mainline 3.0 ones?
The plan is for ruby31 to become default in roughly a month, if everything goes well.
https://lore.kernel.org/distributions/CAEg-Je9LW16niant=h4W+a-TuXQ82qbE_iDO7fRNn+04mwAZwg@mail.gmail.com/T/#mc7444ea547a20413efdc8e2e1b55140b2c5d19f8 If we do decide to patch older Ruby (it's a shame to keep them masked when they're not EOL yet > September), we would be in good company..
(In reply to Sam James from comment #16) > The plan is for ruby31 to become default in roughly a month, if everything > goes well. Next step is to drop ruby30 from defaults (default is currently "ruby30 ruby31"). We will do this on the weekend if all is going ok.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3b63f323c8873cb6b94b48d31740fc2641b55ddf commit 3b63f323c8873cb6b94b48d31740fc2641b55ddf Author: Sam James <sam@gentoo.org> AuthorDate: 2023-06-17 04:02:56 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-06-17 14:43:46 +0000 profiles/base: drop ruby30 from default RUBY_TARGETS ruby30 doesn't support OpenSSL 3 out of the box so flip over to ruby31. The tree is fortunately pretty ready for this already: https://github.com/gentoo/gentoo/pull/31392. Bug: https://bugs.gentoo.org/797325 Bug: https://bugs.gentoo.org/797673 Bug: https://bugs.gentoo.org/899596 Signed-off-by: Sam James <sam@gentoo.org> profiles/base/make.defaults | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
