Bump cryptography from 45.0.7 to 50.0.0 in /platforms/desktop-app

[dependabot]

Bumps cryptography from 45.0.7 to 50.0.0.

Changelog

Sourced from cryptography's changelog.

50.0.0 - 2026-07-31

* **SECURITY ISSUE**:
  :func:`~cryptography.hazmat.primitives.serialization.pkcs7.pkcs7_decrypt_der`
  and its PEM and S/MIME variants no longer expose distinguishable errors or
  timing when unwrapping a ``RecipientInfo``'s ``encryptedKey``, which could
  act as a Bleichenbacher oracle for callers that decrypt untrusted messages.
  A random key is now substituted on failure, as described in :rfc:`3218`.
  Credit to **@X1AOxiang** for reporting the issue. **CVE-2026-69247**
* Deprecated Diffie-Hellman key exchange over finite fields (FFDH).
  Everything FFDH is deprecated, including the types in
  ``cryptography.hazmat.primitives.asymmetric.dh`` and loading FFDH keys or
  parameters with the key loading APIs. Users should migrate to a more
  modern key exchange algorithm.
* Added ``xof()`` class methods to
  :class:`~cryptography.hazmat.primitives.hashes.SHAKE128` and
  :class:`~cryptography.hazmat.primitives.hashes.SHAKE256` for constructing
  algorithm instances configured for use with
  :class:`~cryptography.hazmat.primitives.hashes.XOFHash`.
* The :mod:`X.509 verification <cryptography.x509.verification>` APIs are now
  considered stable and are subject to our API stability policy.
* Added the :doc:`/cobblestone` recipe, an implementation of the
  Cobblestone-128 and Cobblestone-256 instantiations of the `C2SP
  chunked-encryption specification
  <https://c2sp.org/chunked-encryption>`_ for streaming authenticated
  encryption of large messages.
* Parsing a Signed Certificate Timestamp list now rejects encodings that
  carry trailing bytes after the list or after an individual SCT, instead of
  silently ignoring them.
* Added support for using :class:`~cryptography.x509.Name` as a field type in
  the :doc:`/hazmat/asn1/index` module.
* Loading a public key or an EC private key now rejects DER where the
  ``subjectPublicKey`` (or EC ``publicKey``) ``BIT STRING`` declares a non-zero
  number of unused bits, instead of silently ignoring it.
* Parsing a CRL entry's ``InvalidityDate`` extension now rejects a
  ``GeneralizedTime`` that carries fractional seconds or another non-DER form,
  matching the strict encoding already required for every other X.509 time
  field.
* :func:`~cryptography.x509.ocsp.load_der_ocsp_request` and
  :func:`~cryptography.x509.ocsp.load_der_ocsp_response` now reject a request
  or response whose ``version`` field is not ``v1``, the only version defined
  by RFC 6960, matching the version validation already performed when loading
  certificates, CSRs and CRLs.
* :class:`~cryptography.hazmat.primitives.hashes.XOFHash` is now supported
  when building against AWS-LC.
* HMAC (and therefore PBKDF2-HMAC) with SHA-3 hashes is now supported when
  building against AWS-LC.
* Diffie-Hellman (:doc:`/hazmat/primitives/asymmetric/dh`) is now supported
  when building against AWS-LC.
</tr></table> 

... (truncated)

Commits

• dcb7050 Prepare for 50.0.0 release (#15372)
• 53fccd9 Don't leak how PKCS#7 encryptedKey decryption failed (#15369)
• d472f97 Add from __future__ import annotations to all src/ Python files (#15371)
• 908773d Bump downstream dependencies in CI (#15368)
• 2cc07cc Bump BoringSSL, OpenSSL, AWS-LC in CI (#15367)
• c94ede9 chore(deps): bump ruff from 0.16.0 to 0.16.1 (#15366)
• 67a8308 chore(deps): bump virtualenv from 21.7.0 to 21.7.1 (#15365)
• 95018ff Release the GIL in one-shot AEAD encrypt/decrypt (#15361)
• 6954733 Release the GIL during DH and DSA parameter generation (#15364)
• 6893b94 Import _serialization instead of serialization in x509/extensions (#15363)
• Additional commits viewable in compare view

Most Recent Ignore Conditions Applied to This Pull Request

Dependency Name	Ignore Conditions
cryptography	[>= 48.dev0, < 49]

Note
Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

[rtibblesbot]

🟡 Waiting for changes

Last updated: 2026-09-08 19:50 UTC

[github-actions]

Build Artifacts

Asset type	Download link
PEX file	kolibri-0.20.0a2.dev233_g22e63696e.pex
Windows Installer (EXE)	kolibri-setup-0.20.0a2.dev233+g22e63696e-unsigned.exe
Debian Package	kolibri_0.20.0a2.dev233+g22e63696e.d20260908-0ubuntu1_all.deb
Debian Package	kolibri-server_0.20.0~a2.dev233+g22e63696e.d20260908-0ubuntu1_all.deb
Mac Installer (DMG)	kolibri-0.20.0a2.dev233+g22e63696e.dmg
Android Package (APK)	kolibri-0.20.0a2.dev233+g22e63696e-debug.apk
Raspberry Pi Image	kolibri-pi-image-0.20.0a2.dev233+g22e63696e.d20260908.zip
TAR file	kolibri-0.20.0a2.dev233+g22e63696e.tar.gz
WHL file	kolibri-0.20.0a2.dev233+g22e63696e-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

[bjester]

@dependabot recreate

[rtibblesbot]

PR #15030 — cryptography 45.0.7 → 50.0.0 in /platforms/desktop-app. Major bump, production dependency (PyInstaller bundles it into the shipped app; Morango uses its CryptographyKey backend to sign sync payloads). CI passing on all 10 runs including Build DMG, Build EXE and the DMG smoke test.

0 of 1 prior findings resolved; 1 still open.

[blocking] uv.lock still pins cryptography 45.0.7

The recreate moved the target version but rewrote only pyproject.toml. uv.lock:3562/:3584 still carry cryptography 45.0.7 and specifier = "==45.0.7" for kolibri-app; uv lock --check fails on this branch. The commit trailer says dependency-version: 48.0.1 under a subject reading 50.0.0.

Recreating again won't fix it: this branch is from the pip updater, which has no entry in .github/dependabot.yml and never touches the lock — the lock is owned by the uv entry (.github/dependabot.yml:26-31). The prek uv-lock hook doesn't catch it either; its files: pattern is root-anchored, so a workspace member's manifest never triggers it, and no CI job or Makefile passes --frozen/--locked. The practical cost is that every developer's uv sync/uv run silently rewrites uv.lock.

Fix: run uv lock on the branch and push (77 insertions / 15 deletions). It is a workspace-wide re-resolve, not desktop-only — on Python ≥3.10 it also moves kolibri's test group, josepy, django-oidc-provider, mozilla-django-oidc and secretstorage to 50.0.0. All dev/test-scoped, so acceptable.

Changelog / compatibility

• Breaking across 45 → 50: 47.0.0 drops OpenSSL 1.1.x and SECT* curves; 48.0.0 drops Python 3.8; 50.0.0 deprecates FFDH and tightens SCT/DER/OCSP parsing. None reach this project — no cryptography import in kolibri/ or python_packages/, no pkcs7 or FFDH usage, wheels ship their own OpenSSL, and the build pins Python 3.10.
• Security: 50.0.0 fixes the PKCS#7 decrypt timing oracle (CVE-2026-69247); no pkcs7 usage here.
• Verified 50.0.0 against Morango's actual call set — default_backend(), RSAPrivateKey.sign, PKCS1 PEM public / TraditionalOpenSSL private serialization, PKCS1v15+SHA256 sign/verify, PKCS8-header public-key reload. All work, so no silent fallback to pure-Python RSA.
• Green CI is real evidence for the version but none for the lockfile: with no --frozen anywhere, those jobs re-resolved and installed 50.0.0 regardless of what the lock says.
• #15143 carries the same dependency at 50.0.0 in /requirements, from the same unconfigured pip updater. Worth resolving together.

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