chore(deps-dev): bump cryptography from 45.0.7 to 48.0.1 in /platforms/desktop-app

[dependabot]

Bumps cryptography from 45.0.7 to 48.0.1.

Changelog

Sourced from cryptography's changelog.

48.0.1 - 2026-06-09

* Updated Windows, macOS, and Linux wheels to be compiled with OpenSSL 4.0.1.
.. _v48-0-0:
48.0.0 - 2026-05-04

• BACKWARDS INCOMPATIBLE: Support for Python 3.8 has been removed. cryptography now requires Python 3.9 or later.

• BACKWARDS INCOMPATIBLE: Loading an X.509 CRL whose inner TBSCertList.signature algorithm does not match the outer signatureAlgorithm now raises ValueError. Previously, such CRLs were parsed successfully and only rejected during signature validation.

• Added support for :doc:/hazmat/primitives/asymmetric/mlkem and :doc:/hazmat/primitives/asymmetric/mldsa when using OpenSSL 3.5.0 or later, in addition to the existing AWS-LC and BoringSSL support. This means post-quantum algorithms are now available to users of our wheels.

  • Note: Going forward, we do not guarantee that all functionality in cryptography will be available when building against OpenSSL. See :doc:/statements/state-of-openssl for more information.

.. _v47-0-0:

47.0.0 - 2026-04-24

* Support for Python 3.8 is deprecated and will be removed in the next
  ``cryptography`` release.
* **BACKWARDS INCOMPATIBLE:** Support for binary elliptic curves
  (``SECT*`` classes) has been removed. These curves are rarely used and
  have additional security considerations that make them undesirable.
* **BACKWARDS INCOMPATIBLE:** Support for OpenSSL 1.1.x has been removed.
  OpenSSL 3.0.0 or later is now required. LibreSSL, BoringSSL, and AWS-LC
  continue to be supported.
* **BACKWARDS INCOMPATIBLE:** Dropped support for LibreSSL < 4.1.
* **BACKWARDS INCOMPATIBLE:** Loading keys with unsupported algorithms or
  keys with unsupported explicit curve encodings now raises
  :class:`~cryptography.exceptions.UnsupportedAlgorithm` instead of
  ``ValueError``. This change affects
  :func:`~cryptography.hazmat.primitives.serialization.load_pem_private_key`,
  :func:`~cryptography.hazmat.primitives.serialization.load_der_private_key`,
  :func:`~cryptography.hazmat.primitives.serialization.load_pem_public_key`,
  :func:`~cryptography.hazmat.primitives.serialization.load_der_public_key`,
  and :meth:`~cryptography.x509.Certificate.public_key` when called on
  certificates with unsupported public key algorithms.
</tr></table> 

... (truncated)

Commits

• de987ce 48.0.1 version bump and changelog (#14996)
• 8e03e30 bump for 48.0.0 release (#14796)
• 295e0d2 Add AGENTS.md with CLAUDE.md symlink (#14794)
• 104a2de Bump BoringSSL, OpenSSL, AWS-LC in CI (#14793)
• 67ec1e5 call check_length early on AesSiv::encrypt (#14792)
• b2da57a changelog for mldsa/mlkem for openssl (#14791)
• 3cf44ad ML-KEM OpenSSL support (#14781)
• 2e31639 ML-DSA OpenSSL support (#14773)
• 5affe5a fix rust nightly clippy (#14790)
• 2e73ca4 bump rust-openssl dep and update EcPoint::mul_generator to mul_generator2 (#1...
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  You can disable automated security fix PRs for this repo from the Security Alerts page.

[rtibblesbot]

🔵 Review posted

Last updated: 2026-07-18 01:23 UTC

[github-actions]

Build Artifacts

Asset type	Download link
PEX file	kolibri-0.19.6.dev2263_gf4ece0137.d20260718.pex
Windows Installer (EXE)	kolibri-setup-0.19.6.dev2263+gf4ece0137.d20260718-unsigned.exe
Debian Package	kolibri_0.19.6.dev2263+gf4ece0137.d20260718-0ubuntu1_all.deb
Debian Package	kolibri-server_0.19.6~dev2263+gf4ece0137.d20260718-0ubuntu1_all.deb
Mac Installer (DMG)	kolibri-0.19.6.dev2263+gf4ece0137.d20260718.dmg
Android Package (APK)	kolibri-0.19.6.dev2263+gf4ece0137.d20260718-debug.apk
Raspberry Pi Image	kolibri-pi-image-0.19.6.dev2263+gf4ece0137.d20260718.zip
TAR file	kolibri-0.19.6.dev2263+gf4ece0137.d20260718.tar.gz
WHL file	kolibri-0.19.6.dev2263+gf4ece0137.d20260718-py3-none-any.whl

Smoke test screenshot

Download screenshot

[rtibblesbot]

PR #15030 — Dependabot bump of cryptography 45.0.7 → 48.0.1 in the desktop-app build extra.

• Semver risk: major (multi-major, 45 → 48)
• Dependency type: development / build-only — [project.optional-dependencies].build of kolibri-app, gated on python_version >= '3.10'. Not imported by app code (bundled by PyInstaller via the _cffi_backend hiddenimport). grep finds no cryptography/hazmat/x509 usage in platforms/desktop-app.
• Breaking changes across the range: 48.0.0 drops Python 3.8 (requires 3.9+) and raises ValueError on X.509 CRLs with mismatched inner/outer signature algorithm; 47.0.0 removes OpenSSL 1.1.x (requires 3.0.0+), removes binary elliptic curves (SECT*), drops LibreSSL < 4.1, and switches unsupported-key-algorithm errors from ValueError to UnsupportedAlgorithm. None reach this project: build-only, not imported, Python pinned ≥ 3.10, wheels ship their own OpenSSL.
• Security fixes: none called out in the range.
• CI status: failing.

REQUEST_CHANGES — the lockfile was not regenerated. This PR edits only pyproject.toml; the committed uv.lock still pins cryptography==45.0.7 for kolibri-app (uv.lock:3611, :3634). uv lock --check fails on this branch; uv lock --dry-run shows 45.0.7, 47.0.0, 49.0.0 -> 45.0.7, 47.0.0, 48.0.1, 49.0.0.

The repo enforces uv.lock via the astral-sh/uv-pre-commit uv-lock hook, so any dev running local pre-commit, or CI running uv sync --locked/--frozen, fails — or silently installs 45.0.7 instead of 48.0.1, meaning the bump does not take effect through the lock. The green Build DMG/Build EXE jobs don't catch this because make dependencies runs uv sync --extra build without --frozen (live re-resolve).

Fix: run uv lock and commit the updated uv.lock alongside the manifest change — e.g. comment @dependabot recreate, which normally regenerates both together.

---

@rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly

How was this generated?

Ran a dependency-update review pipeline over the version bump:

• Classified the bump by semver (patch / minor / major) and dependency type (production vs. development)
• Extracted the changelog and release notes across the version range
• Assessed compatibility with this project's usage and whether any code changes are required
• Treated CI as the primary safety net
• Scaled the review depth to the update's risk
• Chose the verdict from semver risk, changelog findings, and CI status

[rtibblesbot]

PR #15030 — Dependabot bumps cryptography 45.0.7 → 48.0.1 (multi-major, minor+major range) in the platforms/desktop-app build extra. Development/build-only dependency (bundled by PyInstaller, not imported anywhere in platforms/desktop-app), gated python_version >= '3.10'.

Same commit as the prior round (6b0c0388) — no new commits pushed. The one blocking finding is still open, so the verdict stands.

[blocking] Lockfile not regenerated for the bump

The PR edits only pyproject.toml; the committed uv.lock still resolves cryptography==45.0.7 (all cryptography-45.0.7-* wheel entries). uv lock --check fails on this branch. The repo enforces the lock via the astral-sh/uv-pre-commit uv-lock hook and any CI step running uv sync --locked/--frozen, so the manifest and lock are out of sync — and the intended bump never takes effect through the lock (45.0.7 is what actually installs). Green build jobs don't catch it because make dependencies runs uv sync --extra build without --frozen (a live re-resolve).

Fix: regenerate and commit uv.lock alongside the manifest — comment @dependabot recreate, or run uv lock and commit the result.

Compatibility

Breaking changes in the range (47.0.0 removes OpenSSL 1.1.x + SECT* curves + LibreSSL < 4.1; 48.0.0 drops Python 3.8, raises ValueError on mismatched X.509 CRL signature algorithms) don't reach this project: build-only, not imported, wheels ship their own OpenSSL, pin gated to 3.10+. No security fixes called out in the range. The bump is safe once the lockfile is regenerated.

CI

Failing. The current failure is Python unit tests on Mac OS (3.10) dying at the actions/checkout@v7.0.0 step — an infra/checkout flake, unrelated to this bump. The blocking issue remains the un-regenerated lockfile.

Prior-finding status

UNADDRESSED — platforms/desktop-app/pyproject.toml:37 — uv.lock not regenerated for the bump

---

@rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly

How was this generated?

Ran a dependency-update review pipeline over the version bump:

• Classified the bump by semver (patch / minor / major) and dependency type (production vs. development)
• Extracted the changelog and release notes across the version range
• Assessed compatibility with this project's usage and whether any code changes are required
• Treated CI as the primary safety net
• Scaled the review depth to the update's risk
• Chose the verdict from semver risk, changelog findings, and CI status