Hacker News Digest

Вышли внеплановые критические патчи GitLab для Community и Enterprise Edition: версии 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 и 18.11.13. Всем, кто разворачивает GitLab самостоятельно, настоятельно рекомендуют немедленно обновиться. Облачный GitLab.com уже работает на исправленной версии, а арендаторы GitLab Dedicated на 19.3.5-internal0 и 19.4.2-internal0 и новее защищены и могут ничего не делать.

Патч закрывает несколько уязвимостей. Самая серьёзная — критическое целочисленное переполнение в компиляторе регулярных выражений. Далее идут уязвимости высокой степени риска: некорректная аутентификация при автосвязывании учётных записей через OmniAuth и LDAP по email, а также отравление кэша в эндпоинтах обнаружения OAuth/OIDC. Средний уровень риска — неправильный контроль доступа к полю email в GraphQL для рабочих элементов, неполное применение блокировки членства SAML/LDAP на уровне инстанса, позволяющее несанкционированно добавлять участников, и раскрытие внутренних учётных данных в заголовках ответов. Детали уязвимостей раскроют через 90 дней после выпуска.

Патч содержит миграции базы данных: на одноузловых установках обновление пройдёт с простоем, а на многоузловых при соблюдении процедур обновления без простоя — без него. Обычные миграции входят в 19.4.3 и 19.3.6, пост-развёртываемые — в 19.4.3.

Обсуждение дополняет новость о критических патчах GitLab. Пользователи @molf и @zahlman пояснили, что уязвимость вызвана ошибкой в движке регулярных выражений Ruby (onigmo), а не в самом GitLab. @miduil сообщил о еще одной проблеме с regex, позволяющей неавторизованно обращаться к эндпоинту, однако @dvdkon уточнил, что для этого нужна аутентификация и загрузка вредоносного org-mode файла. @artooro, @merb и @mqus отметили, что встроенный проверщик обновлений GitLab часто ошибочно требует обновления даже после установки последней версии, а его отключение занимает много времени. Для быстрой проверки версии на узлах @beaconflint рекомендует команду `gitlab-rake gitlab:env:info`. @yoyohello13 и @131hn заметили, что из-за еженедельных патчей ручное обновление стало невозможным, поэтому советуют использовать AI-агентов или автоматические CI-процессы. @minraws в связи с рисками самохостинга рекомендует строго фильтровать исходящий трафик (например, через Tailscale). @tptacek указал, что оценка CVSS 10.0 без контекста не отражает реальный уровень риска. В то же время @hobofan и @choilive поспорили о влиянии ИИ на безопасность: первый считает текущую ситуацию худшей в истории ИТ из-за массовых уязвимостей, второй — началом «золотого века» с ростом инвестиций в автоматизированные сканеры.

Переписав JSONPath из Rust в Zig, я оценил простоту и скорость Zig, но столкнулся с рядом непривычных моментов. IDE-поддержка оказалась слабой: только подсветка и базовое автодополнение, что заставило вернуться к работе через терминал. Однако система сборки build.zig оказалась удобной и гибкой — позволяла легко запускать тесты, отладку и проверку соответствия стандарту. Это даже вдохновило на переход на минималистичный стек: Helix + Alacritty + Zellij.

Структура проекта в Zig поощряет плоскую иерархию файлов — в отличие от Rust, где дробление на модули привычно, здесь вложенные папки создают трения при импорте без явной выгоды. Оказалось проще держать связанный код в одном файле и navigировать по разделам. При реализации столкнулся с нюансами управления памятью: в Zig нужно явно дублировать строки перед добавлением в вектор и использовать errdefer для очистки при неудаче — в Rust такая ситуация невозможна благодаря семантике move. Экосистема пока молода: отсутствуют зрелые библиотеки (например, regex без Unicode-свойств), а стандартная библиотека меняет API между версиями. Несмотря на это, Zig оставил впечатление современного, быстрого и перспективного языка — потенциального преемника C, который стоит развивать дальше.

Zig — молодой язык с потенциалом как преемник C, но его слабая IDE-поддержка, отсутствие автоматических деструкторов и фокус на аллокаторах вызывают сомнения в пригодности для продакшена. Rust уже обеспечивает безопасность памяти без GC и считается зрелым выбором для коммерческих проектов. Спор: Zig не требует мутаций из-за аллокаторов — иммутабельность возможна при явной передаче аллокатора. Мутация — выбор программиста, не требование языка. Спор: Отсутствие автоматических деструкторов в Zig критикуют как 'dead-end', но Rust также использует мутации под капотом, скрывая их за иммутабельным интерфейсом. Согласны: Rust — единственный язык, сочетающий высокую производительность, нулевой runtime-overhead и безопасность памяти без GC, незаменимый для продакшена. Совет: В Zig arena-аллокация с defer arena.deinit() упрощает управление памятью в циклах. Спор: IDE-поддержка Zig (ZLS) нестабильна несмотря на LSP — реальная проблема для разработчиков, привыкших к полноценным IDE. Спор: Для архивного порта K&R C C23 предпочтительнее Zig из-за минимальных изменений и стабильности; Zig слишком нестабилен для таких целей. Совет: LLM эффективен для перевода кода между языками, если поведение можно автоматически проверить — снижает риски. Согласны: Современные C-преемники (Zig, Odin, Jai) страдают от одержимости аллокаторами — полезно в нишевых сценариях, но не масштабируется на общие задачи. Спор: Цепочки итераторов в Rust критикуют как 'gaslighting', но защищают как нулевую стоимость абстракций — читаемость зависит от привычки. Согласны: Zig быстр и современен, но незрел из-за незавершённого синтаксиса, слабой инструментальной поддержки и отсутствия стандартов — в отличие от зрелого Rust. Совет: В Helix отсутствует сворачивание кода — затрудняет навигацию по большим файлам Zig, важно при выборе редактора. Согласны: Rust решает управление памятью на этапе компиляции без GC — несмотря на долгую компиляцию, надёжен для командной разработки. Совет: В Zig запуск конкретных тестов через build.zig проще, чем рутинные подходы в других языках — фильтрация по имени экономит время. Спор: Аналогия с выбором блюда в ресторане ошибочна, если есть инструменты (переводчик); в незнании выбор должен быть консервативным.

Клод стал заменять «load‑bearing» и «honest take» на странные фразы, и пользователи ищут способ обойтись этим. Решение — перехватить вывод через хук MessageDisplay и подменить набор слов, чтобы они звучали абсурдно или исчезли. В примере используется небольшой Python‑скрипт с replacements: «seam» → «whatchamacallit», «you're absolutely right» → «I'm a complete clown», «honest take» → «spicy doodad», «load‑bearing» → «cooked». Скрипт читает JSON‑ввод, применяет регулярные замены с флагом re.IGNORECASE и границами слов, чтобы замены срабатывали только целиком.

Чтобы подключить, файл сохраняют в ~/.claude/hooks/wordswap.sh, делают исполняемым и добавляют в settings.json запись, указывающую на скрипт. После перезапуска сессии Claude выводит, например, «cooked seam» вместо «load‑bearing seam» и «spicy doodad» вместо «honest take». На форуме обсуждают, что такие «переводы» уже помогли более 5 000 участникам избавиться от раздражителя, превращая его в комичный «whatchamacallit». Выбирайте свои замены — например, «grilled» вместо «cooked» или «flaming marshmallow» вместо «spicy doodad» — и наслаждайтесь новым стилем общения. Тема набрала более 300 комментариев, где участники делятся своими наборами замен и шутками. Некоторые даже используют её для создания персонализированных стикеров в чатах.

• Люди раздражаются из‑за повторяющихся «клаудизмов», которые модель использует в любом контексте
• Большинство ищут способы ограничить такие фразы через CLAUDE.md или собственные подсказки
• Психологически раздражает, когда ИИ «застревает» в предсказуемом стиле, в отличие от человеческого вариативного голоса
• Некоторые считают эти паттерны полезными сигналом ИИ‑содержимого, но хотят, чтобы модель могла адаптировать стиль под задачу

• CSS

  • min-width: auto (по умолчанию) имеет приоритет над flex-shrink, overflow: hidden, width: 0; задайте min-width: 0.
  • Горизонталь и вертикаль различаются: width: auto растягивается, height: auto по содержимому; margin: 0 auto центрирует по горизонтали, но не по вертикали (в flex-direction: column работает).
  • BFC (display: flow-root) предотвращает схлопывание margin и «обнуление» высоты родителя с float-потомками.
  • Новый stacking context создают transform, filter, opacity, position: fixed/sticky, z-index + absolute/relative и др.; z-index действует только внутри контекста.
  • На мобильных 100vh включает скрытые панели; используйте 100dvh.
  • position: absolute ориентируется на ближайший «positioned» ancestor, а не на родителя.
  • float не работает внутри flex/grid-родителя.
  • Процентные width/height не работают, если размер родителя не задан.
  • display: inline игнорирует width, height, вертикальные margin.
  • Пробелы между inline-block элементами рендерятся; в flex/grid — нет.
  • box-sizing: content-box (по умолчанию) не включает padding/border; включите border-box.
  • Указывайте width/height у <img> для предотвращения CLS.
  • Загрузка файлов не показывается в DevTools; используйте chrome://net-export/.
  • Внутри <script> строка </script> ломает парсинг.

• Unicode

  • Отличайте code point и grapheme cluster (последнее — то, что видит пользователь).

• Маршрутизаторы могут тихо обрывать простаивающие TCP-соединения; настройте TCP-keepalive или HTTP-заголовки.
• Возвращать null из Optional<T> — антипаттерн; Kotlin и аннотации уже решают это.
• UTF-16 в Java/C#/JS — деталь реализации; в Go строки — просто байты.
• min-width: auto работает не везде; CSS-свойства нельзя читать изолированно.
• Регексы, YAML, LF/CRLF, rm -rf $DIR/ — каждый язык/платформа имеет свои подводные камни.