Bug 48465

А что, если генерировать flatpak-пакеты, а не rpm?
Так уже какая-никакая изоляция будет.

Ещё один момент. Например, chrome он давно не обновляет(в т.ч. в p10), из-за чего там уже много незакрытых уязвимостей. С остальным play может быть то же самое.

(Ответ для Sergey V Turchin на комментарий #2)
> Ещё один момент. Например, chrome он давно не обновляет(в т.ч. в p10), из-за
> чего там уже много незакрытых уязвимостей. С остальным play может быть то же
> самое.

Давайте без предположений, пожалуйста. 
Виталий, что там с chrome?

(Ответ для Sergey V Turchin на комментарий #2)
> Ещё один момент. Например, chrome он давно не обновляет(в т.ч. в p10), из-за
> чего там уже много незакрытых уязвимостей. С остальным play может быть то же
> самое.

Давайте без предположений, пожалуйста. 
Виталий, что там с chrome? (Ответ для Sergey V Turchin на комментарий #1)
> А что, если генерировать flatpak-пакеты, а не rpm?
> Так уже какая-никакая изоляция будет.

Это хорошая задача. 
На неё нужны люди.

(Ответ для AEN на комментарий #4)
> (Ответ для Sergey V Turchin на комментарий #2)
> > Ещё один момент. Например, chrome он давно не обновляет(в т.ч. в p10), из-за
> > чего там уже много незакрытых уязвимостей. С остальным play может быть то же
> > самое.
> Давайте без предположений, пожалуйста. 
Ок, без предположений.
С остальным всем play то же самое. Версии, до которых надо обновлять, указаны вручную и не обновляются.
Вот для того пакета, который в p10 https://eepm.ru/releases/3.57.6/app-versions/

(Ответ для Sergey V Turchin на комментарий #5)
> (Ответ для AEN на комментарий #4)
> > (Ответ для Sergey V Turchin на комментарий #2)
> > > Ещё один момент. Например, chrome он давно не обновляет(в т.ч. в p10), из-за
> > > чего там уже много незакрытых уязвимостей. С остальным play может быть то же
> > > самое.
> > Давайте без предположений, пожалуйста. 
> Ок, без предположений.
> С остальным всем play то же самое. Версии, до которых надо обновлять,
> указаны вручную и не обновляются.
> Вот для того пакета, который в p10
> https://eepm.ru/releases/3.57.6/app-versions/

Если версию в p10 нельзя обновлять, то что в этом удивительного?? 
Тем более, бага на Сизифе.
Хватит флейма, Сергей. Давайте подождём Виталия.

(Ответ для AEN на комментарий #6)
> (Ответ для Sergey V Turchin на комментарий #5)
> > (Ответ для AEN на комментарий #4)
> > > (Ответ для Sergey V Turchin на комментарий #2)
> > > > Ещё один момент. Например, chrome он давно не обновляет(в т.ч. в p10), из-за
> > > > чего там уже много незакрытых уязвимостей. С остальным play может быть то же
> > > > самое.
> > > Давайте без предположений, пожалуйста. 
> > Ок, без предположений.
> > С остальным всем play то же самое. Версии, до которых надо обновлять,
> > указаны вручную и не обновляются.
> > Вот для того пакета, который в p10
> > https://eepm.ru/releases/3.57.6/app-versions/
> Если версию в p10 нельзя обновлять, то что в этом удивительного?? 
Т.е. совсем не понимаете, о чём речь?
Версия забита в файле по ссылке, который программа качает и смотрит.

> Тем более, бага на Сизифе.
Вы ищите некие поводы? На Сизифе то же самое.

> Хватит флейма, Сергей.
Я предоставил аргументы в ответ на вашу же просьбу. Вам они чем-то не понравились?

> Давайте подождём Виталия.
Ждём уже больше недели, но я не против.

1. Пожалуйста, приведите пример из нескольких пакетов для  свежего обновления epm и Сизифе. 
2. Пожалуйста, сформулируйте свои предложения по совершенствованию epm. Чем Вы моглибы бы помочь? 

Извините, но я выхожу из обсуждения до получения ответов на 1 и 2.

(Ответ для AEN на комментарий #8)
> Чем Вы моглибы бы помочь? 
Могу помочь удалить вредоносный софт из репозитория. ;-)

Извините, но я выхожу из обсуждения, т.к. разговор односторонний.

Ok. 
Давайте вернемся к предложению Антона. 
Виталий, ждём Вас.

(Ответ для Sergey V Turchin на комментарий #1)
> А что, если генерировать flatpak-пакеты, а не rpm?
> Так уже какая-никакая изоляция будет.

Мне нравится.

(Ответ для manowar@altlinux.org на комментарий #11)
> (Ответ для Sergey V Turchin на комментарий #1)
> > А что, если генерировать flatpak-пакеты, а не rpm?
> > Так уже какая-никакая изоляция будет.
> 
> Мне нравится.

Мне это тоже нравится.
Но.
1. Надо изучить и внедрить технологию
2. Надо генерировать flatpak-пакет на лету, не сохраняя их в хранилище, так как именно такой способ, используемый epm, позволяет реализовать возможный лицензионный запрет на редистрибьюцию.

В связи с этим возникает вопрос о помощи Виталию в развитии важного, на мой взгляд, проекта.

По генерации flatpak задача уже есть:
https://bugzilla.altlinux.org/45924

Создание контрольных сумм для проверенных приложений уже реализовано.
Остаётся добавить проверку на клиентской стороне.

По поводу обновления chrome.
При выполнении epm play --update обновляются установленные приложения до проверенных с данной версией epm версий.
Если выполнить epm play chrome
то будет установлена самая последняя версия.

Тут вопрос только в том, что вышла заминка с регулярностью обновлений epm.

(Ответ для Sergey V Turchin на комментарий #5)
...
> С остальным всем play то же самое. Версии, до которых надо обновлять,
> указаны вручную и не обновляются.
> Вот для того пакета, который в p10
> https://eepm.ru/releases/3.57.6/app-versions/

Желательно не хотеть противоположного. Либо мы разрешаем устанавливать только проверенные версии, либо разрешаем устанавливать самые распоследние версии.
Версии, до которых надо обновлять, не «указаны вручную», а зафиксированы для проверенных версий приложений. Чтобы не было неожиданных проблем у пользователей.
Так что изначальная гипотеза, что epm play устанавливает в систему «без дополнительных проверок» не совсем состоятельна.

> Версия забита в файле по ссылке, который программа качает и смотрит.
Что в этом страшного?

После реализации проверки контрольных сумм посмотрим на лицензионные ограничения и будем двигаться в сторону репозитория со сконвертированными бинарниками, а также же в сторону репозитория для flatpak.

Виталий, спасибо. 
Ждем новостей.

(Ответ для Vitaly Lipatov на комментарий #13)
> Желательно не хотеть противоположного. Либо мы разрешаем устанавливать
> только проверенные версии, либо разрешаем устанавливать самые распоследние
> версии.
Да деле получается, то либо мы _устанавливаем_ нетестированную последнюю версию, _либо_ _обновляем_ на древнюю когда-то протестированную.

> Версии, до которых надо обновлять, не «указаны вручную», а зафиксированы для
> проверенных версий приложений. Чтобы не было неожиданных проблем у
> пользователей.
> Так что изначальная гипотеза, что epm play устанавливает в систему «без
> дополнительных проверок» не совсем состоятельна.
Я вижу лишь подтверждение, что epm play устанавливает в систему без каких-либо проверок вообще. Что вы там тестировали в своей личной песочнице не имеет отношения, т.к. вы не проверяли _абсолютно_ _недоверенный_ процесс установки у пользователя.

(Ответ для Vitaly Lipatov на комментарий #13)
> После реализации проверки контрольных сумм
Вангую, что в реальности это будет означать, что epm play _почти_ никогда не будет проверять эти самые контрольные суммы.

(Ответ для Sergey V Turchin на комментарий #15)
...
> Я вижу лишь подтверждение, что epm play устанавливает в систему без
> каких-либо проверок вообще
Устанавливается приложение, опубликованное разработчиком и доставленное по защищённому каналу связи (https).
Что именно вы предлагаете проверять?

(Ответ для Anton Farygin на комментарий #0)
> Нужно хотя бы проверять контрольные суммы
Против какой атаки это поможет? 
Контрольная сумма имеет смысл, если она получена для прошедшего проверку источника. От софта с вредоносом, опубликованного на сайте разработчика, она не защищает.

(Ответ для Vitaly Lipatov на комментарий #17)
> Устанавливается приложение, опубликованное разработчиком и доставленное по
> защищённому каналу связи (https).
Ага. Защищённому злоумышленником от проверки. :-D

(Ответ для Vitaly Lipatov на комментарий #17)
> > Нужно хотя бы проверять контрольные суммы
> Против какой атаки это поможет?
MITM.

> Контрольная сумма имеет смысл, если она получена для прошедшего проверку источника.
Да. У вас это реализовано? Если нет, то вы <сами догадаетесь, где>.

> От софта с вредоносом, опубликованного на сайте разработчика, она не защищает.
Если контрольная сумма из прошедшего проверку источника, то защищает.

(Ответ для Vitaly Lipatov на комментарий #17)
> Против какой атаки это поможет? 
Виталий! Предлагаю вам проконсультироваться со специалистом, который хоть немного разбирается в безопасности.

(Ответ для Sergey V Turchin на комментарий #20)
> (Ответ для Vitaly Lipatov на комментарий #17)
> > Против какой атаки это поможет? 
> Виталий! Предлагаю вам проконсультироваться со специалистом, который хоть
> немного разбирается в безопасности.

Сергей, было бы хорошо ответить на вопрос Виталия прежде, чем посылать его.

(Ответ для Sergey V Turchin на комментарий #19)
> (Ответ для Vitaly Lipatov на комментарий #17)
> > > Нужно хотя бы проверять контрольные суммы
> > Против какой атаки это поможет?
> MITM.
То есть вы предлагаете защититься от атаки, при которой в атакуемую систему будут внедрены сертификаты УЦ злоумышленника, а сам он встроится в канал связи и с поддельного сайта с поддельными SSL-сертификатами будет отдавать поддельный софт.
Такую атаку может осуществить только Минцифры, при наличии в системе пакета ca-certificates-digital.gov.ru

MITM для репозитория ещё проще, там сертификатов нет, одна только подпись метаданных репозитория. И мы просто верим, что ключ для подписи за прошедшие годы никуда не утёк.

(Ответ для Sergey V Turchin на комментарий #20)
> (Ответ для Vitaly Lipatov на комментарий #17)
> > Против какой атаки это поможет? 
> Виталий! Предлагаю вам проконсультироваться со специалистом, который хоть
> немного разбирается в безопасности.
Это я понимаю. Я не собирался с вами консультироваться, я просто хотел узнать, в чём собственно претензия.

Напомню остальным, что пользователь системы вообще без всяких проверок скачивает из интернета произвольные файлы и устанавливает их в систему, зачастую путём просто копирования файлов. И это не подвергается такой критике, как установка софта из проверенных ссылок, которую предлагает epm play.

(Ответ для AEN на комментарий #21)
> Сергей, было бы хорошо ответить на вопрос Виталия прежде, чем посылать его.
Я сначала ответил, потом послал к специалисту, а не просто "послал".

(Ответ для Vitaly Lipatov на комментарий #22)
> То есть вы предлагаете защититься от атаки, при которой в атакуемую систему
> будут внедрены сертификаты УЦ злоумышленника, а сам он встроится в канал
> связи и с поддельного сайта с поддельными SSL-сертификатами будет отдавать
> поддельный софт.
> Такую атаку может осуществить только Минцифры, при наличии в системе пакета
> ca-certificates-digital.gov.ru
Покажете код в том месте месте, где происходит проверка сертификата Минцифры.

(Ответ для Vitaly Lipatov на комментарий #17)
> доставленное по защищённому каналу связи (https).
Даже это обман.

(In reply to AEN from comment #21)
> (Ответ для Sergey V Turchin на комментарий #20)
> > (Ответ для Vitaly Lipatov на комментарий #17)
> > > Против какой атаки это поможет? 
> > Виталий! Предлагаю вам проконсультироваться со специалистом, который хоть
> > немного разбирается в безопасности.
> 
> Сергей, было бы хорошо ответить на вопрос Виталия прежде, чем посылать его.

Да там не на что отвечать - ошибка Виталия в самом сообщении - нет никакого смысла обсуждать базовые вещи.

Нет никаких проверок подлинности полученных бинарей как и подлинности сайтов, с которых получаются эти бинари.

(Ответ для Sergey V Turchin на комментарий #24)
> (Ответ для Vitaly Lipatov на комментарий #22)
> > То есть вы предлагаете защититься от атаки, при которой в атакуемую систему
> > будут внедрены сертификаты УЦ злоумышленника, а сам он встроится в канал
> > связи и с поддельного сайта с поддельными SSL-сертификатами будет отдавать
> > поддельный софт.
> > Такую атаку может осуществить только Минцифры, при наличии в системе пакета
> > ca-certificates-digital.gov.ru
> Покажете код в том месте месте, где происходит проверка сертификата Минцифры.

(Ответ для Sergey V Turchin на комментарий #25)
> (Ответ для Vitaly Lipatov на комментарий #17)
> > доставленное по защищённому каналу связи (https).
> Даже это обман.

$ epm play chrome
...
Installing The popular and trusted web browser by Google (Stable Channel) from the official site as google-chrome-stable  ...

Warning: Specifying the version is not supported by vendor. Downloading latest version ...

 $ epm install --repack https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
 $ eget --latest https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
 $ /usr/bin/wget --tries 1 --content-disposition https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
--2025-05-28 12:45:54--  https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb

Использование https предполагает, что сертификат сервера подписан УЦ, а передаваемые данные зашифрованы.

Где обман, покажите, пожалуйста.

(Ответ для Vitaly Lipatov на комментарий #27)
> > > доставленное по защищённому каналу связи (https).
> > Даже это обман.
> $ epm play chrome
Очковтирательство.
grep 'http:' /etc/eepm/play.d/*

Сергей, пожалуйста, выбирайте выражения.
Спасибо.

(In reply to Vitaly Lipatov from comment #27)
> Использование https предполагает, что сертификат сервера подписан УЦ, а
> передаваемые данные зашифрованы.

Какой-то сертификат подписан каким-то УЦ.
Важно убедиться как минимум что этот сертификат соотвесвует сайту, к которому идёт обращение, что бы исключить возможную MITM атаку.

Ну и всегда ли eepm идёт на сайт производителя, или бывают исключения ?

(Ответ для AEN на комментарий #29)
> Сергей, пожалуйста, выбирайте выражения.
Только это и делаю, т.к. ответы Виталия говорят либо о некомпетентности, либо о том, что я писал. Но, в некомпетентность не верю, поэтому о ней не писал.

(Ответ для Anton Farygin на комментарий #30)
> Важно убедиться как минимум что этот сертификат соотвесвует сайту, к
> которому идёт обращение, что бы исключить возможную MITM атаку.
И что он подписан доверенным удостоверяющим центром, т.к. подписать кто угодно может.

И никаких http:/ там быть не должно.

Резюмирую. Необходимо:
* Проверять, что сертификат соответствует сайту, с которого происходит загрузка.
* Проверять, что сертификат заверен доверенным удостоверяющим центром.
* Не должно быть никаких http:/ при скачивании(включая перенаправления).
* При каждом перенаправлении проверять всё вышеперечисленное.
Вроде всё на мой непрофессиональный взгляд. До этих пор что-либо говорить про "https" бессмысленно.

(Ответ для Sergey V Turchin на комментарий #28)
> (Ответ для Vitaly Lipatov на комментарий #27)
> > > > доставленное по защищённому каналу связи (https).
> > > Даже это обман.
> > $ epm play chrome
> Очковтирательство.
> grep 'http:' /etc/eepm/play.d/*

Итак, по вашему предложению из почти 300 устанавливаемых приложений мы получили вывод из 13 файлов:
$ grep 'http:' /etc/eepm/play.d/*
/etc/eepm/play.d/alivecolors.sh:        #a= rpm --import http://akvis.com/akvis.asc
/etc/eepm/play.d/alteroffice.sh:epm install "http://repo.alter-os.ru/testing/AlterOffice/v$BASEVER/linux/x64/$distr" --scripts
/etc/eepm/play.d/chrome-remote-desktop.sh:Go to http://remotedesktop.google.com/headless
/etc/eepm/play.d/epson-printer-utility.sh:URL="http://support.epson.net/linux/Printer/LSB_distribution_pages/en/utility.php"
/etc/eepm/play.d/freeplane.sh:URL="http://freeplane.sourceforge.net"
/etc/eepm/play.d/geogebra.sh:        #http://www.geogebra.net/linux/rpm/x86_64/geogebra-classic-6.0.666.0-202109211234.x86_64.rpm
/etc/eepm/play.d/libicu56.sh:    PKGURL="http://ftp.basealt.ru/pub/distributions/archive/p8/date/2018/01/04/x86_64/RPMS.classic/libicu56-5.6.1-alt1.1.x86_64.rpm"
/etc/eepm/play.d/mssql-server.sh:DEBREPO="deb http://ftp.ru.debian.org/debian/ stretch main"
/etc/eepm/play.d/okular-csp.sh:REPOURL="http://packages.lab50.net"
/etc/eepm/play.d/okular-csp.sh:# http://packages.lab50.net/okular/install
/etc/eepm/play.d/spotify.sh:PKGURL="http://repository.spotify.com/pool/non-free/s/spotify-client/$(epm print constructname $PKGNAME "$VERSION*" amd64 deb)"
/etc/eepm/play.d/svp4.sh:PKGURL="http://www.svp-team.com/files/svp4-latest.php?linux"
/etc/eepm/play.d/sweethome3d.sh:#PKGURL="http://download.sourceforge.net/project/sweethome3d/SweetHome3D/SweetHome3D-$VERSION/SweetHome3D-$VERSION-linux-$arch.tgz"
/etc/eepm/play.d/sweethome3d.sh:# http://sourceforge.net/projects/sweethome3d/files/SweetHome3D/SweetHome3D-7.1/SweetHome3D-7.1-linux-x86.tgz/download
/etc/eepm/play.d/xerox-spl-driver.sh:PKGURL="http://download.support.xerox.com/pub/drivers/B215/drivers/linux/ar/Xerox_B215_Linux_PrintDriver_Utilities.tar.gz"


Из которых 4 являлись комментариями в коде,

2 ссылками на apt-репозиторий, потому что там захотели разработчики софта и потому что в Альт проблемы с использованием https для репозиториев:
/etc/eepm/play.d/alteroffice.sh:epm install "http://repo.alter-os.ru/testing/AlterOffice/v$BASEVER/linux/x64/$distr" --scripts
/etc/eepm/play.d/okular-csp.sh:REPOURL="http://packages.lab50.net"

2 ссылки на сайт проекта:
/etc/eepm/play.d/freeplane.sh:URL="http://freeplane.sourceforge.net"
/etc/eepm/play.d/epson-printer-utility.sh:URL="http://support.epson.net/linux/Printer/LSB_distribution_pages/en/utility.php"

1 ссылка на репозиторий Debian:
/etc/eepm/play.d/mssql-server.sh:DEBREPO="deb http://ftp.ru.debian.org/debian/ stretch main"


И остаётся 4 ссылки для скачивания:
1.
/etc/eepm/play.d/libicu56.sh:    PKGURL="http://ftp.basealt.ru/pub/distributions/archive/p8/date/2018/01/04/x86_64/RPMS.classic/libicu56-5.6.1-alt1.1.x86_64.rpm"
она такая, потому что некоторое время назад https на ftp.basealt.ru не работал:
https://bugzilla.altlinux.org/show_bug.cgi?id=46508#c1

2,3,4: эти ссылки на данный момент можно перевести на https, что незамедлительно и делаем.
/etc/eepm/play.d/spotify.sh:PKGURL="http://repository.spotify.com/pool/non-free/s/spotify-client/$(epm print constructname $PKGNAME "$VERSION*" amd64 deb)"
/etc/eepm/play.d/svp4.sh:PKGURL="http://www.svp-team.com/files/svp4-latest.php?linux"
/etc/eepm/play.d/xerox-spl-driver.sh:PKGURL="http://download.support.xerox.com/pub/drivers/B215/drivers/linux/ar/Xerox_B215_Linux_PrintDriver_Utilities.tar.gz"


Таким образом, очковтирательство заключалось в 1% приложений, которые по каким-то обстоятельствам загружались не по https.
На мой взгляд, это неадекватная оценка.

Так что все громкие слова про обман и очковтирательство это просто для хайпа.

(Ответ для Anton Farygin на комментарий #30)
> (In reply to Vitaly Lipatov from comment #27)
> > Использование https предполагает, что сертификат сервера подписан УЦ, а
> > передаваемые данные зашифрованы.
> 
> Какой-то сертификат подписан каким-то УЦ.
> Важно убедиться как минимум что этот сертификат соотвесвует сайту, к
> которому идёт обращение, что бы исключить возможную MITM атаку.
Есть такая программа, называется curl.
Она как раз выполняет все необходимые проверки, используя библиотеку gnutls. В том числе, то, что сайт отвечает сертификатом того домена, который мы запрашивали, и сертификат сайта подписан сертификатом УЦ, установленным в системе.

Можно почитать howto по использованию этой команды:
https://linuxtect.com/how-to-use-curl-command-with-https/

Программа наподобие curl, под названием wget, обычно используется в epm для скачивания файлов. Таким образом, все проверки выполняются.

Я останусь при своём мнении - в подобном приложении очень важно проверять контрольные суммы загружаемых приложений.

А ещё вы почему-то решили что основная проблема в том, что он скачивает без проверки контрольной суммы. Нет, основная проблема в том, что он захламляет систему пакетами из неизвестных источников.

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

(Ответ для Vitaly Lipatov на комментарий #35)
> можно перевести на https
Не упоминайте больше https, пожалуйста, т.к. до выполнения comment#34 это будет только для хайпа и только для неосведомлённых пользователей.

> Так что все громкие слова про обман и очковтирательство
Извиняюсь, ошибся. Дело явно в компетенции.

(Ответ для Anton Farygin на комментарий #37)
> Я останусь при своём мнении - в подобном приложении очень важно проверять
> контрольные суммы загружаемых приложений.
Согласен, это классика. Будем проверять.

Антон, ты не мог бы перевести для меня, что не так с curl при скачивании файлов по https?
Сергей пишет какими-то намёками:
"К сожалению, у него есть недопустимый изъян,"
"Не упоминайте больше https, пожалуйста, т.к. до выполнения comment#34 это будет только для хайпа и только для неосведомлённых пользователей."

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

(Ответ для Vitaly Lipatov на комментарий #40)
> Я бы рад его понять, но кроме обвинений в обмане и некомпетентности, ничего не вижу.
Я же перечислил всё в comment#34 . Что из этого не понятно?

(Ответ для Vitaly Lipatov на комментарий #35)
> Итак, по вашему предложению из почти 300 устанавливаемых приложений мы получили
Какое количество дыр достаточно, чтобы взломать систему?

(In reply to Vitaly Lipatov from comment #40)
> (Ответ для Anton Farygin на комментарий #37)
> > Я останусь при своём мнении - в подобном приложении очень важно проверять
> > контрольные суммы загружаемых приложений.
> Согласен, это классика. Будем проверять.
> 
> Антон, ты не мог бы перевести для меня, что не так с curl при скачивании
> файлов по https?

CURL в своей работе полагается на установленные в систему корневые сертификаты. 
С этим есть проблема - иногда пользователи и администраторы устанавливают в систему корневые сертификаты, которые в дальнейшем (в случае компрометации) позволяют провести  MITM атаку, а в случае с загрузкой и установкой приложений подобная атака чревата полной компрометацией системы.

Ну и помимо этого, поиск варивантов MITM атак на https соединение идёт непрерывно и иногда такой поиск приводит к положительным результатам. И если в браузере хотя бы будет заметен факт перехода на другой ресурс (редирект), то в случае eepm источник получения файла не проверяется - просто идёт доверие на то, что CURL пойдёт и скачает то, что его попросили, при этом отключается запрет на редиректы (что объяснимо)


Я повторю основную задачу - помимо проверки контрольной суммы загружаемого архива важно научиться ограничивать устанавливаемые приложения из неизвестных источников в правах.

(Ответ для Vitaly Lipatov на комментарий #36)
> Есть такая программа, называется curl.
А ещё есть такая программа, называется wget, которая у вас там используется.

(Ответ для Anton Farygin на комментарий #43)
> важно научиться ограничивать устанавливаемые приложения из
> неизвестных источников в правах.
Само собой. Одним https-ом сыт не будешь.

Наткнулся на ещё одну интересную особенность. Использование patchelf в epm play.
За это, ведь, пользователю должно прилететь, правильно?

Хотел предложить уточнить тему данной баги, но понял, что ваше поведение действительно опасно для пользователя.