Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

image.py: survive CryptographyDeprecationWarning… #127

Merged

Conversation

jimklimov
Copy link

@jimklimov jimklimov commented Aug 9, 2024

…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
Copy link

mtelka commented Aug 10, 2024

@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
Copy link
Author

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
Copy link
Author

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

@Toasterson
Copy link

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
Copy link

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

@Toasterson Toasterson merged commit edbde30 into OpenIndiana:oi Aug 11, 2024
@jimklimov jimklimov deleted the survive-CryptographyDeprecationWarning branch August 20, 2024 08:29
@jimklimov
Copy link
Author

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 :\

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants