)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"25b9b13084200858e8e815fdf58d7c18dbb9aee8","unresolved":true,"context_lines":[{"line_number":39,"context_line":"https://bugs.launchpad.net/oslo.utils/+bug/2091114 is jsut one example."},{"line_number":40,"context_line":"as such some operator might want to take the risk that on real hardware"},{"line_number":41,"context_line":"or a future version of qemu/ovmf that this might not work if the firware"},{"line_number":42,"context_line":"actully enforces the uefi spec strictly."},{"line_number":43,"context_line":""},{"line_number":44,"context_line":"3.) we could just remove the conformance check and supprot legacy MBRs even"},{"line_number":45,"context_line":"if we detect a GPT Protective partition as long as the other requiremets"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":2,"id":"c4560546_1746ed99","line":42,"updated":"2025-01-02 15:01:26.000000000","message":"Obviously I\u0027m in favor of strictness and thus #1. If necessary, then #2 with warnings. I think we pretty much lose most ability to say much useful about the image if we do #3.","commit_id":"09bacef3657dfff5b0c48cb0f10b14099eeba54f"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":9649,"name":"Adrian Vladu","email":"avladu@cloudbasesolutions.com","username":"avladu"},"change_message_id":"a3fbc783542389bf0b36989353b03d23a0c4b167","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"f5004e7f_bb8076b7","updated":"2024-12-06 10:12:16.000000000","message":"LGTM.\n\nThese checks should be warnings, and not enforcing. Otherwise perfectly bootable images might not be usable in the OpenStack ecosystem.","commit_id":"09bacef3657dfff5b0c48cb0f10b14099eeba54f"}],"oslo_utils/imageutils/format_inspector.py":[{"author":{"_account_id":9649,"name":"Adrian Vladu","email":"avladu@cloudbasesolutions.com","username":"avladu"},"change_message_id":"a3fbc783542389bf0b36989353b03d23a0c4b167","unresolved":true,"context_lines":[{"line_number":1274,"context_line":"                else:"},{"line_number":1275,"context_line":"                    legacy_mbr \u003d True"},{"line_number":1276,"context_line":"        if not legacy_mbr and found_gpt and valid_partitions !\u003d [0]:"},{"line_number":1277,"context_line":"            raise SafetyViolation(\u0027GPT MBR defines invalid extra partitions\u0027)"},{"line_number":1278,"context_line":"        if not valid_partitions:"},{"line_number":1279,"context_line":"            raise SafetyViolation(\u0027GPT MBR has no partitions defined\u0027)"},{"line_number":1280,"context_line":"        if legacy_mbr:"}],"source_content_type":"text/x-python","patch_set":2,"id":"e6f5d057_de84ed34","line":1277,"updated":"2024-12-06 10:12:16.000000000","message":"In my opinion, these checks should be a warning, not a block on what OpenStack implementor like qemu-kvm/libvirt should do or not do.\nThis decision should be solely left to the OpenStack operator, otherwise, you will end up with perfectly bootable images blocked from usage by these incomplete / mostly undocumented / version dependent bitwise checks.","commit_id":"09bacef3657dfff5b0c48cb0f10b14099eeba54f"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"25b9b13084200858e8e815fdf58d7c18dbb9aee8","unresolved":true,"context_lines":[{"line_number":1274,"context_line":"                else:"},{"line_number":1275,"context_line":"                    legacy_mbr \u003d True"},{"line_number":1276,"context_line":"        if not legacy_mbr and found_gpt and valid_partitions !\u003d [0]:"},{"line_number":1277,"context_line":"            raise SafetyViolation(\u0027GPT MBR defines invalid extra partitions\u0027)"},{"line_number":1278,"context_line":"        if not valid_partitions:"},{"line_number":1279,"context_line":"            raise SafetyViolation(\u0027GPT MBR has no partitions defined\u0027)"},{"line_number":1280,"context_line":"        if legacy_mbr:"}],"source_content_type":"text/x-python","patch_set":2,"id":"629a4218_84e72841","line":1277,"in_reply_to":"30ea4c5a_bf9818ca","updated":"2025-01-02 15:01:26.000000000","message":"The safety checks for the more complicated formats are critical for us to perform, as the recent QCOW, VDMK, etc CVEs have proven, and as the qemu development team has recommended.\n\nThe checks for the less-obvious formats like GPT/MBR are probably not as important (although as Sean points out, not pointless) and we can probably be more lenient on these. However, what is critical is that we have some level of confidence that a GPT image is actually a GPT, and so some amount of validity-checking there is important and worthwhile, IMHO. I think for a GPT, we should make sure there\u0027s just a PMBR single-partition header at the very least, even if we are unable to say more specific things about legacy MBR layouts.","commit_id":"09bacef3657dfff5b0c48cb0f10b14099eeba54f"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"1b05653f3d1d227790250d29316b7f915b241be6","unresolved":true,"context_lines":[{"line_number":1274,"context_line":"                else:"},{"line_number":1275,"context_line":"                    legacy_mbr \u003d True"},{"line_number":1276,"context_line":"        if not legacy_mbr and found_gpt and valid_partitions !\u003d [0]:"},{"line_number":1277,"context_line":"            raise SafetyViolation(\u0027GPT MBR defines invalid extra partitions\u0027)"},{"line_number":1278,"context_line":"        if not valid_partitions:"},{"line_number":1279,"context_line":"            raise SafetyViolation(\u0027GPT MBR has no partitions defined\u0027)"},{"line_number":1280,"context_line":"        if legacy_mbr:"}],"source_content_type":"text/x-python","patch_set":2,"id":"30ea4c5a_bf9818ca","line":1277,"in_reply_to":"e6f5d057_de84ed34","updated":"2024-12-06 13:21:35.000000000","message":"images are uploadable by OpenStack users\nand operator can disable the safety check via config\n\nso they do have the option to opt out.\n\nby opting out however they are takign on all the burden of CVE mitigation.\nthat is not something we could really advocate for in good fait.\n\nthere have been kernel level CVEs related to invlaid GPT partion tabels or validation fo the same in the past both for linux and windows\n\nhttps://www.cvedetails.com/cve/CVE-2011-1776/\nhttps://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-23417\n\nso again we could relax the protections we have but this is here for a valid reason.\n\nmultiple non zero partiosn are only valid if and only if your usign legacy MBR image layout in which case you shoudl not have a GPT protective partion which is signifed by ostype 0xEE\n\n\nas an aside the SME that we need to review this is on PTO until the new year so this is a disucssion we will need to pick up in january.","commit_id":"09bacef3657dfff5b0c48cb0f10b14099eeba54f"}]}