)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":22623,"name":"Erik Olof Gunnar Andersson","email":"eandersson@blizzard.com","username":"eoandersson"},"change_message_id":"93a7268c1a98384b35b0ce3e9a0f53b102b39424","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"783c9451_81a0815d","updated":"2026-07-27 09:24:25.000000000","message":"Some of the failure logs are concerning (but unrelated to this patch).\n\ne.g.\n\n\u003e Exception during message handling: tenacity.RetryError: RetryError[\u003cFuture at 0x7daf807b6000 state\u003dfinished raised TryAgain\u003e]\n\n\u003e Can not send reply for message: ValueError: Cannot convert \u003cFuture at 0x7daf807b6000 state\u003dfinished raised TryAgain\u003e to primitive\n\nThese are likely RabbitMQ or memcached issues, but the poor logging around these isn\u0027t great and possibly an issue upstream?","commit_id":"e9d13ba127bf712d3f0d9b445fc3cff0e9210e30"},{"author":{"_account_id":31664,"name":"Omer Schwartz","email":"oschwart@redhat.com","username":"oschwart"},"change_message_id":"1ea1e18ce4e2696d7ae50830e52cf1884df3e769","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"038a6f18_52654795","updated":"2026-07-23 11:06:56.000000000","message":"recheck zuul nodes infra flakiness not related to the patch","commit_id":"e9d13ba127bf712d3f0d9b445fc3cff0e9210e30"},{"author":{"_account_id":31664,"name":"Omer Schwartz","email":"oschwart@redhat.com","username":"oschwart"},"change_message_id":"8a3341bdac49512c73f3c8c63122da57434f76a5","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"16bf65bd_b9467308","updated":"2026-07-23 21:28:32.000000000","message":"recheck zuul nodes infra flakiness not related to the patch","commit_id":"e9d13ba127bf712d3f0d9b445fc3cff0e9210e30"},{"author":{"_account_id":31664,"name":"Omer Schwartz","email":"oschwart@redhat.com","username":"oschwart"},"change_message_id":"bb50867dbb554855043c60e13448926b9950f405","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"2b092f3a_e34d5b96","updated":"2026-07-24 09:09:23.000000000","message":"recheck zuul nodes infra flakiness not related to the patch","commit_id":"e9d13ba127bf712d3f0d9b445fc3cff0e9210e30"},{"author":{"_account_id":31664,"name":"Omer Schwartz","email":"oschwart@redhat.com","username":"oschwart"},"change_message_id":"b8807361bc93e3b8118b32cc9ca234f807bdabc7","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"2bf736ef_adf0192d","updated":"2026-07-23 09:27:49.000000000","message":"recheck zuul nodes infra flakiness not related to the patch","commit_id":"e9d13ba127bf712d3f0d9b445fc3cff0e9210e30"},{"author":{"_account_id":31664,"name":"Omer Schwartz","email":"oschwart@redhat.com","username":"oschwart"},"change_message_id":"7ac36b25a3fca0283e227e9422dbad0906aaf960","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"3986ce0d_c1616f30","updated":"2026-07-23 12:29:45.000000000","message":"recheck zuul nodes infra flakiness not related to the patch","commit_id":"e9d13ba127bf712d3f0d9b445fc3cff0e9210e30"},{"author":{"_account_id":31664,"name":"Omer Schwartz","email":"oschwart@redhat.com","username":"oschwart"},"change_message_id":"73f521cb522f57fcd0901d19d466b9a1a147a404","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"4c7c41c6_0593ca8d","updated":"2026-07-24 19:06:29.000000000","message":"recheck zuul nodes infra flakiness not related to the patch","commit_id":"e9d13ba127bf712d3f0d9b445fc3cff0e9210e30"},{"author":{"_account_id":31664,"name":"Omer Schwartz","email":"oschwart@redhat.com","username":"oschwart"},"change_message_id":"d8c4ff91dbd657aaf0deb228602021295383577a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"8a5948eb_0114e5fa","updated":"2026-07-23 15:17:28.000000000","message":"recheck zuul nodes infra flakiness not related to the patch","commit_id":"e9d13ba127bf712d3f0d9b445fc3cff0e9210e30"},{"author":{"_account_id":31664,"name":"Omer Schwartz","email":"oschwart@redhat.com","username":"oschwart"},"change_message_id":"28a2c9b61702cebe191f63d3f361bbdcfd8a376a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"a4439df4_4c94cb78","updated":"2026-07-23 19:57:43.000000000","message":"recheck zuul nodes infra flakiness not related to the patch","commit_id":"e9d13ba127bf712d3f0d9b445fc3cff0e9210e30"},{"author":{"_account_id":31664,"name":"Omer Schwartz","email":"oschwart@redhat.com","username":"oschwart"},"change_message_id":"0a22b455b7a1def3fef7e0ee5720436991b731e4","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"017ef5d7_b5a23616","in_reply_to":"783c9451_81a0815d","updated":"2026-07-30 10:24:28.000000000","message":"Hey Erik, I came back from PTO yesterday. It is the new tooz version that caused all of this.\n\nThe patch that bumped the tooz version in the requirements repo was reverted and merged a few hours ago https://review.opendev.org/c/openstack/requirements/+/999181\n\nThis patch should fix the issue in the new tooz version https://review.opendev.org/c/openstack/tooz/+/999176\n\nAnd here we see that with a lower tooz version, designate CI passes again https://review.opendev.org/c/openstack/designate/+/999169\nOf course, a proper fix is needed, so the requirements-check job will pass. Right now it conflicts with the global requirements / constraints file.","commit_id":"e9d13ba127bf712d3f0d9b445fc3cff0e9210e30"},{"author":{"_account_id":6681,"name":"Brent Eagles","email":"beagles@redhat.com","username":"beagles"},"change_message_id":"e72430cb8287ea32a2598cd7aadb959e31acc907","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"f27d1682_7cd1bbf1","updated":"2026-08-03 18:32:58.000000000","message":"A nit and some questions.","commit_id":"582253440fcf1dfd4cc1dcd1300b3ad41141d421"},{"author":{"_account_id":31664,"name":"Omer Schwartz","email":"oschwart@redhat.com","username":"oschwart"},"change_message_id":"67499086097082bcffc97404d051726e9fd98889","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"6d1d6dd3_f1b4ebbd","updated":"2026-08-03 09:40:26.000000000","message":"I am planning to merge this patch soon and rerun the security team\u0027s PQC tool again, as discussed with Mauricio","commit_id":"582253440fcf1dfd4cc1dcd1300b3ad41141d421"},{"author":{"_account_id":31664,"name":"Omer Schwartz","email":"oschwart@redhat.com","username":"oschwart"},"change_message_id":"798a2b6fdc60cc6069337f5b4227f7a27ecdb2a5","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"6dedb40f_692e2f33","updated":"2026-08-10 18:11:31.000000000","message":"Let\u0027s merge it","commit_id":"301129e885b25584f41d1d5ee46eedf7898d3860"}],"designate/backend/impl_nsd4.py":[{"author":{"_account_id":35125,"name":"Mauricio Harley","email":"mharley@redhat.com","username":"mharley-rh"},"change_message_id":"ad0ae737d5408e7ccb510a9829074a2e3b8f2955","unresolved":true,"context_lines":[{"line_number":100,"context_line":"                raise exceptions.ConfigurationError("},{"line_number":101,"context_line":"                    \u0027NSD4 backend: Certificate verification cannot be \u0027"},{"line_number":102,"context_line":"                    \u0027disabled when pqc check_mode is \"strict\".\u0027"},{"line_number":103,"context_line":"                )"},{"line_number":104,"context_line":"            context.verify_mode \u003d ssl.CERT_NONE"},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"        return context"}],"source_content_type":"text/x-python","patch_set":1,"id":"437123bd_99e8905b","line":103,"updated":"2026-07-13 13:18:39.000000000","message":"This preserves `CERT_NONE` as a reachable default when `verify_ssl\u003dfalse` is set - the new raise only triggers when `check_mode \u003d\u003d \"strict\"`, which isn\u0027t the default (disabled). With the default config, an operator can still fully disable certificate verification exactly as before this patch. Is that intentional for backward compatibility, or should check_mode default to permissive so this is at least surfaced as a warning out of the box?","commit_id":"8c398fb0930475bab6a411e3ea7d17968c2aa8a9"},{"author":{"_account_id":31664,"name":"Omer Schwartz","email":"oschwart@redhat.com","username":"oschwart"},"change_message_id":"964364467d17b443e320e3fc8ede8349ae681594","unresolved":false,"context_lines":[{"line_number":100,"context_line":"                raise exceptions.ConfigurationError("},{"line_number":101,"context_line":"                    \u0027NSD4 backend: Certificate verification cannot be \u0027"},{"line_number":102,"context_line":"                    \u0027disabled when pqc check_mode is \"strict\".\u0027"},{"line_number":103,"context_line":"                )"},{"line_number":104,"context_line":"            context.verify_mode \u003d ssl.CERT_NONE"},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"        return context"}],"source_content_type":"text/x-python","patch_set":1,"id":"16d2c662_51bfadfa","line":103,"in_reply_to":"139a790a_3c439b4c","updated":"2026-07-22 15:47:05.000000000","message":"check_mode now defaults to permissive instead of disabled, so this condition is now surfaced with a warning by default rather than requiring an explicit opt-in to even see it.","commit_id":"8c398fb0930475bab6a411e3ea7d17968c2aa8a9"},{"author":{"_account_id":31664,"name":"Omer Schwartz","email":"oschwart@redhat.com","username":"oschwart"},"change_message_id":"91f701a4224aed95d69858ef76176a67db02c0cf","unresolved":true,"context_lines":[{"line_number":100,"context_line":"                raise exceptions.ConfigurationError("},{"line_number":101,"context_line":"                    \u0027NSD4 backend: Certificate verification cannot be \u0027"},{"line_number":102,"context_line":"                    \u0027disabled when pqc check_mode is \"strict\".\u0027"},{"line_number":103,"context_line":"                )"},{"line_number":104,"context_line":"            context.verify_mode \u003d ssl.CERT_NONE"},{"line_number":105,"context_line":""},{"line_number":106,"context_line":"        return context"}],"source_content_type":"text/x-python","patch_set":1,"id":"139a790a_3c439b4c","line":103,"in_reply_to":"437123bd_99e8905b","updated":"2026-07-14 11:37:56.000000000","message":"Exactly, the requirements mention:\n\u003e 1. Should OpenStack reject quantum-risk code, even when user-configurable?\nNo. The migration should be opt-in and backward-compatible. Operators must be able to adopt PQC at their own pace. The goal is to make PQC possible, not to break existing deployments.\n\nhttps://wiki.openstack.org/wiki/Post_quantum_openstack","commit_id":"8c398fb0930475bab6a411e3ea7d17968c2aa8a9"}],"designate/backend/impl_pdns4.py":[{"author":{"_account_id":35125,"name":"Mauricio Harley","email":"mharley@redhat.com","username":"mharley-rh"},"change_message_id":"ad0ae737d5408e7ccb510a9829074a2e3b8f2955","unresolved":true,"context_lines":[{"line_number":34,"context_line":""},{"line_number":35,"context_line":"    __backend_status__ \u003d \u0027integrated\u0027"},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"    def __init__(self, target):"},{"line_number":38,"context_line":"        super().__init__(target)"},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"        self.api_endpoint \u003d self.options.get(\u0027api_endpoint\u0027)"}],"source_content_type":"text/x-python","patch_set":1,"id":"ef55670b_81aeb45d","line":37,"updated":"2026-07-13 13:18:39.000000000","message":"NSD4\u0027s PQC check got dedicated unit tests (`test_init_pqc_permissive`, `test_init_pqc_disabled_no_check`), but this same code path in `PDNS4Backend.__init__` has no test coverage at all - no changes in `test_pdns4.py`. Could you add equivalent tests here for parity?","commit_id":"8c398fb0930475bab6a411e3ea7d17968c2aa8a9"},{"author":{"_account_id":31664,"name":"Omer Schwartz","email":"oschwart@redhat.com","username":"oschwart"},"change_message_id":"964364467d17b443e320e3fc8ede8349ae681594","unresolved":false,"context_lines":[{"line_number":34,"context_line":""},{"line_number":35,"context_line":"    __backend_status__ \u003d \u0027integrated\u0027"},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"    def __init__(self, target):"},{"line_number":38,"context_line":"        super().__init__(target)"},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"        self.api_endpoint \u003d self.options.get(\u0027api_endpoint\u0027)"}],"source_content_type":"text/x-python","patch_set":1,"id":"0c6af4eb_5ea4e22b","line":37,"in_reply_to":"ef55670b_81aeb45d","updated":"2026-07-22 15:47:05.000000000","message":"Added test_init_pqc_permissive and test_init_pqc_disabled_no_check to test_pdns4.py, mirroring the NSD4 coverage.","commit_id":"8c398fb0930475bab6a411e3ea7d17968c2aa8a9"}],"designate/common/crypto_utils.py":[{"author":{"_account_id":35125,"name":"Mauricio Harley","email":"mharley@redhat.com","username":"mharley-rh"},"change_message_id":"ad0ae737d5408e7ccb510a9829074a2e3b8f2955","unresolved":true,"context_lines":[{"line_number":88,"context_line":"            continue"},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"        algorithm, is_vulnerable \u003d is_quantum_vulnerable_cert(cert_path)"},{"line_number":91,"context_line":"        if algorithm is None:"},{"line_number":92,"context_line":"            continue"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"        if is_vulnerable:"}],"source_content_type":"text/x-python","patch_set":1,"id":"4dbf4f46_7fd6dccf","line":91,"updated":"2026-07-13 13:18:39.000000000","message":"In strict mode, a certificate that fails to load or parse is silently skipped here (continue) rather than treated as a failure. That means an unreadable/corrupt cert file defeats the \"refuse to start\" guarantee strict is meant to provide - the opposite of fail-safe. Should this raise `ConfigurationError` in strict mode when algorithm is None, instead of only warning? Also, `except (ValueError, Exception):` in `is_quantum_vulnerable_cert` is effectively a bare except (Exception already covers `ValueError`) - worth narrowing to the specific exceptions `x509.load_*_certificate` can raise, so unexpected bugs aren\u0027t silently swallowed as \"unparseable cert.\"","commit_id":"8c398fb0930475bab6a411e3ea7d17968c2aa8a9"},{"author":{"_account_id":31664,"name":"Omer Schwartz","email":"oschwart@redhat.com","username":"oschwart"},"change_message_id":"964364467d17b443e320e3fc8ede8349ae681594","unresolved":false,"context_lines":[{"line_number":88,"context_line":"            continue"},{"line_number":89,"context_line":""},{"line_number":90,"context_line":"        algorithm, is_vulnerable \u003d is_quantum_vulnerable_cert(cert_path)"},{"line_number":91,"context_line":"        if algorithm is None:"},{"line_number":92,"context_line":"            continue"},{"line_number":93,"context_line":""},{"line_number":94,"context_line":"        if is_vulnerable:"}],"source_content_type":"text/x-python","patch_set":1,"id":"f3bbf74d_f411b53c","line":91,"in_reply_to":"4dbf4f46_7fd6dccf","updated":"2026-07-22 15:47:05.000000000","message":"Fixed both. check_pqc_compliance now raises ConfigurationError when a cert can\u0027t be read or parsed and check_mode\u003dstrict, instead of silently continue-ing — closes the fail-safe gap you flagged. Also narrowed except (ValueError, Exception) to except ValueError in is_quantum_vulnerable_cert, since that\u0027s the only exception x509.load_pem_x509_certificate/load_der_x509_certificate raise for malformed input.","commit_id":"8c398fb0930475bab6a411e3ea7d17968c2aa8a9"}],"designate/conf/pqc.py":[{"author":{"_account_id":35125,"name":"Mauricio Harley","email":"mharley@redhat.com","username":"mharley-rh"},"change_message_id":"ad0ae737d5408e7ccb510a9829074a2e3b8f2955","unresolved":true,"context_lines":[{"line_number":21,"context_line":"PQC_OPTS \u003d ["},{"line_number":22,"context_line":"    cfg.StrOpt("},{"line_number":23,"context_line":"        \u0027check_mode\u0027,"},{"line_number":24,"context_line":"        default\u003d\u0027disabled\u0027,"},{"line_number":25,"context_line":"        choices\u003d["},{"line_number":26,"context_line":"            (\u0027disabled\u0027,"},{"line_number":27,"context_line":"             \u0027No PQC compliance checks are performed. \u0027"}],"source_content_type":"text/x-python","patch_set":1,"id":"42085c3f_56f8329f","line":24,"updated":"2026-07-13 13:18:39.000000000","message":"Given this option gates all PQC-compliance checks (cert algorithm detection, `verify_ssl` enforcement, TLS floor), defaulting to disabled means none of them run unless an operator opts in. Worth considering permissive as the default - it only logs warnings, doesn\u0027t change behavior or fail startup, but at least gives operators visibility without requiring action.","commit_id":"8c398fb0930475bab6a411e3ea7d17968c2aa8a9"},{"author":{"_account_id":31664,"name":"Omer Schwartz","email":"oschwart@redhat.com","username":"oschwart"},"change_message_id":"964364467d17b443e320e3fc8ede8349ae681594","unresolved":false,"context_lines":[{"line_number":21,"context_line":"PQC_OPTS \u003d ["},{"line_number":22,"context_line":"    cfg.StrOpt("},{"line_number":23,"context_line":"        \u0027check_mode\u0027,"},{"line_number":24,"context_line":"        default\u003d\u0027disabled\u0027,"},{"line_number":25,"context_line":"        choices\u003d["},{"line_number":26,"context_line":"            (\u0027disabled\u0027,"},{"line_number":27,"context_line":"             \u0027No PQC compliance checks are performed. \u0027"}],"source_content_type":"text/x-python","patch_set":1,"id":"c89a6a5c_feb3da40","line":24,"in_reply_to":"42085c3f_56f8329f","updated":"2026-07-22 15:47:05.000000000","message":"Changed the default to permissive.","commit_id":"8c398fb0930475bab6a411e3ea7d17968c2aa8a9"},{"author":{"_account_id":6681,"name":"Brent Eagles","email":"beagles@redhat.com","username":"beagles"},"change_message_id":"e72430cb8287ea32a2598cd7aadb959e31acc907","unresolved":true,"context_lines":[{"line_number":21,"context_line":"PQC_OPTS \u003d ["},{"line_number":22,"context_line":"    cfg.StrOpt("},{"line_number":23,"context_line":"        \u0027check_mode\u0027,"},{"line_number":24,"context_line":"        default\u003d\u0027permissive\u0027,"},{"line_number":25,"context_line":"        choices\u003d["},{"line_number":26,"context_line":"            (\u0027disabled\u0027,"},{"line_number":27,"context_line":"             \u0027No PQC compliance checks are performed.\u0027),"}],"source_content_type":"text/x-python","patch_set":5,"id":"f05f1f95_8412ec39","line":24,"updated":"2026-08-03 18:32:58.000000000","message":"commit message implies default is \u0027disabled\u0027 not \u0027permissive\u0027. Considering the release note, you probably meant permissive but you might want to amend to avoid confusion.","commit_id":"582253440fcf1dfd4cc1dcd1300b3ad41141d421"},{"author":{"_account_id":31664,"name":"Omer Schwartz","email":"oschwart@redhat.com","username":"oschwart"},"change_message_id":"1e20d570f0245744432bcdba8e2b528fb9403d2c","unresolved":false,"context_lines":[{"line_number":21,"context_line":"PQC_OPTS \u003d ["},{"line_number":22,"context_line":"    cfg.StrOpt("},{"line_number":23,"context_line":"        \u0027check_mode\u0027,"},{"line_number":24,"context_line":"        default\u003d\u0027permissive\u0027,"},{"line_number":25,"context_line":"        choices\u003d["},{"line_number":26,"context_line":"            (\u0027disabled\u0027,"},{"line_number":27,"context_line":"             \u0027No PQC compliance checks are performed.\u0027),"}],"source_content_type":"text/x-python","patch_set":5,"id":"f4c88b8c_a9bfdec2","line":24,"in_reply_to":"f05f1f95_8412ec39","updated":"2026-08-04 10:49:24.000000000","message":"Fixed — amended the commit message to say permissive, and updated the RSA/ECDSA/DSA list there since strict mode now also flags Ed25519/Ed448/X25519/X448.","commit_id":"582253440fcf1dfd4cc1dcd1300b3ad41141d421"}],"designate/tests/unit/common/test_crypto_utils.py":[{"author":{"_account_id":6681,"name":"Brent Eagles","email":"beagles@redhat.com","username":"beagles"},"change_message_id":"e72430cb8287ea32a2598cd7aadb959e31acc907","unresolved":true,"context_lines":[{"line_number":15,"context_line":"import tempfile"},{"line_number":16,"context_line":"from unittest import mock"},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"from cryptography.exceptions import UnsupportedAlgorithm"},{"line_number":19,"context_line":"from cryptography.hazmat.primitives.asymmetric import dsa"},{"line_number":20,"context_line":"from cryptography.hazmat.primitives.asymmetric import ec"},{"line_number":21,"context_line":"from cryptography.hazmat.primitives.asymmetric import ed25519"}],"source_content_type":"text/x-python","patch_set":5,"id":"8a567ab4_05846385","line":18,"updated":"2026-08-03 18:32:58.000000000","message":"should the cryptography package be included in requirements.txt?","commit_id":"582253440fcf1dfd4cc1dcd1300b3ad41141d421"},{"author":{"_account_id":31664,"name":"Omer Schwartz","email":"oschwart@redhat.com","username":"oschwart"},"change_message_id":"1e20d570f0245744432bcdba8e2b528fb9403d2c","unresolved":false,"context_lines":[{"line_number":15,"context_line":"import tempfile"},{"line_number":16,"context_line":"from unittest import mock"},{"line_number":17,"context_line":""},{"line_number":18,"context_line":"from cryptography.exceptions import UnsupportedAlgorithm"},{"line_number":19,"context_line":"from cryptography.hazmat.primitives.asymmetric import dsa"},{"line_number":20,"context_line":"from cryptography.hazmat.primitives.asymmetric import ec"},{"line_number":21,"context_line":"from cryptography.hazmat.primitives.asymmetric import ed25519"}],"source_content_type":"text/x-python","patch_set":5,"id":"2d286a55_768d7879","line":18,"in_reply_to":"8a567ab4_05846385","updated":"2026-08-04 10:49:24.000000000","message":"Added cryptography\u003e\u003d41.0.0 to requirements.txt. It was only present transitively via keystonemiddleware; crypto_utils.py imports it directly so it should be declared explicitly.","commit_id":"582253440fcf1dfd4cc1dcd1300b3ad41141d421"},{"author":{"_account_id":6681,"name":"Brent Eagles","email":"beagles@redhat.com","username":"beagles"},"change_message_id":"e72430cb8287ea32a2598cd7aadb959e31acc907","unresolved":true,"context_lines":[{"line_number":82,"context_line":"        self.assertTrue(is_vulnerable)"},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"    def test_is_quantum_vulnerable_cert_non_vulnerable_key(self):"},{"line_number":85,"context_line":"        key \u003d ed25519.Ed25519PrivateKey.generate()"},{"line_number":86,"context_line":"        path \u003d self._create_temp_cert(key, no_prehash\u003dTrue)"},{"line_number":87,"context_line":"        algo, is_vulnerable \u003d crypto_utils.is_quantum_vulnerable_cert(path)"},{"line_number":88,"context_line":"        self.assertEqual(\u0027Ed25519PublicKey\u0027, algo)"}],"source_content_type":"text/x-python","patch_set":5,"id":"92a0363b_48eb42ca","line":85,"updated":"2026-08-03 18:32:58.000000000","message":"is ed25519 not currently considered vulnerable?","commit_id":"582253440fcf1dfd4cc1dcd1300b3ad41141d421"},{"author":{"_account_id":31664,"name":"Omer Schwartz","email":"oschwart@redhat.com","username":"oschwart"},"change_message_id":"1e20d570f0245744432bcdba8e2b528fb9403d2c","unresolved":false,"context_lines":[{"line_number":82,"context_line":"        self.assertTrue(is_vulnerable)"},{"line_number":83,"context_line":""},{"line_number":84,"context_line":"    def test_is_quantum_vulnerable_cert_non_vulnerable_key(self):"},{"line_number":85,"context_line":"        key \u003d ed25519.Ed25519PrivateKey.generate()"},{"line_number":86,"context_line":"        path \u003d self._create_temp_cert(key, no_prehash\u003dTrue)"},{"line_number":87,"context_line":"        algo, is_vulnerable \u003d crypto_utils.is_quantum_vulnerable_cert(path)"},{"line_number":88,"context_line":"        self.assertEqual(\u0027Ed25519PublicKey\u0027, algo)"}],"source_content_type":"text/x-python","patch_set":5,"id":"bcf40230_ec02e61f","line":85,"in_reply_to":"92a0363b_48eb42ca","updated":"2026-08-04 10:49:24.000000000","message":"Good catch — Ed25519/Ed448 (EdDSA) and X25519/X448 (ECDH) rely on the same elliptic-curve discrete-log problem as ECDSA, so they\u0027re equally broken by Shor\u0027s algorithm. Added them to QUANTUM_VULNERABLE_NAMES and fixed the test, which was asserting the opposite.","commit_id":"582253440fcf1dfd4cc1dcd1300b3ad41141d421"}]}