Poetry 2.4.2 закрив два шляхи виходу файлів за межі каталогу

Poetry 2.4.2 виправляє три помилки на межі між менеджером залежностей і недовіреними пакетними джерелами. Дві з них могли дозволити записати файл за межами очікуваного каталогу, а третя — встановити артефакт, якого фактично немає у lock-файлі. Реліз опубліковано 29 серпня 2026 року як стабільне patch-оновлення. Для команд, які використовують приватні індекси, дзеркала або встановлюють пакети в CI, це оновлення варто трактувати як безпекове.

Завантаження не повинно визначати шлях на диску

Перше виправлення стосується завантаження файлів із скомпрометованого URL або package source. Якщо ім’я чи шлях із відповіді віддаленого сервера без належної нормалізації потрапляє у локальний filesystem path, конструкції на кшталт переходу до батьківського каталогу можуть вивести запис за межі тимчасової директорії. Наслідок залежить від прав процесу Poetry: у контейнері це може бути робоче дерево, cache або змонтований секрет; на workstation — файли користувача, доступні поточному обліковому запису.

Сам факт використання HTTPS не усуває ризик. TLS підтверджує канал і сервер, але не гарантує, що registry не зламаний, proxy не налаштований помилково, а опублікований пакет не є ворожим. Коректний клієнт має сам перевіряти кінцевий шлях після декодування й нормалізації та відхиляти будь-яку спробу вийти з дозволеного каталогу.

Окремий ризик у розпакуванні sdist

Друге виправлення закриває path traversal під час розпакування source distribution. У release notes окремо названі Python 3.10.0–3.10.12 і 3.11.0–3.11.4: у цих версіях стандартні механізми роботи з tar-архівами не давали Poetry достатнього захисту від спеціально сформованих шляхів усередині архіву. Зловмисний sdist міг записати файл поза цільовою директорією extraction.

Важлива межа формулювання: це не означає, що кожен проєкт на Python 3.10 або 3.11 уже скомпрометований. Потрібен шкідливий архів, який потрапив у процес встановлення. Але CI часто запускає package manager із доступом до token registry, кешів, артефактів і робочого дерева, тому навіть короткий етап розпакування має розглядатися як обробка недовірених даних.

Lock-файл знову є жорсткою межею

Третя помилка проявлялася, коли джерело не надавало хеш для певного артефакту: Poetry міг встановити файл, відсутній у lock-файлі. Lock-файл потрібний не лише для однакових версій. Він зв’язує розв’язане рішення з конкретними артефактами та їхніми контрольними сумами. Якщо клієнт мовчки приймає інший файл лише через неповні метадані джерела, відтворюваність і частина supply-chain контролю втрачаються.

Після оновлення не варто автоматично перегенеровувати lock-файл лише для того, щоб інсталяція з проблемного registry знову стала зеленою. Спочатку перевірте, чому джерело не публікує очікувані хеші, чи збігаються артефакти з upstream і чи не змінився proxy. Новий lock має бути результатом усвідомленого оновлення залежності, а не способом приховати розбіжність.

Практичний висновок: оновіть Poetry до 2.4.2 у локальних середовищах і CI, після чого виконайте чисту інсталяцію з чинного lock-файлу. Помилку перевірки хешів слід розслідувати, а не обходити.

Що перевірити команді

• Зафіксувати версію Poetry у CI image, tool manager або bootstrap script, щоб runner не залишився на старому patch-рівні.
• Запустити інсталяцію в чистому ephemeral середовищі без прогрітого cache та звірити результат із lock-файлом.
• Переглянути права CI: package installation не потребує доступу на запис до SSH-ключів, deployment secrets або системних каталогів.
• Перевірити приватні registry та proxy на повні hash metadata й незмінність уже опублікованих артефактів.
• Для старих гілок Python оновити не лише Poetry, а й сам runtime до підтримуваного patch-релізу.

Обмеження

Нотатки до релізу не наводять CVE, CVSS, підтверджених випадків експлуатації або переліку файлів, які можна перезаписати. Тому не слід вигадувати масштаб атаки. Реальний вплив визначають версія Python, тип пакета, джерело, права процесу та ізоляція runner. Оновлення менеджера залежностей усуває відомі помилки, але не замінює allowlist джерел, перевірку provenance, мінімальні права й одноразові CI-середовища.

Джерело та права

Матеріал є самостійним українським перекладом-переказом release notes Poetry 2.4.2, опублікованих 29 серпня 2026 року radoering та учасниками проєкту. Текст, код і документація офіційного репозиторію поширюються за MIT License. Перекладено, адаптовано й доповнено редакцією «Бібліотеки програміста». Обкладинка створена редакцією за допомогою AI і не входить до першоджерела.