Hacker News Digest

Вредоносная версия библиотеки LiteLLM 1.107.0, опубликованная на PyPI, содержала похититель учётных данных и бэкдор удалённого выполнения кода. Все семь колёс (для Linux, macOS и Windows) устанавливали три файла в site-packages, причём два из них загружались при запуске любого процесса Python — даже если он никогда не импортировал litellm. Исходники на GitHub этих файлов не содержат, а PyPI уже удалил релиз. Чистыми остаются версии 1.106.2, 1.107.0rc1 и 1.107.0rc2, а также зависимые пакеты litellm-proxy-extras==0.4.110 и litellm-enterprise==0.1.78.

Файл cook.pth импортировал cook.py — похититель, собиравший SSH-ключи, облачные учётные данные, секреты CI/CD, токены ИИ-инструментов, пароли браузеров и ключи провайдеров LLM из базы прокси LiteLLM; данные шифровались и отправлялись на www.litellm[.]dev. Второй файл, sitecustomize.py, запускал фоновый демон, который ежечасно читал адрес сервера из файла на GitHub, повторно запускал похититель и скачивал чужой код. Имплант попал в релиз через лишнюю строку data = "cook" в секции maturin файла pyproject.toml: она копировала папку cook/ в колесо, но сама папка в sdist отсутствовала — это единственное видимое изменение. Тег v1.107.0 указывал на коммит с версией 1.108.0, а sdist совпадал с более поздним коммитом main плюс пять отредактированных файлов. Колёса собрал обычный конвейер BerriAI (maturin 1.9.4, корректные записи в RECORD), но ни один публичный запуск GitHub Actions релиз не собирал и не публиковал.

Повторная компрометация LiteLLM (версия 1.107.0) из-за кражи трех GitHub-аккаунтов разработчиков указывает на системную уязвимость цепочки поставок в экосистеме Python. Злоумышленники внедрили файл cook.pth, который автоматически загружается при старте любого Python-процесса. Рекомендации: — зафиксировать версию ≤ 1.106.2, использовать приватные реестры и проверять артефакты сборки (включая .pth-записи); — использовать канарейковые токены (canarytokens.org) для раннего обнаружения атак; — рассмотреть альтернативы, например GoModel на Go. Для защиты экосистемы предлагается внедрить в менеджерах пакетов (uv, npm, pip) задержку установки новых версий на 24–48 часов, а в операционных системах — изолированные программные пространства или легкие VM, чтобы избежать безусловного принятия вредоносных пакетов.

Laya — это семейство открытых моделей для мгновенных структурированных решений (System 1), созданное как альтернатива генеративным LLM для простых классификаций. Оно использует двунаправленные энкодеры и обучение с подкреплением (RLCD) для выдачи честных, калиброванных вероятностей по заданным схемам — без генерации текста. Модели работают за 32.8 мс на одном GPU (7.2 мс/вопрос в батче), что в 6–8 раз быстрее, чем проприетарный аналог Jev от TypeSafe AI, и поддерживают более 100 языков.

Автор разработал похожую идею ещё в марте 2025 года, опубликовав статью, веса, датасет и PyPI-пакет, но позже увидел, как TypeSafe AI представила почти идентичную концепцию под названием Jev — без открытых весов, датасетов или технических статей, но с коммерческой моделью ($0.042 за млн токенов, ~150 мс отклика). В ответ он создал Laya: полностью открытую, быструю и мультиязычную систему для задач вроде маршрутизации тикетов, определения срочности, обнаружения фишинга или оценки риска оттока — всё с честными вероятностями, которые можно использовать напрямую в коде. Все ресурсы доступны на Hugging Face, GitHub и PyPI под лицензией Apache 2.0.

Laya — практичная открытая альтернатива Jev для классификации, но требует дообучения (результат 0.766 после дообучения, базовая модель ~0.35), в отличие от Jev, который работает в zero-shot. Эффективность Laya зависит от дообучения, а не от нулевого шота. Jev удобнее для разработчиков благодаря API и простой настройке; Laya сложна в настройке и не имеет API. Laya использует модели с контекстом 512–1024 токенов, тогда как Jev работает с 32k — критичное ограничение для сложных задач. GLiNER (2023) уже реализовывал похожую архитектуру, что ставит под сомнение новизну Laya. Jev позиционируется как «System One» и «не галлюцинирует», но это маркетинг: обе модели основаны на BERT, разница — в упаковке, а не в технологиях. Laya не может считаться «открытой версией Jev» из-за использования крошечных моделей против позиционирования Jev как «frontier intelligence». Laya полезна для быстрой хостинга модели классификации, но требует дообучения, делая её менее «drop-in», чем Jev с API. Разработчики предпочитают Jev из-за готового API и социального доказательства — не хотят тратить время на сбор данных и инфраструктуру. BERT использовался для подобных задач до Jev и Laya — это переупаковка известных подходов. Для признания открытой работы нужны инструменты, API и документация, как у Jev. Laya может работать на MacBook Pro M5 с 48 ГБ ОЗУ, но лучше использовать облачные GPU (Lambda Labs, RunPod). Подходит для классификации тикетов и логов ошибок, но не для сложных сценариев с рассуждением — там нужны LLM. Некорректно сравнивать Laya и Jev по метрикам, если Jev zero-shot, а Laya требует дообучения. В здравоохранении и с чувствительными данными Laya предпочтительнее — можно хостить локально, Jev требует отправки данных в облако. Laya — не прорыв, а напоминание, что для многих задач достаточно простых быстрых моделей, а не генеративных LLM. Утверждение, что Jev «не галлюцинирует», — маркетинговая уловка: негенерирующие модели не могут галлюцинировать в классическом смысле.

Perl не мёртв, его популярность находится на уровне периода dotcom пузыря, согласно отчёту CPAN 2023. Новичков среди пользователей Perl становится всё меньше с 2011 года, хотя общее использование языка остаётся стабильным. Raku (бывший Perl 6) не стал причиной упадка, так как Perl продолжал расти даже во время разработки Raku.

Основные гипотезы упадка Perl связаны с изменением поколений программистов и развитием инструментов разработки. Программисты, выросшие на Unix-системах, естественно воспринимали Perl как продолжение shell, C, awk и sed. Новое поколение, воспитанное на Microsoft, Visual Basic и Java, предпочло Python. Кроме того, появление мощных менеджеров пакетов сделало доступными множество альтернатив, в то время как раньше Perl был одним из немногих доступных инструментов.

• Perl умер не из-за Raku, а из-за отсутствия единого пути развития, отсутствия стандарта кодстайла и культуры «один-разовых» скриптов.
• Python и PHP выиграли, потому что они были «дружелюбнее» для новичков и имели лучшую документацию.
• CPAN стал менее удобным, чем PyPI и npm, что сделало Perl менее привлекательным.
• Отсутствие единого фреймворка для веб-разработки и отсутствие стандарта ООП в Perl 5.
• Не было единого сообщества, которое могло бы продвигать Perl, в то время как Python и JavaScript имели Google и Facebook.

Python Software Foundation (PSF) withdrew its $1.5 million grant application to the US National Science Foundation (NSF) after the agency demanded a commitment to abandon diversity, equity, and inclusion (DEI) initiatives. The proposed funding aimed to enhance security for Python's package repository PyPI by developing automated tools to proactively detect malicious code in packages, a significant improvement over current reactive methods. The NSF's condition required the PSF to affirm it would not "advance or promote DEI," a restriction applying to all PSF activities, not just the funded project. Violation would trigger the NSF to reclaim previously awarded funds, creating substantial financial risk.

This demand directly conflicted with the PSF's core mission, explicitly stating its commitment to supporting "a diverse and international community." Despite the grant's potential to significantly boost the PSF's annual $5 million budget and develop security tools with broader open-source ecosystem benefits (like NPM and Crates.io), the organization refused to compromise its values. The PSF Board unanimously decided withdrawal was necessary to retain the freedom to support its entire community. The loss of this funding, coupled with economic pressures, increases the PSF's need for direct community financial support.

• PSF отказалась от $1,5 млн гранта из-за требования отказаться от DEI-программ, что вызвало широкий резонанс в сообществе.
• Обсуждение подняло вопрос о том, что DEI-программы могут быть незаконны, и что это может быть причиной, по которой грант был отклонен.
• Некоторые участники обсуждения выразили обеспокоенность тем, что отказ от гранта может повлиять на безопасность и стабильность экосистемы Python.
• Были высказаны предложения о том, что сообщество могло бы само финансировать нужды, чтобы не зависеть от грантов с политическими условиями.
• Обсуждение также затронуло вопрос о том, что DEI-программы могут быть незаконны, и что это может быть причиной, по которой грант был отклонен.