Hello! I've just uploaded python3-cryptography 44.0.2-1 which makes yubikey-
manager
 and python3-ykman not installable.

Note that the upstream pyproject.toml has "cryptography (>=3.0, <48)".

We believe that the bug you reported is fixed in the latest version of
yubikey-manager, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1115706@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Simon Josefsson <simon@josefsson.org> (supplier of updated yubikey-manager package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Fri, 19 Sep 2025 12:26:13 +0200
Source: yubikey-manager
Architecture: source
Version: 5.8.0-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Security Tools <team+pkg-security@tracker.debian.org>
Changed-By: Simon Josefsson <simon@josefsson.org>
Closes: 1115706
Changes:
 yubikey-manager (5.8.0-1) unstable; urgency=medium
 .
   * Team upload.
   * New upstream version 5.8.0
   * Bump minimum python3-cryptography to 48.  Closes: #1115706.
Checksums-Sha1:
 308240def4b64af48292613ae44036b14371fec8 3139 yubikey-manager_5.8.0-1.dsc
 1622de9068b2146f3b28a36d5759564e90f2d418 228631 yubikey-manager_5.8.0.orig.tar.gz
 fb9411b2d86beaf0cfc8ee614ef0cb22991016a0 488 yubikey-manager_5.8.0.orig.tar.gz.asc
 8dbcc4162f017262623bfbd5fdf312f87555d17c 73400 yubikey-manager_5.8.0-1.debian.tar.xz
 488dfaffa580f84754f3f301eb85b94661b238c6 8015 yubikey-manager_5.8.0-1_amd64.buildinfo
Checksums-Sha256:
 7568905d84922d1f52272bc44216fece6ce51f71e827f48b730cb602bf8609c0 3139 yubikey-manager_5.8.0-1.dsc
 3af0da65e1fdd46763c94ee74e2da55a4b6e7771da776c197f5f4b4581738560 228631 yubikey-manager_5.8.0.orig.tar.gz
 ea6373df90e8dd046cd4b0a09827d3db48ef112faf9cfa8517736da03f566c0c 488 yubikey-manager_5.8.0.orig.tar.gz.asc
 70b3b566d616db85766489d07394a4c4609c26f099654c93fdfbf1e24e84a11f 73400 yubikey-manager_5.8.0-1.debian.tar.xz
 868ef20c9f141aebe461351ccd187fad5824d0bddaedd07b5da239316faf851c 8015 yubikey-manager_5.8.0-1_amd64.buildinfo
Files:
 838d4771613f17fed1a8fe1bf39c2c11 3139 utils optional yubikey-manager_5.8.0-1.dsc
 3377af790f60d33ed194a38ecfded66b 228631 utils optional yubikey-manager_5.8.0.orig.tar.gz
 fa4b15e34a660f9685d141ce6553e3b8 488 utils optional yubikey-manager_5.8.0.orig.tar.gz.asc
 123b1795c8e3d18e16b35283095828b7 73400 utils optional yubikey-manager_5.8.0-1.debian.tar.xz
 b03b723843d96ed09f13753901610376 8015 utils optional yubikey-manager_5.8.0-1_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----

iQNoBAEWCgMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmjNMNQUHHNpbW9uQGpv
c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f
V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z
ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh
BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA
/iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx
+3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx
I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0
+MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R
cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE
8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J
ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6
qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB
BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA
JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF
PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh
is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFot57AQCzKwtTQDVD
qMscvpelBQYpWXPGYr5u+7bSDLq2X0LAsgEA0CkxiI00VEOk95aftCIB7YPP9+u2
fvxqz+rl1/TnFQ8=
=jKZm
-----END PGP SIGNATURE-----

Andrey Rakhmatullin <wrar@debian.org> writes:

However why would one want to have these << dependencies?  I guess they
are mirroring upstream pyproject.toml, but I still don't understand the
reason.  Once python3-fido2 v2 is uploaded to Debian we will have the
same problem with it too.  Shouldn't we just drop them?  Any objections
to do this?

Package: yubikey-manager
Depends: ...
         python3-cryptography (>= 3.0.0),
         python3-cryptography (<< 44),
         python3-fido2 (>= 0.9),
         python3-fido2 (<< 2.0)

/Simon

It's an interesting question for which I don't have an answer, even
pyopenssl (notably maintained by the same PyCA as cryptography itself) has
a regularly bumped upper dep on cryptography. E.g. the recently released
25.3.0 has the bump as the only change.

Debian-python,

Does anyone have thoughts on why some python packages use << versioning
on build dependencies even when there are no such versions released?

If this a python cultural upstream thing, is this something that should
be mirrored in Debian's Depends: versioning?

I'm guessing an upstream may want to protect against some potential
future API break with a future version of some build dependency, to be
certain to notice when upstream bumps versions and get a hard failure to
be able to resolve things, but I'm guessing this probably does more
damage than good if mirrored in the Debian versioning.  Which happened
now for yubikey-manager.  I've not seen this used in other language
ecosystems as much.  But I may be missing something.

Of course, if there is a KNOWN problem with a more recent version of
some package, then a << dependency is fully appropriate.

Btw, I just realized that maybe yubikey-manager could be team-maintained
by the python team rather than the pkg-security team that I just nudged
it into, I suppose people here will have more knowledge about python
stuff than on pkg-security.

/Simon

Andrey Rakhmatullin <wrar@debian.org> writes:

Hi Simon (2025.09.19_13:10:16_+0000)

You sometimes see this. It's over-protective IMHO.

We don't always do this. Packages need to declare PEP386 (in practice
PEP440) compliance for dh_python3 to do this. Or you have to pass
--accept-upstream-versions.
That's probably worth re-visiting, because everything is PEP440
compliant, these days.

It's problematic for us to not mirror it, because then you can have
packages installed that don't have their dependencies met. pip doesn't
like that. pkg_resources (IIRC) used to also get quite up set about it.

So, typically patching the upstream dependencies is appropriate in these
situations.

Stefano

Stefano Rivera <stefanor@debian.org> writes:

Thanks - this was the wisdom and context I was missing!  I can't claim
to fully grasp it, but now I know there is a python-specific reason to
not remove << in debian/control for Depends: or Build-Depends: on
upstream packages without those releases.

Or, as it happened for yubikey-manager, sync the debian/control <<
versioning with upstream's << versioning, which got out of sync over
time.

It would be nice with a linter tool to catch this.

/Simon

Hi Simon (2025.09.19_15:55:56_+0000)

That's unusal. Typically you can rely on dh_python3 to generate your
dependencies.

Stefano

Stefano Rivera <stefanor@debian.org> writes:

Package: yubikey-manager
Depends: ${misc:Depends},
         ${python3:Depends},
         python3-click (>= 8.0),
         python3-ykman (= ${binary:Version}),
         pcscd,
         python3-cryptography (>= 3.0.0),
         python3-cryptography (<< 44),
         python3-fido2 (>= 0.9),
         python3-fido2 (<< 2.0)

Package: python3-ykman
Depends: ${misc:Depends},
         ${python3:Depends},
         python3-keyring (>= 23.4),
         python3-cryptography (>= 3.0.0),
         python3-cryptography (<< 48),
         python3-fido2 (>= 0.9),
         python3-fido2 (<< 2.0)

Which leads to binary packages (at least on my laptop's build) with:

 Package: yubikey-manager
 Depends: python3-ykman (= 5.8.0-1), python3:any, python3-click (>= 8.0), pcscd, python3-cryptography (>= 3.0.0), python3-cryptography (<< 44), python3-fido2 (>= 0.9), python3-fido2 (<< 2.0)

 Package: python3-ykman
 Depends: python3-click (>= 8.0), python3-cryptography (>= 3.0.0), python3-cryptography (<< 48), python3-fido2 (>= 0.9), python3-keyring (>= 23.4), python3-pyscard (>= 2.0), python3:any, python3-fido2 (<< 2.0)

If I drop all the hard coded python versioning, like this:

 Depends: ${misc:Depends},
          ${python3:Depends},
-         python3-click (>= 8.0),
-         python3-ykman (= ${binary:Version}),
-         pcscd,
-         python3-cryptography (>= 3.0.0),
-         python3-cryptography (<< 44),
-         python3-fido2 (>= 0.9),
-         python3-fido2 (<< 2.0)
+         pcscd
 Recommends: libyubikey-udev
 Description: Python library and command line tool for configuring a YubiKey
  YubiKey Manager (ykman) is a command line tool for configuring a YubiKey over
@@ -54,12 +48,7 @@ Package: python3-ykman
 Architecture: all
 Section: python
 Depends: ${misc:Depends},
-         ${python3:Depends},
-         python3-keyring (>= 23.4),
-         python3-cryptography (>= 3.0.0),
-         python3-cryptography (<< 48),
-         python3-fido2 (>= 0.9),
-         python3-fido2 (<< 2.0)
+         ${python3:Depends}
 Recommends: pcscd

the resulting binary packages looks like this:

 Package: yubikey-manager
 Depends: python3-ykman (= 5.8.0-1), python3:any, pcscd

 Package: python3-ykman
 Depends: python3-click (>= 8.0), python3-cryptography (>= 3.0), python3-cryptography (<< 48), python3-fido2, python3-keyring (>= 23.4), python3-pyscard (>= 2.0), python3:any

That seems more appropriate, right?

This would also fix the <<44 version dependency on the 'yubikey-manager'
binary package that I failed to fix in my last upload since I only
looked at 'python3-ykman'.

Please holler if this seems like a bad idea to upload.

/Simon

Control: reopen -1
Control: notfixed -1 yubikey-manager/5.8.0-1

This only changed the deps of python3-ykman, but not of yubikey-manager.