hi team, we're running into an upstream dependency constraint issue and wanted to check if there's a planned path forward. context: • We're trying to upgrade the

cryptography

package to

>=48.0

in our environment due to security requirements, but we're blocked by c7n's pinned dependency. • What we found: ◦ `c7n 0.9.51`(latest) pins`cryptography`to`46.0.7` ◦ All`c7n`versions`>=0.9.47`are pinned to specific cryptography versions (

44.0.3

,

45.0.7

,

46.0.5

, or`46.0.7`) ◦ `cryptography >=48.0`is incompatible with any current`c7n`release is there a plan to support

cryptography >= 48.0

in an upcoming

c7n

release? Or is there a recommended workaround (e.g., using a version constraint range instead of a pinned version) that would allow consumers to upgrade

cryptography

independently? Thanks!

There are 2 different but related things going on here. 1. c7n no longer pins old

cryptography

versions (we have in the past, but temporarily in response to breakages/incompatibilities) 2. we do freeze/lock package versions for releases, in an attempt to keep the c7n environment fairly predictable and avoid surprises We're coming up on a month since the last release, so about ready to do a pass of upgrades which will update

cryptography

to the latest that all of our dependencies allow. That last bit is relevant because

c7n_oci

depends on

cryptography<47

(issue). Because c7n has a unified dep tree across all supported providers, we can't update to 48 until that OCI issue is resolved.

Thanks for your support!