From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 27 Apr 2020 14:55:43 +0300 From: "Dmitry V. Levin" To: ALT Devel discussion list Message-ID: <20200427115542.GA28775@altlinux.org> References: <20200417235446.GB31146@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [devel] =?koi8-r?b?X19saWJjX2VuYWJsZV9zZWN1cmUg1yBvcGVuc3NsIGxp?= =?koi8-r?b?YmNyeXB0bw==?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2020 11:55:43 -0000 Archived-At: List-Archive: List-Post: On Mon, Apr 27, 2020 at 11:30:47AM +0300, Mikhail Novosyolov wrote: > 18.04.2020 02:54, Dmitry V. Levin пишет: > > On Sat, Apr 18, 2020 at 02:21:43AM +0300, Mikhail Novosyolov wrote: > >> Попробовал собрать AppImage на основе библиотек из Альта. AppImage - это такая штука, где сбандлены необходимые для работы программы библиотеки, но libc используется системная, что позволяет и программу запускать в разных дистрибутивах, и системные плагины NSS использовать. Для этой цели собрал в сизиф пакет linuxdeployqt. > >> > >> Оказалось, что libcrypto.so.10 (я делал на основе p8, то же самое будет относиться и к сизифу) использует внутренний в glibc интерфейс __libc_enable_secure, который не выведен наружу в других дистрибутивах. > > Всё-таки __libc_enable_secure выведен у всех, потому что этот символ > > определён в ld, а используется ещё и в libc. Но у нас этот символ > > версионирован не как у всех в GLIBC_PRIVATE, а в baseline version, что, > > наверное, было не совсем правильно сделано, лучше было бы выделить для > > этого отдельную версию, но потом уже поздно было это менять. > > > > У нас в libc есть ещё несколько символов, которые широко используются > > нашими пакетами, но которых пока нет в других libc: > > __strlcat_chk > > __strlcpy_chk > > strlcat > > strlcpy > > > >> Это сделано патчем openssl-owl-alt-issetugid.patch: > >>> --- openssl/crypto/uid.c > >>> +++ openssl/crypto/uid.c > >>> @@ -77,8 +77,12 @@ int OPENSSL_issetugid(void) > >>>  # include OPENSSL_UNISTD > >>>  # include > >>>   > >>> +extern int __libc_enable_secure; > >>> + > >>>  int OPENSSL_issetugid(void) > >>>  { > >>> +    if (__libc_enable_secure) > >>> +        return 1; > >>>      if (getuid() != geteuid()) > >>>          return 1; > >>>      if (getgid() != getegid()) > >> В связи с этим возник вопрос: в Альте glibc запатчен, чтобы вывести эту внутреннюю функцию? > > Да, коммит 730399f767758a200256d7eb20f74d2310ab973b. > > > >> Используется ли она в каких-либо еще внешних потребителях? > > Как минимум ещё в libtinfo. > > У меня получилось собрать работающую на других дистрибутивах AppImage-подобную структуру на основе библиотек из p8, в т.ч. Qt5 оттуда, путем сборки openssl без патча openssl-owl-alt-issetugid.patch. Но наличие таких нюансов стало неприятной неожиданностью, и вот почему. > > Начнем с "обычных" пользователей. Среди них достаточно востребовано иметь возможность запускать AppImage и другие сторонние бинарные сборки в целях упрощения жизни и решения повседневных задач. Но вроде бы они особо не страдают и могут их запускать (ну, кроме заблокированного из коробки fuse, что мешает запустить AppImage, но, с точки зрения администратора корпоративных рабочих станций, мне такая блокировка из коробки скорее нравится, чем не нравится). > > Больше всего интересует вопрос отечественной блобятинки, т.е. различных программных изделий, выпускаемых и используемых в рамках импортозамещения. Большинство их разработчиков не очень хорошо умеют упаковывать программы под Линукс, как с точки зрения сборки исполняемых файлов, так и с точки зрения создания RPM-пакетов или иных форм дистрибуции. В результате некоторые из них поддерживают только 1-2 отечественных дистрибутива, теряя часть пользователей, некоторые пытаются собирать по пакету под каждый дистрибутив, тратя на это огромное количество ресурсов. Это плохо и для разработчиков ПО, и для разработчиков дистрибутивов, которые вынуждены иметь с ним дело. Единственным выходом из ситуации я вижу попытки рекомендовать разработчикам собирать универсальные исполняемые файлы или пакеты с грамотно сбандленными библиотеками и грамотно прописанные зависимости в RPM, например, не libgnomekeyring, a libgnome-keyring.so.0()(64bit). Была мысль, что многим будет гораздо проще не > изобретать сложную систему сборки с частичной статической линковкой, а собирать с системными библиотеками в какой-нибудь ОС, а затем упаковывать AppImage, это очень просто. AppImage-подобную структуру можно положить в RPM-пакет, зная про AutoReq, AutoProv и др. И вот здесь встает вопрос, насколько помешают такие фокусы. Соберут в Альте - не заработает в других дистрибутивах. Тот же openssl настолько часто используется и однозначно будет сбандливаться, что Альт можно сразу не рекомендовать для сборки AppImage-подобных пакетов. А вот если собрать ПО на другом дистрибутиве, то есть небольшая вероятность возникновения проблем в Альте. Думаю, что нужно сильно постараться, чтобы их поймать, т.к. внутренний API __libc_enable_secure заведомо не стоит использовать, но, может быть, есть другие подобные нюансы. Вы помните такой проект LSB, и чем он фактически закончился? -- ldv