Опасная уязвимость в GitHub Actions позволила бы злоумышленникам выполнять произвольный код в CI/CD пайплайнах проектов с открытым исходным кодом, используя функцию pull_request_target.

Основная проблема заключалась в том, что некоторые рабочие процессы в nixpkgs использовали pull_request_target и доверяли коду из форков, выполняя команды вроде xargs над именами файлов из PR. Это позволило бы атакующему создать файл с именем вроде --help, который интерпретировался бы как флаг для утилиты, что привело бы к выполнению произвольного кода.

Более серьёзный случай включал симлинки: рабочий процесс проверки CODEOWNERS мог быть обманнут для чтения произвольных файлов с диска, включая файлы учётных данных. Если бы атакующий смог заставить систему прочитать файл с учётными данными, он мог бы украсть токены GitHub.

К счастью, эти уязвимости были обнаружены и исправлены до того, как их могли эксплуатировать. Авторы рекомендуют всем, кто использует pull_request_target, тщательно проверять свои рабочие процессы и избегать доверия к коду из форков.

• Проблема в том, что pull_request_target в GitHub Actions позволяет уязвимости, но при этом остаётся единственным способом запуска CI для форков в организациях, не использующих форки.
• Подверженность pull_request_target в действии: злоумышленник может украсть токены и секреты, используя триггер, что приводит к тому, что вредоносный код может быть запущен в контексте базовой ветви.
• Предложение: GitHub должен либо полностью отключить pull_request_target, либо предоставить безопасный способ запуска CI для форков.
• Параллельно обсуждается, что если бы NixOS принял предложение обеспечивать подпись коммитов и независимые воспроизводимые сборки, как это делает Guix, то подобные атаки были бы невозможны.

GitHub сообщает о сбое веб-хуков: с 17:30 до 19:30 UTC не работали webhook-доставки, а затем и другие сервисы. Команда уже восстановила работу и ведёт мониторинг. Подробности и подписка на обновления — в статусе инцидента.

• Пользователи жалуются на регулярные сбои GitHub: от тотального отсутствия push/pull до «залипших» PR и застрявших CI-запусков.
• Сторонники самостоятельного хостинга спорят, что монолитный подход GitHub увеличивает шанс «всё сломать» и усложняет отладку.
• Сторонники GitHub отвечают, что самостоятельный хостинг не защищён от сбоев и требует тратить время на интеграцию инструментов вместо разработки.
• Участники обсуждения отмечают, что GitHub Actions и большинство других сервисов всё ещё нестабильны, а их взаимодействие с Issues и PR нередко приводит к сбоям.
• В итоге обсуждение свелось к тому, что единственный способ избежать сбоев — это не полагаться ни на один сервис целиком, а держать варианты «под рукой» и быть готовым в любой момент мигрировать.

Jules — это ИИ-агент для автоматизации разработки, который теперь предлагает API для интеграции в рабочие процессы. С его помощью можно автоматизировать создание задач, исправление багов и внедрение фич через инструменты вроде Slack, Linear или Jira, а также встраивать в CI/CD-пайплайны GitHub Actions. Например, можно отправить запрос на создание сессии через cURL, указав промпт и контекст репозитория.

Кроме API, в обновлениях появилась поддержка командной строки, веб-серфинг, тестирование веб-приложений с визуализацией результатов, работа с обратной связью из PR, загрузка изображений и увеличение размера VM до 20 ГБ. Агент стал быстрее и надёжнее, добавлена критика кода, интерактивное планирование и поддержка Bun.

• Перенос инфраструктуры на Railway и использование Jules для самостоятельного создания PR клиентом для мелких правок
• Критика Jules как продукта Google: фрагментация предложений, опасения по поводу закрытости и возможного прекращения поддержки
• Обсуждение различий между Jules, Claude Code, Copilot и другими агентами, их интеграций и безопасности
• Сравнение моделей использования: асинхронные агенты vs. интерактивные инструменты в IDE, вопросы доверия и ROI
• Критика антропоморфных названий продуктов и размышления о целесообразности разработки в личное время

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

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

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

GitHub Actions начинает процесс отказа от Node 20, так как его поддержка завершится в апреле 2026 года. Планируется переход на Node 24 осенью 2025 года. Сейчас последняя версия раннера поддерживает обе версии, но по умолчанию используется Node 20. Для тестирования Node 24 можно установить переменную окружения FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true.

С 4 марта 2026 года раннеры перейдут на Node 24 по умолчанию. Чтобы продолжить использовать Node 20 после этой даты, нужно установить ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true, но это будет работать только до лета 2026 года, когда Node 20 окончательно удалят. Node 24 несовместим с macOS 13.4 и ниже, а также не поддерживает ARM32, что повлияет на самохостинг. Разработчикам действий и пользователям рекомендуется обновить конфигурации и рабочие процессы соответственно.

• Пользователи выражают недовольство частыми устареваниями (deprecations) и проблемами совместимости в GitHub Actions, особенно с версиями Node.js (пропуск версии 22, переход на 24) и действиями (например, actions/checkout).
• Обсуждаются проблемы безопасности из-за уязвимостей в устаревших версиях Node.js в раннерах GHA, что может привести к компрометации репозиториев и инфраструктуры.
• Предлагаются альтернативы: использование самодельных скриптов для установки Node.js, упаковка действий в Docker-контейнеры или переход на самописные раннеры (например, github-act-runner) для большего контроля.
• Критикуется привязка к проприетарному сервису (GHA) для обеспечения долгосрочной стабильности сборок; предлагается выносить логику сборки в собственные скрипты (Makefile).
• Отмечаются проблемы с экосистемой Node.js: медленная адаптация зависимостей к новым LTS-версиям и отсутствие расширенной поддержки старых ОС со стороны провайдеров.

Атака на поставки @ctrl/tinycolor: разбор инцидента

Злоумышленник добавил вредоносный workflow в GitHub Actions общего репозитория и похитил npm-токен с правами публикации. С помощью этого токена были опубликованы вредоносные версии 20 пакетов, включая @ctrl/tinycolor.

Мой аккаунт GitHub и репозиторий @ctrl/tinycolor не были скомпрометированы напрямую. Не использовался фишинг, на моём компьютере не устанавливались вредоносные пакеты. GitHub и npm оперативно отреагировали, удалив зловредные версии. Я выпустил чистые версии пакетов для очистки кэшей.

Как это произошло

Раньше я участвовал в проекте angulartics2 — общем репозитории, где у нескольких человек были права администратора. Там остался секрет GitHub Actions — npm-токен с широкими правами на публикацию.

Злоумышленник принудительно отправил ветку Shai-Hulud в angulartics2 с вредоносным workflow. Workflow запустился сразу после отправки (без проверки, так как у collaborator были права администратора) и украл npm-токен. С помощью украденного токена атакующий опубликовал вредоносные версии 20 пакетов.

Планы на будущее

Сейчас я использую semantic-release с GitHub Actions для публикации. Моя цель — перейти на Trusted Publishing (OIDC) в npm, чтобы полностью отказаться от статических токенов. Однако интеграция с semantic-release ещё в разработке.

Для небольших пакетов я продолжу использовать semantic-release, но с ужесточённым контролем: никаких новых участников, отдельные npm-токены с правами только на публикацию конкретного пакета.

Я планирую и дальше использовать pnpm, который блокирует неавторизованные postinstall-скрипты, и изучу новую настройку minimumReleaseAge.

Пожелания к системе публикации

В идеале хотелось бы иметь в npm единый переключатель для принудительного использования Trusted Publishing (OIDC) для всех моих пакетов. Такой же переключатель блокировал бы любые релизы без provenance, обеспечивая безопасность на уровне аккаунта. Также хотелось бы иметь встроенную поддержку semantic-release с OIDC и provenance, чтобы статические токены больше не требовались.

Кроме того, было бы удобно иметь безопасный вариант публикации с подтверждением человека прямо в интерфейсе GitHub: защищённый workflow_dispatch, использующий 2FA GitHub для удовлетворения требованиям двухфакторной аутентификации без необходимости публиковать со своего компьютера.

• Предлагается использовать ручные релизы и многоэтапные проверки для публикации пакетов вместо полной автоматизации CI/CD.
• Обсуждаются недостатки долгоживущих токенов и предлагается использовать Trusted Publishing с короткоживущими токенами или OIDC.
• Поднимается вопрос о необходимости встроенной MFA (двухфакторной аутентификации) для подтверждения публикации в CI-системах.
• Предлагается разделить процесс на загрузку пакета и его публикацию для пользователей, чтобы повысить контроль.
• Обсуждается идея использования подписей нескольких авторов или проверки подписей коммитов для обеспечения безопасности.
• Отмечается сложность настройки безопасных машинно-машинных потоков (OIDC) и необходимость более простых решений.
• Упоминается, что многие разработчики игнорируют вопросы безопасности до момента взлома и необходимы системные изменения.

Компрометация пакетов 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 или созданию безопасного форка/дистрибутива пакетов.

Статические сайты = машина времени
Варун написал о геймификации блогов, и я вспомнил свои «бейджики» 2021 года. Сначала подумал, что скриншотов нет, но потом понял: сайт на Eleventy статичный, поэтому достаточно git checkout нужного коммита и eleventy serve, чтобы увидеть страницу в том же виде.

В отличие от WordPress или сборок, где посты тянутся из CMS только при деплое, у меня каждый коммит — полный снепшот. Путешествие во времени занимает две команды (если только я не забыл закоммитить).

Год назад я завёл GitHub Action, который ежемесячно делает скрин главной «на всякий случай», но теперь не переживаю: история дизайна всегда под рукой в git.

Если тема близка — пишите на juhamattisantala@gmail.com, буду рад обсудить.

• Участники обсуждают, как лучше «путешествовать во времени» по старым версиям сайтов: Wayback Machine, Git-архивы, локальные бэкапы или собственные «музейные» режимы.
• Кто-то предпочитает чистый HTML/CSS без генераторов, чтобы минимизировать зависимости и упростить долгосрочное хранение.
• Поднимаются вопросы обратной совместимости JS/CSS и роли стандартов: насколько браузеры гарантируют, что сегодняшние сайты откроются через десятилетия.
• Упоминаются практические сложности: старые зависимости, версии Node, базы данных, билд-инструменты.
• Появляются идеи распределённого архивирования (плагины, GitHub Actions, клиентские кэши) и примеры «игровых» подходов к ведению блога.

Современные 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 или векторные инструкции.

• Google представила Gemini CLI GitHub Actions — бесплатного ИИ-напарника для репозиториев. Он работает как автономный агент для рутинных критичных задач и как коллаборатор по запросу, которому можно быстро делегировать работу.

• Функции:

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

• Польза для команд:

  • Ускорение код-ревью и исправления ошибок.
  • Поддержка документации, тестов и рефакторинга.
  • Снижение нагрузки на разработчиков за счёт рутины.

• Доступность: без дополнительной стоимости, ориентировано на совместную работу в GitHub.

• Это GitHub Action, которую добавляют в YAML-файлы workflow; она вызывает Gemini CLI, передаёт ему промпты и контекст репозитория.
• Название «Gemini CLI» сбивает с толку: по факту это не CLI-утилита, а плагин для GitHub, что вызывает вопросы о брендинге и самоконкуренции с Jules.
• Установка требует Google Cloud-проекта и API-ключа; OAuth-авторизация пока не работает, а бесплатный режим ограничен квотами Google AI Studio.
• Пользователи жалуются на запутанную документацию, отсутствие понятных сценариев использования и невозможность отказа от сбора кода как тренировочных данных.
• По отзывам, инструмент годится для быстрого обзора PR новичков, но не заменяет Copilot Agent или Claude Code для профессиональной разработки.