LINUX.ORG.RU

Безопасная загрузка и распространение апплетов

 , ,


0

2

Здравствуйте. Снова контекст разработки окружения рабочего стола. Имеется API для разработки кастомных апплетов. Соответственно, планируется также запустить магазин расширений, где будут представлены различные конфиги, темы и, в том числе, апплеты. Апплет у меня - просто динамически подключаемая *.so библиотека. Перечислю варианты, которые мне приходят в голову

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

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

  3. Распространяется только исходный код. Вроде вариант и неплох, но делать это единственным способом установки апплета - ну такое себе, мне кажется (хотя, поправьте, если не прав). По идее, это может усложнить установку апплета для обычного пользователя.

  4. Наконец, последнее, что приходит на ум, самому распространять только исходный код, но также давать названия пакетов в репозиториях официальных дистрибутивов. С одной стороны, оф репозитории - доверенный источник бинарников. С другой стороны, если нужного дистрибутива в списке нет, то можно собрать самому.

Естественно, что ручную модерацию я осуществлять буду перед публикацией, но хочу услышать ваше мнение по поводу всех этих вариантов


Апплет у меня - просто динамически подключаемая *.so библиотека.

Тут вполне читабельные скрипты лишний раз перечитывать приходится, а ты сразу с козырей зашёл.

bdrbt
()

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

shimshimshim
()
Последнее исправление: shimshimshim (всего исправлений: 1)

вариантов масса, вот пример с github который закроет большинство ваших вопросов:

  1. git checkout -b feat/feature1

  2. git commit …

  3. git push origin feat/feature1

  4. merge PR into master

  5. запускаются github workflow, которые запаковывают ваш в код в пакеты

  6. публикация артефактов к github релизу

gagarin0
()

1 не будет работать, потому что сумма не будет сходиться, для этого нужно в точности такое же сборочное окружение вплоть до версии компилятора и libc, во-вторых нужно требовать reproducible builds от разработчиков. reproducible builds работают для целиковых дистрибутивов, когда ты условные пакеты дебиана собираешь на дебиане X и я собираю на таком же дебиане X, и у нас чексуммы сойдутся. Для отдельных приложений которые собираются в любых дистрибутивах это не работает. Есть отдельные экосистемы которые не зависят от окружения, например rust или андроид, но это не твой кейс, как я понимаю. Можно поставлять окружение для сборки, но это усложнит жизнь разработчикам.

И вообще не факт что собранные сошки заработают в другом окружении с другой libc и с основным приложением которое возможно собрано другим компилятором, с другой libc/libc++ - обычная проблема распространения бинарников под линукс. А ведь у тебя наверняка не только linux x86_64 целевая платформа, твоим окружением можно пользоваться и под bsd, и под другими posix совместимыми системами, и не только x86, а ещё aarch64 и riscv. Никто под это всё ничего собирать не будет. Ты тоже. Потом, есть зависимости - наверняка будут апплеты которым нужны какие-то внешние библиотеки, как ты их собрался ставить?

Поэтому ответ как всегда один - забить на магазин, ориентироваться на штатные пакеты дистрибутивов. Да, их не будет пока их кто-то не сделает. Кому-то будет нужно - сделают, не сделают - значит не нужно.

Альтернативные варианты - писать апплеты на интерпретируемых языках типа питона или lua, тогда из можно распространять в виде архива с исходником и ассетами, и это будет работать везде.

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

Поэтому только системные пакеты или интерпретируемые языки.

anonymous
()
Ответ на: комментарий от anonymous

ориентироваться на штатные пакеты дистрибутивов

но это же не мешает реализовать вариант #4. распространять только исходный код + давать ссылки на пакеты в оф репозиториях

интерпретируемые языки

Lua - это хорошо, но мне кажется, что работу с Xlib, D-Bus и все в таком духе будет достаточно сложно реализовать в Lua

понял, тогда остановлюсь на последнем варианте

thm
() автор топика
Последнее исправление: thm (всего исправлений: 1)
Ответ на: комментарий от thm

но это же не мешает реализовать вариант #4. распространять только исходный код + давать ссылки на пакеты в оф репозиториях

Я не понял что значит «распространять исходный код». Доступ к репозиториям в любом случае есть, или допускалась мысль распространять только блобы? Что ты собрался распространять в контексте «магазина» не представляю. Страничка с описанием, красивыми скриншотами, 5 звёздами, и вместо кнопки install «сходите на github.com/… и соберите сами»?

Lua - это хорошо, но мне кажется, что работу с Xlib, D-Bus и все в таком духе будет достаточно сложно реализовать в Lua

В Lua святятся более высокоуровневые API, естественно.

anonymous
()
Ответ на: комментарий от anonymous

Я не понял что значит «распространять исходный код»

давать ссылку на репозиторий с кодом

допускалась мысль распространять только блобы

нет, конечно

вместо кнопки install «сходите на github.com/… и соберите сами»?

ссылки на пакеты в оф репозиториях самых major и popular дистрибутивов + сходите на github.com и соберите сами, если нужного дистрибутива в списке нет

В Lua святятся более высокоуровневые API, естественно.

подумаю в сторону Lua тогда. конечно же, хочется сделать удобную страничку с кнопкой install :)

thm
() автор топика
Последнее исправление: thm (всего исправлений: 1)
Ответ на: комментарий от thm

ссылки на пакеты в оф репозиториях самых major и popular дистрибутивов + сходите на github.com и соберите сами, если нужного дистрибутива в списке нет

Ну так себе UX для громкого слова «магазин», конечно. Но типа реестр официально поддерживаемых дополнений - наверное норм.

anonymous
()