<?xml version="1.0" encoding="UTF-8" ?>

<bugzilla version="5.2"
          urlbase="https://bugzilla.altlinux.org/"
          
          maintainer="jenya@basealt.ru"
>

    <bug>
          <bug_id>47150</bug_id>
          
          <creation_ts>2023-08-07 18:11:58 +0300</creation_ts>
          <short_desc>Не работает Easy Anti-Cheat в steam (sysv linker hashes in glibc)</short_desc>
          <delta_ts>2023-09-01 20:04:31 +0300</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>4</classification_id>
          <classification>Development</classification>
          <product>Sisyphus</product>
          <component>glibc</component>
          <version>unstable</version>
          <rep_platform>x86_64</rep_platform>
          <op_sys>Linux</op_sys>
          <bug_status>CLOSED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc>https://bugs.archlinux.org/task/79292</bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>P5</priority>
          <bug_severity>minor</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Mikhail Tergoev">tergoev-m</reporter>
          <assigned_to name="Gleb F-Malinovskiy">glebfm</assigned_to>
          <cc>ghgh2222</cc>
    
    <cc>glebfm</cc>
    
    <cc>lav</cc>
    
    <cc>ldv</cc>
    
    <cc>rider</cc>
          
          <qa_contact>qa-sisyphus</qa_contact>

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>231003</commentid>
    <comment_count>0</comment_count>
    <who name="Mikhail Tergoev">tergoev-m</who>
    <bug_when>2023-08-07 18:11:58 +0300</bug_when>
    <thetext>Не работают игры с Easy Anti-Cheat в steam при glibc 2.36+

Нашел:
https://github.com/ValveSoftware/Proton/issues/6051
где описывается проблема, если glibc 2.36+

Дальше нашел пример как в Арче вышли из ситуации:
https://github.com/archlinux/svntogit-packages/blob/packages/glibc/trunk/reenable_DT_HASH.patch

И большая статья по этому поводу:
https://maskray.me/blog/2022-08-20-glibc-and-dt-gnu-hash</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>231018</commentid>
    <comment_count>1</comment_count>
    <who name="Dmitry V. Levin">ldv</who>
    <bug_when>2023-08-08 13:08:42 +0300</bug_when>
    <thetext>Я думаю, что нам не стоит откатывать https://sourceware.org/cgit/glibc/commit/?id=e47de5cb2d4dbecb58f569ed241e8e95c568f03c, пусть лучше проприетарщики актуализируют свой протухший софт.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>231025</commentid>
    <comment_count>2</comment_count>
    <who name="Mikhail Tergoev">tergoev-m</who>
    <bug_when>2023-08-08 13:37:06 +0300</bug_when>
    <thetext>(Ответ для Dmitry V. Levin на комментарий #1)
&gt; Я думаю, что нам не стоит откатывать
&gt; https://sourceware.org/cgit/glibc/commit/
&gt; ?id=e47de5cb2d4dbecb58f569ed241e8e95c568f03c, пусть лучше проприетарщики
&gt; актуализируют свой протухший софт.

Судя из: https://bugs.archlinux.org/task/79292

A quick test with a glibc 2.38 build with --hash-style=both does work for me,
so just adding that to the LDFLAGS for glibc seems to be enough, no patch needed.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>231197</commentid>
    <comment_count>3</comment_count>
    <who name="Gleb F-Malinovskiy">glebfm</who>
    <bug_when>2023-08-10 19:17:18 +0300</bug_when>
    <thetext>(In reply to Mikhail Tergoev from comment #2)
&gt; Судя из: https://bugs.archlinux.org/task/79292
&gt; 
&gt; A quick test with a glibc 2.38 build with --hash-style=both does work for me,
&gt; so just adding that to the LDFLAGS for glibc seems to be enough, no patch
&gt; needed.

Патч или не патч это вопрос реализации.  Если бы мы хотели откатить это изменение, то откатить указанный Димой коммит было бы самым лучшим решением.  Но мы не хотим и дело тут не в способе решения.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>231198</commentid>
    <comment_count>4</comment_count>
    <who name="Anton Farygin">rider</who>
    <bug_when>2023-08-10 20:35:11 +0300</bug_when>
    <thetext>Почти наверняка может вылезти где-то ещё, пусть лучше повисит в открытом виде.

Всё-таки совместимость с софтом лучше не ломать.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>231209</commentid>
    <comment_count>5</comment_count>
    <who name="Gleb F-Malinovskiy">glebfm</who>
    <bug_when>2023-08-11 10:47:01 +0300</bug_when>
    <thetext>Если вдруг кому-то очень нужно:

# cat /etc/apt/vendors.list.d/team.list
simple-key &quot;team-glebfm&quot; {
        Fingerprint &quot;ABADA2EF01C15A653AC3425B51D2B221D1D1C7E6&quot;;
        Name &quot;glebfm@altlinux.org&quot;;
}
# tail -1 /etc/apt/sources.list        
rpm [team-glebfm] http://ftp.altlinux.org/pub/people/glebfm/glibc-hashstyleboth x86_64 hasher</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>231236</commentid>
    <comment_count>6</comment_count>
    <who name="Mikhail Tergoev">tergoev-m</who>
    <bug_when>2023-08-11 15:10:36 +0300</bug_when>
    <thetext># apt-repo add rpm [team-glebfm] http://ftp.altlinux.org/pub/people/glebfm/glibc-hashstyleboth x86_64 hasher

Так как нужно еще и i586, добавляю и его:
# apt-repo add rpm [team-glebfm] http://ftp.altlinux.org/pub/people/glebfm/glibc-hashstyleboth i586 hasher

# apt-repo upgrade
Получено: 1 http://ftp.altlinux.org glebfm/glibc-hashstyleboth/x86_64 release [2776B]
Получено: 2 http://ftp.altlinux.org glebfm/glibc-hashstyleboth/i586 release [2776B]
Получено: 3 http://ftp.altlinux.org ALTLinux/Sisyphus/x86_64 release [4238B]
Получено: 4 http://ftp.altlinux.org ALTLinux/Sisyphus/x86_64-i586 release [1680B]
Получено: 5 http://ftp.altlinux.org ALTLinux/Sisyphus/noarch release [2859B]
Получено 14,3kB за 0s (221kB/s).                   
Получено: 1 http://ftp.altlinux.org glebfm/glibc-hashstyleboth/x86_64/hasher pkglist [28,5kB]
Получено: 2 http://ftp.altlinux.org glebfm/glibc-hashstyleboth/x86_64/hasher release [125B]
Получено: 3 http://ftp.altlinux.org glebfm/glibc-hashstyleboth/i586/hasher pkglist [28,8kB]
Получено: 4 http://ftp.altlinux.org glebfm/glibc-hashstyleboth/i586/hasher release [125B]
Найдено http://ftp.altlinux.org ALTLinux/Sisyphus/x86_64/classic pkglist
Найдено http://ftp.altlinux.org ALTLinux/Sisyphus/x86_64/classic release
Найдено http://ftp.altlinux.org ALTLinux/Sisyphus/x86_64/gostcrypto pkglist
Найдено http://ftp.altlinux.org ALTLinux/Sisyphus/x86_64/gostcrypto release
Найдено http://ftp.altlinux.org ALTLinux/Sisyphus/x86_64-i586/classic pkglist
Найдено http://ftp.altlinux.org ALTLinux/Sisyphus/x86_64-i586/classic release
Найдено http://ftp.altlinux.org ALTLinux/Sisyphus/noarch/classic pkglist
Найдено http://ftp.altlinux.org ALTLinux/Sisyphus/noarch/classic release
Получено 57,5kB за 0s (482kB/s).
Чтение списков пакетов... Завершено
Построение дерева зависимостей... Завершено
Чтение списков пакетов... Завершено
Построение дерева зависимостей... Завершено
Подсчет обновлений... Завершено
Следующие пакеты будут ОБНОВЛЕНЫ:
  glibc glibc-core glibc-debug glibc-devel glibc-devel-static glibc-doc glibc-gconv-modules glibc-i18ndata glibc-locales glibc-nss
  glibc-pthread glibc-timezones glibc-utils iconv libnsl1 nscd
Следующие пакеты будут УДАЛЕНЫ:
  тут удаляются i586 пакеты включая i586-steam
16 будет обновлено, 0 новых установлено, 111 пакетов будет удалено и 0 не будет обновлено.

Что я делаю не так?

# cat /etc/apt/sources.list  
rpm [team-glebfm] http://ftp.altlinux.org/pub/people glebfm/glibc-hashstyleboth/x86_64 hasher
rpm [team-glebfm] http://ftp.altlinux.org/pub/people glebfm/glibc-hashstyleboth/i586 hasher</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>231248</commentid>
    <comment_count>7</comment_count>
    <who name="Gleb F-Malinovskiy">glebfm</who>
    <bug_when>2023-08-11 16:04:26 +0300</bug_when>
    <thetext>(In reply to Mikhail Tergoev from comment #6)
&gt; # apt-repo add rpm [team-glebfm]
&gt; http://ftp.altlinux.org/pub/people/glebfm/glibc-hashstyleboth x86_64 hasher
&gt; 
&gt; Так как нужно еще и i586, добавляю и его:
&gt; # apt-repo add rpm [team-glebfm]
&gt; http://ftp.altlinux.org/pub/people/glebfm/glibc-hashstyleboth i586 hasher

Нет, нужно не i586, а x86_64-i586, т.е. arepo.  Я про него совсем забыл.

Я добавил arepo, теперь можно использовать:

rpm [team-glebfm] http://ftp.altlinux.org/pub/people/glebfm/glibc-hashstyleboth x86_64 hasher
rpm [team-glebfm] http://ftp.altlinux.org/pub/people/glebfm/glibc-hashstyleboth x86_64-i586 hasher</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>231261</commentid>
    <comment_count>8</comment_count>
    <who name="Mikhail Tergoev">tergoev-m</who>
    <bug_when>2023-08-11 17:18:15 +0300</bug_when>
    <thetext>x86_64-i586 - первым делом пробовал, но не работало.

Теперь всё ок. Античиты снова работают.

Оставлю тут простейшую пошаговую инструкцию:
# apt-repo add rpm [team-glebfm] http://ftp.altlinux.org/pub/people/glebfm/glibc-hashstyleboth x86_64 hasher
# apt-repo add rpm [team-glebfm] http://ftp.altlinux.org/pub/people/glebfm/glibc-hashstyleboth x86_64-i586 hasher
# apt-repo upgrade</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>231264</commentid>
    <comment_count>9</comment_count>
    <who name="Gleb F-Malinovskiy">glebfm</who>
    <bug_when>2023-08-11 17:23:22 +0300</bug_when>
    <thetext>(In reply to Mikhail Tergoev from comment #8)
&gt; x86_64-i586 - первым делом пробовал, но не работало.
Да, я про него забыл совсем, а не только написать про него.

&gt; Оставлю тут простейшую пошаговую инструкцию:
Без vendors.list не заработает проверка подписи через [team-glebfm].</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>231265</commentid>
    <comment_count>10</comment_count>
    <who name="Mikhail Tergoev">tergoev-m</who>
    <bug_when>2023-08-11 17:32:09 +0300</bug_when>
    <thetext>&gt; Без vendors.list не заработает проверка подписи через [team-glebfm].

Исправляюсь:

# apt-repo add rpm [team-glebfm] http://ftp.altlinux.org/pub/people/glebfm/glibc-hashstyleboth x86_64 hasher

# apt-repo add rpm [team-glebfm] http://ftp.altlinux.org/pub/people/glebfm/glibc-hashstyleboth x86_64-i586 hasher

# echo -e &apos;simple-key &quot;team-glebfm&quot; {\n        Fingerprint &quot;ABADA2EF01C15A653AC3425B51D2B221D1D1C7E6&quot;;\n        Name &quot;glebfm@altlinux.org&quot;;\n}&apos; &gt;&gt; /etc/apt/vendors.list.d/team.list

# apt-repo upgrade</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>231322</commentid>
    <comment_count>11</comment_count>
    <who name="Vitaly Lipatov">lav</who>
    <bug_when>2023-08-13 18:27:48 +0300</bug_when>
    <thetext>(Ответ для Mikhail Tergoev на комментарий #0)
&gt; Не работают игры с Easy Anti-Cheat в steam при glibc 2.36+
&gt; 
&gt; Нашел:
&gt; https://github.com/ValveSoftware/Proton/issues/6051
&gt; где описывается проблема, если glibc 2.36+
&gt; 
&gt; Дальше нашел пример как в Арче вышли из ситуации:
&gt; https://github.com/archlinux/svntogit-packages/blob/packages/glibc/trunk/
&gt; reenable_DT_HASH.patch
...
Конечно, стало известно, что «for EPIC Games EAC, there is already a fix for this in EOS SDK 1.15.2 (August 2022) and the corresponding version of the anti-cheat module».
Как я понимаю, это разработчикам всех игр нужно пересобраться с обновлённым SDK.

В Fedora рассматривали эту проблему
https://bugzilla.redhat.com/show_bug.cgi?id=2129358

и решили не ломать Fedora как игровую платформу:
* Пн окт 17 2022 Carlos O&apos;Donell &lt;carlos@redhat.com&gt; - 2.36.9000-10
- Enable ELF DT_HASH for shared objects and the dynamic loader (#2129358)


(Ответ для Dmitry V. Levin на комментарий #1)
&gt; Я думаю, что нам не стоит откатывать
&gt; https://sourceware.org/cgit/glibc/commit/
&gt; ?id=e47de5cb2d4dbecb58f569ed241e8e95c568f03c, пусть лучше проприетарщики
&gt; актуализируют свой протухший софт.
Ну это же просто такой хитрый оборот, всем понятно, что проприетарщики по определению ничего не будут актуализировать.
С другой стороны, разработчики glibc считают возможным незаметно выключать поддержку DT_HASH без всякого анонса. Точнее, они-то поменяли умолчание, оставив выбор для разработчиков дистрибутивов, которые в итоге без анонса отключают DT_HASH для glibc, разрушая совместимость.


(Ответ для Gleb F-Malinovskiy на комментарий #3)
&gt; (In reply to Mikhail Tergoev from comment #2)
&gt; &gt; Судя из: https://bugs.archlinux.org/task/79292
&gt; &gt; 
&gt; &gt; A quick test with a glibc 2.38 build with --hash-style=both does work for me,
&gt; &gt; so just adding that to the LDFLAGS for glibc seems to be enough, no patch
&gt; &gt; needed.
&gt; 
&gt; Патч или не патч это вопрос реализации.  Если бы мы хотели откатить это
&gt; изменение, то откатить указанный Димой коммит было бы самым лучшим решением.
&gt; Но мы не хотим и дело тут не в способе решения.

А какие-то аргументы есть? А видно только «мы хотели» и «мы не хотим».

Чем продолжение поддержки совместимости с DT_HASH ухудшает glibc?
Почему вы считаете, что лучше иметь два glibc в репозитории, чем один с поддержкой DT_HASH?
Считаете ли вы, что АЛЬТ не должен быть игровой платформой?
Считаете ли вы, что случайное появление несовместимостей с проприетарным ПО это хорошо, и не стоит ничего делать для исправления?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>231358</commentid>
    <comment_count>12</comment_count>
    <who name="Gleb F-Malinovskiy">glebfm</who>
    <bug_when>2023-08-14 13:10:34 +0300</bug_when>
    <thetext>(In reply to Vitaly Lipatov from comment #11)
&gt; (Ответ для Mikhail Tergoev на комментарий #0)
&gt; Конечно, стало известно, что «for EPIC Games EAC, there is already a fix for
&gt; this in EOS SDK 1.15.2 (August 2022) and the corresponding version of the
&gt; anti-cheat module».
&gt; Как я понимаю, это разработчикам всех игр нужно пересобраться с обновлённым
&gt; SDK.
Это вроде было известно -- говорят, что часть игр с EAC прекрасно работает.

&gt; Ну это же просто такой хитрый оборот, всем понятно, что проприетарщики по
&gt; определению ничего не будут актуализировать.
Да, если будет работать, то не будут актуализировать.

&gt; С другой стороны, разработчики glibc считают возможным незаметно выключать
&gt; поддержку DT_HASH без всякого анонса. Точнее, они-то поменяли умолчание,
&gt; оставив выбор для разработчиков дистрибутивов, которые в итоге без анонса
&gt; отключают DT_HASH для glibc, разрушая совместимость.
В ALT gnu hash исользуется начиная с того, как в binutils 2.17.50.0.3-alt1 (Fri Aug 18 2006) появилась поддержка этой фичи и в gcc 4.1.1-alt8 (Sun Oct 01 2006) была реализована безусловная передача --hash-style=gnu линкеру.  Разработчики дистрибутива приняли решение очень давно.  Тот факт, что glibc по своим причинам (которые описаны в комментариях к убранным изменениям) считали нужным поддерживать sysv hash style на это решение никак не влияет.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>231400</commentid>
    <comment_count>13</comment_count>
    <who name="Vitaly Lipatov">lav</who>
    <bug_when>2023-08-15 02:11:14 +0300</bug_when>
    <thetext>(Ответ для Gleb F-Malinovskiy на комментарий #12)
&gt; (In reply to Vitaly Lipatov from comment #11)
&gt; &gt; (Ответ для Mikhail Tergoev на комментарий #0)
&gt; &gt; Конечно, стало известно, что «for EPIC Games EAC, there is already a fix for
&gt; &gt; this in EOS SDK 1.15.2 (August 2022) and the corresponding version of the
&gt; &gt; anti-cheat module».
&gt; &gt; Как я понимаю, это разработчикам всех игр нужно пересобраться с обновлённым
&gt; &gt; SDK.
&gt; Это вроде было известно -- говорят, что часть игр с EAC прекрасно работает.
&gt; 
&gt; &gt; Ну это же просто такой хитрый оборот, всем понятно, что проприетарщики по
&gt; &gt; определению ничего не будут актуализировать.
&gt; Да, если будет работать, то не будут актуализировать.
Боюсь, что они в последнюю очередь будут интересоваться тем, что работает на glibc в ALT.

&gt; &gt; С другой стороны, разработчики glibc считают возможным незаметно выключать
&gt; &gt; поддержку DT_HASH без всякого анонса. Точнее, они-то поменяли умолчание,
&gt; &gt; оставив выбор для разработчиков дистрибутивов, которые в итоге без анонса
&gt; &gt; отключают DT_HASH для glibc, разрушая совместимость.
&gt; В ALT gnu hash исользуется начиная с того, как в binutils 2.17.50.0.3-alt1
&gt; (Fri Aug 18 2006) появилась поддержка этой фичи и в gcc 4.1.1-alt8 (Sun Oct
&gt; 01 2006) была реализована безусловная передача --hash-style=gnu линкеру. 
&gt; Разработчики дистрибутива приняли решение очень давно.  Тот факт, что glibc
&gt; по своим причинам (которые описаны в комментариях к убранным изменениям)
&gt; считали нужным поддерживать sysv hash style на это решение никак не влияет.
Это выглядит так, что все не при делах:
- разработчики glibc говорят «мы меняем умолчание, вы можете у себя выбрать что нужно»
- сопровождающий пакета glibc говорит «мы давно уже выбрали, и изменение в апстриме нас не касается»

Но по факту новая версия пакета ломает определённую функциональность.

Вы скажите просто, почему заботливо не предупредили, что в новой сборке пакета будет радикальное изменение? Ну может забыли или не знали?

Хотя и вопросы в предыдущем комментарии остались без ответа.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>231445</commentid>
    <comment_count>14</comment_count>
    <who name="Vitaly Lipatov">lav</who>
    <bug_when>2023-08-15 12:04:41 +0300</bug_when>
    <thetext>(Ответ для Gleb F-Malinovskiy на комментарий #12)
...
&gt; В ALT gnu hash исользуется начиная с того, как в binutils 2.17.50.0.3-alt1
&gt; (Fri Aug 18 2006) появилась поддержка этой фичи и в gcc 4.1.1-alt8 (Sun Oct
&gt; 01 2006) была реализована безусловная передача --hash-style=gnu линкеру. 
&gt; Разработчики дистрибутива приняли решение очень давно.  Тот факт, что glibc
&gt; по своим причинам (которые описаны в комментариях к убранным изменениям)
&gt; считали нужным поддерживать sysv hash style на это решение никак не влияет.
Не вижу связи между тем, как собираются бинарники (--hash-style=gnu это отличное решение, так сделали все, понятно, что DT_GNU_HASH лучше) и тем ломается ли совместимость в glibc.
О влиянии на решение тоже вопросов не было.

Картина-то другая. В Fedora в обход фриза проносили возвращение DT_HASH в glibc, чтобы в релизе запускались игры, а у нас будут вопросы на много лет, почему игра не запускается. А ответа-то нет.
Если поддержка DT_HASH возвращается двумя строчками
LDFLAGS.so=&quot;-Wl,--hash-style=both&quot;
LDFLAGS-rtld=&quot;-Wl,--hash-style=both&quot;
при сборке glibc, это вопрос того, будет ли сохраняться совместимость. Зачем рассказывать про binutils?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>231448</commentid>
    <comment_count>15</comment_count>
    <who name="Gleb F-Malinovskiy">glebfm</who>
    <bug_when>2023-08-15 12:30:57 +0300</bug_when>
    <thetext>(In reply to Vitaly Lipatov from comment #14)
&gt; Зачем рассказывать про binutils?
Ты написал что-то очень странное про умолчания в glibc связанные с выбором hash style, мне пришлось объяснять.  Из твоего следующего ответа я могу сделать вывод, что ты не понял моё объяснение.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>231451</commentid>
    <comment_count>16</comment_count>
    <who name="Gleb F-Malinovskiy">glebfm</who>
    <bug_when>2023-08-15 12:40:28 +0300</bug_when>
    <thetext>(In reply to Vitaly Lipatov from comment #13)
&gt; Вы скажите просто, почему заботливо не предупредили, что в новой сборке
&gt; пакета будет радикальное изменение? Ну может забыли или не знали?
Странный вопрос.  Забыли, что в EAC делаются такие странные вещи? :)
Нет, конечно не знали.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>232396</commentid>
    <comment_count>17</comment_count>
    <who name="Repository Robot">repository-robot</who>
    <bug_when>2023-09-01 20:04:31 +0300</bug_when>
    <thetext>glibc-6:2.38.0.11.g1aed90c9c8-alt1 -&gt; sisyphus:

 Fri Sep 01 2023 Gleb F-Malinovskiy &lt;glebfm@altlinux&gt; 6:2.38.0.11.g1aed90c9c8-alt1
 - Updated to glibc-2.38-11-g1aed90c9c8.
 - Enabled ELF DT_HASH for shared objects and the dynamic loader (ALT#47150).</thetext>
  </long_desc>
      
      

    </bug>

</bugzilla>