Bugzilla – Bug 1223072
[aarch64] Segfault during VM installation on Mac HW with pointer auth enabled
Last modified: 2024-05-16 08:40:15 UTC
Created attachment 874356 [details] Segfault error text I am receiving a segfault before the end of the installation of an openSUSE Tumbleweed (snapshot 20240417) in my aarch64 laptop. The segfault happens right at 97% progress of the installer, at the stage "Prepare system for initial boot". I have attached a screenshot with the segfault error. My system: - Macbook Pro with M2 Pro processor (aarch64) - Software: I have received this error in UTM (with both QEMU and Virtualization framework) and Tart (with Virtualization framework). If you need any other information from me, please let me know, since this error is fully reproducible each time from my side.
Could you try to boot with arm64.nopauth please? Append it on kernel command line
Marcos, welcome to reporting YaST bugs. Please be advised that for all YaST bug reports we always need an y2logs tarball generated with the supplied 'save_y2logs' script. Please read the Bug Reporting FAQ: https://en.opensuse.org/openSUSE:Report_a_YaST_bug and also this: https://en.opensuse.org/openSUSE:How_to_Write_a_Good_Bugreport
Marcos, we are waiting for your feedback.
Created attachment 874457 [details] y2logs
Thanks suggestion from a SUSE employee, I was able to workaround this issue by using the text-mode installer (and not the UI installer). The suggestion by Guillaume Gardet, to set arm64.nopauth as a kernel option (in the "linux ..." entry), also worked fine. --- My main issue comes when I run the installer in UI mode, without the suggestion from Guillaume, and let it continue until it errors with: "An error occurred during the installation." (previous to this screen, the segfault is shown but it's quickly hidden). As requested by Stefan Hundhammer, I have attached the y2logs file, which I hope helps understand what could be going on. This y2logs file was generated from a failed installation which had the error appear. It is worth noting that the segfault happens any time I abort the installation. If I start the installer, and immediately abort it, I see the segfault (see attached screenshot) and the installer then switches to text-mode. But it does not seem to indicate any error, only that there had been some issues starting the UI. Therefore, I'm not very sure if the segfault has anything to do with my actual errors. (In reply to Guillaume GARDET from comment #1) > Could you try to boot with arm64.nopauth please? > Append it on kernel command line That worked! (In reply to Stefan Hundhammer from comment #2) > Marcos, welcome to reporting YaST bugs. > > Please be advised that for all YaST bug reports we always need an y2logs > tarball generated with the supplied 'save_y2logs' script. Please read the > Bug Reporting FAQ: > > https://en.opensuse.org/openSUSE:Report_a_YaST_bug > > and also this: > > https://en.opensuse.org/openSUSE:How_to_Write_a_Good_Bugreport I have attached the file to this ticket. I generated it in the following way: - Launch the UI installer and let it fail. - The segfault screen appears, and immediately switches to the text-mode installer with the text: "The installation has failed". - Mount /dev/vda2 to a specific folder /my-mount so I can access save_y2logs (this CLI tool is not present in the mounted text-based installer files). - Execute /my-mount/usr/sbin/save_y2logs - Copy the logs over to a USB or mounted files that I can access outside of the VM. I am also going to be updating the title of this bug report, given that the segmentation fault does not seem to be related at all to my installation error.
The attached y2log seems to contain a successful installation from today. If any installation fails and get back to Linuxrc, you don't really need to mount any partition. In fact, that partition does not contain logs from the installation itself (if it's the failed one), it's the installation system that contains them and in such case simply switching to another terminal should work. And there save_y2logs should also exist.
Created attachment 874459 [details] installation error screen
It seems like you are right. When I install normally, I see the error "An error occurred during the installation" (I have attached this as a screenshot). What confuses me is that it will switch to the text-based installer. However, when I reboot it after disconnecting the installation media, it actually boots the OS correctly, in spite of the error above. Note: I am not seeing the installer error with the options proposed by Guillaume, nor when I use the text-based installer. That said, since there doesn't seem to be a major issue (given the installer error above), and that a simple reboot would resolve it once finished, I think we can consider it resolved. (In reply to Lukas Ocilka from comment #6) > The attached y2log seems to contain a successful installation from today. > If any installation fails and get back to Linuxrc, you don't really need to > mount any partition. In fact, that partition does not contain logs from the > installation itself (if it's the failed one), it's the installation system > that contains them and in such case simply switching to another terminal > should work. And there save_y2logs should also exist. The y2logs were from the installation system, and given what you mention, it is very likely that the installation had ultimately succeeded. Just that save_y2logs was not present, so I had to mount the installed system (which did include the program) to be able to execute it.
y2start.log: >> Stage [call]: ================ >> Stage [call]: Starting YaST... >> Stage [call]: ================ >> |-- Allow big memory allocation: overcommit_memory=1 >> |-- MODULE_NAME: installation >> |-- MODE_FLAGS: >> |-- MODULE_ARGS: --arg initial >> |-- MODE: qt >> |-- UI_ARGS: --noborder --auto-fonts --fullscreen >> |-- QT_IM_MODULE: xim >> Stage [call]: =============== >> Stage [call]: YaST terminated >> Stage [call]: =============== >> |-- Y2_EXIT_CODE: 139 >> |-- Reset memory allocation: overcommit_memory=0 >> |-- Copy first level log file to installed system >> |-- Creating hook script list: postFirstCall... >> Stage [1]: Starting F10-cleanup... >> Stage [1]: ======================= >> |-- YaST2 exit code on level (1): 139 >> |-- Stopping UTF-8 mode... >> |-- Creating hook script list: postFirstStage... Exit code 139 -> terminated with signal 139-128 == 11 (SIGSEGV). No backtrace in the last lines of y2log: >> 10:46:49 <1> [Ruby] yast2/fs_snapshot.rb(configured?):140 Checking if Snapper is configured: "/usr/bin/snapper --no-dbus --root=%{root} --csvout list-configs --columns config,subvolume | /usr/bin/grep "^root," >/dev/null" returned: {"exit"=>0, "stderr"=>"", "stdout"=>""} >> 10:46:49 <1> [Ruby] installation/snapshots_finish.rb(write):43 Creating root filesystem snapshot >> 10:46:49 <1> [wfm] Y2WFMComponent.cc(SCRSetDefault):327 Setting default SCR: 5 >> 10:46:49 <2> [agent-ini] IniParser.cc(UpdateIfModif):915 Data file '/etc/install.inf' was changed externaly! >> 10:46:49 <1> [wfm] Y2WFMComponent.cc(SCRSetDefault):327 Setting default SCR: 3 >> 10:46:49 <1> [wfm] modules/Linuxrc.rb:78 SCR handle 5 closed >> 10:46:49 <1> [Ruby] yast2/fs_snapshot.rb(create):334 Executing: "/usr/bin/snapper --no-dbus --root=/ create --type single --description after\ installation --userdata "important=yes" --cleanup number" >> 10:46:49 <1> [Ruby] yast2/fs_snapshot.rb(all):272 Retrieving snapshots list: /usr/bin/snapper --no-dbus --root=%{root} --utc --csvout list --disable-used-space --columns number,type,pre-number,date,user,cleanup,description returned: {"exit"=>0, "stderr"=>"", "stdout"=>"number,type,pre-number,date,user,cleanup,description\n0,single,,,root,,current\n1,single,,2024-04-23 14:44:19,root,,first root filesystem\n2,single,,2024-04-23 14:46:49,root,number,after installation\n"} Last-but-one 'ps' in memsample.zcat: >> ### free-0049-2024-04-23T10:46:44-04:00 >> total used free shared buff/cache available >> Mem: 4007960 1566412 840656 314004 2125908 2441548 >> Swap: 2098152 5924 2092228 >> >> ### ps-0049-2024-04-23T10:46:44-04:00 >> PID TTY VSZ DRS TRS RSS SIZE PPID COMMAND >> ... >> ... >> 1687 tty1 3092 2971 120 1664 416 1685 /bin/dash /sbin/inst_setup yast >> 1897 tty1 4168 3287 880 2688 472 1687 /bin/bash /usr/sbin/yast2 >> 1898 tty1 7620 6739 880 3584 1000 1897 /bin/bash /usr/lib/YaST2/startup/YaST2.First-Stage >> 2917 tty1 7884 7003 880 3712 1264 1898 /bin/bash /usr/lib/YaST2/startup/YaST2.call installation initial >> 3338 tty7 279504 277014 2489 59104 27132 2917 /usr/bin/Xorg.bin -noreset -br -nolisten tcp -deferglyphs 16 vt07 >> 3480 tty1 1778612 1778608 3 473868 898284 2917 /usr/bin/ruby.ruby3.3 --encoding=utf-8 /usr/lib/YaST2/bin/y2start installation --arg initial qt --noborder --auto-fonts --fullscreen >> 7506 tty1 0 0 0 0 0 3480 [get_kernel_vers] <defunct> >> 7571 tty1 0 0 0 0 0 3480 [get_kernel_vers] <defunct> >> 8519 tty1 7252 6371 880 3200 604 3480 /bin/bash -e /usr/sbin/shim-install --config-file=/boot/grub2/grub.cfg >> 8545 tty1 13548 11865 1682 7040 4052 8519 /usr/sbin/grub2-install --target=arm64-efi --no-nvram
That red error pop-up is from "linuxrc" which initiates the whole installation process, and acts as a kind of watchdog. This is not the text-mode installer; that would be YaST with the NCurses UI which is just the normal YaST installer with an NCurses (text mode) UI front-end. As long as the red error popup is still open, you can still switch to a text console (Alt-F2) where a root shell is running during the installation.
storage-inst/04-committed.yml: # 2024-04-23 10:44:18 -0400 --- - disk: name: "/dev/sda" size: 3424090 KiB (3.27 GiB) block_size: 0.5 KiB io_size: 0 B min_grain: 1 MiB align_ofs: 0 B partition_table: msdos mbr_gap: 1 MiB partitions: - free: size: 1208 KiB (1.18 MiB) start: 0 B - partition: size: 12348 KiB (12.06 MiB) start: 1208 KiB (1.18 MiB) name: "/dev/sda1" type: primary id: dos32 file_system: vfat - partition: size: 3410534 KiB (3.25 GiB) start: 13556 KiB (13.24 MiB) name: "/dev/sda2" type: primary id: linux file_system: iso9660 label: openSUSE-Tumbleweed-DVD-aarch64 - disk: name: "/dev/vda" size: 64 GiB block_size: 0.5 KiB io_size: 0 B min_grain: 1 MiB align_ofs: 0 B partition_table: gpt partitions: - free: size: 1 MiB start: 0 B - partition: size: 128 MiB start: 1 MiB name: "/dev/vda1" type: primary id: esp file_system: vfat mount_point: "/boot/efi" fstab_options: - utf8 - partition: size: 63358 MiB (61.87 GiB) start: 129 MiB name: "/dev/vda2" type: primary id: linux file_system: btrfs mount_point: "/" btrfs: default_subvolume: "@" subvolumes: - subvolume: path: "@" - subvolume: path: "@/boot/grub2/arm64-efi" - subvolume: path: "@/home" - subvolume: path: "@/opt" - subvolume: path: "@/root" - subvolume: path: "@/srv" - subvolume: path: "@/usr/local" - subvolume: path: "@/var" nocow: true - partition: size: 2098159.5 KiB (2.00 GiB) start: 63487 MiB (62.00 GiB) name: "/dev/vda3" type: primary id: swap file_system: swap mount_point: swap - free: size: 16.5 KiB start: 67108847.5 KiB (64.00 GiB)
Nothing obvious. No useful message in /var/log/messages. No indication of OOM. No backtrace (!) as usual from our libzypp watchdog; something just crashes without any hint what happened. But there were problems not so long ago on aarch64 with that 'pauth', so please try what Guillaume suggested in comment #1.
(In reply to Stefan Hundhammer from comment #12) > But there were problems not so long ago on aarch64 with that 'pauth', so > please try what Guillaume suggested in comment #1. Disregard; I overlooked where you wrote that you tried that, and it helped. Looks like one of the libs that we use (Qt?) does something that is caught by that pointer auth; which should be a development aid, not yet another obstacle as it turns out to be. Closing as WORKSFORME since there is a viable kernel option to make it work.
It looks like https://bugzilla.suse.com/show_bug.cgi?id=1219717 found by openQA: https://openqa.opensuse.org/tests/4094077#step/await_install/109 Pointer Authentication is a security feature, not a debug feature. So, there is a bug which must be fixed. Usually, some assembler files which do not support PAuth, or build not using distro flags.
Created attachment 874470 [details] updated y2logs I have attached the y2logs, obtained directly from the shell accessed through the "An error occurred during the installation" screen, in case it is useful to you.
*** Bug 1219717 has been marked as a duplicate of this bug. ***
(In reply to Marcos Bjoerkelund from comment #15) > Created attachment 874470 [details] > updated y2logs > > I have attached the y2logs, obtained directly from the shell accessed > through the "An error occurred during the installation" screen, in case it > is useful to you. Looks like zypp: 2024-04-24 09:09:39 <5> install(3481) [zypp] ZYppFactory.cc(backtraceHandler):58 Error: signal 11
Libzypp has a general signal handler that normally generates a backtrace in the y2log so we have a fighting chance to debug anything. But that doesn't mean that a segfault is the fault of libzypp.
(In reply to Guillaume GARDET from comment #14) > It looks like https://bugzilla.suse.com/show_bug.cgi?id=1219717 found by > openQA: https://openqa.opensuse.org/tests/4094077#step/await_install/109 > > Pointer Authentication is a security feature, not a debug feature. So, there > is a bug which must be fixed. Sure; like we never had any issues with that architecture before. I recall simple system calls (file operations!) failing at random some years ago. And OF COURSE (like always) everbody kept blaming YaST, because they were installing with YaST, and then something bad happened. And it turned out (of course) that not a single one of those bugs was a YaST bug, but it was US who had to debug all those shit bugs. Like in the Wild West: Guilty unless proven innocent beyond the shadow of a doubt. If you want to start debugging this, have a lot of fun. I am not going to. Do you have any idea of the complexity of YaST with all its library layers, its own as well as third-party like libQt; let alone libzypp, or the embedded Ruby interpreter, or the embedded Perl interpreter? Go ahead and start working on this thing with GDB. Have a lot of fun. > Usually, some assembler files which do not support PAuth, or build not using distro flags.
Unless there is any hard evidence to the contrary, this is not a YaST problem.
Just as a hint, adding Y2DEBUG=1 to the Linuxrc (Installer/Kernel) command line might give much more hints in the y2log, but we usually don't recommend it by default as it bloats the log too much be be useful when looking for a needle. Page https://en.opensuse.org/SDB:Linuxrc also offers Y2DEBUGGER=1 and links to more details at https://yastgithubio.readthedocs.io/en/latest/debugging/ - but I have no real experience with it.
Created attachment 874473 [details] y2logs with Y2DEBUG=1 Find attached the y2logs file with Y2DEBUG=1.
The last lines of the latest y2log with Y2DEBUG: >> 10:05:19 <0> [scr] ../../libscr/src/include/scr/Y2AgentComponent.h(evaluate):95 evaluate (`Read (."umount_result")) >> 10:05:19 <0> [scr] ../../libscr/src/include/scr/Y2AgentComponent.h(evaluate):100 Going to evaluate `Read (."umount_result") >> 10:05:19 <0> [scr] ../../libscr/src/include/scr/Y2AgentComponent.h(evaluate):121 After code evaluation: `Read (."umount_result") >> 10:05:19 <0> [scr] ScriptingAgent.cc(Read):194 This is ScriptingAgent(0xaaab14af6b60)::Read >> 10:05:19 <0> [scr] ScriptingAgent.cc(Read):195 opt: null >> 10:05:19 <0> [scr] ScriptingAgent.cc(executeSubagentCommand):589 ScriptingAgent::executeSubagentCommand: Read >> 10:05:19 <0> [scr] ScriptingAgent.cc(executeSubagentCommand):590 path: .etc.install_inf."SecondStageRequired" >> 10:05:19 <0> [scr] ScriptingAgent.cc(executeSubagentCommand):591 arg: null >> 10:05:19 <0> [scr] ScriptingAgent.cc(executeSubagentCommand):592 opt: null >> 10:05:19 <0> [scr] ../../libscr/src/include/scr/Y2AgentComponent.h(evaluate):95 evaluate (`Read (."SecondStageRequired")) >> 10:05:19 <0> [scr] ../../libscr/src/include/scr/Y2AgentComponent.h(evaluate):100 Going to evaluate `Read (."SecondStageRequired") >> 10:05:19 <0> [scr] ../../libscr/src/include/scr/Y2AgentComponent.h(evaluate):121 After code evaluation: `Read (."SecondStageRequired") >> 10:05:19 <1> [wfm] Y2WFMComponent.cc(SCRSetDefault):327 Setting default SCR: 3 >> 10:05:19 <1> [wfm] modules/Linuxrc.rb:78 SCR handle 5 closed >> 10:05:19 <1> [Ruby] yast2/fs_snapshot.rb(create):334 Executing: "/usr/bin/snapper --no-dbus --root=/ create --type single --description after\ installation --userdata "important=yes" --cleanup number" >> 10:05:19 <0> [libscr] SCR.cc(SCRExecute2):129 Running SCR::Execute on SCR agent 0xaaab1bab2b50 >> 10:05:19 <0> [libscr] SCR.cc(SCRExecute2):130 path: .target.bash_output >> 10:05:19 <0> [libscr] SCR.cc(SCRExecute2):131 args: "/usr/bin/snapper --no-dbus --root=/ create --type single --description after\\ installation --userdata \"important=yes\" --cleanup number" >> 10:05:19 <0> [scr] ScriptingAgent.cc(Execute):246 This is ScriptingAgent::Execute >> 10:05:19 <0> [scr] ScriptingAgent.cc(executeSubagentCommand):589 ScriptingAgent::executeSubagentCommand: Execute >> 10:05:19 <0> [scr] ScriptingAgent.cc(executeSubagentCommand):590 path: .target.bash_output >> 10:05:19 <0> [scr] ScriptingAgent.cc(executeSubagentCommand):591 arg: "/usr/bin/snapper --no-dbus --root=/ create --type single --description after\\ installation --userdata \"important=yes\" --cleanup number" >> 10:05:19 <0> [scr] ScriptingAgent.cc(executeSubagentCommand):592 opt: null >> 10:05:19 <0> [agent-system] ../../libscr/src/include/scr/Y2AgentComponent.h(evaluate):95 evaluate (`Execute (.bash_output, "/usr/bin/snapper --no-dbus --root=/ create --type single --description after\\ installation --userdata \"important=yes\" --cleanup number")) >> 10:05:19 <0> [agent-system] ../../libscr/src/include/scr/Y2AgentComponent.h(evaluate):100 Going to evaluate `Execute (.bash_output, "/usr/bin/snapper --no-dbus --root=/ create --type single --description after\\ installation --userdata \"important=yes\" --cleanup number") >> 10:05:19 <0> [agent-system] ../../libscr/src/include/scr/Y2AgentComponent.h(evaluate):121 After code evaluation: `Execute (.bash_output, "/usr/bin/snapper --no-dbus --root=/ create --type single --description after\\ installation --userdata \"important=yes\" --cleanup number") >> 10:05:19 <0> [agent-system] ../../libscr/src/include/scr/Y2AgentComponent.h(evaluate):142 Execute, arg size is 2 >> 10:05:19 <0> [agent-system] SystemAgent.cc(Execute):918 Execute (.bash_output) >> 10:05:19 <0> [bash] ShellCommand.cc(shellcommand):31 shellcommand start >> 10:05:19 <0> [bash] ShellCommand.cc(shellcommand):200 shellcommand end >> 10:05:19 <0> [libscr] SCR.cc(SCRExecute2):129 Running SCR::Execute on SCR agent 0xaaab1bab2b50 >> 10:05:19 <0> [libscr] SCR.cc(SCRExecute2):130 path: .target.bash_output >> 10:05:19 <0> [libscr] SCR.cc(SCRExecute2):131 args: "/usr/bin/snapper --no-dbus --root=/ --utc --csvout list --disable-used-space --columns number,type,pre-number,date,user,cleanup,description" >> 10:05:19 <0> [scr] ScriptingAgent.cc(Execute):246 This is ScriptingAgent::Execute >> 10:05:19 <0> [scr] ScriptingAgent.cc(executeSubagentCommand):589 ScriptingAgent::executeSubagentCommand: Execute >> 10:05:19 <0> [scr] ScriptingAgent.cc(executeSubagentCommand):590 path: .target.bash_output >> 10:05:19 <0> [scr] ScriptingAgent.cc(executeSubagentCommand):591 arg: "/usr/bin/snapper --no-dbus --root=/ --utc --csvout list --disable-used-space --columns number,type,pre-number,date,user,cleanup,description" >> 10:05:19 <0> [scr] ScriptingAgent.cc(executeSubagentCommand):592 opt: null >> 10:05:19 <0> [agent-system] ../../libscr/src/include/scr/Y2AgentComponent.h(evaluate):95 evaluate (`Execute (.bash_output, "/usr/bin/snapper --no-dbus --root=/ --utc --csvout list --disable-used-space --columns number,type,pre-number,date,user,cleanup,description")) >> 10:05:19 <0> [agent-system] ../../libscr/src/include/scr/Y2AgentComponent.h(evaluate):100 Going to evaluate `Execute (.bash_output, "/usr/bin/snapper --no-dbus --root=/ --utc --csvout list --disable-used-space --columns number,type,pre-number,date,user,cleanup,description") >> 10:05:19 <0> [agent-system] ../../libscr/src/include/scr/Y2AgentComponent.h(evaluate):121 After code evaluation: `Execute (.bash_output, "/usr/bin/snapper --no-dbus --root=/ --utc --csvout list --disable-used-space --columns number,type,pre-number,date,user,cleanup,description") >> 10:05:19 <0> [agent-system] ../../libscr/src/include/scr/Y2AgentComponent.h(evaluate):142 Execute, arg size is 2 >> 10:05:19 <0> [agent-system] SystemAgent.cc(Execute):918 Execute (.bash_output) >> 10:05:19 <0> [bash] ShellCommand.cc(shellcommand):31 shellcommand start >> 10:05:19 <0> [bash] ShellCommand.cc(shellcommand):200 shellcommand end >> 10:05:19 <1> [Ruby] yast2/fs_snapshot.rb(all):272 Retrieving snapshots list: /usr/bin/snapper --no-dbus --root=%{root} --utc --csvout list --disable-used-space --columns number,type,pre-number,date,user,cleanup,description returned: {"exit"=>0, "stderr"=>"", "stdout"=>"number,type,pre-number,date,user,cleanup,description\n0,single,,,root,,current\n1,single,,2024-04-24 08:02:46,root,,first root filesystem\n2,single,,2024-04-24 08:05:19,root,number,after installation\n"} >> 10:05:19 <5> [zypp] ZYppFactory.cc(backtraceHandler):58 Error: signal 11 So there were some snapper operations, but was it them that crashed? I don't know.
So, sadly, there is nothing really useful. It crashes after this call: https://github.com/yast/yast-yast2/blob/master/library/system/src/lib/yast2/fs_snapshot.rb#L272 log.info("Retrieving snapshots list: #{LIST_SNAPSHOTS_CMD} returned: #{out}") That does not sound like something that could crash. The very next line of code is: csv = CSV.parse(out["stdout"], headers: true, converters: [:date_time, :numeric]) But that is a standard Ruby library, nothing specific to YaST. Hard to say if it has problems to parse this input: "number,type,prenumber,date,user,cleanup,description\n0,single,,,root,,current\n1,single,,2024-04-24 08:02:46,root,,first root filesystem\n2,single,,2024-04-24 08:05:19,root,number,after installation\n"
works for me irb irb(main):001> require "csv" => true irb(main):002> stdout = "number,type,prenumber,date,user,cleanup,description\n0,single,,,root,,current\n1,single,,2024-04-24 08:02:46,root,,first root filesystem\n2,single,,2024-04-24 08:0 5:19,root,number,after installation\n" => "number,type,prenumber,date,user,cleanup,description\n0,single,,,root,,current\n1,single,,2024-04-24 08:02:46,root,,first root filesystem\n2,single,,2024-04-24 08:05:19,root,number... irb(main):003> csv = CSV.parse(stdout, headers: true, converters: [:date_time, :numeric]) => #<CSV::Table mode:col_or_row row_count:4> ... irb(main):004>
If we can't even get a backtrace because obviously it also kills our backtracer, I don't see what we can do here. The problem might be literally anywhere. We use so many components - there is no way to even start investigating anything. And then we have an unknown virtualization layer on an unknown host system.
For the record, this has been fixed with https://build.opensuse.org/request/show/1169904 which will be in snapshot 20240514+.
JFTR: That SR from comment #27 was against ruby3.3. From the change log: ------------------------------------------------------------------- Tue Apr 23 16:24:04 UTC 2024 - Marcus Rueckert <mrueckert@suse.de> - Update to 3.3.1 (boo#1221851 boo#1221852 boo#1223314) https://www.ruby-lang.org/en/news/2024/04/23/ruby-3-3-1-released/ https://www.ruby-lang.org/en/news/2024/04/23/arbitrary-memory-address-read-regexp-cve-2024-27282/ https://www.ruby-lang.org/en/news/2024/03/21/rce-rdoc-cve-2024-27281/ https://www.ruby-lang.org/en/news/2024/03/21/buffer-overread-cve-2024-27280/ https://github.com/ruby/ruby/releases/tag/v3_3_1 ------------------------------------------------------------------- Wed Jan 31 09:55:13 UTC 2024 - Guillaume GARDET <guillaume.gardet@opensuse.org> - Add additionnal flags: cflags, cppflags and ASFLAGS -------------------------------------------------------------------