uv 0.12.8 посилив перевірку хешів і прискорив великі Python-проєкти

uv 0.12.8 закриває небезпечну неоднозначність у режимі --require-hashes і одночасно прискорює роботу з великими lock-файлами та паралельними інсталяціями. Стабільний реліз вийшов 31 серпня 2026 року. Найважливіша захисна зміна: менеджер більше не довіряє хешам direct URL, якщо вони були знайдені лише всередині metadata іншого wheel, а не надійшли з явного перевіреного джерела.

Чому походження хеша має значення

Режим --require-hashes потрібний, щоб інсталяція приймала лише артефакти з очікуваними контрольними сумами. Але сама наявність рядка з хешем ще не створює довіри: важливо, звідки цей хеш отримано. Якщо URL і його checksum з’явилися лише в metadata пакета, який уже контролює стороння сторона, вони не повинні автоматично ставати незалежним підтвердженням цілісності.

У 0.12.8 uv припиняє таку довіру для direct URLs. Практично це означає, що команди зі строгими requirements або lock-файлами краще захищені від ситуації, коли транзитивні metadata підсовують одночасно і файл, і «доказ» для нього. Після оновлення інсталяція може відхилити конфігурацію, яка раніше проходила. Це не регресія, а сигнал додати хеш у контрольований manifest або перевірити походження залежності.

Один wheel — одне завантаження

Друга помітна зміна запобігає повторному завантаженню й розпакуванню одного remote wheel кількома процесами uv одночасно. Такий сценарій типовий для CI-хоста з паралельними jobs або monorepo, де кілька команд стартують майже синхронно. Координація зменшує зайвий network traffic, disk I/O і пікове використання CPU на extraction.

Окремо пришвидшено побудову dependency graph із великих lock-файлів: пакети індексуються під час обходу, а той самий підхід поширено на export, дерево залежностей, audit та freshness checks. Для маленького сервісу різниця може бути непомітною, натомість у workspace із сотнями пакетів скорочується повторний пошук по всьому документу.

Експериментальний content-addressed cache

Preview-функція content-addressed-cache тепер дедуплікує однакові файли не лише всередині одного wheel, а й між різними cached wheels. Ідея проста: однаковий вміст зберігається один раз і повторно використовується через filesystem-механізми. Реліз також зменшує allocations під час extraction, повторно використовуючи hashing buffer, та пришвидшує cleanup на macOS завдяки пакетному читанню кількості hard links.

Це preview, тому не варто одразу робити його єдиною опорою production build. Спочатку виміряйте розмір cache, час cold/warm install, поведінку cleanup і сумісність із backup, antivirus та файловою системою runner. Hard links мають власні обмеження між volumes і в контейнерних середовищах.

Azure і приватні індекси

Для Azure Storage підібрано сумісну API version, щоб credential retry працював, коли public access вимкнено. Параметр shared access signature sig тепер редагується у URL, які показуються користувачеві. Це важлива гігієна логів: SAS query може фактично бути секретом, тому його не можна залишати у CI output, exception report або support ticket.

Оновлення зменшує ризик нового витоку, але не видаляє старі логи. Якщо раніше URL із sig= могли потрапити в артефакти, варто виконати пошук, обмежити доступ, видалити доступні копії та перевипустити чинні SAS-токени.

Практичний висновок: оновіть uv до 0.12.8 насамперед там, де використовуються --require-hashes, direct URLs, Azure Storage або паралельні CI jobs. Помилки після посилення hash policy не обходьте — виправляйте джерело довіри.

Що перевірити після оновлення

• Зробити чисту інсталяцію без старого cache і звірити результат із lock-файлом.
• Переглянути direct URL dependencies та переконатися, що хеші зафіксовані у контрольованому файлі.
• Запустити кілька паралельних jobs і порівняти network traffic та час extraction.
• Перевірити CI-логи на відсутність Azure sig і замінити раніше розкриті токени.
• Preview cache спочатку тестувати на окремому runner із можливістю швидкого очищення.

Обмеження

Release notes не повідомляють про CVE, підтверджену експлуатацію або гарантований відсоток прискорення. Ефект залежить від розміру lock-файлу, швидкості storage, паралельності та стану cache. Дедуплікація залишається preview-функцією, а виправлення hash policy не замінює підписані артефакти, allowlist registry і мінімальні права CI.

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

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