У цій новині чудово все.
Популярний редактор, Claude Code і прокидання ssh-тунелю прямо до своєї машини.
Чого вже там розмінюватися на дрібниці та збирати дані.

Компрометація офіційного доповнення Claude Code для VS Code від компанії Anthropic.

Згадав кумедний ланцюжок подій.
Пише мені якось колега, з питанням, мовляв, чому у нас на другорядному сервері GitLab доступ закритий не тільки для сторонніх, але й ще, не вдаючись до деталей, Front-end закритий директивою auth_basic у Nginx?
На що я пожартував, що якщо дуже заважає жити, то можемо відключити для пула твоїх IP, робочих/домашніх. Ну чи сам відкрий, тиж теж адмін.

На тому й вирішили.
Проходить буквально тиждень та прилітає Critical patch release.

GitLab issues emergency patch: GitLab випустив екстрене виправлення для критичної вразливості CVE-2026-19478 з оцінкою серйозності 9.4 із 10.
І мене це тоді посміхнуло. Ще через кілька днів приходить Alert про ще одне критичне оновлення.

Добре поповнення колекції.
Новинам треба дати настоятися, після чого смакувати деталі.

• Red Hat, RED HAT, КАРЛ!
• GitHub Actions, як завжди.
• NPM, до цього вже звикли.
• Arch User Repository, вже цікавіше.

Минуло лише пів року, але стрічка новин не переставала приносити нові кумедні вразливості.
Як завжди, я не акцентую увагу на системних вразливостях snapd / Rust Coreutils / Flatpak, ядрі (Copy Fail, Dirty Frag, Fragnesia, pidfd, PinTheft, GRO Frag) або AppArmor.

Якими б небезпечними вони не були - вони “умовно” пасивні, тобто за їх наявності потрібна низка факторів і активних дій зсередини чи ззовні для успішної експлуатації.

Мені набагато цікавіше стежити за поширеннями шкідливого коду в системах розповсюдження пакетів, бібліотеках та інших репозиторіях.

Тому що це стосується “активних” і безпосередніх атак, їм майже не потрібно поєднання певних факторів, після завантаження вони відразу ж вразять репозиторій розробника, далі зберуть його персональну / фінансову / авторизаційну інформацію, а після цього продовжать діяти по ланцюжку на всіх серверах, до яких у нього був доступ.

Продовжуючи попередні нудні опуси на тему ізоляції оточень, саме час пригадати про wayland.
Звичайно, це не заклик до дії, а лише приклади та роздуми.
Сам я дотримуюся філософії, де центр системи це користувач, і він має право налаштовувати все так, як він вважає за потрібне, а не так як це нав’язується загальними тенденціями, або як це реалізовано в конкретному дистрибутиві, разом з цим розуміючи і приймаючи всі ризики та наслідки цих дій.
Як то кажуть, “If you know what you are doing”.

І перш ніж розпочати, знову варто написати, що:

• Так, я розумію, що це дуже поверхово.
• Так, ніякі підключення до локальної графічної оболонки не припустимі для чогось небезпечного, і потрібно використовувати vnc або virt-viewer/spice.
• Непривілейований LXC слід замінити на Xen / KVM
• І так, я знаю, що з KVM ізоляції також можна вийти.
• І про Flatpak я теж знаю.
• І, нарешті, так, я знаю про Qubes OS та її архітектуру, можна сказати, з моменту її появи, а це 2010 рік.

І, дещо спрощуючи та адаптуючи ідеї QubesOS під свої повсякденні завдання, я віддаю перевагу в основному використати або інших локальних юзерів, або досить легковажні оточення LXC.

І так, у них я запускаю не щось потенційно небезпечне, а те, що багато хто з вас використовують безпосередньо під своїм акаунтом у системі, наприклад:

• Firefox для повсякденного використання та перегляду “чого завгодно”.
• Декілька проектів, які використовують пакети з PyPI, RubyGems.
• Окремо те, що я збираю з сорців з того ж GitHub.
• Сторонні програми element-desktop, Telegram, Zoom.