[devel] I: glibc 2.32 && sisyphus snapshot publication skip

[devel] I: glibc 2.32 && sisyphus snapshot publication skip

[Gleb Fotengauer-Malinovskiy]

[-- Attachment #1: Type: text/plain, Size: 5655 bytes --]

Hi,

On Thu, Dec 17, 2020 at 02:30:25PM +0000, Girar awaiter (glebfm) wrote:
> http://git.altlinux.org/tasks/263483/logs/events.8.1.log
> 
> 2020-Dec-17 14:16:56 :: test-only task #263483 for sisyphus resumed by glebfm:
> 2020-Dec-17 14:16:56 :: message: Update glibc; drop FTBFS packages blocking this update.
> #100 removed
> #200 removed
> #300 build 2.32-alt1 from /people/glebfm/packages/glibc.git fetched at 2020-Dec-16 19:12:07

On Thu, Dec 17, 2020 at 03:13:36PM +0000, Girar pender (glebfm) wrote:
> http://git.altlinux.org/tasks/archive/done/_257/263483/logs/events.9.1.log

В связи с этим обновлением glibc пришлось отключить публикацию
сегодняшнего снапшота репозитория sisyphus.  Это связано с тем, что версия
openssh, которая была в этом снапшоте имела seccomp-фильтр, который
запрещает использование некоторых системных вызовов, которые используются
в функциях glibc, которые вызывает sshd.  Т.е. после обновления glibc без
обновления seccomp-фильтра sshd стал бы нерабочим.

Сейчас openssh в Сизифе обновлён и добавлена защита, которая не позволит
точечно обновить glibc без обновления openssh, так что следующий снапшот
репозитория будет опубликован как обычно.


Также в связи с обновлением glibc сломалась сборка некоторых пакетов:

On Fri, Dec 18, 2020 at 07:32:51AM +0000, ALT beekeeper wrote:
> MySQL-8.0.22-alt1
> autofs-5.1.6-alt1
> conntrack-tools-1.4.6-alt1
> dsniff-2.4-alt0.13.b1
> glusterfs7-7.8-alt3
> glusterfs8-8.2-alt3
> libdb4.7-4.7.25-alt9
> librpcsecgss-0.19-alt1.qa1_10
> libvirt-6.10.0-alt1
> libxview-3.2p1.4-alt11
> lmbench-3.0-alt3
> ltspfs-0.3-alt4.20070117.qa1
> ltspfsd-0.3-alt0.2.2.qa1
> make-initrd-busybox-1.28.1-alt2
> nfs-1:2.5.2-alt1
> octave-instrument-control-0.6.0-alt1
> ogdi-3.2.0-alt1.beta2.2
> openl2tp-1.8-alt7
> p3nfs-5.19-alt1.qa2
> perl-Quota-1.8.1-alt1
> python-2.7.18-alt2
> python3-3.8.6-alt1
> quota-2:4.06.0.4.43b6-alt1
> samba-4.12.10-alt2
> trickle-1.07-alt4
> watchdog-5.13-alt1_18
> xinetd-2.3.15-alt4
> zfs-0.8.4-alt4

* Remove configure option --enable-obsolete-rpc.  Sun RPC is removed
  from glibc.  This includes the rpcgen program, librpcsvc, and the Sun
  RPC header files.  Backward compatibility for old programs is kept
  only for architectures and ABIs that have been added in or before
  glibc 2.31.  New programs need to use TI-RPC
  <http://git.linux-nfs.org/?p=steved/libtirpc.git;a=summary> and
  rpcsvc-proto <https://github.com/thkukuk/rpcsvc-proto>.

> alsamixergui-0.9.0-alt5
> evms-2.5.5-alt47
> itk-snap-3.8.0-alt2
> kBuild-0.1.9998.r3178-alt4
> launchtool-0.7-alt1.qa1
> libxview-3.2p1.4-alt11
> mars_nwe-0.99-alt5
> procinfo-1:18-alt1.qa1

* The deprecated arrays sys_siglist, _sys_siglist, and sys_sigabbrev
  are no longer available to newly linked binaries, and their declarations
  have been removed from <string.h>.  They are exported solely as
  compatibility symbols to support old binaries.  All programs should use
  strsignal instead.

> faketime-0.2.6-alt1

* The gettimeofday function no longer reports information about a
  system-wide time zone.  This 4.2-BSD-era feature has been deprecated
  for many years, as it cannot handle the full complexity of the
  world's timezones, but hitherto we have supported it on a
  best-effort basis.  Changes required to support 64-bit time_t on
  32-bit architectures have made this no longer practical.

> fuse-chironfs-1.1.1-alt1.qa2
> fuse-cryfs-0.9.11-alt1
> gsimplecal-2.0-alt1.git20140809
> hfsprogs-540.1.linux3-alt1.1
> imagewriter-1.10-alt4
> ipsec-tools-0.8.2-alt3
> libchipmunk-7.0.3-alt1
> libcoredumper-1.2.1-alt2.3
> libdispatch-objc2-1.2-alt6.git20140226
> libirrlicht-1.8.4-alt3
> msd_lite-1.08-alt4
> powershell-6.0.0-alt8

* The deprecated <sys/sysctl.h> header and the sysctl function have been
  removed.  To support old binaries, the sysctl function continues to
  exist as a compatibility symbol (on those architectures which had it),
  but always fails with ENOSYS.  This reflects the removal of the system
  call from all architectures, starting with Linux 5.5.
 
> gcc4.9-4.9.2-alt8
> gcc5-5.3.1-alt8
> gcc6-6.3.1-alt6
> gcc7-7.3.1-alt9

  [18231] libc: ipc_perm struct's mode member has wrong type in
    sys/ipc.h

> libxview-3.2p1.4-alt11
> mars_nwe-0.99-alt5
> ppp-2.4.8-alt2

* The deprecated symbols sys_errlist, _sys_errlist, sys_nerr, and _sys_nerr
  are no longer available to newly linked binaries, and their declarations
  have been removed from from <stdio.h>.  They are exported solely as
  compatibility symbols to support old binaries.  All programs should use
  strerror or strerror_r instead.

> linuxtv-dvb-apps-1.1.1-alt2.2
> rdate-1.4-alt5.qa1
> vdr-2.2.0-alt8

* The obsolete function stime is no longer available to newly linked
  binaries, and its declaration has been removed from <time.h>.
  Programs that set the system time should use clock_settime instead.

> qosmic-1.6.0-alt1

/* The -ffinite-math symbols were added on GLIBC 2.15 and moved to compat
   symbol so newer architectures do not require to support it.  */

-- 
glebfm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

[devel] Inconvenient seccomp (Was: I: glibc 2.32 && sisyphus snapshot publication skip)

[Vladimir D. Seleznev]

On Fri, Dec 18, 2020 at 06:38:47PM +0300, Gleb Fotengauer-Malinovskiy wrote:
> Hi,
> 
> On Thu, Dec 17, 2020 at 02:30:25PM +0000, Girar awaiter (glebfm) wrote:
> > http://git.altlinux.org/tasks/263483/logs/events.8.1.log
> > 
> > 2020-Dec-17 14:16:56 :: test-only task #263483 for sisyphus resumed by glebfm:
> > 2020-Dec-17 14:16:56 :: message: Update glibc; drop FTBFS packages blocking this update.
> > #100 removed
> > #200 removed
> > #300 build 2.32-alt1 from /people/glebfm/packages/glibc.git fetched at 2020-Dec-16 19:12:07
> 
> On Thu, Dec 17, 2020 at 03:13:36PM +0000, Girar pender (glebfm) wrote:
> > http://git.altlinux.org/tasks/archive/done/_257/263483/logs/events.9.1.log
> 
> В связи с этим обновлением glibc пришлось отключить публикацию
> сегодняшнего снапшота репозитория sisyphus.  Это связано с тем, что версия
> openssh, которая была в этом снапшоте имела seccomp-фильтр, который
> запрещает использование некоторых системных вызовов, которые используются
> в функциях glibc, которые вызывает sshd.  Т.е. после обновления glibc без
> обновления seccomp-фильтра sshd стал бы нерабочим.
> 
> Сейчас openssh в Сизифе обновлён и добавлена защита, которая не позволит
> точечно обновить glibc без обновления openssh, так что следующий снапшот
> репозитория будет опубликован как обычно.

Ручная защита...

Seccomp -- крайне неудобная и, скажем так, неконсистентная вещь для
дистрибуции. Этот случай с openssh -- наглядный пример, когда из-за
изменения поведения glibc правила seccomp ломают приложение. И эта вещь,
которую легко обнаружить, сложнее обнаружить, когда правила внезапно и
тихо становятся бесполезными.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] Inconvenient seccomp (Was: I: glibc 2.32 && sisyphus snapshot publication skip)

[Dmitry V. Levin]

On Fri, Dec 18, 2020 at 07:08:51PM +0300, Vladimir D. Seleznev wrote:
> On Fri, Dec 18, 2020 at 06:38:47PM +0300, Gleb Fotengauer-Malinovskiy wrote:
> > On Thu, Dec 17, 2020 at 02:30:25PM +0000, Girar awaiter (glebfm) wrote:
> > > http://git.altlinux.org/tasks/263483/logs/events.8.1.log
> > > 
> > > 2020-Dec-17 14:16:56 :: test-only task #263483 for sisyphus resumed by glebfm:
> > > 2020-Dec-17 14:16:56 :: message: Update glibc; drop FTBFS packages blocking this update.
> > > #100 removed
> > > #200 removed
> > > #300 build 2.32-alt1 from /people/glebfm/packages/glibc.git fetched at 2020-Dec-16 19:12:07
> > 
> > On Thu, Dec 17, 2020 at 03:13:36PM +0000, Girar pender (glebfm) wrote:
> > > http://git.altlinux.org/tasks/archive/done/_257/263483/logs/events.9.1.log
> > 
> > В связи с этим обновлением glibc пришлось отключить публикацию
> > сегодняшнего снапшота репозитория sisyphus.  Это связано с тем, что версия
> > openssh, которая была в этом снапшоте имела seccomp-фильтр, который
> > запрещает использование некоторых системных вызовов, которые используются
> > в функциях glibc, которые вызывает sshd.  Т.е. после обновления glibc без
> > обновления seccomp-фильтра sshd стал бы нерабочим.
> > 
> > Сейчас openssh в Сизифе обновлён и добавлена защита, которая не позволит
> > точечно обновить glibc без обновления openssh, так что следующий снапшот
> > репозитория будет опубликован как обычно.
> 
> Ручная защита...
> 
> Seccomp -- крайне неудобная и, скажем так, неконсистентная вещь для
> дистрибуции. Этот случай с openssh -- наглядный пример, когда из-за
> изменения поведения glibc правила seccomp ломают приложение. И эта вещь,
> которую легко обнаружить, сложнее обнаружить, когда правила внезапно и
> тихо становятся бесполезными.

Можете попробовать реализовать и заапстримить что-нибудь получше! :)


-- 
ldv

Re: [devel] Inconvenient seccomp (Was: I: glibc 2.32 && sisyphus snapshot publication skip)

[Alexey Gladkov]

On Fri, Dec 18, 2020 at 07:08:51PM +0300, Vladimir D. Seleznev wrote:
> On Fri, Dec 18, 2020 at 06:38:47PM +0300, Gleb Fotengauer-Malinovskiy wrote:
> > Hi,
> > 
> > On Thu, Dec 17, 2020 at 02:30:25PM +0000, Girar awaiter (glebfm) wrote:
> > > http://git.altlinux.org/tasks/263483/logs/events.8.1.log
> > > 
> > > 2020-Dec-17 14:16:56 :: test-only task #263483 for sisyphus resumed by glebfm:
> > > 2020-Dec-17 14:16:56 :: message: Update glibc; drop FTBFS packages blocking this update.
> > > #100 removed
> > > #200 removed
> > > #300 build 2.32-alt1 from /people/glebfm/packages/glibc.git fetched at 2020-Dec-16 19:12:07
> > 
> > On Thu, Dec 17, 2020 at 03:13:36PM +0000, Girar pender (glebfm) wrote:
> > > http://git.altlinux.org/tasks/archive/done/_257/263483/logs/events.9.1.log
> > 
> > В связи с этим обновлением glibc пришлось отключить публикацию
> > сегодняшнего снапшота репозитория sisyphus.  Это связано с тем, что версия
> > openssh, которая была в этом снапшоте имела seccomp-фильтр, который
> > запрещает использование некоторых системных вызовов, которые используются
> > в функциях glibc, которые вызывает sshd.  Т.е. после обновления glibc без
> > обновления seccomp-фильтра sshd стал бы нерабочим.
> > 
> > Сейчас openssh в Сизифе обновлён и добавлена защита, которая не позволит
> > точечно обновить glibc без обновления openssh, так что следующий снапшот
> > репозитория будет опубликован как обычно.
> 
> Ручная защита...
> 
> Seccomp -- крайне неудобная и, скажем так, неконсистентная вещь для
> дистрибуции. Этот случай с openssh -- наглядный пример, когда из-за
> изменения поведения glibc правила seccomp ломают приложение. И эта вещь,
> которую легко обнаружить, сложнее обнаружить, когда правила внезапно и
> тихо становятся бесполезными.

Согласен. seccomp очень неудобный механизм. Тут бы пригодилось что-нибудь
типа pledge. Для линукса создать бы libpledge и привязать его к libc.

-- 
Rgrds, legion

Re: [devel] Inconvenient seccomp (Was: I: glibc 2.32 && sisyphus snapshot publication skip)

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 3155 bytes --]

On Fri, 18 Dec 2020 19:48:37 +0100 Alexey Gladkov wrote:
> On Fri, Dec 18, 2020 at 07:08:51PM +0300, Vladimir D. Seleznev wrote:
> > On Fri, Dec 18, 2020 at 06:38:47PM +0300, Gleb Fotengauer-Malinovskiy wrote:
> > > Hi,
> > > 
> > > On Thu, Dec 17, 2020 at 02:30:25PM +0000, Girar awaiter (glebfm) wrote:
> > > > http://git.altlinux.org/tasks/263483/logs/events.8.1.log
> > > > 
> > > > 2020-Dec-17 14:16:56 :: test-only task #263483 for sisyphus resumed by glebfm:
> > > > 2020-Dec-17 14:16:56 :: message: Update glibc; drop FTBFS packages blocking this update.
> > > > #100 removed
> > > > #200 removed
> > > > #300 build 2.32-alt1 from /people/glebfm/packages/glibc.git fetched at 2020-Dec-16 19:12:07
> > > 
> > > On Thu, Dec 17, 2020 at 03:13:36PM +0000, Girar pender (glebfm) wrote:
> > > > http://git.altlinux.org/tasks/archive/done/_257/263483/logs/events.9.1.log
> > > 
> > > В связи с этим обновлением glibc пришлось отключить публикацию
> > > сегодняшнего снапшота репозитория sisyphus.  Это связано с тем, что версия
> > > openssh, которая была в этом снапшоте имела seccomp-фильтр, который
> > > запрещает использование некоторых системных вызовов, которые используются
> > > в функциях glibc, которые вызывает sshd.  Т.е. после обновления glibc без
> > > обновления seccomp-фильтра sshd стал бы нерабочим.
> > > 
> > > Сейчас openssh в Сизифе обновлён и добавлена защита, которая не позволит
> > > точечно обновить glibc без обновления openssh, так что следующий снапшот
> > > репозитория будет опубликован как обычно.
> > 
> > Ручная защита...
> > 
> > Seccomp -- крайне неудобная и, скажем так, неконсистентная вещь для
> > дистрибуции. Этот случай с openssh -- наглядный пример, когда из-за
> > изменения поведения glibc правила seccomp ломают приложение. И эта вещь,
> > которую легко обнаружить, сложнее обнаружить, когда правила внезапно и
> > тихо становятся бесполезными.
> 
> Согласен. seccomp очень неудобный механизм. Тут бы пригодилось что-нибудь
> типа pledge. Для линукса создать бы libpledge и привязать его к libc.

Как я понял, pledge — это syscall OpenBSD и без поддержки со
стороны ядра просто либой его не сделать.

Я только рад буду видеть pledge в Linux, но это маловероятно :( 


Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] Inconvenient seccomp (Was: I: glibc 2.32 && sisyphus snapshot publication skip)

[Alexey Gladkov]

[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]

On Fri, Dec 18, 2020 at 11:21:18PM +0300, Andrey Savchenko wrote:
> > Согласен. seccomp очень неудобный механизм. Тут бы пригодилось что-нибудь
> > типа pledge. Для линукса создать бы libpledge и привязать его к libc.
> 
> Как я понял, pledge — это syscall OpenBSD

Да, он родимый.

> и без поддержки со стороны ядра просто либой его не сделать.

Проблема не в новых syscalls, которые появляются в ядре, а в библиотеках
(libc), которые прячут от приложения системные вызовы. Та или иная
библиотечная функция в разное выполнять разные системные вызовы. В такое
ситуации написать seccomp та ещё задача.

> Я только рад буду видеть pledge в Linux, но это маловероятно :( 

На уровне ядра это будет также неюзабильно как и голый seccomp.

-- 
Rgrds, legion


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[devel] I: rpcsvc-proto-devel + rpcgen

[Dmitry V. Levin]

On Fri, Dec 18, 2020 at 06:38:47PM +0300, Gleb Fotengauer-Malinovskiy wrote:
[...]
> Также в связи с обновлением glibc сломалась сборка некоторых пакетов:
[...]
> * Remove configure option --enable-obsolete-rpc.  Sun RPC is removed
>   from glibc.  This includes the rpcgen program, librpcsvc, and the Sun
>   RPC header files.  Backward compatibility for old programs is kept
>   only for architectures and ABIs that have been added in or before
>   glibc 2.31.  New programs need to use TI-RPC
>   <http://git.linux-nfs.org/?p=steved/libtirpc.git;a=summary> and
>   rpcsvc-proto <https://github.com/thkukuk/rpcsvc-proto>.

В Сизиф собран вышеупомянутый rpcsvc-proto, соответственно, файлы
/usr/include/rpcsvc/* из glibc-devel < 2.32 теперь можно найти в пакете
rpcsvc-proto-devel, а /usr/bin/rpcgen, который был в glibc-utils < 2.32,
теперь можно найти в пакете rpcgen.

Напоминаю список пакетов:
MySQL-8.0.22-alt1	rider mike shaba nickel
autofs-5.1.6-alt1	sbolshakov @everybody
dsniff-2.4-alt0.13.b1	vseleznv ldv
glusterfs7-7.8-alt3	lav @everybody
glusterfs8-8.2-alt3	lav @everybody
libdb4.7-4.7.25-alt9	ldv
librpcsecgss-0.19-alt1.qa1_10	viy @everybody
libvirt-6.10.0-alt1	shaba rider @everybody
libxview-3.2p1.4-alt11	viy @everybody
lmbench-3.0-alt3	antohami @everybody
ltspfs-0.3-alt4.20070117.qa1	@nobody
ltspfsd-0.3-alt0.2.2.qa1	@nobody
make-initrd-busybox-1.28.1-alt2	legion
octave-instrument-control-0.6.0-alt1	qa_viy @everybody
ogdi-3.2.0-alt1.beta2.2	oddity @everybody
openl2tp-1.8-alt7	sbolshakov @everybody
p3nfs-5.19-alt1.qa2	@nobody
perl-Quota-1.8.1-alt1	viy @everybody
python-2.7.18-alt2	vseleznv imz george cow glebfm
python3-3.8.6-alt1	grenka imz vitty george glebfm darktemplar
samba-4.12.10-alt2	sin @qa
trickle-1.07-alt4	naf @everybody
watchdog-5.13-alt1_18	oddity @qa
xinetd-2.3.15-alt4	ldv
Возможно, некоторым из этих пакетов поддержка rpc на самом деле не нужна.

Enjoy!


-- 
ldv

Re: [devel] I: rpcsvc-proto-devel + rpcgen

[Антон Мидюков]

19.12.2020 18:56, Dmitry V. Levin пишет:
> On Fri, Dec 18, 2020 at 06:38:47PM +0300, Gleb Fotengauer-Malinovskiy wrote:
> [...]
>> Также в связи с обновлением glibc сломалась сборка некоторых пакетов:
> [...]
>> * Remove configure option --enable-obsolete-rpc.  Sun RPC is removed
>>   from glibc.  This includes the rpcgen program, librpcsvc, and the Sun
>>   RPC header files.  Backward compatibility for old programs is kept
>>   only for architectures and ABIs that have been added in or before
>>   glibc 2.31.  New programs need to use TI-RPC
>>   <http://git.linux-nfs.org/?p=steved/libtirpc.git;a=summary> and
>>   rpcsvc-proto <https://github.com/thkukuk/rpcsvc-proto>.
> 
> В Сизиф собран вышеупомянутый rpcsvc-proto, соответственно, файлы
> /usr/include/rpcsvc/* из glibc-devel < 2.32 теперь можно найти в пакете
> rpcsvc-proto-devel, а /usr/bin/rpcgen, который был в glibc-utils < 2.32,
> теперь можно найти в пакете rpcgen.
> 
> Напоминаю список пакетов:
...
> lmbench-3.0-alt3	antohami @everybody

Не собирается из-за отсутствия rpc/rpc.h
И где его брать?


-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel] I: rpcsvc-proto-devel + rpcgen

[Dmitry V. Levin]

On Sun, Dec 20, 2020 at 09:26:07PM +0700, Антон Мидюков wrote:
> 19.12.2020 18:56, Dmitry V. Levin пишет:
> > On Fri, Dec 18, 2020 at 06:38:47PM +0300, Gleb Fotengauer-Malinovskiy wrote:
> > [...]
> >> Также в связи с обновлением glibc сломалась сборка некоторых пакетов:
> > [...]
> >> * Remove configure option --enable-obsolete-rpc.  Sun RPC is removed
> >>   from glibc.  This includes the rpcgen program, librpcsvc, and the Sun
> >>   RPC header files.  Backward compatibility for old programs is kept
> >>   only for architectures and ABIs that have been added in or before
> >>   glibc 2.31.  New programs need to use TI-RPC
> >>   <http://git.linux-nfs.org/?p=steved/libtirpc.git;a=summary> and
> >>   rpcsvc-proto <https://github.com/thkukuk/rpcsvc-proto>.
> > 
> > В Сизиф собран вышеупомянутый rpcsvc-proto, соответственно, файлы
> > /usr/include/rpcsvc/* из glibc-devel < 2.32 теперь можно найти в пакете
> > rpcsvc-proto-devel, а /usr/bin/rpcgen, который был в glibc-utils < 2.32,
> > теперь можно найти в пакете rpcgen.
> > 
> > Напоминаю список пакетов:
> ...
> > lmbench-3.0-alt3	antohami @everybody
> 
> Не собирается из-за отсутствия rpc/rpc.h
> И где его брать?

Он уже давно переехал в libtirpc-devel.


-- 
ldv

Re: [devel] I: glibc 2.32 && sisyphus snapshot publication skip

[Alexey Tourbin]

On Fri, Dec 18, 2020 at 6:46 PM Gleb Fotengauer-Malinovskiy
<glebfm@altlinux.org> wrote:
> В связи с этим обновлением glibc пришлось отключить публикацию
> сегодняшнего снапшота репозитория sisyphus.  Это связано с тем, что версия
> openssh, которая была в этом снапшоте имела seccomp-фильтр, который
> запрещает использование некоторых системных вызовов, которые используются
> в функциях glibc, которые вызывает sshd.  Т.е. после обновления glibc без
> обновления seccomp-фильтра sshd стал бы нерабочим.

А как удалось понять, что sshd становится нерабочим? Если бы при
сборке openssh выполнялся полноценный тест (запустить sshd на высоком
порту и попробовать к нему подключиться), то пакет перестал бы
пересобираться. Но что-то не видно, чтобы в openssh.spec выполнялись
какие-нибудь тесты.

Если при тестовой пересборке 'make check' перестает работать, то это
полезный индикатор, но это же не совсем то, что нужно. Нужно чтобы
проверка базовой работоспособности некоторых пакетов была встроена в
сборочную систему и работала на уровне транзакций/заданий.

Re: [devel] I: glibc 2.32 && sisyphus snapshot publication skip

[Dmitry V. Levin]

On Mon, Dec 21, 2020 at 05:33:24AM +0300, Alexey Tourbin wrote:
> On Fri, Dec 18, 2020 at 6:46 PM Gleb Fotengauer-Malinovskiy
> <glebfm@altlinux.org> wrote:
> > В связи с этим обновлением glibc пришлось отключить публикацию
> > сегодняшнего снапшота репозитория sisyphus.  Это связано с тем, что версия
> > openssh, которая была в этом снапшоте имела seccomp-фильтр, который
> > запрещает использование некоторых системных вызовов, которые используются
> > в функциях glibc, которые вызывает sshd.  Т.е. после обновления glibc без
> > обновления seccomp-фильтра sshd стал бы нерабочим.
> 
> А как удалось понять, что sshd становится нерабочим?

В результате тестирования.

> Если бы при
> сборке openssh выполнялся полноценный тест (запустить sshd на высоком
> порту и попробовать к нему подключиться), то пакет перестал бы
> пересобираться. Но что-то не видно, чтобы в openssh.spec выполнялись
> какие-нибудь тесты.

Для начала мы планируем доделать make check в openssh, там есть некоторые
заморочки с переносом тестов в qemu.

Далее есть выбор из двух вариантов:
- Запаковать openssh-checkinstall, а также glibc-checkinstall,
  openssl-checkinstall, и т.д., добавив в них зависимости
  на openssh-checkinstall.
- Пересобирать openssh при каждом значимом изменении пакетов (если
  меняется rpm identity), входящих в его сборочную среду, с публикацией
  результата пересборки, если он меняется значимым образом (если меняется
  rpm identity).


-- 
ldv

Re: [devel] I: glibc 2.32 && sisyphus snapshot publication skip

[Alexey Tourbin]

On Mon, Dec 21, 2020 at 2:34 PM Dmitry V. Levin <ldv@altlinux.org> wrote:
> > Если бы при
> > сборке openssh выполнялся полноценный тест (запустить sshd на высоком
> > порту и попробовать к нему подключиться), то пакет перестал бы
> > пересобираться. Но что-то не видно, чтобы в openssh.spec выполнялись
> > какие-нибудь тесты.
>
> Для начала мы планируем доделать make check в openssh, там есть некоторые
> заморочки с переносом тестов в qemu.
>
> Далее есть выбор из двух вариантов:
> - Запаковать openssh-checkinstall, а также glibc-checkinstall,
>   openssl-checkinstall, и т.д., добавив в них зависимости
>   на openssh-checkinstall.
> - Пересобирать openssh при каждом значимом изменении пакетов (если
>   меняется rpm identity), входящих в его сборочную среду, с публикацией
>   результата пересборки, если он меняется значимым образом (если меняется
>   rpm identity).

Второй вариант слишком радикальный. Он кагбе дезавуирует понятие
бинарной совместимости как подозрительное. Возможен даже более
радикальный вариант: намертво приклеиваться к версиям библиотек, от
которых зависит сборка (openssh-server будет требовать glibc-core =
%version-%release). Этим мы кагбе говорим: в такой комбинации точно
работало; будет ли работать в других комбинациях - бог весть, надо
пересобрать, чтобы убедиться. Конечно, с rpm такой трюк не пройдет,
потому что в системе может быть установлен только один glibc-core.
По-моему, Nix package manager реализует как раз такую идею: он клеет
намертво и умеет бесконфликтно устанавливать намертво приклеенные
библиотеки.

Я посмотрел, как устроены пакеты checkinstall. Немного странно, что
они складывают программы в /var и запускают их в %post. Но может так и
лучше (для запуска тестов не требуется entry point).

Как тогда это может работать? В репозитории есть несколько десятков
пакетов *-checkinstall. Для каждого из них сборочная система
поддерживает список пакетов в чруте. Отдельная стадия сборки задания -
вычисление списков для *-checkinstall. Следующая стадия - для тех
*-checkinstall пакетов, у которых меняется содержимое чрута,
выполняется дополнительный install test (устанавливается именно этот
foo-checkinstall пакет).

В общем, это дополнительная работа по поддержке checkinstall пакетов.
Они не обязательно должны полностью реплицировать 'make check': 'make
check' может выполняться долго, а foo-checkinstall желательно чтобы
устанавливался достаточно быстро.

Другое направление мысли - надо поднимать в чруте настоящий сервис
sshd.  На современных ядрах это можно делать без прав рута, через
kernel.unprivileged_userns_clone=1. Плюс в том, что этим проверяется
боевая конфигурация. Минус в том, что такие контейнеры разворачиваются
дольше, и готового минималистичного решения для этого скорее всего
нет. Еще одно направление мысли - надо тестировать обновление rpm -U,
а не установку rpm -i, и проверять, что sshd перезапустился, после
чего пробовать к нему подключиться.

* * *

А почему вообще в репозитории openssh старой версии - 7.9? В Федоре 33
версия 8.4.

Мужчина, вы не так давно писали, что у пакетов должен быть мейнтейнер,
а если мейнтейнера нету, то не надо такие суррогатные пакеты
направлять в основной репозиторий и т.п. Между тем, если бы робот
синхронизировал сборку openssh с Федорой, а в релисе у этой сборки был
знак подчеркивания, то дефекта с seccomp просто не возникло бы.

В ваших рассуждениях про мейнтейнеров есть bias: поскольку вы
стейкхолдер, то вы исходите из того, как должен быть устроен проект в
целом, какие у него цели и задачи, что суть правильно в отвлеченном
смысле и т.п.  К этому еще примешиваются конъюнктурные соображение:
дескать "мы же не дериватив", поэтому надо как-то сигналить городу и
миру, что мы автохтонная Русская ОС для ЭВМ и т.п.

Bias становится ясен, если принять более прагматичный взгляд конечно
пользователя. Многих пользователей Русской ОС заставляют ею
пользоваться, спуская ее сверху (в бюджетных организациях и т.п.). То
есть многие пользователи - не стейкхолдеры, им всё равно, как устроен
проект, есть ли у пакетов мейнтейнеры и т.п. Им только нужно, чтобы
всё работало - не хуже, чем в других дистрибутивах. Если в
дистрибутиве есть "импортозамещённые баги", то это ужасный bummer.
Если же баги такие как у всех, то bummer не такой ужасный.

Это приводит меня к мысли, что нужно активнее синхронизировать всю
пакетную базу с апстримом и с другими дистрибутивами. Если дистрибутив
отходит от типичного сочетания версий (openssh и glibc), то он берет
на себя дополнительные риски, и, хуже того, перекладывает их на
конечных пользователей.

Re: [devel] I: glibc 2.32 && sisyphus snapshot publication skip

[Vladimir D. Seleznev]

On Mon, Dec 21, 2020 at 04:41:52PM +0300, Alexey Tourbin wrote:
> On Mon, Dec 21, 2020 at 2:34 PM Dmitry V. Levin <ldv@altlinux.org> wrote:
> > > Если бы при
> > > сборке openssh выполнялся полноценный тест (запустить sshd на высоком
> > > порту и попробовать к нему подключиться), то пакет перестал бы
> > > пересобираться. Но что-то не видно, чтобы в openssh.spec выполнялись
> > > какие-нибудь тесты.
> >
> > Для начала мы планируем доделать make check в openssh, там есть некоторые
> > заморочки с переносом тестов в qemu.
> >
> > Далее есть выбор из двух вариантов:
> > - Запаковать openssh-checkinstall, а также glibc-checkinstall,
> >   openssl-checkinstall, и т.д., добавив в них зависимости
> >   на openssh-checkinstall.
> > - Пересобирать openssh при каждом значимом изменении пакетов (если
> >   меняется rpm identity), входящих в его сборочную среду, с публикацией
> >   результата пересборки, если он меняется значимым образом (если меняется
> >   rpm identity).
> 
> Второй вариант слишком радикальный. Он кагбе дезавуирует понятие
> бинарной совместимости как подозрительное. Возможен даже более
> радикальный вариант: намертво приклеиваться к версиям библиотек, от
> которых зависит сборка (openssh-server будет требовать glibc-core =
> %version-%release). Этим мы кагбе говорим: в такой комбинации точно
> работало; будет ли работать в других комбинациях - бог весть, надо
> пересобрать, чтобы убедиться.

Мне казалось, цель у этого иная, а предпосылки чуть ли не
противоположные: известно, что прежняя сборка OpenSSH работала, в то
время как после изменения rpmidentity -- неизвестно. И для раннего
обнаружения багов и поломок нужно пересобирать.

> [skip]
> А почему вообще в репозитории openssh старой версии - 7.9? В Федоре 33
> версия 8.4.

openssh 7.9 за всё это время не стала хуже.

> [skip]
> Им только нужно, чтобы всё работало - не хуже, чем в других
> дистрибутивах. Если в дистрибутиве есть "импортозамещённые баги", то
> это ужасный bummer.  Если же баги такие как у всех, то bummer не такой
> ужасный.

А в openssh 7.9 есть известные баги?

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] I: glibc 2.32 && sisyphus snapshot publication skip

[Dmitry V. Levin]

On Mon, Dec 21, 2020 at 04:41:52PM +0300, Alexey Tourbin wrote:
> On Mon, Dec 21, 2020 at 2:34 PM Dmitry V. Levin wrote:
> > > Если бы при
> > > сборке openssh выполнялся полноценный тест (запустить sshd на высоком
> > > порту и попробовать к нему подключиться), то пакет перестал бы
> > > пересобираться. Но что-то не видно, чтобы в openssh.spec выполнялись
> > > какие-нибудь тесты.
> >
> > Для начала мы планируем доделать make check в openssh, там есть некоторые
> > заморочки с переносом тестов в qemu.
> >
> > Далее есть выбор из двух вариантов:
> > - Запаковать openssh-checkinstall, а также glibc-checkinstall,
> >   openssl-checkinstall, и т.д., добавив в них зависимости
> >   на openssh-checkinstall.
> > - Пересобирать openssh при каждом значимом изменении пакетов (если
> >   меняется rpm identity), входящих в его сборочную среду, с публикацией
> >   результата пересборки, если он меняется значимым образом (если меняется
> >   rpm identity).
> 
> Второй вариант слишком радикальный. Он кагбе дезавуирует понятие
> бинарной совместимости как подозрительное.

Если нам заранее известно, что пакет использует seccomp filter, то мы
заранее знаем, что понятие бинарной совместимости для него не применимо
в том объёме, в котором оно применимо к пакетам, которые не используют
seccomp filter.

Поэтому да, такие пакеты нужно тестировать заново при каждом значимом
изменении их установочной среды, в которую, между прочим, входит и ядро.


-- 
ldv

Re: [devel] I: glibc 2.32 && sisyphus snapshot publication skip

[Anton V. Boyarshinov]

В Mon, 21 Dec 2020 17:19:42 +0300
"Dmitry V. Levin" <ldv@altlinux.org> пишет:

> Поэтому да, такие пакеты нужно тестировать заново при каждом значимом
> изменении их установочной среды, в которую, между прочим, входит и ядро.
> 

Которых у нас одновременно несколько, разных версий и с разными
конфигурациями :(

Re: [devel] I: glibc 2.32 && sisyphus snapshot publication skip

[Anton Farygin]

On 21.12.2020 14:34, Dmitry V. Levin wrote:
> On Mon, Dec 21, 2020 at 05:33:24AM +0300, Alexey Tourbin wrote:
>> On Fri, Dec 18, 2020 at 6:46 PM Gleb Fotengauer-Malinovskiy
>> <glebfm@altlinux.org> wrote:
>>> В связи с этим обновлением glibc пришлось отключить публикацию
>>> сегодняшнего снапшота репозитория sisyphus.  Это связано с тем, что версия
>>> openssh, которая была в этом снапшоте имела seccomp-фильтр, который
>>> запрещает использование некоторых системных вызовов, которые используются
>>> в функциях glibc, которые вызывает sshd.  Т.е. после обновления glibc без
>>> обновления seccomp-фильтра sshd стал бы нерабочим.
>> А как удалось понять, что sshd становится нерабочим?
> В результате тестирования.

Так даже в результате тестирования ошибки такого рода исправляются 
далеко не сразу. Вот хороший пример этой длинной истории, когда не 
работало у всех (кто жаловался) кроме ментейнера:
https://bugzilla.altlinux.org/show_bug.cgi?id=27752

Re: [devel] I: glibc 2.32 && sisyphus snapshot publication skip

[Pavel Nakonechnyi]

On Tue, 22 Dec 2020 at 09:05, Sergei Epiphanov <serpiph@gmail.com> wrote:
>
> Также отвалился пакет cifs-utils, идёт ругань "Unable to apply capability set", в сети кивают на libcap-0.8.2 (мол, 0.8 такой проблемы не даёт).
>

Это другая проблема, появилась в начале декабря, я писал об этом в
telegram канале, какой патч приложить тоже давал ссылку.


--
 WBR, Pavel

Re: [devel] I: glibc 2.32 && sisyphus snapshot publication skip

[Anton Farygin]

On 22.12.2020 11:52, Pavel Nakonechnyi wrote:
> On Tue, 22 Dec 2020 at 09:05, Sergei Epiphanov <serpiph@gmail.com> wrote:
>> Также отвалился пакет cifs-utils, идёт ругань "Unable to apply capability set", в сети кивают на libcap-0.8.2 (мол, 0.8 такой проблемы не даёт).
>>
> Это другая проблема, появилась в начале декабря, я писал об этом в
> telegram канале, какой патч приложить тоже давал ссылку.
>
>
Патчи всё-таки лучше фиксировать в bugzilla, как и ошибки.

Если это было нужно сделать в libcap, то отправьте изменение, пожалуйста.

Re: [devel] libcap-ng

[Dmitry V. Levin]

On Tue, Dec 22, 2020 at 12:10:43PM +0300, Anton Farygin wrote:
> On 22.12.2020 11:52, Pavel Nakonechnyi wrote:
> > On Tue, 22 Dec 2020 at 09:05, Sergei Epiphanov <serpiph@gmail.com> wrote:
> >> Также отвалился пакет cifs-utils, идёт ругань "Unable to apply capability set", в сети кивают на libcap-0.8.2 (мол, 0.8 такой проблемы не даёт).
> >>
> > Это другая проблема, появилась в начале декабря, я писал об этом в
> > telegram канале, какой патч приложить тоже давал ссылку.
> >
> Патчи всё-таки лучше фиксировать в bugzilla, как и ошибки.
> 
> Если это было нужно сделать в libcap, то отправьте изменение, пожалуйста.

Судя по нумерации 0.8.2, речь идёт о libcap-ng, а не о libcap.


-- 
ldv

Re: [devel] I: glibc 2.32 && sisyphus snapshot publication skip

[Yuri Sedunov]

В Вт, 22/12/2020 в 12:10 +0300, Anton Farygin пишет:
> 
> Патчи всё-таки лучше фиксировать в bugzilla, как и ошибки.
> 
> Если это было нужно сделать в libcap, то отправьте изменение,
> пожалуйста.

Проблема появилась в этой libcap-ng:

* Mon Nov 23 2020 Anton Farygin <rider@altlinux.ru> 0.8.1-alt1
- 0.8.1

С ней отвалился gnome-keyring. Благо, апстрим уже к тому времени
выпустил исправление.

commit ebc7bc9efacc17049e54da8d96a4a29943621113
Author: Steve Grubb <sgrubb@redhat.com>
Date:   Fri Nov 20 11:52:14 2020 -0500

    Update libcap-ng capability handling
    
There is a change in libcap-ng-0.8.1 that causes gnome-keyring to not
work correctly. The capng_apply function now returns an error if it
cannot change the bounding set. Previously this was ignored. Which
means now gnome-keyring exits when it shouldn't.
    
The new patch adds troubleshooting info to the error messages. And it
checks to see if we have CAP_SETPCAP. If we do not, then we cannot
change the bounding set and just set capabilities. On the setuid side,
it now drops the bounding set and clears any supplemental groups that
may be left over as an accident.


-- 
Yuri N. Sedunov

Re: [devel] I: glibc 2.32 && sisyphus snapshot publication skip

[Anton Farygin]

On 22.12.2020 12:50, Sergei Epiphanov wrote:
>
> Yuri Sedunov <aris@altlinux.org> 22 декабря 2020 г. 12:41:53 написал:
>
>> В Вт, 22/12/2020 в 12:10 +0300, Anton Farygin пишет:
>>>
>>> Патчи всё-таки лучше фиксировать в bugzilla, как и ошибки.
>>>
>>> Если это было нужно сделать в libcap, то отправьте изменение,
>>> пожалуйста.
>>
>> Проблема появилась в этой libcap-ng:
>>
>> * Mon Nov 23 2020 Anton Farygin <rider@altlinux.ru> 0.8.1-alt1
>> - 0.8.1
>>
>> С ней отвалился gnome-keyring. Благо, апстрим уже к тому времени
>> выпустил исправление.
>>
>>
>
> У нас как раз эта версия.
>
сейчас отправлю 0.8.2