image.py: survive CryptographyDeprecationWarning…

[jimklimov]

…about negative certificate numbers

Context: as discussed on IRC, when upgrading from a ~Jan 2024 state of OpenIndiana to Aug 2024, my local zones would not boot, behaving strange and effectively unable to run binaries. After some investigation I found that the zones' packages did not get updated, and pkg would calculate its upgrade path for 10 minutes and then crash with a stack trace ending in:

  File "/usr/lib/python3.9/vendor-packages/pkg/client/pkgplan.py", line 346, in evaluate
      dest_pub, self.image.trust_anchors,
    File "/usr/lib/python3.9/vendor-packages/pkg/client/image.py", line 352, in trust_anchors
      x509.load_pem_x509_certificate( cryptography.utils.CryptographyDeprecationWarning:
         Parsed a negative serial number, which is disallowed by RFC 5280. Loading this
         certificate will cause an exception in the next release of cryptography. 

According to pyca/cryptography#10247 as of this writing (Aug 2024) the support is still there, just the deprecation warnings are sent. In pkg(5) this happens in a try/except context, so the warning crashes the program. Shrugging it off like in this PR let my zones complete their upgrade and happily boot.

[mtelka]

@jimklimov, this is really interesting. I'd like to know answer for the following questions:

• Do you see this in the global zone too? If not, any idea why not?
• What certificate does have a negative serial number?
• If this is a wide(r) problem, wouldn't it be better to remove the deprecation warning exception directly from cryptography instead?

Thank you.

[jimklimov]

My guess from reading pyca discussions is that negative-numbered certs were quite popular in some CAs, then frowned upon and I suppose phased out as time went. This may explain why others did not stumble on this issue, as they upgraded more frequently and got newer certs (indeed gotta find which and in what context) before pyca du-jour began to warn?

Not sure why this did not block my GZ upgrade. One guess is that I might have used the older pkg to begin in its clone, and then used the updated pkg in local zones' clones. Another, that if this depends on the packages having signed files or whatever, the GZ being minimalistic just did not have the tainted packages?..

[jimklimov]

I'll try to spawn another cloned zoneroot to see which cert this is about, during the week.

[Toasterson]

Thanks for the look deeper. By default we have no Signed packages so it might be that it only applied to you because you have one publisher that does. If it is because of the transport certificates then I would need to look into the dehydrated script if it has an error.

[Toasterson]

The patch looks good though. Merging. Keep me posted on the results of your tests.

[jimklimov]

Tried to instantiate an older BE to upgrade into current, but the issue did not expose itself, update in the ABE succeeded. Will try with some others, but perhaps the fix in current pkg (part of what I'm upgrading into) neuters the problem by now :\