If I'm understanding this upstream bug, certbot can't currently handle overly dev-python/cryptography-43.0.0 or newer. https://github.com/certbot/certbot/issues/9967 ============================= /usr/lib/python3.12/site-packages/certbot/ocsp.py:238: CryptographyDeprecationWarning: Properties that return a naïve datetime object have been deprecated. Please switch to this_update_utc. if not response_ocsp.this_update: /usr/lib/python3.12/site-packages/certbot/ocsp.py:240: CryptographyDeprecationWarning: Properties that return a naïve datetime object have been deprecated. Please switch to this_update_utc. if response_ocsp.this_update > now + timedelta(minutes=5): /usr/lib/python3.12/site-packages/certbot/ocsp.py:242: CryptographyDeprecationWarning: Properties that return a naïve datetime object have been deprecated. Please switch to next_update_utc. if response_ocsp.next_update and response_ocsp.next_update < now - timedelta(minutes=5): ============================= Until upstream fixes their bug, Gentoo probably needs to disallow the current ebuild from using the new cryptography package. Reproducible: Always
Forgot to state: this is output when running certbot renew.
(In reply to Philippe Chaintreuil from comment #0) > If I'm understanding this upstream bug, certbot can't currently handle > overly dev-python/cryptography-43.0.0 or newer. > > https://github.com/certbot/certbot/issues/9967 > > ============================= > /usr/lib/python3.12/site-packages/certbot/ocsp.py:238: > CryptographyDeprecationWarning: Properties that return a naïve datetime > object have been deprecated. Please switch to this_update_utc. > if not response_ocsp.this_update: > /usr/lib/python3.12/site-packages/certbot/ocsp.py:240: > CryptographyDeprecationWarning: Properties that return a naïve datetime > object have been deprecated. Please switch to this_update_utc. > if response_ocsp.this_update > now + timedelta(minutes=5): > /usr/lib/python3.12/site-packages/certbot/ocsp.py:242: > CryptographyDeprecationWarning: Properties that return a naïve datetime > object have been deprecated. Please switch to next_update_utc. > if response_ocsp.next_update and response_ocsp.next_update < now - > timedelta(minutes=5): > ============================= > > Until upstream fixes their bug, Gentoo probably needs to disallow the > current ebuild from using the new cryptography package. > > Reproducible: Always Just noting I am also seeing exactly this.
Confirmed, same here ...
I've added PYTHONWARNINGS=ignore before certbot renew --quiet in crontab as a workaround for now
Upstream doesn't seem like they're going to be very responsive[1] to addressing these warnings. Feels like they'll get to upgrading to cryptography 43.0.0 when they feel like it. So, since Gentoo only has cryptography 43.0.x in the tree at this point, lets just patch in the fix. The certbot code is already dealing in UTC, so it seems pretty straight forward. PR: https://github.com/gentoo/gentoo/pull/38775 If maintainers want tweaks, I'm happy to make them. If they don't want it at all, no hard feelings. [1] https://github.com/certbot/certbot/issues/9967#issuecomment-2251124561
Perhaps someone should just open a PR with upstream that adds the if/else or try/except?
My Python kungfu isn't strong enough for an upstream patch. This is a warning, not an exception, so try/catch won't trigger to my knowledge. And I don't know how to reliably version check a library. And I don't know how to test against old versions of the library to confirm changes are working as expected. Since we have removed old cryptography versions, the fix in our scope was more straightforward. But if someone else knows Python better, an upstream fix would be better.
(In reply to Philippe Chaintreuil from comment #7) > My Python kungfu isn't strong enough for an upstream patch. This is a > warning, not an exception, so try/catch won't trigger to my knowledge. And > I don't know how to reliably version check a library. And I don't know how > to test against old versions of the library to confirm changes are working > as expected. Well, you would first try "this_update_utc", which would be an exception if it doesn't exist, and if that exception occurs then you would try again using "this_update" to support older versions.
I've stated other reasons I do not feel capable of offering code changes to upstream. You are welcome to do so though.
I don't know what those reasons could be other than fear that they won't accept the change. If you don't offer it, they certainly can't accept it. It is generally considered "the right thing to do" to offer patches upstream rather than turn the distro into a maze of downstream patches when it can be avoided. Whether upstream accepts the patch or not is beside the point -- the point is to try. (In reply to Philippe Chaintreuil from comment #9) > You are welcome to do so though. I don't use this package -- you do and Matthew (presumably) does.
I think it's reasonable for someone to be in a position where they've crafted a workaround that Works For Them, sharing it in case others are stuck, but aren't confident that it's correct / aren't currently able to interact with a (new) upstream and submit it and justify it and so on. Let's leave it there on that.
Now, as for the fix itself: if you're not confident enough to submit it upstream (which is fine), I think we can go in another direction. With patches that actually change something, I think it's reasonable to request (even demand) it be sent upstream if someone is proposing it actually be included in the ebuild. We can avoid any semantic changes and just do the bare minimum to silence the deprecation warning, given upstream are already aware.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6af2e1684b64a9e0d621903d02de17e3b8540a67 commit 6af2e1684b64a9e0d621903d02de17e3b8540a67 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-10-05 05:58:22 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-10-05 05:58:22 +0000 app-crypt/certbot: workaround cryptography deprecation warnings Not ideal but the bug has been open a while and doing this as a drive-by; the upstream bug doesn't seem to be going anywhere either. Just suppress the dev-python/cryptography deprecation warnings for now given it's very vocal and shows up in cron jobs. Closes: https://bugs.gentoo.org/937889 Signed-off-by: Sam James <sam@gentoo.org> app-crypt/certbot/certbot-2.11.0-r1.ebuild | 69 ++++++++++++++++++++++ ...karound-cryptography-deprecation-warnings.patch | 36 +++++++++++ 2 files changed, 105 insertions(+)
Thanks Sam! I didn't even realize one could locally suppress warning like that in Python.
@sam, the patch doesn't work. ================================================================== /usr/lib/python3.12/site-packages/certbot/ocsp.py:248: CryptographyDeprecationWarning: Properties that return a naïve datetime object have been deprecated. Please switch to next_update_utc. ================================================================== You've got... ================================================================== warnings.filterwarnings("ignore",category=DeprecationWarning) ================================================================== ... in the patch, but it's actually of type "CryptographyDeprecationWarning" (which subclasses from UserWarning, not DeprecationWarning for some reason [1]). If I change that line in the patch to ... ================================================================== warnings.filterwarnings("ignore",category=CryptographyDeprecationWarning) ================================================================== ... it does work & it does suppress the log spam. [1] https://github.com/pyca/cryptography/blob/56933bf61a4539a1306534a196e67e40c5084719/src/cryptography/utils.py#L16C38-L16C49
(In reply to Sam James from comment #11) > I think it's reasonable for someone to be in a position where they've > crafted a workaround that Works For Them, sharing it in case others are > stuck, but aren't confident that it's correct / aren't currently able to > interact with a (new) upstream and submit it and justify it and so on. > > Let's leave it there on that. As we can see, that worked out well. :) I specifically had questions about people being in the position you describe for the specific reason of the specificity inherent in: "Upstream doesn't seem like they're going to be very responsive" therefore "I don't feel confident submitting an upstream patch" I didn't think this was a good reason, and I still don't think it's a good reason...
Oops, thanks!
(In reply to Eli Schwartz from comment #16) > (In reply to Sam James from comment #11) > > I think it's reasonable for someone to be in a position where they've > > crafted a workaround that Works For Them, sharing it in case others are > > stuck, but aren't confident that it's correct / aren't currently able to > > interact with a (new) upstream and submit it and justify it and so on. > > > > Let's leave it there on that. > > As we can see, that worked out well. :) No comment ;)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5180e4596a18e5f17b23364643c9d50b52e33f21 commit 5180e4596a18e5f17b23364643c9d50b52e33f21 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-10-09 10:31:26 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-10-09 10:31:26 +0000 app-crypt/certbot: fix deprecation warning name Closes: https://bugs.gentoo.org/937889 Fixes: 6af2e1684b64a9e0d621903d02de17e3b8540a67 Signed-off-by: Sam James <sam@gentoo.org> .../certbot/{certbot-2.11.0-r1.ebuild => certbot-2.11.0-r2.ebuild} | 0 .../certbot-2.11.0-workaround-cryptography-deprecation-warnings.patch | 2 +- 2 files changed, 1 insertion(+), 1 deletion(-)
Sorry to post on a closed issue, but this patch gives a runtime error for me: ian ~ # certbot certificates Saving debug log to /var/log/letsencrypt/letsencrypt.log An unexpected error occurred: NameError: name 'CryptographyDeprecationWarning' is not defined Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details. ian ~ # Since this appears to work for others, any pointers as to what I can look for to find/insert the CryptographyDeprecationWarning definition?
(In reply to Ian Pickworth from comment #20) > Sorry to post on a closed issue, but this patch gives a runtime error for me: > > ian ~ # certbot certificates > Saving debug log to /var/log/letsencrypt/letsencrypt.log > An unexpected error occurred: > NameError: name 'CryptographyDeprecationWarning' is not defined > Ask for help or search for solutions at https://community.letsencrypt.org. > See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with > -v for more details. > ian ~ # > > Since this appears to work for others, any pointers as to what I can look > for to find/insert the CryptographyDeprecationWarning definition? My limited python skills found that, to get the patch to work, the following import statement has to be added to the patch (in the cryptography import code block): from cryptography.utils import CryptographyDeprecationWarning
Created attachment 905593 [details, diff] Modified patch to include CryptographyDeprecationWarning import Added an import statement for CryptographyDeprecationWarning to the original deprecation warning removal patch
I'm embarrassed to say that I think Eli was proven right. Anyway, as penance, I'll fix it properly upstream as well.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=83f5bc98f8cfe888e5a62ef61a215dce575c5b6c commit 83f5bc98f8cfe888e5a62ef61a215dce575c5b6c Author: Sam James <sam@gentoo.org> AuthorDate: 2024-10-14 00:32:43 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-10-14 00:32:43 +0000 app-crypt/certbot: drop workaround patch I'm going to do it properly later tonight hopefully. Bug: https://bugs.gentoo.org/937889 Signed-off-by: Sam James <sam@gentoo.org> .../certbot/{certbot-2.11.0-r2.ebuild => certbot-2.11.0-r3.ebuild} | 4 ---- 1 file changed, 4 deletions(-)
> certbot 3.0.1 containing a fix for this has now been released https://github.com/certbot/certbot/issues/9967#issuecomment-2477224504 Release notes: https://github.com/certbot/certbot/releases/tag/v3.0.1
Great -- can you submit a PR containing the new release? :)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fa2b0c81fd002c90b796b62dc234247c5fdf7f13 commit fa2b0c81fd002c90b796b62dc234247c5fdf7f13 Author: Thibaud CANALE <thican@thican.net> AuthorDate: 2024-11-14 19:31:57 +0000 Commit: Matthew Thode <prometheanfire@gentoo.org> CommitDate: 2024-11-15 16:46:24 +0000 app-crypt/certbot: add 3.0.1 Closes: https://bugs.gentoo.org/937889 Closes: https://bugs.gentoo.org/943522 Signed-off-by: Thibaud CANALE <thican@thican.net> Closes: https://github.com/gentoo/gentoo/pull/39320 Signed-off-by: Matthew Thode <prometheanfire@gentoo.org> app-crypt/certbot/Manifest | 1 + app-crypt/certbot/certbot-3.0.1.ebuild | 66 ++++++++++++++++++++++++++++++++++ 2 files changed, 67 insertions(+) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7fe0979184963745d8035b690e9362cce9c333b8 commit 7fe0979184963745d8035b690e9362cce9c333b8 Author: Thibaud CANALE <thican@thican.net> AuthorDate: 2024-11-14 19:30:22 +0000 Commit: Matthew Thode <prometheanfire@gentoo.org> CommitDate: 2024-11-15 16:46:23 +0000 app-crypt/acme: add 3.0.1 Closes: https://bugs.gentoo.org/937889 Closes: https://bugs.gentoo.org/943522 Signed-off-by: Thibaud CANALE <thican@thican.net> Signed-off-by: Matthew Thode <prometheanfire@gentoo.org> app-crypt/acme/Manifest | 1 + app-crypt/acme/acme-3.0.1.ebuild | 65 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 66 insertions(+)
