Hacker News Digest

Злоумышленники заявили о краже 10,6 ТБ данных из облачной платформы TiDB Cloud компании PingCAP — это 4 901 203 файла, включая полный контрольный слой продакшена. По их словам, выгрузка шла почти два месяца и оставалась незамеченной: 88 последовательных экспортов каждые шесть часов с 8 по 30 сентября, последний — в 06:02 UTC 30 сентября. Репликацию собственной базы данных TiDB Cloud они настроили через учётные данные, найденные в репозиториях самой компании: ключи сервисного аккаунта GCP и субъект Azure.

Среди похищенного — 180 046 организаций-арендаторов, 292 276 записей пользователей, 403 262 уникальных адреса электронной почты, 115 308 пар ключей API в открытом виде (42 612 активных), 20 645 574 SQL-запроса клиентов из редактора и Chat2Query, 102 003 766 подключений к шлюзу, 5 036 738 IP-адресов серверов заказчиков, 377 446 задач Jira, 433 928 контактов CRM, 92 ГБ данных о затратах AWS с метками арендаторов и 413 приватных репозиториев с исходным кодом. Также упоминаются 1 809 внешних конечных точек баз данных с учётными записями root и admin на хостах MySQL/Aurora заказчиков и 290 идентификаторов аккаунтов AWS.

Первый этап публикации — около 200 ГБ, доступен через торрент-файл размером 128,3 ГиБ. Атакующие подчёркивают, что PingCAP, будучи облачным провайдером, не заметил массовой выгрузки из AWS, GCP, Jira и Azure, хотя компания зарабатывает на обещании безопасности мультитенантной платформы.

Обсуждение указывает на катастрофический уровень операционной безопасности PingCAP: инженеры хранили production-учетные данные клиентов и ключи сервисных аккаунтов GCP и Azure в тикетах Jira и репозиториях. Это позволило атакующим настроить автоматическую репликацию данных в течение месяца. Сообщество ставит под сомнение заявления компании об отсутствии воздействия на данные, так как у хакеров есть полные дампы контрольного слоя. В споре о природе утечки @gregwebs считает, что утекли в основном метаданные, однако другие указывают на наличие SQL-логов с реальными данными клиентов. Проведенный ранее аудит NCC Group выявил разрыв между анализом кода и реальной безопасностью процессов. @kobieps отмечает необходимость перестройки индустрии пентестов, так как даже enterprise-grade вендоры допускают подобные провалы. @ozgrakkurt полагает, что безопасность была бы выше при использовании консервативной модели разрешений (как в Deno), где всё закрыто по умолчанию. Также пользователи иронизировали по поводу Rust, но @boorbat уточнил, что TiDB на 95% написан на Go.

Git-bug — это распределённый трекер ошибок, полностью интегрированный в Git: он хранит данные внутри репозитория, не добавляя файлов в проект, и позволяет работать офлайн, синхронно с кодом через обычные команды git bug push и git bug pull. Благодаря этому ваш трекер ошибок всегда доступен, даже без интернета или при недоступности внешних сервисов, и не привязывает вас к конкретному провайдеру — вы получаете полную резервную копию вместе с кодом.

Инструмент поддерживает несколько workflow: нативный (синхронизация через Git remotes), bridge-режим (импорт/экспорт с другими трекерами вроде Jira или GitHub Issues) и экспериментальный веб-интерфейс. Управление происходит через CLI: создание багов (git bug add), фильтрация по запросам (git bug ls "status:open"), интерактивный терминальный UI (git bug termui) и GraphQL API для интеграции с внешними инструментами. Все операции быстрые, не загрязняют рабочее дерево и сохраняют полную историю изменений вместе с коммитами. Лицензия — GPLv3.

Git-bug изолирует трекер ошибок от кода, но требует упрощения интерфейса для нетехнических пользователей и решения конфликтов идентичностей при офлайн-синхронизации. Для монетизации нужно снизить барьер входа, так как Git-интеграция уменьшает доступность по сравнению с GitHub или Jira. Рекомендуется интегрировать ForgeFed или IndieAuth для децентрализованной аутентификации, избегая привязки к централизованным провайдерам. Использование DID:PLC (как в Bluesky) упростит перенос идентификаторов между репозиториями — критично для распределённой модели. Некоторые считают, что трекер ошибок не должен быть частью репозитория: достаточно хранить баги в отдельной ветке или в SQLite (как @0xbadcafebee). Git-bug эффективен для маленьких команд, где минимизация переключения контекста между кодом и трекером повышает продуктивность (по @michaelastreiko). Проблема дублирования багов при офлайн-работе требует механизма слияния, аналогичного git-слиянию — это не решено в текущей реализации (по @promptsphereeee). Имя 'git-bug' ограничивает применение для отслеживания фич — возможно, стоит переименовать или расширить функционал (по @bflesch). Для привлечения пользователей важно поддерживать WebUI с OAuth, но также обеспечить работу без веб-интерфейса (как b4 и cgit на kernel.org, по @Aissen). Git-bug — часть тренда локально-первичных инструментов (как Fossil, ticgit, git-issue), но его успех зависит от устранения барьеров ввода и синхронизации (по @Izkata и @khimaros). Разделение трекера и кода через отдельную ветку (например, issues-branch) даёт гибкость и изолирует изменения (по @0xbadcafebee), что проще для масштабирования. Некоторые сомневаются в необходимости Git-bug, так как GitHub Issues уже интегрирован с Git и работает для большинства команд (по @Alex131313 и @zeroq). Использование git-refs для хранения багов (как в gitseq от @inguz) позволяет сохранять подпись и последовательность — потенциально более надёжно, чем текущий подход git-bug.

AI-ассистент GitHub Copilot случайно внёс критическую уязвимость в репозиторий Snowflake, заменив безопасный шаблон обработки данных на прямую подстановку пользовательского ввода в shell-скрипт. Это позволило любому пользователю GitHub выполнить произвольный код через создание специально оформленного issue — уязвимость была активна всего пять дней, пока Wiz Red Agent, автономный AI-инструмент для поиска уязвимостей, не обнаружил и эксплуатировал её, получив доступ к внутренней системе Jira Snowflake через украденный токен. AI-ревью не заметило опасность, потому что не понимало исторический контекст: ранее использовавшийся метод с env: и jq был специально добавлен для предотвращения инъекций.

Snowflake оперативно устранила уязвимость в тот же день, сменить токен и подтвердила, что Wiz был единственным субъектом доступа. Инцидент стал ярким примером рисков, связанных с автоматизацией кода: AI-агенты могут удалять защищающие паттерны, не понимая их назначения. Важно внедрять «охранительные барьеры», запрещающие AI заменять структурированные парсеры на прямую подстановку строк. Уязвимость не была следствием человеческой ошибки — она родилась в AI-автоисправлении, что ставит под сомнение надёжность текущих практик код-ревью с участием ИИ.

Уязвимость возникла не из-за AI, а из-за слабой проверки изменений, устаревших практик в GitHub Actions и некорректной обработки null-значений в шаблонах, что усиливает риск доверия автоматическим исправлениям без ручного аудита. AI не создаёт новых типов уязвимостей, но ускоряет их появление, делая распространёнными существующие ошибки: интерполяцию пользовательского ввода в shell-командах через ${{ }} без экранирования, использование curl вместо надёжных действий для взаимодействия с Jira (технический долг), и логику с `github.event.pull_request` в событиях `issues` — где `pull_request` всегда null, что возвращает `false` при любом условии. Оригинальный шаблон с `env` + `jq` был безопасен: переменные передавались через окружение, а не вставлялись в shell-строку. AI заменил его на опасную подстановку в одинарные кавычки. Ручной аудит диффов стал узким местом: AI упрощает генерацию изменений, но стоимость проверки не снизилась. Культура ревью «LGTM» без анализа превратила AI в просто замену человека в цепочке, не снизив риски. Советы: — Использовать статический анализ (например, zizmor) в CI для выявления template-injection до слияния. — Минимизировать логику в GitHub Actions, вынося сложные операции в отдельные скрипты. — Избегать интерполяции пользовательского ввода в shell через ${{ }} — использовать env-переменные и jq. — Системы, обрабатывающие пользовательский ввод в shell, должны fail-closed при null-значениях — поведение GitHub Actions по умолчанию небезопасно. AI обнажил системные слабости: устаревшие действия, отсутствие статического анализа и слепое доверие к автоматическим изменениям.

Atlassian приобретает The Browser Company
Сегодня мы объявили о покупке The Browser Company — создателей браузеров Dia и Arc.

Цель
Создать первый AI-браузер для командной работы, объединив любовь TBC к инновациям и опыт Atlassian в управлении командами.

Проблема
Современные браузеры заточены под потребление, а не работу: куча вкладок, потерянные вкладки, отсутствие контекста задач.

Решение
Arc уже умеет группировать вкладки, а Dia добавляет AI-агента, который:

• собирает контекст из Jira, Confluence, Slack;
• автоматически открывает нужные страницы;
• помогает быстрее принимать решения.

Что дальше

• Arc и Dia продолжат работать как сейчас.
• Постепенно появится глубокая интеграция с Atlassian-продуктами.
• Команды объединятся, чтобы масштабировать идею «браузера для работы».

Мы верим, что совместно сделаем работу более продуктивной и приятной.

• Arc был признан инновационным браузером для продвинутых пользователей, но рост остановился и команда переключилась на новый проект Dia с ИИ, вызвав шквал критики.
• Пользователи считают отказ от Arc ошибкой: продукт нравился, но монетизировать его оказалось сложно.
• Покупка Atlassian за $610 млн наличными выглядит странно: стратегического перекрытия продуктов нет, выручки у TBC не было.
• Многие опасаются, что Arc «умрёт» под крылом Atlassian, и уже переходят на Zen или Firefox.
• Общий вывод: это похоже на дорогой acqui-hire или ставку на «AI-агентов» в корпоративной экосистеме Atlassian.

Le Chat: 20+ MCP-коннекторов и Memories

• Каталог коннекторов (beta)
  20+ безопасных интеграций: Databricks, Snowflake, GitHub, Jira, Notion, Asana, Outlook, Box, Stripe, Zapier и др.

  • Поиск, анализ, действия в одном чате.
  • Добавьте собственные MCP-коннекторы.
  • Запуск в браузере, мобильном, on-prem или вашем облаке.

• Memories (beta)
  Персонализированные ответы на основе сохранённых фактов и предпочтений.

  • Контроль: хранить, править, удалять.
  • Импорт из ChatGPT.

• Бесплатно для всех пользователей.

Категории коннекторов

• Данные: Databricks, Snowflake, Pinecone, Prisma Postgres, DeepWiki.
• Продуктивность: Box, Notion, Asana, Monday, Jira, Confluence.
• Разработка: GitHub, Linear, Sentry, Cloudflare.
• Автоматизация: Zapier, Brevo.
• Коммерция: PayPal, Plaid, Square, Stripe.
• Custom: любые MCP-серверы.

Примеры

• Анализ отзывов в Databricks → задача в Asana.
• PR в GitHub → задача в Jira + документация в Notion.
• Сравнение контрактов в Box → краткий отчёт обратно в Box.
• Jira → спринт-обзор в Confluence.
• Stripe → аномалии → задача в Linear.

Управление и безопасность
Админы определяют доступ, аутентификация от имени пользователя.
Развёртывание: self-hosted, ваше облако или Mistral Cloud.

• Пользователи жалуются на провал gpt-5-mini и переходят на mistral-medium-0525: дешевле, быстрее, но при ошибке «падает жёстче».
• Mistral анонсировала 20+ «безопасных» MCP-коннекторов (S3, FTP, SharePoint и др.) и поддержку кастомных удалённых коннекторов.
• Валютация в $14 млрд выглядит низкой против OpenAI/Anthropic; для европейцев главный плюс — «сделано в ЕС».
• Качество моделей: в чате и простых задачах сравнимо с OpenAI, но уступает топ-версиям; скорость реакции высокая.
• Бесплатный тариф и быстрый релиз новых фич отмечают как плюсы, однако многие так и не пробовали Mistral всерьёз.