Hacker News Digest

Simon Tatham обнаружил, что обновление Linux-клиента Zoom до версии 7.1.5 привело к активному чтению всего содержимого X11-буфера обмена (CLIPBOARD selection) сразу после его изменения, что ранее не наблюдалось в версии 6.6. Это создаёт угрозу конфиденциальности, особенно если буфер используется менеджером паролей для передачи учётных данных, поскольку Zoom теперь автоматически запрашивает вставку содержимого буфера при каждой смене его владельца, вероятно, через расширение XFIXES.

Проблема проявляется при использовании однократных инструментов вставки (one-shot paste), которые завершают работу после выполнения одного запроса на вставку — теперь они прерываются сразу же, так как Zoom перехватывает буфер и инициирует собственный запрос на вставку. Tatham отмечает, что в X11 можно обойти эту проблему через автопечать (autotype), не задействуя буфер обмена, тогда как в Wayland такой обход невозможен, и любое приложение с доступом к буферу может читать его содержимое, делая уязвимость системной в данном окружении. Обсуждение в комментариях подтверждает, что Wayland не решает проблему, а лишь меняет её контекст.

Проблема доступа Zoom к буферу обмена в Linux вызвана уязвимостью X11 — устаревшего механизма, не отвечающего современным требованиям конфиденциальности. В Linux отсутствует стандартизированная система разрешений (как в Android) из-за обилия ПО и отсутствия централизованного контроля, поэтому проприетарным приложениям с сетевым доступом нельзя доверять. Снижение доверия к Zoom также связано с историей нарушений, например, использованием открытых TCP-портов как backdoor на macOS. Способы минимизации рисков: — Использовать веб-клиент (браузер блокирует доступ к буферу по умолчанию) или Jitsi (открытая альтернатива без проприетарного клиента). — Установить Qubes OS для изоляции Zoom в отдельной виртуальной машине. — Отключать Zoom сразу после встречи. — В Wayland использовать wl-copy вместо xclip для более контролируемой работы с буфером. Спорные моменты: — Wayland считается безопаснее, однако попытки ограничить доступ к буферу могут привести к появлению окон захвата фокуса, воссоздавая уязвимость. — Дискутируется необходимость root-доступа для Zoom: одни считают его удобным для установки, другие — излишним для видеоконференций. Пользователям с лицензированными университетскими аккаунтами рекомендуется проверить, не нарушает ли поведение клиента соглашения о конфиденциальности.

Чтобы проверить, действительно ли оптимизации снижают вводную задержку в играх под Linux, я построил аппаратный измеритель. На монитор крепится фотосенсор, а на микроконтроллере Adafruit QT Py RP2040 имитируется клик мыши с частотой 1000 Гц. При нажатии устройство собирает около 12 000 проб из фотодиода с интервалом ≈ 24 мкс и передаёт их по USB в CSV‑лог. На хосте из этих данных вычисляется время от отправки клика до первого заметного изменения яркости экрана — то есть полная системная задержка.

Тестировал я три сценария: X11 против нативного Wayland, включённый/выключенный VRR и использование форка DXVK с низкой задержкой. Нативный Wayland показывает почти ту же задержку, что и X11 (≈ 7 мс), тогда как XWayland удваивает её, добавляя около 2,1 мс. При включении X11, VRR и low‑latency‑DXVK медиана latency падает на 0,72 мс, а jitter резко снижается благодаря более стабильному темпу рендеринга. Эти цифры подтверждают, что отказ от XWayland и включение VRR дают измеримый выигрыш, а остальные «тюнинг‑трюки» работают лишь при определённых условиях.

• Автор измерил вводную задержку в Linux‑системах, сравнив X11, XWayland, Wayland‑композиторы и Windows‑подобные конфигурации.
• Выяснилось, что XWayland добавляет заметную (≈3 мс) задержку, тогда как современные Wayland‑реализации почти не уступают по скорости.
• Обсуждатели отмечают, что измерения при 500 Гц скрывают реальные различия, а на обычных 60–120 Гц результаты могут выглядеть иначе.
• Комментарии варьируются от восхищения результатами и предложений улучшать тесты до вопросов о влиянии дистрибутивов, драйверов и игровых движков.

Joshua Blais глубоко интегрирует Emacs в свою рабочую среду, используя его для практически всех задач, кроме работы с видео. Он выбрал Hyprland в качестве оконного менеджера, отмечая его простоту настройки и отсутствие лагов в Wayland-режиме, в отличие от GNOME, где приходилось запускать Emacs в X11. Его цель — создать бесшовную среду, где мысли мгновенно превращаются в действия.

Автор рассматривал EXWM как оконный менеджер, но отказался от идеи из-за однопоточности Emacs (риск зависания всей системы) и привязки к X11, в то время как развитие Linux движется к Wayland. Для ускорения workflows он создал кастомный лаунчер на Go, который ускорил его работу в 10 раз. Текущая настройка включает vterm в качестве терминала по умолчанию, универсальный лаунчер, org mode для заметок, менеджер паролей, почту, чтение лент и музыку — всё внутри Emacs.

• Спор о влиянии инструментов на творчество: одни утверждают, что свобода от инструментов раскрывает потенциал профессионалов, другие считают это заблуждением, подчеркивая важность качества инструментов.
• Критика дистрибутивов типа Doom Emacs и Spacemacs: пользователи отмечают их полезность для новичков, но указывают на ограничения при глубокой кастомизации и конфликт с личными предпочтениями.
• Технические ограничения Emacs: обсуждение проблем с EXWM (конфликт клавиш, однопоточность) и TRAMP для удаленной разработки, а также сравнение с современными редакторами вроде Helix.
• Философия кастомизации: Emacs ценится за возможность полной настройки через Elisp, но это требует времени и усилий, что отпугивает некоторых пользователей.
• Альтернативы и будущее: предложения о создании единого универсального редактора, критика текущей модели с множеством "окон в окнах" и поиск баланса между простотой и гибкостью.

Выпущены исправления для трех критических уязвимостей в X.Org X server и Xwayland. Обновления xorg-server-21.1.19 и xwayland-24.1.9 исправляют проблемы, существовавшие в предыдущих версиях. Все три уязвимости (CVE-2025-62229, CVE-2025-62230 и CVE-2025-62231) были обнаружены Jan-Niklas Sohn при сотрудничестве с Trend Micro Zero Day Initiative.

Первая уязвимость связана с use-after-free при создании XPresentNotify структур, вторая - с некорректным удалением Xkb клиентских ресурсов, а третья - с переполнением значения в XkbSetCompatMap(). Две из этих проблем существуют с версии X11R6, что подчеркивает их серьезность. Все исправления уже доступны в репозиториях, и пользователям рекомендуется немедленно обновить системы для предотвращения потенциальных атак.

• В обсуждении поднимается вопрос о том, что X11/X.Org уязвим к трем недавно обнаруженным уязвимостям, и что это может быть последней каплей, которая убедит окончательно перейти на Wayland.
• Участники обсуждают, что X11 не имеет никаких механизмов безопасности, и что это не может быть исправлено без полной переработки.
• Некоторые участники высказывают мнение, что X11 устарел и что усилия по его поддержке были бы лучше направлены на другие проекты.
• Также обсуждается, что X11 не может быть защищен от вредоносного клиента, и что это не может быть исправлено без полной переработки.

Fynedesk — это полноценная десктопная среда для Linux/Unix, построенная на основе инструментария Fyne. Она предлагает минималистичный интерфейс с акцентом на простоту и производительность, используя Go для кросс-платформенной разработки. Проект включает стандартные компоненты: панель задач, меню приложений, управление окнами и настройки темы, что делает его готовым к повседневному использованию.

Ключевое преимущество — лёгкость кастомизации и расширения благодаря модульной архитектуре и чистой кодовой базе на Go. Это позволяет разработчикам быстро адаптировать или дополнять функциональность под свои нужды. Fynedesk позиционируется как альтернатива тяжёлым средам вроде GNOME или KDE, особенно для ресурсоограниченных систем или пользователей, ценящих скорость и минимализм.

• Обсуждение фокусируется на поддержке Wayland в FyneDesk, с ожиданием её реализации в будущих версиях и критикой текущей зависимости от X11.
• Участники отмечают потенциал проекта как современной кроссплатформенной среды на Go, но выражают озабоченность по поводу скорости разработки и активности коммитов.
• Поднимаются вопросы о мотивации и статусе разработки (хобби, коммерческий или академический проект), а также о простоте использования и настройки.
• Обсуждаются технические аспекты: производительность, возможность кастомизации, сравнение с другими средами и работа на мобильных устройствах.
• Некоторые пользователи выражают скептицизм, считая проект устаревшим или игрушечным без поддержки Wayland, в то время как другие защищают его и призывают к поддержке.

System76 выпустила бета-версию Pop!_OS 24.04 LTS с новой средой рабочего стола COSMIC, полностью разработанной внутри компании. Ключевые изменения включают замену стандартных GNOME-приложений на COSMIC-аналоги: Files, Terminal, Text Editor и Media Player, а также обновлённый магазин приложений COSMIC Store. Для установки требуется отключить Secure Boot в BIOS, рекомендуется минимум 4 ГБ ОЗУ и 16 ГБ места.

Известные проблемы беты: несохранение избранных приложений из предыдущей версии, временное отключение PPA при обновлении, ограниченная поддержка перетаскивания файлов между Wayland и X11-приложениями. Также ожидаются баги в играх и отсутствие экранной подсказки для переключения дисплеев. Выпуск финальной версии намечен после исправления ошибок.

• Пользователи положительно оценивают новый рабочий стол Cosmic DE за его функциональность, включая панель на всех экранах и улучшенное управление окнами, по сравнению с GNOME.
• Некоторые пользователи выражают скептицизм относительно готовности Cosmic DE к релизу, отмечая проблемы с драйверами Nvidia, отсутствие поддержки Secure Boot и ARM64, а также сыроватый интерфейс.
• Многие пользователи успешно используют Pop!_OS на старом оборудовании (например, MacBook Pro 2014 года), хотя иногда требуется ручная настройка Wi-Fi и других компонентов.
• Обсуждаются преимущества Pop!_OS, такие как предустановленные драйверы Nvidia в Live ISO и режим тайлинга, а также сравнивается Cosmic с другими средами, такими как Hyprland и Sway.
• Высказываются опасения, что небольшой команде System76 может не хватить ресурсов для долгосрочной поддержки собственной среды рабочего стола, и отмечается медленный темп разработки.

На Linux Ctrl-C/Ctrl-V в терминале не работают, потому что Ctrl нужен для управляющих кодов. Приходится жать Ctrl+Shift+C/V. К 2025 году появится универсальное решение без лишнего ПО: старые коды клавиш Copy и Paste, которые Linux «знает» с древности.

Как это работает

1. Клавиатура
   Программируемые клавиатуры (System76 Launch, Framework 16, ZSA Moonlander, Keychron Q10 и др.) позволяют назначить на любую клавишу слой, где C = Copy, V = Paste. Для активации слоя удерживается модификатор (например, «Raise» на моей Corne).

2. Прошивка и конфигураторы
   Производители дают свои утилиты (System76 Keyboard Configurator), а Vial поддерживает множество моделей. В слое можно вывести Copy/Paste на C/V, стрелки на домашний ряд и прочие удобства.

3. ПО Linux
   Приложения опираются на GUI-тулкиты GTK и Qt.

   • GTK добавил поддержку Copy/Paste-кодов в январе 2025.
   • Qt внедрит их в версии 6.10 (сентябрь 2025).

Совокупность программируемого «железа» и обновлённых тулкитов даст единые горячие клавиши Copy/Paste во всех приложениях Linux без дополнительных твиков.

• Участники жалуются на разнообразие клипбордов в Linux (X11, Vim, tmux) и их несогласованность.
• В терминалах приходится добавлять Shift к Ctrl-C/Ctrl-V, что ломает мышечную память и вызывает ошибки.
• Apple решает конфликт отдельным Cmd-ключом, но даже там приложения перехватывают сочетания непредсказуемо.
• Многие используют альтернативы: Ctrl/Shift-Insert, выделение + средняя кнопка мыши, ремап клавиш, покупку программируемых клавиатур.
• Единого механизма объявления и настройки шорткатов в Linux нет, поэтому Chrome и другие приложения игнорируют системные привязки.

StarDict — кроссплатформенный словарь GPLv3 — при работе в X11 по умолчанию пересылает выделенный пользователем текст по нешифрованному HTTP на два китайских сервиса: YouDao и dict.cn.

Проблема обнаружена Винсентом Лефевром 4 августа 2025 года при подготовке к Debian 13. Пакет stardict-plugin, который ставится автоматически, содержит плагин YouDao. Функция «scan» (включена по умолчанию) отслеживает выделение мышью и отправляет текст на серверы без шифрования.

На Wayland уязвимости нет: система блокирует чтение чужих выделений, но и «scan» не работает.

Сопровождающий Debian Сяо Шэн Вэнь считает поведение допустимым: функции можно отключить. Лефевр возражает: конфиденциальные возможности не должны быть активны по умолчанию.

Описание пакета упоминает «scan», но не говорит, что YouDao — онлайн-сервис. Сяо предложил вынести сетевые плагины в отдельный пакет, но сомневается в необходимости.

Аналогичные проблемы сообщались в 2009 и 2015 годах; тогда отключили сетевые словари по умолчанию, но плагин YouDao (добавлен в 2016) игнорирует эту настройку.

• Пакет StarDict по умолчанию отправляет выделенный текст на китайские серверы по нешифрованному HTTP.
• Мейнтейнер Debian отмахнулся: «в описании пакета всё написано, RTFM».
• Пользователи возмущены: словарь можно было сделать полностью локальным (≈ 400 МБ), а поведение — опциональным.
• Уязвимость годами игнорировалась, баг-репорты закрывались как «небаг».
• Сообщество требует исключить StarDict из репозиториев и пересмотреть политику мейнтейнеров.

Как приложение получает фокус в Wayland
В X11 окно могло «захватить» внимание само; в Wayland это невозможно. Приложение может лишь получить фокус, если композитор одобрит запрос. Для этого используется протокол XDG Activation.

1. Приложение-источник (например, мессенджер) запрашивает у композитора токен активации.
2. Токен передаётся целевому приложению через переменную окружения XDG_ACTIVATION_TOKEN или поле activation-token в DBus.
3. Получив токен, приложение просит композитор активировать своё окно.
4. Композитор проверяет подлинность: наличие токена, серийный номер события, ID приложения и т.д. При сомнении запрос отклоняется.

Готовые решения в KDE/Qt

• QWindow::requestActivate() сама использует токен из окружения или запрашивает новый.
• OpenUrlJob, ApplicationLauncherJob, KDBusService уже умеют работать с токенами.
  Благодаря этому большинство KDE-приложений работают без изменений.

Почему X11 не идеален
У KWin-X11 была «защита от кражи фокуса», но она опиралась на эвристики и могла быть обойдена.

Тестируем правильность
В свежем KWin включите «Extreme»-режим предотвращения кражи фокуса: окно поднимется только при валидном токене. За последние дни исправлены:

• Dolphin терял токен при новом запуске;
• KRunner, Kickoff и прочие плазмоиды не запрашивали токен;
• LayerShell-Qt теперь читает переменную и запрашивает активацию при показе;
• привилегированные клиенты (Plasma, KGlobalAccel) могут получать токены;
• нажатия модификаторов больше не считаются «пользовательским взаимодействием».

Спецификация DBusRunner получила метод SetActivationToken, который теперь используют Baloo и KClock для корректного открытия файлов в уже запущенных окнах.

• Пользователи рады, что Wayland запрещает приложениям «воровать» фокус, в отличие от X11/macOS/Windows, где авто-обновления и всплывающие окна прерывают работу.
• Некоторые жалуются: из-за новых правил пароли и другие важные диалоги прячутся под окнами, пока не всё ПО перейдёт на XDG Activation.
• Дискуссия о том, кто должен решать передачу фокуса: само приложение, оконный менеджер или пользователь.
• Название «Window Activation» ввело в заблуждение: многие ждали статью о лицензировании Windows.