55586 2025-08-13 10:45:28 +0300 Библиотеки не соотвествуют shared library policy 2026-10-18 22:25:02 +0300 1 1 4 Development Sisyphus wasmtime unstable x86_64 Linux RESOLVED FIXED P5 normal --- 1 rx1513 kiper kiper lav qa-sisyphus oldest_to_newest 270808 0 rx1513 2025-08-13 10:45:28 +0300 https://www.altlinux.org/Shared_Libs_Policy 270809 1 rx1513 2025-08-13 10:47:07 +0300 Мне также непонятно отсутствие макросов для сборки растовской части. 270811 2 rx1513 2025-08-13 10:55:00 +0300 Можете объяснить как вы собирали этот пакет? 270888 3 kiper 2025-08-14 13:43:26 +0300 (Ответ для Сергей Жидких на комментарий #2) > Можете объяснить как вы собирали этот пакет? В соответствии с https://www.altlinux.org/RPM/Rust и подсматривая, как данный пакет собирался в других дистрибутивах. (Ответ для Сергей Жидких на комментарий #1) > Мне также непонятно отсутствие макросов для сборки растовской части. Прошу простить мою некомпетентность в данном вопросе как человеку, проходящему join. Будет исправлено в следующей сборке. (Ответ для Сергей Жидких на комментарий #0) > https://www.altlinux.org/Shared_Libs_Policy А вот тема баги чуть сложнее, чем может показаться на первый взгляд. В upstream-е wasmtime уже поднимался issue по поводу soname в 2021 году(https://github.com/bytecodealliance/wasmtime/issues/2996). На текущий момент, насколько я знаю, проблема не решена(хоть issue и закрыт). В документации нет явного указания, что версия ABI wasmtime-c-api привязана к версии самого wasmtime. В связи с чем можно сделать вывод, что нет явного версионирования ABI, как и определённых гарантий с версионированием основного проекта в отношение API wasmtime-c-api. Как возможные варианты решения проблемы: 1. Пинать upstream в новой issue, объясняя плюсы soname и версионирования ABI в wasmtime-c-api во второй раз. Возможно приложив PR. 2. В случае, если issue затухнет во второй раз, взвалить версионирование ABI на человека X, которым могу выступить и я, когда руки дойдут до использования в своём личном проекте. Но эти решения требуют определённого времени, так что сразу предложу временные варианты решения: 1. Оставить как есть. Но я чувствую, что данный вариант не устроит вас и CMake(https://gitlab.kitware.com/cmake/cmake/-/issues/22307#note_971562). 2. Использовать в качестве soname полную версию пакета. Данный вариант уже собран в тестовой задаче #392354(https://git.altlinux.org/tasks/392354). Эти два временных варианта - две крайности, которые не решают настоящую проблему, описанную в https://www.altlinux.org/Shared_Libs_Policy. 270908 4 rx1513 2025-08-14 16:21:12 +0300 (Ответ для kiper на комментарий #3) > (Ответ для Сергей Жидких на комментарий #2) > > Можете объяснить как вы собирали этот пакет? > > В соответствии с https://www.altlinux.org/RPM/Rust и подсматривая, как > данный пакет собирался в других дистрибутивах. Вы пробовали собирать без RUST_MIN_STACK? Если разработчик явно не указал требование к размеру стека при сборке, значит переполнение стека может указывать на проблемы с компилятором. Совсем недавно из-за этого некоторые пакеты периодически падали при сборке. > (Ответ для Сергей Жидких на комментарий #1) > > Мне также непонятно отсутствие макросов для сборки растовской части. > > Прошу простить мою некомпетентность в данном вопросе как человеку, > проходящему join. Будет исправлено в следующей сборке. > Спасибо. Обратите также внимание на используемую лицензию, она имеет дополнительный пункт "LLVM Exceptions to the Apache 2.0 License". Поскольку у нас нет такой лицензии её нужно паковать вместе с пакетом как "Apache-2.0 with LLVM-exception" по названию используемому в cargo.toml. Можете в качестве примера взять https://packages.altlinux.org/ru/sisyphus/srpms/llvm17.0/specfiles/ > (Ответ для Сергей Жидких на комментарий #0) > > https://www.altlinux.org/Shared_Libs_Policy > > А вот тема баги чуть сложнее, чем может показаться на первый взгляд. В > upstream-е wasmtime уже поднимался issue по поводу soname в 2021 > году(https://github.com/bytecodealliance/wasmtime/issues/2996). > На текущий момент, насколько я знаю, проблема не решена(хоть issue и > закрыт). В документации нет явного указания, что версия ABI wasmtime-c-api > привязана к версии самого wasmtime. > В связи с чем можно сделать вывод, что нет явного версионирования ABI, как и > определённых гарантий с версионированием основного проекта в отношение API > wasmtime-c-api. > > Как возможные варианты решения проблемы: > 1. Пинать upstream в новой issue, объясняя плюсы soname и версионирования > ABI в wasmtime-c-api во второй раз. Возможно приложив PR. > 2. В случае, если issue затухнет во второй раз, взвалить версионирование ABI > на человека X, которым могу выступить и я, когда руки дойдут до > использования в своём личном проекте. > > Но эти решения требуют определённого времени, так что сразу предложу > временные варианты решения: > 1. Оставить как есть. Но я чувствую, что данный вариант не устроит вас и > CMake(https://gitlab.kitware.com/cmake/cmake/-/issues/22307#note_971562). > 2. Использовать в качестве soname полную версию пакета. Данный вариант уже > собран в тестовой задаче #392354(https://git.altlinux.org/tasks/392354). > > Эти два временных варианта - две крайности, которые не решают настоящую > проблему, описанную в https://www.altlinux.org/Shared_Libs_Policy. Спасибо за развёрнутый ответ, было очень полезно узнать про проблемы растовских C-подобных библиотек. Очень плохо что upstream не понимает назначение soname. Оба временных решения являются плохими. Если разработчики не понимают для чего нужен soname, значит и гарантий что будет однозначное соответствие между C API и версией пакета нет. В таком случае ручное задание soname будет надёжнее. Я считаю стоит всё-таки достучаться до upstream-а и если откажется идти на сотрудничество, то заниматься версионированием самостоятельно. 270914 5 kiper 2025-08-14 17:31:04 +0300 (Ответ для Сергей Жидких на комментарий #4) > Вы пробовали собирать без RUST_MIN_STACK? Да. Насколько я помню, падала сборка на x86. В логах сборки прямым текстом была рекомендация. > Если разработчик явно не указал > требование к размеру стека при сборке, значит переполнение стека может > указывать на проблемы с компилятором. Совсем недавно из-за этого некоторые > пакеты периодически падали при сборке. Попробую собрать без RUST_MIN_STACK. По итогу сборки отпишусь сюда. Задача #392457 > Спасибо. Обратите также внимание на используемую лицензию, она имеет > дополнительный пункт "LLVM Exceptions to the Apache 2.0 License". Поскольку > у нас нет такой лицензии её нужно паковать вместе с пакетом как "Apache-2.0 > with LLVM-exception" по названию используемому в cargo.toml. Можете в > качестве примера взять > https://packages.altlinux.org/ru/sisyphus/srpms/llvm17.0/specfiles/ Благодарю. Возьму на заметку и исправлю! > Оба временных решения являются плохими. Если разработчики не понимают для > чего нужен soname, значит и гарантий что будет однозначное соответствие > между C API и версией пакета нет. В таком случае ручное задание soname будет > надёжнее. Согласен с вами. > Я считаю стоит всё-таки достучаться до upstream-а и если откажется идти на > сотрудничество, то заниматься версионированием самостоятельно. Так и поступлю. 270915 6 kiper 2025-08-14 17:57:21 +0300 (Ответ для kiper на комментарий #5) > (Ответ для Сергей Жидких на комментарий #4) > > Вы пробовали собирать без RUST_MIN_STACK? > > Да. Насколько я помню, падала сборка на x86. В логах сборки прямым текстом > была рекомендация. > > > Если разработчик явно не указал > > требование к размеру стека при сборке, значит переполнение стека может > > указывать на проблемы с компилятором. Совсем недавно из-за этого некоторые > > пакеты периодически падали при сборке. > > Попробую собрать без RUST_MIN_STACK. По итогу сборки отпишусь сюда. Задача > #392457 Этап сборки прошёл. Ошибки переполнения стека не произошла. Благодарю за информацию! 270917 7 rx1513 2025-08-14 18:02:21 +0300 ﷐[U+1F44D]﷑ 285127 8 lav 2026-04-04 02:20:54 +0300 А чем закончилась сборка? Хотелось бы увидеть более новую версию (39 хотя бы) 302728 9 lav 2026-10-17 22:20:38 +0300 Переработку из ветки people/kiper/packages/wasmtime (SONAME, подпакеты common и docs, ExcludeArch %ix86) перенёс в обновление 49.0.3-alt1, таск #437259. Библиотека теперь libwasmtime.so.49 (только мажорная версия: патч-выпуски wasmtime совместимы), пакет libwasmtime49 с Obsoletes старого libwasmtime. Спасибо за подготовленную работу. Задачу #392457 (43.0.1) можно удалить. 302764 10 repository-robot 2026-10-18 22:25:02 +0300 wasmtime-49.0.3-alt1 -> sisyphus: Fri Oct 16 2026 Vitaly Lipatov <lav@altlinux.ru> 49.0.3-alt1 - new version 49.0.3 - exclude i586 build (rustc runs out of memory on 32-bit) - build libwasmtime with SONAME libwasmtime.so.49 and package it as libwasmtime49 according to Shared Libs Policy (closes: #55586) - add common (license) and docs subpackages, make examples noarch - use Rust macros (added BuildRequires: rpm-macros-rust), fix License (Apache-2.0 with LLVM-exception) - added BuildRequires: gcc-c++ (cpp.req for the C++ API headers) - package C API headers in libwasmtime-devel (only conf.h was packaged) - based on the work of Korney Gedert (thanks to kiper@) - security fixes: + CVE-2026-34941, GHSA-hx6p-xpx3-jvvv: fix heap OOB read in UTF-16 to latin1+utf16 string transcoding. + CVE-2026-34942, GHSA-jxhv-7h78-9775: fix panic when transcoding misaligned utf-16 strings. + CVE-2026-34943, GHSA-m758-wjhj-p3jq: fix panic when lifting flags component value. + CVE-2026-34944, GHSA-qqfj-4vcm-26hv: fix segfault or out-of-sandbox load with f64x2.splat on x86-64. + CVE-2026-34945, GHSA-m9w2-8782-2946: fix host data leakage with 64-bit tables and Winch. + CVE-2026-34946, GHSA-q49f-xg75-m9xw: fix host panic when Winch executes table.fill. + CVE-2026-34971, GHSA-jhxm-h53p-jm7w: fix miscompiled guest heap access (sandbox escape) on aarch64 Cranelift. + CVE-2026-34983, GHSA-hfr4-7c6c-48w2: fix use-after-free after cloning wasmtime::Linker. + CVE-2026-34987, GHSA-xx5w-cvp6-jv83: fix sandbox-escaping memory access with Winch on aarch64. + CVE-2026-34988, GHSA-6wgr-89rj-399p: fix data leakage between pooling allocator instances. + CVE-2026-35186, GHSA-f984-pcp8-v2p7: fix improperly masked table.grow return value with Winch. + CVE-2026-35195, GHSA-394w-hwhg-8vgm: fix out-of-bounds write or crash when transcoding component model strings. + CVE-2026-44216, GHSA-p8xm-42r7-89xg: fix panic when allocating a table exceeding host address space. + GHSA-32h6-97mm-8q3c: fix stack buffer overflow from unvalidated async-lifted callback result count. + GHSA-hgjw-h833-99q9: fix stores mixing up type indices between engines. + GHSA-jqpg-j7w6-42pr: fix dynamic record lifting allocating beyond hostcall fuel limit. + GHSA-q554-3cjc-rx7p: fix component-model handle tables not charged to any limit. + GHSA-vcg5-q8m5-8379: fix async-entrypoint requirement enforcement. + GHSA-vqjp-4c8c-hfgg: fix filesystem sandbox escape via trailing slashes in paths or symlinks. + GHSA-wjc8-633q-pwxr: fix stack overflow dropping a long chain of recursive types.