Hacker News Digest

Red Hat подтвердила инцидент безопасности после заявлений хакеров о взломе их репозиториев на GitHub. Хакеры из группы CyberNiggers утверждают, что получили доступ к внутренним системам компании через скомпрометированные токены GitHub, что позволило им скачать исходный код проприетарных проектов, включая инструменты для управления инфраструктурой. Компания заявила, что расследует ситуацию, но пока не обнаружила признаков компрометации production-среды или клиентских данных.

Инцидент подчеркивает растущие риски, связанные с утечками токенов доступа к платформам разработки. Red Hat уже отозвала затронутые учетные данные и усилила мониторинг активности. Хакеры угрожают опубликовать украденные данные, если их требования не будут выполнены, хотя конкретные детали вымогательства не раскрываются.

• Хакеры заявили, что пытались связаться с Red Hat с требованием выкупа, но получили только шаблонный ответ с инструкцией отправить отчет об уязвимости в отдел безопасности.
• Взлом произошел в экземпляре GitLab, используемом Red Hat Consulting, а не в GitHub, как изначально сообщалось.
• Участники обсуждают противоречие между официальными заявлениями Red Hat о безопасности (ISO27001) и реальной практикой хранения данных.
• Высказываются мнения, что инцидент может быть следствием бюрократии и человеческого фактора, а не политики IBM.
• Обсуждается ирония ситуации: компания, проповедующая безопасность, сама стала жертвой утечки данных.

Как работает OAuth
Вместо передачи логина-пароля стороннему приложению OAuth выдаёт токен доступа — персональный «ключ» для конкретного пользователя. Приложение использует его, чтобы действовать от имени пользователя без доступа к его паролю.

Классический поток

1. Пользователь нажимает «Подключить банк» в YNAB.
2. YNAB открывает браузер с URL провайдера (например, банка), куда добавляет client_id, redirect_uri, scope и случайный state.
3. Пользователь логинится у провайдера и разрешает доступ.
4. Провайдер перенаправляет обратно в YNAB с кодом авторизации.
5. YNAB обменивает код на токен доступа через безопасный back-end-запрос.
6. С токеном YNAB запрашивает данные счёта.

PKCE
Для мобильных и SPA добавляют code_challenge и code_verifier, чтобы перехват кода не дал злоумышленнику токен.

Refresh-токены
Короткоживущий access token можно обновлять долгоживущим refresh token без повторного логина.

Итог
OAuth разделяет аутентификацию и авторизацию: пользователь доверяет провайдеру, провайдер — приложению, приложение получает минимально необходимые права.

• Участники жалуются, что OAuth/OIDC кажутся простыми, но реальная реализация требует чтения спецификаций и RFC, а поверхностных гайдов мало.
• Несколько человек подтвердили: приходится самим собирать знания из RFC, OIDC-документов и собственных заметок.
• Упомянуты полезные ресурсы — гайд Alex Bilbie, книга Aaron Parecki, страницы Mozilla и RFC-примеры.
• PKCE считается не «менее безопасным», а способом защитить целостность потока; просят отдельный материал о нём.
• Критика стандарта: OAuth 2.0 «скелет протокола», с множеством опциональных частей и историческими уязвимостями.

Краткий обзор
Повторяя подход победителей ARC-2024, я заметил: чем меньше модель уверена в пикселе, тем выше шанс ошибки. Авторегрессия заставляет «писать» решение слева-направо, как печатать на машинке без возврата.

Я переделал Qwen3-8B в диффузионный режим: сначала заполняем «лёгкие» токены, потом сложные. На 10 шагах модель быстрее и точнее по пикселям, но решает не больше задач. На 30 шагах точность совпадает с базовой, а время выше — из-за отсутствия кеширования.

Как работает генерация

1. Кодируем вход как обычный LLM.
2. Случайно маскируем 80 % выходных токенов.
3. На каждом шаге модель предсказывает маскированные токены; выбираем наиболее вероятные и «размаскиваем».
4. Повторяем, пока не останется масков.

Почему +1 % к пикселям ≠ +1 % к задачам
ARC требует абсолютного совпадения всей сетки. Даже 1 ошибка = 0 баллов. Диффузия чаще «почти» правильна, но «почти» не считается.

Технические детали

• Архитектура: обычный декодер → полносвязный «энкодер» без кэша.
• Обучение: 1 эпоха, lr 5e-5, batch 64, маскирование 80 %, аугментации поворот/отражение.
• Данные: 400 задач ARC + 800 синтетических, длина фиксирована 4096 токенов.

Результаты на eval-2025

Метод	Время	Точн. токенов	Решено задач
Авторегрессия	1×	94 %	21 %
Диффузия 10 шагов	0.6×	95 %	19 %
Диффузия 30 шагов	1.3×	94 %	21 %

Следующие шаги

• Вернуть кеш входных токенов, ограничив пересчёт скрытых состояний.
• Увеличить шаги до 50–100 при сохранении скорости.
• Попробовать «гибрид»: диффузия для грубой раскладки, авторегрессия для деталей.

• @radarsat1 предложил добавить в генерацию LLM «токен backspace» для отмены уже выданных токенов, но @imtringued и @_diyar отметили, что при обычной однонаправленной архитектуре это сводится к возврату к прежнему состоянию и не решает проблему.
• @dev_hugepages указал на исследование (2306.05426), где такой механизм уже реализован в рамках IL-обучения.
• @mNovak отметил, что диффузионная модель решает головоломки итеративно, но «раскрывает» слишком мало токенов за ход, тратя лишние раунды.
• @namibj подчеркнул необходимость механизма «retraction», чтобы избежать застревания на ошибочных решениях.
• @twotwotwo заметил парадокс: люди чаще редактируют код, а LLM генерируют его целиком, что делает правку затратной.