Вредоносная версия библиотеки 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, чтобы избежать безусловного принятия вредоносных пакетов.

Автор разместил свой личный сайт в сети Tor как скрытый сервис, доступный по .onion-адресу, который генерируется из открытого ключа и не требует DNS, сертификатов или раскрытия IP-адреса. Трафик шифруется end-to-end через сеть Tor, обеспечивая анонимность как пользователей, так и самого сервера — никакая сторона не может связать личность посетителя с его действиями или локацию хостинга.

Для настройки скрытого сервиса автор отредактировал файл /etc/tor/torrc, указав директорию для ключей и перенаправление порта 80 на локальный веб-сервер (127.0.0.1:8080). После перезагрузки Tor сгенерировал уникальный .onion-адрес, который был использован в конфигурации nginx для обслуживания статического сайта без TLS, поскольку шифрование обеспечивается Tor. Чтобы избежать перенаправления на clearnet-домен, сайт собирается дважды: один раз для обычного веба, второй — с базовым URL, равным .onion-адресом, используя Hugo с флагом --baseURL. Этот процесс автоматизирован в пайплайне деплоя через GitHub Actions, который синхронно обновляет обе версии сайта. Оба варианта — clearnet и Tor — поддерживаются в актуальном состоянии без ручного вмешательства. Сайт доступен в сети Tor по адресу dhevt6e4rtgbtr3jh53xrpwmgtilkah6nyjujocsspssrsexc7omxhid.onion.

Размещение сайта в Tor реально, но требует ряда оптимизаций. Чтобы снизить нагрузку на соединения и компенсировать низкую пропускную способность, рекомендуется минимизировать HTTP-запросы, использовать серверный рендеринг, CSS-анимации и встраивать мелкие ресурсы через base64. Для ускорения загрузки можно внедрить HTTP/2 и HTTPS-сертификат. Технические рекомендации: — Добавить заголовок Onion-Location на clearnet-версию для автоматического предложения .onion-адреса в Tor Browser. — Привязывать HiddenServicePort к Unix-сокету или нестандартному локальному IP (не 127.0.0.1), чтобы упростить развертывание нескольких сайтов и избежать случайного доступа. — Обязательно резервировать приватный ключ сервиса, иначе при его потере придется менять адрес. — Не совмещать роль скрытого сервиса с ролью exit-ноды из соображений безопасности. Безопасность и доступность: — Против DDoS в Tor часто применяют двойные капчи. — Для защиты от фронтинга следует использовать уникальные заголовки и отдельные домены. — После перезапуска сервиса возможны задержки в доступности; рекомендуется использовать мосты (obfs4, snowflake) и fallback-механизмы. — v3-адреса длинные, а высокая латентность сети делает предпочтительным использование статического контента. Особенности и альтернативы: — Отсутствие DNS, сертификатов и публичного IP усложняет, но не исключает возможность деанонимизации сервиса государственными агентствами. — В качестве альтернатив с иными компромиссами по скорости и анонимности можно рассмотреть I2P и Yggdrasil.

Система GitHub Actions перестала обрабатывать очередь задач из-за сбоя в контроллере самодельных раннеров (ARC). Поды раннеров застряли в состоянии «idle», что привело к накоплению задач и сбоям в выполнении workflow.

Ключевые цифры: 99 % успешных завершений после исправления, но вебхуковые триггеры и миграции через GitHub Enterprise Importer остаются ограниченными. Инженеры уже выпустили фикс, ускоривший очистку очереди и восстановление нагрузки.

Восстановление происходит поэтапно: GitHub Pages, Copilot code review и Copilot coding agent показывают признаки стабилизации, однако intermittent‑ошибки могут сохраняться. Следующие релизы ARC получат автоматическое восстановление, устраняя необходимость ручного удаления подов.

Пользователи сталкиваются с частыми сбоями GitHub Actions и Pages, что заставляет некоторых переходить на альтернативы — GitLab, Forgejo или self-hosted CI/CD. Среди причин называют рост нагрузки и возможную интеграцию с ИИ-провайдерами. Проблемы критичны для бизнесов, зависящих от автоматизации. Некоторые предлагают вернуться к платной модели аккаунтов для улучшения надёжности.

Zig мигрирует основной репозиторий с GitHub на Codeberg из-за деградации платформы после продажи Microsoft в 2018 году. GitHub стал медленным и buggy (перегружен JS-фреймворками), Actions — ненадёжным ("vibe-scheduling" заданий, backlog даже на master, баги без фиксов). Плюс связь с ICE и нарушения строгой no-LLM/no-AI политики из-за навязчивого Copilot. Вместо трат на обход CI-проблем, выбрали смену хостинга.

GitHub Sponsors — ключевой доход ZSF, но признан liability; просят донаторов перейти на non-profit Every.org, перки (имя на главной/релизах) переносят туда. Миграция: GitHub read-only, canonical — codeberg.org/ziglang/zig. Issues/PRs оставляют на GitHub (не мигрировать, продолжают мониторить), на Codeberg нумеруют с 30000. Благодарности Forgejo/Codeberg: Earl Warren, Otto, Gusted, Mathieu Fenniak. Non-profits — оплот от платформенного капитализма.

• Zig мигрирует с GitHub на Codeberg из-за связей с ICE, AI-спама и падения качества; пост критикуют за оскорбления разработчиков ("обезьяны", "неудачники").
• Поддержка миграции как шага к независимости от Microsoft и продвижению Forgejo/Codeberg.
• Критика Codeberg: слабая инфраструктура, низкая скорость, проблемы доступности (CAPTCHA для screen reader).
• Смешанные реакции: энтузиазм тренду ухода с GitHub, но сомнения в стабильности для крупных проектов.

GitHub Actions добавили поддержку YAML-якорей, что автор считает серьёзной ошибкой. Якоря избыточны: ту же функциональность можно реализовать через встроенные механизмы вроде workflow-level env, которые прозрачнее и логичнее в архитектуре. Они вводят ненужную сложность, нарушая локальность — теперь элементы могут зависеть от частей конфигурации в совершенно другом месте файла, что усложняет чтение и анализ.

Кроме того, якоря усугубляют проблемы безопасности: инструментам сложнее анализировать workflows, так как нарушается соответствие между исходным YAML и объектной моделью. Это мешает точно отслеживать уязвимости, например утечки секретов. GitHub не реализовал ключи слияния (merge keys), единственный сценарий, где якоря могли бы быть оправданы, что делает их поддержку бессмысленной и вредной.

• Внедрение YAML-якорей в GitHub Actions оценивается положительно для устранения дублирования в конфигурациях, но критикуется за использование нестандартного синтаксиса, усложняющего анализ.
• Высказываются предложения заменить YAML на полноценный язык программирования для определения пайплайнов, чтобы улучшить тестируемость, локальную разработку и избежать сложностей шаблонизации.
• Поднимаются проблемы безопасности из-за неявного распространения переменных окружения (включая секреты) при использовании якорей и слияния объектов, что противоречит принципу минимальных привилегий.
• Отмечается, что текущие ограничения GitHub Actions (например, отсутствие фильтрации путей для workflow_call) вынуждают пользователей создавать костыльные решения или полагаться на сторонние инструменты.
• Обсуждаются компромиссы между декларативным и императивным подходами: одни предпочитают чистый YAML для читаемости, другие генерируют его из кода для удобства поддержки сложных логик.

Компрометация пакетов ctrl/tinycolor и 40+ других в NPM

Популярный пакет @ctrl/tinycolor с более чем 2 млн загрузок в неделю был скомпрометирован вместе с 40+ другими пакетами в результате сложной атаки на цепочку поставок. Вредоносное ПО самораспространяется по пакетам maintainer'ов, собирает учетные данные AWS/GCP/Azure с помощью TruffleHog и создает бэкдоры через GitHub Actions.

Технический анализ

Атака реализуется через многоступенчатую цепочку, использующую Node.js process.env для доступа к учетным данным. Основной элемент — файл bundle.js (~3.6 МБ), который выполняется асинхронно во время npm install.

Механизм самораспространения
Вредоносное ПО через функцию NpmModule.updatePackage запрашивает API реестра NPM для получения до 20 пакетов maintainer'а и принудительно публикует обновления, создавая каскадный эффект компрометации.

Сбор учетных данных
Используются инструменты вроде TruffleHog для сканирования файловой системы на наличие секретов. Целевые учетные данные включают:

• Токены доступа GitHub
• Ключи доступа AWS
• Учетные данные Google Cloud Platform

• Пользователи выражают обеспокоенность невозможностью аудита всех зависимостей и их уязвимостью к атакам в npm.
• Критикуется архитектура npm, в частности выполнение postinstall-скриптов по умолчанию, в отличие от других менеджеров пакетов.
• Предлагаются решения: игнорирование скриптов в настройках, песочница (bubblewrap), использование подписей кода и каррированных пакетов.
• Указывается на системную проблему экосистемы JS: огромное количество мелких зависимостей и отсутствие сильной стандартной библиотеки.
• Обсуждается масштаб атаки (180+ пакетов) и её возможная связь с государственными акторами.
• Поднимается вопрос уязвимости других экосистем (PyPI) и необходимости обязательной 2FA и подписи артефактов.
• Высказываются радикальные предложения по замене npm или созданию безопасного форка/дистрибутива пакетов.

Современные CI-платформы стали мощнее, но и сложнее. GitHub Actions, GitLab и др. предлагают YAML-конфиги с шаблонами, условиями, секретами, кешем, артефактами, экосистемой actions — в итоге CI превращается в полноценную систему сборки.

Базовые примитивы (задачи, зависимости, шаги) не отличаются от Makefile-ов, а добавление распределённого запуска и кеша делает CI почти идентичным современным билд-системам вроде Bazel.

Сложность растёт:

• YAML становится языком программирования.
• Пользователи копируют чужие конфиги, не понимая, что происходит.
• Платформы закрываются на собственных экосистемах, создавая vendor lock-in.

Итог: вместо простого «удалённого запуска тестов» мы получили громоздкую систему, где границы между CI и build-системой стёрлись.

• Участники сходятся во мнении, что современные CI-системы слишком сложны и слишком «далеко» от разработчика, превращаясь в гибрид билд-системы и платформы.
• Многие предлагают упрощение: локально-переносимые скрипты (Bash, Justfile, build.bash), контейнеры или минималистичные движки вроде builds.sr.ht, Drone OSS, Buildbot, Linci.
• Критика YAML-конфигураций и SaaS-зависимости: GitHub Actions «застрял», GitLab CI мощнее, но всё равно требует «платформы».
• Идея «CI должен быть просто расширением билд-системы» (Bazel, Nix, Dagger) звучит, но требует единого «Steve Jobs билд-систем», а не новых технологий.
• Итог: пока нет серебряной пули; кто хочет простоты — пишет ./build.sh и запускает где угодно, кто хочет мощности — мирится с уровнем сложности текущих CI.

FFmpeg/asm-lessons — репозиторий с уроками по ассемблеру для FFmpeg.
Цель: научиться писать высокопроизводительные рутины на x86-64, ARM и других архитектурах, ориентированные на мультимедиа-задачи.

Содержание (кратко):

• Уроки: от базовых инструкций до векторных расширений (SSE/AVX, NEON).
• Примеры: реализация IDCT, фильтров, цветового преобразования.
• Тесты: юнит-тесты и бенчмарки для сравнения C vs asm.
• CI: автоматическая проверка на x86-64 и ARM через GitHub Actions.

Как начать:

1. Клонируйте репо.
2. Установите nasm, yasm или llvm-mingw.
3. Соберите пример: make lesson01.

Полезные ссылки:

• Документация FFmpeg
• x86 SIMD
• ARM NEON

• Пользователи восхищаются масштабом FFmpeg и экономией вычислений даже при небольших улучшениях.
• Обсуждаются случаи, когда ручная сборка быстрее intrinsic’ов, и инструменты для поиска «горячих точек».
• Некоторые ждали более глубокой связи с FFmpeg, а не общее введение в ассемблер.
• Поднимаются вопросы портативности (пока только x86-64), необходимости математических подготовок и перегруженности NASM-макросами.
• Большинство соглашается: писать LLVM IR вручную нет смысла, проще использовать inline-assembly или векторные инструкции.