LINUX.ORG.RU
Ответ на: комментарий от WatchCat

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

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

обычное дело и замечательно работает.

Да. Хороший пример в этом плане пакеты из pypi.org, которые предполагалось ставить через pip, но в gentoo нормально и лучше ставить через emerge.

grem ★★★★★
()
Ответ на: комментарий от slovazap

ибо опакечивание модулей в репозиториях

Причём тут опакечивание, если вопрос в изменении кода программ? Да, для некоторых пакетов, которые важны для системы в целом или являются очень популярными, мантейнеры могут сделать изменения и отправить пулреквест разработчику. Могут даже сами тянуть свою ветку и заниматься его патченьем. Но это не для всех и не всегда. А если твой пакет не в офицальной репе, то каким волшебным образом «экосистема» исправит зависимости?

Так что прекращай рассказывать сказки о молочных реках и кисельных берегах.

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

Причём тут опакечивание, если вопрос в изменении кода программ? Да, для некоторых пакетов, которые важны для системы в целом или являются очень популярными, мантейнеры могут сделать изменения и отправить пулреквест разработчику. Могут даже сами тянуть свою ветку и заниматься его патченьем. Но это не для всех и не всегда. А если твой пакет не в офицальной репе, то каким волшебным образом «экосистема» исправит зависимости?

При чём тут пулл реквесты, какие нахрен ветки? Обсуждаемая ситуация: есть A, B и C которые зависят от D. Пусть у D две версии API. A зависит от 0.*, B от 1.*, C от *. В D находят критическую уязвимость, исправляют в последней версии.

Что происходит в ублюдской экосистеме, предлагаемой нам pip, npm, cargo, go get и компанией? Два варианта:

  • в A, B, C зафризены определённые коммиты зависимости. При установке ничего не конфликтует, нам прилетают 3 версии D, возможно все уязвимые. Чтобы их исправить, нужно сначала найти все проекты что их используют, узнать уязвим ли каждый зафризенный коммит и пропатчить заново в каждом случае.
  • Коммиты не зафризены. Нам прилетает N версий D, причем при каждой сборке может прилететь новая. Для A всегда прилетает уязвимая версия. Для остальных возможно исправленная, если их вовремя пересобрать. Узнать с каким конкретно коммитом D собран каждый конкретный потребитель может быть проблематично. Исправлять руками нужно каждого потребителя использующего непоследнюю мажорную ветку зависимости. C может ещё и сломаться в любой момент.

Что происходит в нормальной экосистеме нативных пакетов? Мантейнер D видит обновление, проверяет работу A, B, C с ним. В лучшем случае всё продолжает работать, потому что изменение API не затронуло A (обычная, вообще, ситуация, учитывая как легко сломать API и как мало оно сломает практике). Копия D одна, патчить ничего не нужно. Фикс уязвимости в D мгновенно прорастает во всех потребителей. Лепота. Менее общий случай - A таки ломается, но тривиально патчится. То же самое, лепота. Плохой случай, A тривиально не пропатчить. Добавляется compat версия пакета D, в ней впоследствии ОДИН раз исправляется уязвимость. Нужно следить за ещё одной версией D, но и только. Сколько бы не было потребителей, они не ломаются и не подвержены уязвимостям.

Так что прекращай рассказывать сказки о молочных реках и кисельных берегах.

Ещё раз, ты будешь спорить с тысячами опакеченных и замечательно работающих в любом уважающем себя репозитории модулей? Питон, например, в arch/aur 6k, nix, freebsd, opensuse, fedora - 3k, gentoo 2.5k, debian 2k, macports 1.5k, pkgsrc, rosa, mageia, guix - 1k. Даже хипстерские rust и go, не смотря на хитровыгнутые собственные пакетные менеджеры, вообще никак не приспособленные для опакечивания в системе, в fedora и ubuntu опакечены уже по 1-1.5k штук.

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

При чём тут пулл реквесты, какие нахрен ветки?

В D находят критическую уязвимость, исправляют в последней версии.

Ты вообще чем читаешь о чём я тебе пишу, жопой? Речь идёт о смене API. Уязвимость патчится без изменения API, как правило. И не ломает совместимость. Я тебе говорю о случае когда ломается обратная совместимость, привет openssl. И там был не «Фикс уязвимости в D», а исправление всех зависимых пакетов.

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

Я спорю с тобой, для которого «деньги из тумбочки».

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

Ты вообще чем читаешь о чём я тебе пишу, жопой?

Это прежде всего к тебе вопрос.

Речь идёт о смене API.

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

Уязвимость патчится

А про уязвимость было в нагрузку - про то что в ублюдочной инфрастуктуре ещё и патчить дыры не представляется возможным, потому что сложность исправление дыры в модуле там - O(количества потребителей), а в нормальных пакетах - O(количества актуальных мажорных версий модуля в репозитории).

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

slovazap ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.