uv 0.12.12 підписує Python-бінарники та точніше фіксує залежності за датою

uv 0.12.12 додає перевірювану ідентичність видавця до готових бінарників і виправляє відтворюваність lock-файлів із часовим обмеженням. Випуск опубліковано 9 вересня 2026 року. Виконувані файли в архівах для macOS і Windows, а також wheels пакетів uv та uv_build, тепер підписані кодовим підписом.

Що саме підписується

На macOS виконувані файли підписані сертифікатом Apple Developer ID та пройшли нотаризацію Apple. На Windows застосовано timestamped Authenticode через Azure Artifact Signing. Підпис дозволяє операційній системі й корпоративним засобам захисту перевірити видавця та цілісність файла, а також створювати правила allowlist за сертифікатом.

Timestamp важливий, бо підтверджує момент підписання. Файл може залишатися перевірюваним після завершення строку дії сертифіката, якщо підпис був чинним на момент створення. Водночас code signing не доводить відсутність помилок у програмі: він відповідає на питання, ким підписаний артефакт і чи змінювався він після цього.

Підпис, checksum та attestation — різні рівні

Реліз і далі публікує SHA-256 checksums для архівів. Хеш допомагає звірити байти, але сам по собі не встановлює особу видавця. Підпис пов’язує артефакт із сертифікатом, а GitHub Artifact Attestation дозволяє перевірити походження release artifact у контексті репозиторію.

Для перевірки attestation команда релізу пропонує gh attestation verify <file> --repo astral-sh/uv. У CI доцільно поєднати всі три механізми: завантажувати через TLS, перевіряти attestation або підпис і фіксувати checksum там, де потрібна сувора відтворюваність.

Виправлено exclude-newer

Параметр exclude-newer задає часову межу для вибору дистрибутивів. У 0.12.12 пакети, завантажені після цієї межі, виключаються не лише під час resolution, а й із lock-файлів та згенерованих requirement hashes. Раніше пізніший файл міг потрапити до результату й порушити обіцянку збірки «станом на дату».

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

Практичний план для команди

• Оновити uv у тестовому CI та перевірити code-signing політики macOS і Windows.
• Для hermetic build повторно створити lock-файл із чинним exclude-newer і переглянути diff.
• Додати перевірку GitHub attestation перед перенесенням бінарника у внутрішній registry.
• Не вимикати антивірусні перевірки лише тому, що файл підписаний.

Практичний висновок: реліз невеликий за кількістю функцій, але важливий для supply-chain security. Підписані бінарники спрощують контроль видавця, а виправлений cutoff робить lock-файли точнішими.

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

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