Репозиторий Python-пакетов PyPI (Python Package Index) временно запретил регистрацию новых пользователей и создание новых проектов из-за непрекращающейся массовой загрузки вредоносных пакетов в ходе автоматизированной атаки. Блокировка была введена после того, как 26 и 27 марта в репозиторий было загружено 566 пакетов с вредоносным кодом, стилизованных под 16 популярных Python-библиотек...Подробнее: https://www.opennet.me/opennews/art.shtml?num=60874
На самом деле, утомительно по 10 раз перепроверять, что вон тот васянопакет на самом деле настояший васянопакет, и вовсе не соседний, поддельный с малварью. И Snyk тут не всегда поможет (да и сам он выглядит, как скам).
Хоть как-то у себя поддерживать базу доверительных публичных ключей: https://packages.gentoo.org/categories/sec-keys и верифицмровать ключи разрабов по WOT.Проверять подписи пактов.
Разрабам использовать аппаратные хранилища для своих приватных ключей:
https://www.linux.org.ru/forum/security/17518444?cid=17519118
https://www.linux.org.ru/forum/security/17518444?cid=17520696
И раздавать свои публичные ключи для подписи другими.
А бэкдор в xz-utils ведь был подписан? Или нет?
Говорат был подписан: "Newer releases were signed by a potentially compromised upstream maintainer." https://packages.gentoo.org/packages/app-arch/xz-utilsВ Gentoo забанили все что подписано его ключом. И инцендент, пока, рассматривается как компроментация разработчика и воровство приватного ключа, а не умышленные действия. Да, приватные ключи разрабов необходимо аппаратно защищать:
https://www.nitrokey.com/news/2018/nitrokey-partners-linux-f...
https://www.nitrokey.com/news/2019/nitrokey-partners-gentoo-...
https://www.nitrokey.com/news/2021/nitrokey-equips-arch-linu...
Адекватные люди ставят все pure-python пакеты исключительно из исходников, бинарные - по возможности из дистра, по возможности - компилируют сами.
А как отличить правильный исходник от «немножко изменённого»? У бинарника хотя бы чексумма есть...
Вот бинарник от подправленного ты никак не отличишь - злоумышленник и сумму пересчитает, и ключом своим подпишет, и ссылку на ключ на свою заменит.А исходник... исходник — он живой! В него правки вносятся постоянно. Захватят контроль над репозиторием — автор обнаружит. От вредительства самим автором это никак не защитит, от этого только Чучхе с лично написанным всем софтом и лично сделанным всем железом. А то, что это нереализуемо — это не отменяет гарантий метода, нет софта - некого винить ведь!
Кстати, там в дистрибутивных xz-utils малварь нашли в исходниках, вот это по-актуальнее https://bugs.gentoo.org/928134 https://www.openwall.com/lists/oss-security/2024/03/29/4
В том то и дело, что нашли. В бинарнике бы её даже выискивать не стали.
И подчеркну - бэкдор был именно в релизах, которые обычно никто не смотрит, потому что все разрабы работают с git. А спалили именно на работе с другими разрабами. Если бы xz был поддерживаемым - спалили бы гораздо раньше. Но он фактически не был никому интересен. Как и bitmessage, в котором тоже был явный бэкдор, RCE, вообще никак не спрятанный - публично сообщили только после начала массовой атаки. Не пользуйтесь проектами с низким числом независимых разрабов и индикаторами мутности, или читайте и аудируйте их исходники сами.
Неа, никто ничего не заметил за 2 месяца и растащили повсюду, в том числе по дистрам. Никто не использует гит/свн и т.д., понятное дело все берут релизный архив с исходниками, а он-то и заражён. То, что он соответствует реальным исходникам, никто не проверяет, как мы видим.
Повторяю: недоумки берут архив с релизами. Просто потому, что для архива нужен просто curl, а для релиза - git + git-lfs + libcurl для фетча по http + настройка (которую можно сделать черрез переменные окружения), потому что гит откажется даже клонировать, пока никнейм и email не задашь.
Дело в том, что это быстрее и лучше поддаётся автоматизации. И разве люди, сношающиеся с гитхабами и их ограничениями скорости, не недоумки? Самые настоящие. Проблема не в используемых инструментах, проблема в том, что пользователям получать дерево достаточно болезненно, а если ещё разные ветки с тегами выкачивать придётся, то всё.
Смотри, перечень пакетов со сборкой которых возникли сложности лично у меня только на той неделе. Каковы будут дальнейшие рекомендации? О, я бы сейчас с удовольствием предоставил ещё и гигабайты максимально мутных логов, но так, навскидку? И чёт почти ничего в репах и не водится. А если и есть, то протухшее и неактуальное.thinc, blis, pyee, tensorflow, srsly, cupy
Читай маны
Ты не понял. Тысячи пакетов я скомпилировал, включая все используемые пакеты в pypi. Кроме этих. А эти ну никак не компилируются. Дальнейшие действия? В итоге, есть только блобы в pypi и больше ничего. И игры с тулчейнами тоже ни к чему не приводят. Какой вообще смысл их компилировать разработчику? Правильно, никакого. А пользователи могут взять ровно те же общедоступные блобы, собранные в непонятных условиях.
Не из pypi надо кшмпилить, а с гитхаба.
>tensotflowСказано:
>по возможностиTensorflow я сам ставлю из бинарей. Потому что Гуглаг специально саботируют его сборку всеми, кто не может терпеть базель.
А сам список пакетов как бы намекает, что вы ставите всё подряд. У меня и за полгода такого длинного списка с проблемами не наберётсяж
Это 1 spacy и его зависимости на самом деле.
Я себе просто отключил проверку зависимостей в pip. Доустанавливаю если что-то не работает вне зависимости от того, что записано в METADATA. И такое гигантское дерьмо приходится ставить из бинарных пакетов. Ручками. Из исходников ставлю всякую мелочь вроде colorama, setultools, pip, etc. И если учитывать зависимости, то у самого TensorFlow дофига бинарных зависимостей.
> Каковы будут дальнейшие рекомендацииСлезть с питона, очевидно же.
А какой не является? Можно список с аргументами?
Много ли ты видел pure-python пакетов?
Более сотни - это лишь те, что я полностью сам написал, без учёта превосходящего вклада в чужие пакеты, большая часть из которых pure python.
под pure python имеется в виду отсутствие компиляции cext или долботни с maturin/setuptools-rust, что пакет можно установить просто распаковкой. Это не означает отсутствие зависимостей от компонентов в native-коде, таких как сам интерпретатор, shared-библиотеки, другие пакеты, jar-файлы, .Net-сборки, ONNX-файлы и т.д.
Правда, pure python _именно это_ и означает: только интерпретируемый код, без использования нативного (компилируемого) в любом виде, за исключением интерпретатора и его стандартных бинарных компонентов. И, в частности, без таких трюков как освобождение gil на время, пока нативный код исполняется. По этой же причине, такой код является третьесортным -- он просаживается в многопотоке.
>за исключением интерпретатора и его стандартных бинарных компонентовО, оправдания пошли! Для меня pure-python пакет - это пакет, состоящий из кода на языке Python. Он может зависеть от нативных либ и прочих вещей, но эти вещи в состав пакета не входят. Поэтому сборка пакета своидится к созданию zip-архива нужного формата, а установка - к его распаковке. И почти не зависит от версии питона, а даже если зависит - то юзеру не придётся иметь на компе тулчейн (который в запущенных случаях должен быть MSVC). Ну ещё setuptools может сгенерить бинари для console_scripts в процессе установки (да, их не pip генерит, а setuptools)
Например, Paramiko не pure-python, потому что зависит от cryptography, написанном на Си. А вот Bottle является одиночным файлом без зависимостей.
Есть модуль multiprocessing. Между разными процессами GIL не используется.
Зато добавляются накладные расходы, IPC очень дорого и невозможно шарить конекшены допустим. Вообще, я сравнивал на примере requests, намного выгоднее быстрее удобнее и эффективнее взять aiohttp. Раньше приходилось обмазываться pycurl, но, среди прочих недостатков, он не работает с асинхронным кодом и его слишком легко засегфолтить.
Ну так про GIL говорили же. А GIL никак не связан с однопоточной природой Asyncio.
Как можно из 16 пакетов сделать 566, кажись это очень эффективные менеджеры:)
И куда он отправляет пароли? Давайте уже вычислим по IP этого мамкиного шалунишку.
Тебе надо, сам и вычисляй (С). ))
Нет, это тебе надо чтобы тут пользователь вычислил! (иначе бы комментарии не писал)
Так что сам вычисляй!
Рекурсия получается
Точнее, не рекурсия, а бесконечный цикл.
>И куда он отправляет пароли?На какой-нибудь бесплатный хостинг/ВПН, естественно.
А нельзя сделать просто проверку на похожесть и не разрешать имена пакетов, похожие на существующие?
>проверку на похожестьВо сколько символов разница должна быть, чтобы название не считать похожим?
С точностью до опечатки достаточно.
> 38 - MatplotlibЛюбые "научные" книги, в том числе по ИИ, содержащие упоминание технологий Python, приобретению, прочтению и использованию в практических целях не подлежат. Хотя мнения своего никому не навязываю. Впрочем, результат и так описан в статье.
Тёплое с мягким тебя где научили сравнивать? Или ты сам?
Надо запрещать похожие названия, а вообще давно пора по умолчанию сделать username/package как схему именования, тогда злоумышленникам придётся имя пользователя делать похожим, но и его можно запретить.
Во сколько символов разница должна быть, чтобы название не считать похожим?
Очевидно, коллега - специалист по сравнению> Тёплое с мягким
Поэтому будет делать это
> сам
> Во сколько символов разница должна быть, чтобы название не считать похожим?Очевидно разница может быть равна нулю. Функция похожести будет сложнее чем просто сравнение длин.
> вообще давно пора по умолчанию сделать username/packageи будут тайпсквотить имена разрабов кроме имени пакета
>> вообще давно пора по умолчанию сделать username/package
> и будут тайпсквотить имена разрабов кроме имени пакетаДля тайпскотинга имени пакета нужна 1 учетная запись, для имени пользователя N. Это сильно усложнит вредителям жизнь. К тому же никто не мешает запретить похожесть имен пользователей, чтобы избежать проблем, описанных в новости.
Ну парни, кожанные мешки не могут называться программистами, если попадаются на тайпсквотинг ловушку СЕОшников.
Это джунгли, прежде чем выбирать библиотеку нужно чекать название из нескольких источников.