)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"9eaaabb26c0fd6ddd38c396c2dc2499ad6b25990","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"115804a2_faa9bfa4","updated":"2025-12-05 16:08:53.000000000","message":"Just 2 minor things, otherwise this looks good to me.","commit_id":"36c09496f4b5f1221df62181511c3a2a6c7d9d70"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"327bbf321091bdb6363dfc200545d579d4e43b55","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"cd5784c3_4829d37b","updated":"2026-02-18 16:01:49.000000000","message":"I think I\u0027m reasonably okay with this now if you can (at least) soften the language about \"glance should never do this\".","commit_id":"86aba94b3816c8eefee26a09797ba6c6f941b585"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"593fcedec7129650ab3a363c2ef43a22651c7be6","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":7,"id":"7d2b5fde_7e4db224","updated":"2025-12-11 19:20:56.000000000","message":"My concerns have been addressed; LGTM.","commit_id":"86aba94b3816c8eefee26a09797ba6c6f941b585"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"c346e59c5be72e1ee8464fa0c0d1ab18bd614916","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":8,"id":"16d762be_6b2d16e2","updated":"2026-02-24 18:08:04.000000000","message":"So, I have spent a little bit of time proving out that in-flight inspection of an encrypted LUKS image is doable. It\u0027s not quite in a format yet to share, but I\u0027ll work on getting it at least presentable soon so we can have a look.\n\nI think that given that progress, it would be good to keep glance\u0027s current strong safety checking guarantees even for the LUKS disk format so long as that work pans out as it seems like it will.","commit_id":"37bc213e3396c7045a9fdc5c7036b27793eaa1ae"},{"author":{"_account_id":8122,"name":"Cyril Roelandt","email":"cyril@redhat.com","username":"cyril.roelandt.enovance"},"change_message_id":"87e395306077a8b8f486b805492ba599236434be","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":8,"id":"714df0da_ee82e942","in_reply_to":"16d762be_6b2d16e2","updated":"2026-02-25 20:47:00.000000000","message":"As this seems doable, I would like this to be mentioned in the spec.","commit_id":"37bc213e3396c7045a9fdc5c7036b27793eaa1ae"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"c7646de8f2144075211fd70a72ef788af1d1d53e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":9,"id":"6f2a5a20_0aa6697b","updated":"2026-03-12 15:27:17.000000000","message":"I have removed the statements about raw LUKS inspection being impossible/problematic because I was able to successfully test Dan Smith\u0027s latest POC for the LUKS inspector in oslo.utils, which will be able to address this.","commit_id":"41cbd8fe83af754bcf98de4f71f954af83ceb266"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"9be57fdf7bbb50f76c6c4c1970784045c39ccff8","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":10,"id":"5bd7250c_534ea330","updated":"2026-03-12 16:37:19.000000000","message":"@cyril@redhat.com, I assume you want to move this to specs/2026.2 right?","commit_id":"c51f07c142a1ddbeee22379c6f81f364dee5d907"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"1ead82b695a26a3b60511789171301675c04ab35","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":13,"id":"13beb551_93324841","updated":"2026-03-18 13:29:48.000000000","message":"Moved to `specs/2026.2` and changed the image conversion behavior to gracefully skip (like for ISO) instead of failing/rejecting the process.","commit_id":"1f5da261d08a71afc24c28ee4cb6c8cf322f7751"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"b2744f86fa9aeff91ba46429348af15ccb363aad","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":15,"id":"6f491a2d_d92cf8fc","updated":"2026-05-01 13:36:25.000000000","message":"Yep, looks good to me, thanks Markus!","commit_id":"1c2eca902824c83c8a769d199ee99b18cb54c39c"}],"specs/2026.1/approved/glance/standardized_image_encryption.rst":[{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"9eaaabb26c0fd6ddd38c396c2dc2499ad6b25990","unresolved":true,"context_lines":[{"line_number":175,"context_line":"To not accidentally delete a key, which is used to encrypt an image, we will"},{"line_number":176,"context_line":"let Glance register as a consumer of that key (secret in Barbican [1]) when the"},{"line_number":177,"context_line":"corresponding encrypted image is uploaded and unregister as a consumer when the"},{"line_number":178,"context_line":"image is deleted in Glance. When the parameter \"os_encrypt_key_deletion_policy\""},{"line_number":179,"context_line":"is set to \"True\", we will try to delete the key. If that fails, because there"},{"line_number":180,"context_line":"was still a consumer, we let Glance log that as a warning and proceed with the"},{"line_number":181,"context_line":"image deletion process. In this case the key might still be used for another"},{"line_number":182,"context_line":"image or some other ressource and we do not want to delete it, we rather assume"}],"source_content_type":"text/x-rst","patch_set":3,"id":"e4d9019f_a9d75f7c","line":179,"range":{"start_line":178,"start_character":27,"end_line":179,"end_character":48},"updated":"2025-12-05 16:08:53.000000000","message":"This isn\u0027t a boolean (at least, cinder_encryption_key_id isn\u0027t):\nhttps://opendev.org/openstack/glance/src/commit/955d086873b9368090134aa01d5226f9b9fa19df/etc/schema-image.json#L36-L43\n\nI think we should stick with the enumerated values for the renamed property.","commit_id":"36c09496f4b5f1221df62181511c3a2a6c7d9d70"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"f7317018e6608b27f7bc58c731b236171a74f1fb","unresolved":false,"context_lines":[{"line_number":175,"context_line":"To not accidentally delete a key, which is used to encrypt an image, we will"},{"line_number":176,"context_line":"let Glance register as a consumer of that key (secret in Barbican [1]) when the"},{"line_number":177,"context_line":"corresponding encrypted image is uploaded and unregister as a consumer when the"},{"line_number":178,"context_line":"image is deleted in Glance. When the parameter \"os_encrypt_key_deletion_policy\""},{"line_number":179,"context_line":"is set to \"True\", we will try to delete the key. If that fails, because there"},{"line_number":180,"context_line":"was still a consumer, we let Glance log that as a warning and proceed with the"},{"line_number":181,"context_line":"image deletion process. In this case the key might still be used for another"},{"line_number":182,"context_line":"image or some other ressource and we do not want to delete it, we rather assume"}],"source_content_type":"text/x-rst","patch_set":3,"id":"def864ac_9efc6769","line":179,"range":{"start_line":178,"start_character":27,"end_line":179,"end_character":48},"in_reply_to":"e4d9019f_a9d75f7c","updated":"2025-12-09 10:47:35.000000000","message":"You are right. In the implementation we actually expect it to be \"on_image_deletion\" like with the old property. I\u0027ve aligned the spec to that.","commit_id":"36c09496f4b5f1221df62181511c3a2a6c7d9d70"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"9eaaabb26c0fd6ddd38c396c2dc2499ad6b25990","unresolved":true,"context_lines":[{"line_number":269,"context_line":"Other end user impact"},{"line_number":270,"context_line":"---------------------"},{"line_number":271,"context_line":""},{"line_number":272,"context_line":"* Users should be able to optionally, but knowingly upload an encrypted image."},{"line_number":273,"context_line":""},{"line_number":274,"context_line":"* If an administrator has configured Glance to reject unencrypted images, such"},{"line_number":275,"context_line":"  images will not be accepted when attempted to be uploaded to Glance."}],"source_content_type":"text/x-rst","patch_set":3,"id":"21d8337d_9435cdf1","line":272,"updated":"2025-12-05 16:08:53.000000000","message":"We\u0027ll have to educate people about the correct disk_format to use, i.e., \u0027raw\u0027 vs. \u0027gpt\u0027, because once the image goes active in glance, I believe it cannot be changed.","commit_id":"36c09496f4b5f1221df62181511c3a2a6c7d9d70"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"f7317018e6608b27f7bc58c731b236171a74f1fb","unresolved":false,"context_lines":[{"line_number":269,"context_line":"Other end user impact"},{"line_number":270,"context_line":"---------------------"},{"line_number":271,"context_line":""},{"line_number":272,"context_line":"* Users should be able to optionally, but knowingly upload an encrypted image."},{"line_number":273,"context_line":""},{"line_number":274,"context_line":"* If an administrator has configured Glance to reject unencrypted images, such"},{"line_number":275,"context_line":"  images will not be accepted when attempted to be uploaded to Glance."}],"source_content_type":"text/x-rst","patch_set":3,"id":"330c7bc1_eb23a5ff","line":272,"in_reply_to":"21d8337d_9435cdf1","updated":"2025-12-09 10:47:35.000000000","message":"Good point. I\u0027ve added this to the end user impact section. A suitable section will be added to the user documentation.","commit_id":"36c09496f4b5f1221df62181511c3a2a6c7d9d70"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5a82f8eae9bbe1c47c75d8a3853e43f0bfa0cbcb","unresolved":true,"context_lines":[{"line_number":91,"context_line":"content. Such image\u0027s \u0027container_format\u0027 must be set to luks and the"},{"line_number":92,"context_line":"\u0027disk_format\u0027 will be used to indicate the decrypted format: raw or gpt. As the"},{"line_number":93,"context_line":"contained format can only be verified by decrypting the entire payload of the"},{"line_number":94,"context_line":"image, because LUKS does not support streamable decryption, attesting this is"},{"line_number":95,"context_line":"currently out of scope for Glance. Every service that consumes such"},{"line_number":96,"context_line":"LUKS-encrypted images needs to be aware of that and implement further"},{"line_number":97,"context_line":"validation if necessary."},{"line_number":98,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"9ab8ab88_a08922a6","line":95,"range":{"start_line":94,"start_character":60,"end_line":95,"end_character":33},"updated":"2025-12-09 18:26:50.000000000","message":"We can check that it\u0027s LUKS at least.\n\nAlso, I\u0027m not actually sure this is universally true... If you read the LUKS header you may be able to decrypt the first block of data, which is enough for MBR/GPT assertion. That\u0027s possible right? Yes, confirmed further down in the doc, but perhaps a note here as well even if referring to below.","commit_id":"84dcca662a75920e42c1a1a1ed2124a57ccbcc39"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"f466764e89e3da50eabb6c071b53529417986f79","unresolved":true,"context_lines":[{"line_number":91,"context_line":"content. Such image\u0027s \u0027container_format\u0027 must be set to luks and the"},{"line_number":92,"context_line":"\u0027disk_format\u0027 will be used to indicate the decrypted format: raw or gpt. As the"},{"line_number":93,"context_line":"contained format can only be verified by decrypting the entire payload of the"},{"line_number":94,"context_line":"image, because LUKS does not support streamable decryption, attesting this is"},{"line_number":95,"context_line":"currently out of scope for Glance. Every service that consumes such"},{"line_number":96,"context_line":"LUKS-encrypted images needs to be aware of that and implement further"},{"line_number":97,"context_line":"validation if necessary."},{"line_number":98,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"71b8de45_1ee30d9e","line":95,"range":{"start_line":94,"start_character":60,"end_line":95,"end_character":33},"in_reply_to":"5fd63044_ac836bd5","updated":"2025-12-11 17:27:58.000000000","message":"Yeah, my point is just that we _should_ assert that it at least has a LUKS header at a minimum, and that we can try to assert the contents match the `disk_format` if possible (and not if we determine it\u0027s not possible).","commit_id":"84dcca662a75920e42c1a1a1ed2124a57ccbcc39"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"c7646de8f2144075211fd70a72ef788af1d1d53e","unresolved":false,"context_lines":[{"line_number":91,"context_line":"content. Such image\u0027s \u0027container_format\u0027 must be set to luks and the"},{"line_number":92,"context_line":"\u0027disk_format\u0027 will be used to indicate the decrypted format: raw or gpt. As the"},{"line_number":93,"context_line":"contained format can only be verified by decrypting the entire payload of the"},{"line_number":94,"context_line":"image, because LUKS does not support streamable decryption, attesting this is"},{"line_number":95,"context_line":"currently out of scope for Glance. Every service that consumes such"},{"line_number":96,"context_line":"LUKS-encrypted images needs to be aware of that and implement further"},{"line_number":97,"context_line":"validation if necessary."},{"line_number":98,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"e7517f18_2cb515dd","line":95,"range":{"start_line":94,"start_character":60,"end_line":95,"end_character":33},"in_reply_to":"71b8de45_1ee30d9e","updated":"2026-03-12 15:27:17.000000000","message":"I have removed this statement now as we will likely be able to attest this thanks to your work on the oslo.utils inspector.","commit_id":"84dcca662a75920e42c1a1a1ed2124a57ccbcc39"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"9011e5e78c5bd28c469dbf94477577a7f76592a3","unresolved":true,"context_lines":[{"line_number":91,"context_line":"content. Such image\u0027s \u0027container_format\u0027 must be set to luks and the"},{"line_number":92,"context_line":"\u0027disk_format\u0027 will be used to indicate the decrypted format: raw or gpt. As the"},{"line_number":93,"context_line":"contained format can only be verified by decrypting the entire payload of the"},{"line_number":94,"context_line":"image, because LUKS does not support streamable decryption, attesting this is"},{"line_number":95,"context_line":"currently out of scope for Glance. Every service that consumes such"},{"line_number":96,"context_line":"LUKS-encrypted images needs to be aware of that and implement further"},{"line_number":97,"context_line":"validation if necessary."},{"line_number":98,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"5fd63044_ac836bd5","line":95,"range":{"start_line":94,"start_character":60,"end_line":95,"end_character":33},"in_reply_to":"9ab8ab88_a08922a6","updated":"2025-12-10 15:59:00.000000000","message":"\u003e That\u0027s possible right? Yes, confirmed further down in the doc, but perhaps a note here as well even if referring to below.\n\nAre you referring to the following statement I added in the section of the PTG summary?\n\n\u003e The Glance defender mechanism could be extended to verify the existence of the GPT header within the first blocks of the encryption payload.\n\nIf so, I was effectively quoting you from the 2025-10-30 PTG session with that statement. My stance was that from what I was able to research, LUKS cannot be decrypted in a streamable fashion. However, as far as I recall you said that similar things have been done in the Glance defender mechanisms already and that you are confident that it can be done for LUKS. That\u0027s why I included it in the later section which is effectively a PTG decision record summary. Sorry if I got you wrong on that.\n\nPersonally, I cannot say for sure if it *can* be implemented in such a manner and currently still have my doubts. Maybe we should change the statement to clarify that and emphasize that implementation details about the format validation are still up for debate?","commit_id":"84dcca662a75920e42c1a1a1ed2124a57ccbcc39"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5a82f8eae9bbe1c47c75d8a3853e43f0bfa0cbcb","unresolved":true,"context_lines":[{"line_number":134,"context_line":"will be allowed in combination with qcow and raw images. We use this two"},{"line_number":135,"context_line":"versions for the following reasons:"},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"1. Nova can directly use qcow-LUKS encrypted when creating a server. This is"},{"line_number":138,"context_line":"   the standard procedure of Nova. Nova can also handle LUKS-encrypted raw"},{"line_number":139,"context_line":"   images."},{"line_number":140,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"7dd69fa6_5e2c2505","line":137,"updated":"2025-12-09 18:26:50.000000000","message":"I think it\u0027s implied by the fact that this is a glance spec, but I think it\u0027s worth calling out somewhere here that this is just the glance part of it. Nova will not be able to consume these images until/unless work is done on the nova side to enable it.\n\nI say that because I talked to at least one person recently that thought this might be the last nail required to enable the full end-to-end workflow, and it\u0027s not.","commit_id":"84dcca662a75920e42c1a1a1ed2124a57ccbcc39"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"9011e5e78c5bd28c469dbf94477577a7f76592a3","unresolved":true,"context_lines":[{"line_number":134,"context_line":"will be allowed in combination with qcow and raw images. We use this two"},{"line_number":135,"context_line":"versions for the following reasons:"},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"1. Nova can directly use qcow-LUKS encrypted when creating a server. This is"},{"line_number":138,"context_line":"   the standard procedure of Nova. Nova can also handle LUKS-encrypted raw"},{"line_number":139,"context_line":"   images."},{"line_number":140,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"ce418d44_1176dc06","line":137,"in_reply_to":"7dd69fa6_5e2c2505","updated":"2025-12-10 15:59:00.000000000","message":"I rephrased this part to emphasize that this lays the foundation for a future implementation in Nova and that the decision is based on Nova\u0027s existing familiarity with the qcow2 format.","commit_id":"84dcca662a75920e42c1a1a1ed2124a57ccbcc39"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"f466764e89e3da50eabb6c071b53529417986f79","unresolved":false,"context_lines":[{"line_number":134,"context_line":"will be allowed in combination with qcow and raw images. We use this two"},{"line_number":135,"context_line":"versions for the following reasons:"},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"1. Nova can directly use qcow-LUKS encrypted when creating a server. This is"},{"line_number":138,"context_line":"   the standard procedure of Nova. Nova can also handle LUKS-encrypted raw"},{"line_number":139,"context_line":"   images."},{"line_number":140,"context_line":""}],"source_content_type":"text/x-rst","patch_set":4,"id":"dca828f0_1aa42f96","line":137,"in_reply_to":"ce418d44_1176dc06","updated":"2025-12-11 17:27:58.000000000","message":"Done","commit_id":"84dcca662a75920e42c1a1a1ed2124a57ccbcc39"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5a82f8eae9bbe1c47c75d8a3853e43f0bfa0cbcb","unresolved":true,"context_lines":[{"line_number":190,"context_line":"encryption to be handled by Glance. This would be more than the scope of this"},{"line_number":191,"context_line":"spec will be. So if image conversion is enabled and an encrypted images that"},{"line_number":192,"context_line":"needs conversion is uploaded the API will return a 400 Error and the image will"},{"line_number":193,"context_line":"be put in the queued state as a result."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"Alternatives"},{"line_number":196,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"378d6ae4_578b3ebe","line":193,"updated":"2025-12-09 18:26:50.000000000","message":"Images are only converted when used through import, which means in many cases the image goes back to `staged`,  not `queued`. To be clear, enabling image conversion effectively disables the ability to upload (via import) encrypted images, right? I think it\u0027s worth saying that (perhaps with a `..note:`) to be explicit.","commit_id":"84dcca662a75920e42c1a1a1ed2124a57ccbcc39"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"1ead82b695a26a3b60511789171301675c04ab35","unresolved":false,"context_lines":[{"line_number":190,"context_line":"encryption to be handled by Glance. This would be more than the scope of this"},{"line_number":191,"context_line":"spec will be. So if image conversion is enabled and an encrypted images that"},{"line_number":192,"context_line":"needs conversion is uploaded the API will return a 400 Error and the image will"},{"line_number":193,"context_line":"be put in the queued state as a result."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"Alternatives"},{"line_number":196,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"c220a76a_b9f3c1b0","line":193,"in_reply_to":"052461bb_168e3cf6","updated":"2026-03-18 13:29:48.000000000","message":"Since I now changed to skipping conversion and preserving the file (like with ISOs) instead of rejecting it, this is no longer relevant.","commit_id":"84dcca662a75920e42c1a1a1ed2124a57ccbcc39"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"f466764e89e3da50eabb6c071b53529417986f79","unresolved":true,"context_lines":[{"line_number":190,"context_line":"encryption to be handled by Glance. This would be more than the scope of this"},{"line_number":191,"context_line":"spec will be. So if image conversion is enabled and an encrypted images that"},{"line_number":192,"context_line":"needs conversion is uploaded the API will return a 400 Error and the image will"},{"line_number":193,"context_line":"be put in the queued state as a result."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"Alternatives"},{"line_number":196,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"8322091f_1b2d162f","line":193,"in_reply_to":"3147bb73_e8e4f040","updated":"2025-12-11 17:27:58.000000000","message":"Thanks, and ... we can make the actual API request fail if we check/reject during the flow creation. Since we have no way (AFAIK) to communicate that \"this will always fail\" back to the user if we do it async, it is probably best to add these checks in the sync part.","commit_id":"84dcca662a75920e42c1a1a1ed2124a57ccbcc39"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"9011e5e78c5bd28c469dbf94477577a7f76592a3","unresolved":true,"context_lines":[{"line_number":190,"context_line":"encryption to be handled by Glance. This would be more than the scope of this"},{"line_number":191,"context_line":"spec will be. So if image conversion is enabled and an encrypted images that"},{"line_number":192,"context_line":"needs conversion is uploaded the API will return a 400 Error and the image will"},{"line_number":193,"context_line":"be put in the queued state as a result."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"Alternatives"},{"line_number":196,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"3147bb73_e8e4f040","line":193,"in_reply_to":"378d6ae4_578b3ebe","updated":"2025-12-10 15:59:00.000000000","message":"I have rewritten this section slightly. While implementing this in the patchset I realized that the relevant plugin flow is async and I see no way to return any API error during the initial import request. It will simply fail in the conversion plugin later on. I updated this section to reflect that.\n\nI added the \"staged\" state as you suggested.","commit_id":"84dcca662a75920e42c1a1a1ed2124a57ccbcc39"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"bcec38d04e870abad304aef5ca0f31d90f58a80c","unresolved":true,"context_lines":[{"line_number":190,"context_line":"encryption to be handled by Glance. This would be more than the scope of this"},{"line_number":191,"context_line":"spec will be. So if image conversion is enabled and an encrypted images that"},{"line_number":192,"context_line":"needs conversion is uploaded the API will return a 400 Error and the image will"},{"line_number":193,"context_line":"be put in the queued state as a result."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"Alternatives"},{"line_number":196,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"b86353ee_9de1f8c3","line":193,"in_reply_to":"8322091f_1b2d162f","updated":"2026-01-30 14:52:26.000000000","message":"\u003e we can make the actual API request fail if we check/reject during the flow creation. Since we have no way (AFAIK) to communicate that \"this will always fail\" back to the user if we do it async, it is probably best to add these checks in the sync part.\n\nThis would require the \"sync part\" [1] to know which import plugins will be used later in the async flow. However, Glance will discover and enable import plugins dynamically depending on its `glance-image-import.conf` settings way later in the aysnc flow dynamically [2] based on config options only the async part is aware of [3].\n\nThis would mean replicating the import plugin discovery and config parsing (currently exclusive to the async flow) in the sync part just to check for this conflict early and I\u0027m not sure if that is justified.\n\n[1] https://github.com/openstack/glance/blob/1247e0fa2f6132babd7124e2d0030348e5f69d0c/glance/api/v2/images.py#L465-L493\n\n[2] https://github.com/openstack/glance/blob/1247e0fa2f6132babd7124e2d0030348e5f69d0c/glance/async_/flows/plugins/__init__.py#L23-L31\n\n[3] https://github.com/openstack/glance/blob/1247e0fa2f6132babd7124e2d0030348e5f69d0c/glance/async_/flows/api_image_import.py#L82","commit_id":"84dcca662a75920e42c1a1a1ed2124a57ccbcc39"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"327bbf321091bdb6363dfc200545d579d4e43b55","unresolved":true,"context_lines":[{"line_number":190,"context_line":"encryption to be handled by Glance. This would be more than the scope of this"},{"line_number":191,"context_line":"spec will be. So if image conversion is enabled and an encrypted images that"},{"line_number":192,"context_line":"needs conversion is uploaded the API will return a 400 Error and the image will"},{"line_number":193,"context_line":"be put in the queued state as a result."},{"line_number":194,"context_line":""},{"line_number":195,"context_line":"Alternatives"},{"line_number":196,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":4,"id":"052461bb_168e3cf6","line":193,"in_reply_to":"b86353ee_9de1f8c3","updated":"2026-02-18 16:01:49.000000000","message":"Fair enough, I was just addressing your statement of:\n\n\u003e I see no way to return any API error during the initial import request\n\nFlow creation is where you get to synchronously raise an exception that will propagate back to the request.","commit_id":"84dcca662a75920e42c1a1a1ed2124a57ccbcc39"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"5a82f8eae9bbe1c47c75d8a3853e43f0bfa0cbcb","unresolved":true,"context_lines":[{"line_number":385,"context_line":"  \u0027os_encrypt_key_id\u0027"},{"line_number":386,"context_line":""},{"line_number":387,"context_line":"* all images that have \u0027cinder_encryption_key_deletion_policy\u0027 set, need to"},{"line_number":388,"context_line":"  convert it to \u0027os_encrypt_key_deletion_policy\u0027"},{"line_number":389,"context_line":""},{"line_number":390,"context_line":""},{"line_number":391,"context_line":"Implementation"}],"source_content_type":"text/x-rst","patch_set":4,"id":"e20687f7_daf6c8a5","line":388,"updated":"2025-12-09 18:26:50.000000000","message":"Are you expecting to provide a migration path for this, or are you suggesting that operators need to do this? Also, surely the old keys will continue to be honored by previous honor-ees even after the upgrade right? The way this is phrased it sounds like a hard break.","commit_id":"84dcca662a75920e42c1a1a1ed2124a57ccbcc39"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"9011e5e78c5bd28c469dbf94477577a7f76592a3","unresolved":true,"context_lines":[{"line_number":385,"context_line":"  \u0027os_encrypt_key_id\u0027"},{"line_number":386,"context_line":""},{"line_number":387,"context_line":"* all images that have \u0027cinder_encryption_key_deletion_policy\u0027 set, need to"},{"line_number":388,"context_line":"  convert it to \u0027os_encrypt_key_deletion_policy\u0027"},{"line_number":389,"context_line":""},{"line_number":390,"context_line":""},{"line_number":391,"context_line":"Implementation"}],"source_content_type":"text/x-rst","patch_set":4,"id":"f7e08ec9_efa756f5","line":388,"in_reply_to":"e20687f7_daf6c8a5","updated":"2025-12-10 15:59:00.000000000","message":"I added a sentence to end of that section stating that this will be automated by database migrations.\n\nThey are already being implemented here: https://review.opendev.org/c/openstack/glance/+/926905","commit_id":"84dcca662a75920e42c1a1a1ed2124a57ccbcc39"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"f466764e89e3da50eabb6c071b53529417986f79","unresolved":false,"context_lines":[{"line_number":385,"context_line":"  \u0027os_encrypt_key_id\u0027"},{"line_number":386,"context_line":""},{"line_number":387,"context_line":"* all images that have \u0027cinder_encryption_key_deletion_policy\u0027 set, need to"},{"line_number":388,"context_line":"  convert it to \u0027os_encrypt_key_deletion_policy\u0027"},{"line_number":389,"context_line":""},{"line_number":390,"context_line":""},{"line_number":391,"context_line":"Implementation"}],"source_content_type":"text/x-rst","patch_set":4,"id":"9f3a3576_3115e8fc","line":388,"in_reply_to":"f7e08ec9_efa756f5","updated":"2025-12-11 17:27:58.000000000","message":"Done","commit_id":"84dcca662a75920e42c1a1a1ed2124a57ccbcc39"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"327bbf321091bdb6363dfc200545d579d4e43b55","unresolved":true,"context_lines":[{"line_number":161,"context_line":"handled in similar ways by both Cinder and Nova."},{"line_number":162,"context_line":""},{"line_number":163,"context_line":"The key management is handled differently than with encrypted volumes or"},{"line_number":164,"context_line":"encrypted ephemeral storage. The reason for this is, that the encryption and"},{"line_number":165,"context_line":"decryption of an image should never happen in Glance but only on client side."},{"line_number":166,"context_line":"Therefore the service which needs to create a key for a newly created"},{"line_number":167,"context_line":"encrypted image may not be the same service which then has to delete the key"},{"line_number":168,"context_line":"(in most cases Glance). To delete a key, which has not been created by the same"}],"source_content_type":"text/x-rst","patch_set":7,"id":"c836f354_a836db77","line":165,"range":{"start_line":164,"start_character":58,"end_line":165,"end_character":76},"updated":"2026-02-18 16:01:49.000000000","message":"This is one of my main gripes here... this seems to effectively close the door to glance ever decrypting the image for the purposes of inspection and safety, which runs counter to a lot of work done recently. Here, you mean \"client side\" to include nova itself (someday) right? I don\u0027t see why nova would be allowed to decrypt the image for the purposes of boot (with inspection before) and not glance. The image would still be encrypted at rest, but I would think we would want to keep the opportunity for deep image inspection.\n\nBelow (L285) you seem to leave the door open to this in the future - can you soften the wording  here?","commit_id":"86aba94b3816c8eefee26a09797ba6c6f941b585"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"abc3882fb612e07897cfa7546566a9ae624fe0a7","unresolved":false,"context_lines":[{"line_number":161,"context_line":"handled in similar ways by both Cinder and Nova."},{"line_number":162,"context_line":""},{"line_number":163,"context_line":"The key management is handled differently than with encrypted volumes or"},{"line_number":164,"context_line":"encrypted ephemeral storage. The reason for this is, that the encryption and"},{"line_number":165,"context_line":"decryption of an image should never happen in Glance but only on client side."},{"line_number":166,"context_line":"Therefore the service which needs to create a key for a newly created"},{"line_number":167,"context_line":"encrypted image may not be the same service which then has to delete the key"},{"line_number":168,"context_line":"(in most cases Glance). To delete a key, which has not been created by the same"}],"source_content_type":"text/x-rst","patch_set":7,"id":"3f893f13_66b4cd4a","line":165,"range":{"start_line":164,"start_character":58,"end_line":165,"end_character":76},"in_reply_to":"c836f354_a836db77","updated":"2026-02-24 13:13:29.000000000","message":"Done","commit_id":"86aba94b3816c8eefee26a09797ba6c6f941b585"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"327bbf321091bdb6363dfc200545d579d4e43b55","unresolved":true,"context_lines":[{"line_number":196,"context_line":"require decryption and encryption to be handled by the Glance import plugin"},{"line_number":197,"context_line":"and appropriate access to Barbican from within the plugin flow architecture,"},{"line_number":198,"context_line":"which exceeds the scope of this spec. So if image conversion is enabled and an"},{"line_number":199,"context_line":"encrypted image is uploaded that would need conversion, the conversion plugin"},{"line_number":200,"context_line":"will reject the image if it detects an encrypted image based on its metadata."},{"line_number":201,"context_line":"The image will be put back into the original \"queued\" or \"staged\" state as a"},{"line_number":202,"context_line":"result."},{"line_number":203,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"6b12f869_a390daed","line":200,"range":{"start_line":199,"start_character":56,"end_line":200,"end_character":21},"updated":"2026-02-18 16:01:49.000000000","message":"We currently allow images like ISOs to be uploaded and bypass the \"convert everything to qcow format\" configuration. I\u0027m not sure if that\u0027s appropriate here or not, but a blanket rejection means that if glance is configured for image conversion, encrypted images will always be rejected after stage and during import. Since that\u0027s not externally discoverable by a user trying (and retrying) to upload an image, it seems like a poor experience that we should be able to make better.","commit_id":"86aba94b3816c8eefee26a09797ba6c6f941b585"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"1ead82b695a26a3b60511789171301675c04ab35","unresolved":false,"context_lines":[{"line_number":196,"context_line":"require decryption and encryption to be handled by the Glance import plugin"},{"line_number":197,"context_line":"and appropriate access to Barbican from within the plugin flow architecture,"},{"line_number":198,"context_line":"which exceeds the scope of this spec. So if image conversion is enabled and an"},{"line_number":199,"context_line":"encrypted image is uploaded that would need conversion, the conversion plugin"},{"line_number":200,"context_line":"will reject the image if it detects an encrypted image based on its metadata."},{"line_number":201,"context_line":"The image will be put back into the original \"queued\" or \"staged\" state as a"},{"line_number":202,"context_line":"result."},{"line_number":203,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"abfe8735_61c643d9","line":200,"range":{"start_line":199,"start_character":56,"end_line":200,"end_character":21},"in_reply_to":"6b12f869_a390daed","updated":"2026-03-18 13:29:48.000000000","message":"I think this is actually a very good idea and also justified in my opinion since we would want to keep the protection offered by the encryption kept intact.\nI adjusted both this spec and the implementation patchset to switch to simply skipping conversion for encrypted images, like with ISOs.","commit_id":"86aba94b3816c8eefee26a09797ba6c6f941b585"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"327bbf321091bdb6363dfc200545d579d4e43b55","unresolved":true,"context_lines":[{"line_number":285,"context_line":"* In case of raw LUKS images with gpt disk format, the Glance defender mechanism"},{"line_number":286,"context_line":"  could be extended to verify the existence of the GPT header within the first"},{"line_number":287,"context_line":"  blocks of the encryption payload by using the encryption key which is"},{"line_number":288,"context_line":"  available to the involved OpenStack services anyway. "},{"line_number":289,"context_line":""},{"line_number":290,"context_line":"* The case of raw LUKS images with raw disk format is a more complicated one."},{"line_number":291,"context_line":"  To avoid vulnerabilities related to interpreting maliciously crafted image"}],"source_content_type":"text/x-rst","patch_set":7,"id":"18f55a31_8a15884d","line":288,"updated":"2026-02-18 16:01:49.000000000","message":"Stray trailing whitespace here.","commit_id":"86aba94b3816c8eefee26a09797ba6c6f941b585"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"abc3882fb612e07897cfa7546566a9ae624fe0a7","unresolved":false,"context_lines":[{"line_number":285,"context_line":"* In case of raw LUKS images with gpt disk format, the Glance defender mechanism"},{"line_number":286,"context_line":"  could be extended to verify the existence of the GPT header within the first"},{"line_number":287,"context_line":"  blocks of the encryption payload by using the encryption key which is"},{"line_number":288,"context_line":"  available to the involved OpenStack services anyway. "},{"line_number":289,"context_line":""},{"line_number":290,"context_line":"* The case of raw LUKS images with raw disk format is a more complicated one."},{"line_number":291,"context_line":"  To avoid vulnerabilities related to interpreting maliciously crafted image"}],"source_content_type":"text/x-rst","patch_set":7,"id":"72d9084b_c92288ea","line":288,"in_reply_to":"18f55a31_8a15884d","updated":"2026-02-24 13:13:29.000000000","message":"Done","commit_id":"86aba94b3816c8eefee26a09797ba6c6f941b585"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"327bbf321091bdb6363dfc200545d579d4e43b55","unresolved":true,"context_lines":[{"line_number":326,"context_line":""},{"line_number":327,"context_line":"2. Secondly, when volumes are handled in Nova, they are not interpreted in the"},{"line_number":328,"context_line":"   same way as images. For LUKS-encrypted volumes there are two ways for them"},{"line_number":329,"context_line":"   to be handled. In case of QEMU/KVM, they can be passed to the hypervisor"},{"line_number":330,"context_line":"   directly leveraging the native LUKS implementation in QEMU. In any other"},{"line_number":331,"context_line":"   case, the encryption is handled by the host kernel using dm-crypt and the"},{"line_number":332,"context_line":"   block device interface exposing the decrypted block data is passed directly"}],"source_content_type":"text/x-rst","patch_set":7,"id":"eb22d3eb_2bce1bec","line":329,"range":{"start_line":329,"start_character":39,"end_line":329,"end_character":75},"updated":"2026-02-18 16:01:49.000000000","message":"FWIW, this is specifically what the qemu team has told us is not okay. Not in terms of LUKS specifically, but basically \"any untrusted disk image should not be given to any qemu component without being safety-checked first\" (paraphrased of course). So while I want to believe that doing this would be safe because qemu should be decrypting the LUKS part and treating the internals as a raw disk, I can\u0027t say that for sure (and can\u0027t say that recent history gives me high confidence).\n\nToday, AFAIK, nova\u0027s encrypted volume support is all based on dm-crypt, right? In that case, we should be able to (and probably should already) inspect the dm-crypt device after setup.","commit_id":"86aba94b3816c8eefee26a09797ba6c6f941b585"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"cda1fa698650d1d1cdb4b63ace4b6a843b392c7a","unresolved":true,"context_lines":[{"line_number":326,"context_line":""},{"line_number":327,"context_line":"2. Secondly, when volumes are handled in Nova, they are not interpreted in the"},{"line_number":328,"context_line":"   same way as images. For LUKS-encrypted volumes there are two ways for them"},{"line_number":329,"context_line":"   to be handled. In case of QEMU/KVM, they can be passed to the hypervisor"},{"line_number":330,"context_line":"   directly leveraging the native LUKS implementation in QEMU. In any other"},{"line_number":331,"context_line":"   case, the encryption is handled by the host kernel using dm-crypt and the"},{"line_number":332,"context_line":"   block device interface exposing the decrypted block data is passed directly"}],"source_content_type":"text/x-rst","patch_set":7,"id":"7431c8f9_e4d347b4","line":329,"range":{"start_line":329,"start_character":39,"end_line":329,"end_character":75},"in_reply_to":"1972789c_eab59733","updated":"2026-02-19 21:04:33.000000000","message":"I wasn\u0027t sure where it was either but I just checked the original patch [1] and it looks like it\u0027s pretty much this:\n\n* https://github.com/openstack/nova/blob/64d6ba34c5eade5b1729d0250d61211833c2457b/nova/virt/libvirt/driver.py#L2254-L2282\n\n* https://github.com/openstack/nova/blob/64d6ba34c5eade5b1729d0250d61211833c2457b/nova/virt/libvirt/volume/volume.py#L120-L131\n\nand the `elif:` is the dm-crypt way.\n\n[1] https://review.opendev.org/c/openstack/nova/+/523958","commit_id":"86aba94b3816c8eefee26a09797ba6c6f941b585"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"4a56843e06a214d9feca51f90888523ee58a44c3","unresolved":true,"context_lines":[{"line_number":326,"context_line":""},{"line_number":327,"context_line":"2. Secondly, when volumes are handled in Nova, they are not interpreted in the"},{"line_number":328,"context_line":"   same way as images. For LUKS-encrypted volumes there are two ways for them"},{"line_number":329,"context_line":"   to be handled. In case of QEMU/KVM, they can be passed to the hypervisor"},{"line_number":330,"context_line":"   directly leveraging the native LUKS implementation in QEMU. In any other"},{"line_number":331,"context_line":"   case, the encryption is handled by the host kernel using dm-crypt and the"},{"line_number":332,"context_line":"   block device interface exposing the decrypted block data is passed directly"}],"source_content_type":"text/x-rst","patch_set":7,"id":"1972789c_eab59733","line":329,"range":{"start_line":329,"start_character":39,"end_line":329,"end_character":75},"in_reply_to":"33414c6a_b9f3ccb7","updated":"2026-02-19 14:55:10.000000000","message":"Okay, I didn\u0027t find it in a quick search of the encryptors setup in the libvirt driver, so I\u0027m not sure where that actually happens, but I\u0027ll go look. I\u0027ll also try to not think about ways that might be like handing it a qcow file :/","commit_id":"86aba94b3816c8eefee26a09797ba6c6f941b585"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"abc3882fb612e07897cfa7546566a9ae624fe0a7","unresolved":true,"context_lines":[{"line_number":326,"context_line":""},{"line_number":327,"context_line":"2. Secondly, when volumes are handled in Nova, they are not interpreted in the"},{"line_number":328,"context_line":"   same way as images. For LUKS-encrypted volumes there are two ways for them"},{"line_number":329,"context_line":"   to be handled. In case of QEMU/KVM, they can be passed to the hypervisor"},{"line_number":330,"context_line":"   directly leveraging the native LUKS implementation in QEMU. In any other"},{"line_number":331,"context_line":"   case, the encryption is handled by the host kernel using dm-crypt and the"},{"line_number":332,"context_line":"   block device interface exposing the decrypted block data is passed directly"}],"source_content_type":"text/x-rst","patch_set":7,"id":"9d550975_10ea8a5f","line":329,"range":{"start_line":329,"start_character":39,"end_line":329,"end_character":75},"in_reply_to":"7431c8f9_e4d347b4","updated":"2026-02-24 13:13:29.000000000","message":"\u003e Today, AFAIK, nova\u0027s encrypted volume support is all based on dm-crypt, right? In that case, we should be able to (and probably should already) inspect the dm-crypt device after setup.\n\nAs Melanie already highlighted, the two mechanisms I described here in the spec are exactly what is used in Nova today if you use encrypted volumes.\n\nWith the image encryption spec we only add new possible sources of volumes (created from the new image format) but the mechanisms for attachment and their usage in Nova stay exactly the same with the tiny exception of the extended passphrase handling in terms of hex conversion to support more key types.","commit_id":"86aba94b3816c8eefee26a09797ba6c6f941b585"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"c346e59c5be72e1ee8464fa0c0d1ab18bd614916","unresolved":false,"context_lines":[{"line_number":326,"context_line":""},{"line_number":327,"context_line":"2. Secondly, when volumes are handled in Nova, they are not interpreted in the"},{"line_number":328,"context_line":"   same way as images. For LUKS-encrypted volumes there are two ways for them"},{"line_number":329,"context_line":"   to be handled. In case of QEMU/KVM, they can be passed to the hypervisor"},{"line_number":330,"context_line":"   directly leveraging the native LUKS implementation in QEMU. In any other"},{"line_number":331,"context_line":"   case, the encryption is handled by the host kernel using dm-crypt and the"},{"line_number":332,"context_line":"   block device interface exposing the decrypted block data is passed directly"}],"source_content_type":"text/x-rst","patch_set":7,"id":"ba59785f_d15f0475","line":329,"range":{"start_line":329,"start_character":39,"end_line":329,"end_character":75},"in_reply_to":"9d550975_10ea8a5f","updated":"2026-02-24 18:08:04.000000000","message":"Yep, I found it shortly after commenting :)","commit_id":"86aba94b3816c8eefee26a09797ba6c6f941b585"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"90434c774bbe77b500213247f1d7671da8fceb54","unresolved":true,"context_lines":[{"line_number":326,"context_line":""},{"line_number":327,"context_line":"2. Secondly, when volumes are handled in Nova, they are not interpreted in the"},{"line_number":328,"context_line":"   same way as images. For LUKS-encrypted volumes there are two ways for them"},{"line_number":329,"context_line":"   to be handled. In case of QEMU/KVM, they can be passed to the hypervisor"},{"line_number":330,"context_line":"   directly leveraging the native LUKS implementation in QEMU. In any other"},{"line_number":331,"context_line":"   case, the encryption is handled by the host kernel using dm-crypt and the"},{"line_number":332,"context_line":"   block device interface exposing the decrypted block data is passed directly"}],"source_content_type":"text/x-rst","patch_set":7,"id":"33414c6a_b9f3ccb7","line":329,"range":{"start_line":329,"start_character":39,"end_line":329,"end_character":75},"in_reply_to":"eb22d3eb_2bce1bec","updated":"2026-02-18 23:23:17.000000000","message":"\u003e Today, AFAIK, nova\u0027s encrypted volume support is all based on dm-crypt, right? In that case, we should be able to (and probably should already) inspect the dm-crypt device after setup.\n\nThere are two ways, IIUC, there\u0027s dm-crypt and then there\u0027s QEMU native LUKS encryption as described here:\n\nhttps://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/libvirt-qemu-native-luks.html","commit_id":"86aba94b3816c8eefee26a09797ba6c6f941b585"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"7f7f91e974297cd3a675f9b1b662fb50842211c1","unresolved":true,"context_lines":[{"line_number":338,"context_line":"As such, encrypted volumes originating from an encrypted image with raw disk"},{"line_number":339,"context_line":"format would not cause issues in Nova in the same way as the encrypted images"},{"line_number":340,"context_line":"themselves would directly."},{"line_number":341,"context_line":""},{"line_number":342,"context_line":""},{"line_number":343,"context_line":"Notifications impact"},{"line_number":344,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"ee39d56c_03070ece","line":341,"updated":"2025-12-11 22:30:48.000000000","message":"On this part I agree that Nova doesn\u0027t interpret the encrypted data in the volumes but I do wonder what, if anything, will be done for defending in this case? Would Cinder volumes be a loophole for potential bad images?\n\nI\u0027m not flagging this as a potential problem for this spec but I am curious what the thoughts were on this. I could have missed something in the discussions up to now because I don\u0027t know _that_ much about Cinder volume encryption stuff, and if so, sorry for that.\n\nContinuing my thought ... I would think for the Cinder case the defending would happen at upload to Glance time, so would it upload and pass disk_format\u003dgpt in the case of a bootable volume? That way Glance can verify it and then after that we assume most bootable volumes have been vetted by Glance? I say \"most\" because it obviously wouldn\u0027t apply to legacy encrypted raw LUKS bootable images.","commit_id":"86aba94b3816c8eefee26a09797ba6c6f941b585"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"f58ae3fa74a728d78611cb8e9c0efd5cbe9a69e1","unresolved":true,"context_lines":[{"line_number":338,"context_line":"As such, encrypted volumes originating from an encrypted image with raw disk"},{"line_number":339,"context_line":"format would not cause issues in Nova in the same way as the encrypted images"},{"line_number":340,"context_line":"themselves would directly."},{"line_number":341,"context_line":""},{"line_number":342,"context_line":""},{"line_number":343,"context_line":"Notifications impact"},{"line_number":344,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"9c99f6cb_877cf441","line":341,"in_reply_to":"0fa9ec5e_d6e69258","updated":"2026-03-19 18:33:41.000000000","message":"\u003e I don\u0027t think I disagree with this, but I guess I\u0027d maybe add:\n\u003e\n\u003e * Nova will never boot luks/raw images (a block we can put in today to make sure it handles this gracefully).\n\u003e * Nova will not boot qcow2-with-luks images today, but may in the future (we can put this block in today for graceful handling)\n\u003e * Nova may in the future boot luks/gpt or qcow2-with-luks\n\nSorry if something has flown over my head but, why would we be wanting to never allow Nova booting luks/raw someday in the future when we have local disk encryption? It would seem weird to allow booting from encrypted raw luks Cinder volumes but not local encrypted raw luks disks ever in the future.","commit_id":"86aba94b3816c8eefee26a09797ba6c6f941b585"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"c193967dcc22d2354757532b588967197929e7ae","unresolved":true,"context_lines":[{"line_number":338,"context_line":"As such, encrypted volumes originating from an encrypted image with raw disk"},{"line_number":339,"context_line":"format would not cause issues in Nova in the same way as the encrypted images"},{"line_number":340,"context_line":"themselves would directly."},{"line_number":341,"context_line":""},{"line_number":342,"context_line":""},{"line_number":343,"context_line":"Notifications impact"},{"line_number":344,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"0fa9ec5e_d6e69258","line":341,"in_reply_to":"4f7725f5_27f8acc3","updated":"2026-03-18 16:58:58.000000000","message":"\u003e Please correct me if I\u0027m wrong but I think that the concerns you describe only apply if you wanted to achieve full interoperability between Cinder and Nova, i.e., booting an encrypted image in Nova (ephemeral storage) which originated from an encrypted volume in Cinder (using Cinder\u0027s upload-to-image API).\n\nThe concerns I describe are centered around wanting this to be consistent and coherent, and not eliminate a future where nova is able to boot from these instances (which is kinda the default reason for images and glance to exit) and a future where glance makes (or verifies) assertions about the content of images.\n\n\u003e Although this is totally in the spirit of the overall image encryption standardization, I think fully addressing this is going out of scope for *this* spec and the initial implementation. Especially when the GPT disk_format and related handling in Glance is not fully established yet.\n\nAgain, I\u0027m just trying to make sure we don\u0027t eliminate the possibility to get there. If we merge this spec and it sort of disqualifies our ability to do the things I hope we get to some day, then that\u0027s a problem.\n\n\u003e My proposal is:\n\u003e \n\u003e * for this spec, draw the line at \"Nova will not accept raw for bootable ephemeral storage\" and \"Cinder uses raw to convert between encrypted volumes and images\", as described in the section this comment thread is located on\n\u003e   * with the result that interoperability from Cinder to Nova being limited for the time being, i.e., the images created by Cinder might not be accepted by Nova\n\u003e * once the GPT disk_format is well established in Glance and Cinder, create a future spec and implementation that introduces the ability to identify GPT in Cinder during upload-to-volume action and set the image attribute accordingly\n\u003e   * this would then enable users to transfer encrypted images originating from Cinder to Nova\n\nI don\u0027t think I disagree with this, but I guess I\u0027d maybe add:\n\n- Nova will never boot luks/raw images (a block we can put in today to make sure it handles this gracefully).\n- Nova will not boot qcow2-with-luks images today, but may in the future (we can put this block in today for graceful handling)\n- Nova may in the future boot luks/gpt or qcow2-with-luks\n\nThe other thing that I think is important is that glance take some stand about what is allowed in a luks/raw. Today, glance will flag an image that contains an unsafe qcow2 (even if it is claimed to be a raw), and ideally should stop allowing qcow2 content when the claimed format is raw. I\u0027d like to _keep_ those strong assertions, even for luks/* (as we have discussed and I think we now agree).","commit_id":"86aba94b3816c8eefee26a09797ba6c6f941b585"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"ce22db25079844fde68894da6c1b261d8aa0f874","unresolved":true,"context_lines":[{"line_number":338,"context_line":"As such, encrypted volumes originating from an encrypted image with raw disk"},{"line_number":339,"context_line":"format would not cause issues in Nova in the same way as the encrypted images"},{"line_number":340,"context_line":"themselves would directly."},{"line_number":341,"context_line":""},{"line_number":342,"context_line":""},{"line_number":343,"context_line":"Notifications impact"},{"line_number":344,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"4f7725f5_27f8acc3","line":341,"in_reply_to":"626f5ea6_40aa94f7","updated":"2026-01-30 14:27:54.000000000","message":"\u003e Just to be clear, when I said \"nova can\u0027t boot from these at all\" I meant the encrypted images (of an encrypted volume) not encrypted volumes themselves. I think the latter probably does work, right?\n\nYes, booting Nova instances from Cinder volumes which are encrypted does work.\n\n\u003e At the point at which cinder is uploading the image to glance, it has access to the unencrypted content, right? It can inspect the actual contents, assert the format (and that the safety checks pass) before it is uploaded to glance, correct? If it\u0027s bootable and it looks like a valid/safe GPT, it can set it in glance thusly, yes? That to me sounds like a good idea.\n\nCinder has several supported storage backends which all behave a bit differently, so I cannot speak for every one of them off the top of my head but given the architecture of the image upload done by Cinder in such case I\u0027d also assume that Cinder *could* look at the contents if it wanted to.\n\nThe (merged) Cinder spec about this image encryption [1] does not propose that behavior yet. I did have a brief discussion in the comments with Brian Rosmaita about this and I had a look at the following two patches:\n\n* https://review.opendev.org/c/openstack/glance/+/933601\n* https://review.opendev.org/c/openstack/cinder/+/934261\n\n... which still seem to be WIP (at the time of writing). As such I\u0027m having a hard time proposing mechanisms in the specs for which the foundations aren\u0027t done yet.\n\n[1] https://review.opendev.org/c/openstack/cinder-specs/+/964777\n\nFrom my point of view, the Cinder side of things will be totally fine with just \"raw\" for now in terms of creating images from encrypted volumes and vice versa.\n\nPlease correct me if I\u0027m wrong but I think that the concerns you describe only apply if you wanted to achieve full interoperability between Cinder and Nova, i.e., booting an encrypted image in Nova (ephemeral storage) which originated from an encrypted volume in Cinder (using Cinder\u0027s upload-to-image API).\n\nAlthough this is totally in the spirit of the overall image encryption standardization, I think fully addressing this is going out of scope for *this* spec and the initial implementation. Especially when the GPT disk_format and related handling in Glance is not fully established yet.\n\nMy proposal is:\n\n* for this spec, draw the line at \"Nova will not accept raw for bootable ephemeral storage\" and \"Cinder uses raw to convert between encrypted volumes and images\", as described in the section this comment thread is located on\n  * with the result that interoperability from Cinder to Nova being limited for the time being, i.e., the images created by Cinder might not be accepted by Nova\n* once the GPT disk_format is well established in Glance and Cinder, create a future spec and implementation that introduces the ability to identify GPT in Cinder during upload-to-volume action and set the image attribute accordingly\n  * this would then enable users to transfer encrypted images originating from Cinder to Nova","commit_id":"86aba94b3816c8eefee26a09797ba6c6f941b585"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"4111f62a2c646c2fdee27897f731dfbaf83ff281","unresolved":true,"context_lines":[{"line_number":338,"context_line":"As such, encrypted volumes originating from an encrypted image with raw disk"},{"line_number":339,"context_line":"format would not cause issues in Nova in the same way as the encrypted images"},{"line_number":340,"context_line":"themselves would directly."},{"line_number":341,"context_line":""},{"line_number":342,"context_line":""},{"line_number":343,"context_line":"Notifications impact"},{"line_number":344,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"9e01b3ce_9750e753","line":341,"in_reply_to":"666a0675_1a9626d1","updated":"2025-12-12 20:52:54.000000000","message":"Derp, I didn\u0027t realize that currently it is not possible to boot from an encrypted Cinder volume. So ... that answers that.\n\n\u003e Something else that has to be done first is figuring out how to get legit cinder snapshots that should be bootable into glance as gpt instead of raw. My preference would be for there to be some way to tell cinder\u0027s snapshot operation that you want it to be bootable, so cinder says \"cool, let me make sure this is some recognizable bootable format\" and then have it set that as such in glance when it does. Currently this is the thing that is blocking Nova being able to stop booting any-binary-data-stream as raw.\n\nI would think this would be doable today with Cinder being that every volume has a `bootable` field. Like when you ask Cinder to snapshot a volume, if `bootable \u003d True` then call Glance with the right stuff.\n\n\u003e So the question is, what new \"loophole\" would be added by the image encryption. The only thing I can think of is that by allowing disk_format\u003draw for encrypted images created from volumes, whose payload may have been malicously crafted during volume attachment, they cannot be inspected in Glance in contrast to disk_format\u003dgpt.\n\nWhen I thought \"loophole\", I had been thinking that today it is possible to boot-from-volume in Nova with an encrypted Cinder volume. And that if we needed to not regress on that, we would be continuing to allow Nova to boot from a raw image without requiring it to be GPT. So I was thinking a bootable Cinder volume would be a way around the future only-allow-booting-GPT Nova behavior.\n\nSince boot-from-volume from encrypted image is not actually supported today, then we will be able to be consistent with the only-GPT boot images rule in Nova without regressing established behavior.\n\n\u003e In case of volumes, that would be a weak protection in my opinion. You could set the volume to non-bootable, upload an image from it with disk_format\u003draw, create a new volume from that and set the volume to bootable (os-set_bootable API).\n\nI completely agree, that\u0027s why I was a bit confused (given my misunderstanding of the current state of bootable encrypted Cinder volumes).\n\nThat makes a lot more sense to me that Nova would treat these the same in that it would check for GPT, as Dan mentioned, before going ahead and booting it. Previously I had not been sure if this spec was somehow implying that encrypted bootable Cinder volumes would be allowed to be disk_format raw instead of GPT and still be booted by Nova. I understand now that it isn\u0027t.","commit_id":"86aba94b3816c8eefee26a09797ba6c6f941b585"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"0be8b6f00ff50465d9b95c0e42c24b01ebbacac4","unresolved":true,"context_lines":[{"line_number":338,"context_line":"As such, encrypted volumes originating from an encrypted image with raw disk"},{"line_number":339,"context_line":"format would not cause issues in Nova in the same way as the encrypted images"},{"line_number":340,"context_line":"themselves would directly."},{"line_number":341,"context_line":""},{"line_number":342,"context_line":""},{"line_number":343,"context_line":"Notifications impact"},{"line_number":344,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"666a0675_1a9626d1","line":341,"in_reply_to":"68cb0f15_ae5f117c","updated":"2025-12-12 18:28:35.000000000","message":"\u003e What are \"bad images\" in this context from your point of view? From the discussions up until now I gathered that the main threat we want to defend against are images which might trigger some unintended and dangerous behavior (e.g. OSSA-2024-001) in any of the tools they are interpreted with, qemu-img for example, when they are attempted to be identified or converted. Do you have any other kinds of \"bad\" in my mind?\n\nNote that `qemu` itself is included in that list, not just things like `qemu-img`.\n\n\u003e From my experience with volumes, the first entity that interprets its (decrypted) payload is the bootloader for the guest VM.\n\nThis is definitely not the case here, and we\u0027re not really trying to protect against the in-VM interpretation of the disk contents being a problem. We\u0027re focused just on the hypervisor and associated tooling that runs on the host itself.\n\n\u003eA user attaches an empty volume to a Nova instance - encrypted or not, does not matter. The user remotely connects to the VM via SSH. As the volume is a generic block device they can write any data to it. They can craft the binary representation of a malicious image within the VM and write it directly to the volume.\n\nThis is one of the attack vectors from the aforementioned CVE. The \"malicious data\" could have just been a qcow2 header that would convince nova/qemu/etc to read files on the host and expose them into the guest. That is no longer possible (unless you\u0027ve found another such scenario in which case I hope you\u0027re not disclosing a zero-day) because we will inspect the supposedly-raw-but-actually-qcow2 data stream and refuse to treat it as the other format.\n\n\u003e But for Nova interoperability it might help to treat uploading bootable volumes always as gpt with additional verification, given that non-gpt bootable volumes do not sound like a valid use case.\nBut that\u0027d require a working mechanism for validating GPT in LUKS as mentioned earlier.\n\nYep, that sort of change to the status quo is what I\u0027m saying we need consideration, discussion, and hopefully action on.","commit_id":"86aba94b3816c8eefee26a09797ba6c6f941b585"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"0ca90dd840cffc0849e0086b8a95235649d5a1af","unresolved":true,"context_lines":[{"line_number":338,"context_line":"As such, encrypted volumes originating from an encrypted image with raw disk"},{"line_number":339,"context_line":"format would not cause issues in Nova in the same way as the encrypted images"},{"line_number":340,"context_line":"themselves would directly."},{"line_number":341,"context_line":""},{"line_number":342,"context_line":""},{"line_number":343,"context_line":"Notifications impact"},{"line_number":344,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"cefa1678_5f5d1a8e","line":341,"in_reply_to":"9c99f6cb_877cf441","updated":"2026-03-19 19:55:00.000000000","message":"The above is in line with my long-term goal of making nova refuse to boot raw images. You can store anything in glance that you want, and there are cases for that now (like ironic with firmware and ramdisk images IIRC). Nova will try to boot these today for no good reason other than that it doesn\u0027t know better.\n\nI have (since the big CVE of 2024) been hoping to make Nova start refusing raw and require GPT, since that\u0027s actually a disk format that UEFI (and pc-bios) can actually boot from and stop with this \"well, anything could be raw, so everything might as well be raw\" situation we have now. During research for the aforementioned CVE, we found StackExchange articles where people were trying to make something work with qcow2/vmdk/whatever images and \"experts\" said \"just tell glance it\u0027s raw regardless of the actual disk format and then it\u0027ll work\".\n\nThe above also implies that even though cinder is currently uploading everything as raw (again, regardless of what it really is), it could/should set the type to something correct if possible (either because cinder inspects it or the user says \"my intent is for this to be bootable\"). That would mean that if you create a snapshot of some random data volume, it\u0027d be raw, but if you\u0027ve actually got a partition table and a partition marked bootable, it\u0027d be GPT and nova would know the difference between the two.\n\nMy hope is that if/when we\u0027re going to add support for container_format\u003dluks to nova, we can make nova also require that it\u0027s GPT inside, Cinder will have set it as such, glance will have confirmed that on upload, etc. During the aftermath (in the first PTG) of the 2024 CVE, I presented this \"only boot GPT not raw\" vision and seemed to get pretty wide agreement that it\u0027d be a good idea, but some of the inertia behind it has fallen away. What I don\u0027t want to do is lose the ability to achieve that.","commit_id":"86aba94b3816c8eefee26a09797ba6c6f941b585"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fe574563a44b43bc38d5cab240f192255e6bc78b","unresolved":true,"context_lines":[{"line_number":338,"context_line":"As such, encrypted volumes originating from an encrypted image with raw disk"},{"line_number":339,"context_line":"format would not cause issues in Nova in the same way as the encrypted images"},{"line_number":340,"context_line":"themselves would directly."},{"line_number":341,"context_line":""},{"line_number":342,"context_line":""},{"line_number":343,"context_line":"Notifications impact"},{"line_number":344,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"626f5ea6_40aa94f7","line":341,"in_reply_to":"9e01b3ce_9750e753","updated":"2026-01-29 14:54:52.000000000","message":"\u003e Derp, I didn\u0027t realize that currently it is not possible to boot from an encrypted Cinder volume. So ... that answers that.\n\nJust to be clear, when I said \"nova can\u0027t boot from these at all\" I meant the encrypted images (of an encrypted volume) not encrypted volumes themselves. I think the latter probably does work, right?\n\nIt has been over a month since this discussion so I\u0027ve lost some mental context here. My understanding was that we were waiting for some sort of resolution of:\n\n\u003e But for Nova interoperability it might help to treat uploading bootable volumes always as gpt with additional verification, given that non-gpt bootable volumes do not sound like a valid use case.\nBut that\u0027d require a working mechanism for validating GPT in LUKS as mentioned earlier.\n\nAt the point at which cinder is uploading the image to glance, it has access to the unencrypted content, right? It _can_ inspect the actual contents, assert the format (and that the safety checks pass) before it is uploaded to glance, correct? If it\u0027s bootable _and_ it looks like a valid/safe GPT, it can set it in glance thusly, yes? That to me sounds like a good idea.\n\nNow that said, I think my concerns remain as:\n\n1. I think that if glance is going to allow an encrypted image to be uploaded that is anything other than raw, it needs to be able to safety-check it (ideally it would be able to safety check the raw too, but...). If the key isn\u0027t available, then perhaps it should not allow you to upload a qcow2+luks or a luks+gpt. I also think that means nova shouldn\u0027t agree to let you boot either of those, unless it is going to safety check it with the key first, before it lets qemu-anything touch the image.\n\n2. I want to retain the future option to have nova refuse to boot raw images, only GPT ones. If we have to make a special exception for raw \"because meh, we can\u0027t see inside\" then that weakens the entire house of course.","commit_id":"86aba94b3816c8eefee26a09797ba6c6f941b585"},{"author":{"_account_id":4690,"name":"melanie witt","display_name":"melwitt","email":"melwittt@gmail.com","username":"melwitt"},"change_message_id":"9a0441cc8c1f2269b9a714eecc85e638951c409b","unresolved":true,"context_lines":[{"line_number":338,"context_line":"As such, encrypted volumes originating from an encrypted image with raw disk"},{"line_number":339,"context_line":"format would not cause issues in Nova in the same way as the encrypted images"},{"line_number":340,"context_line":"themselves would directly."},{"line_number":341,"context_line":""},{"line_number":342,"context_line":""},{"line_number":343,"context_line":"Notifications impact"},{"line_number":344,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5bfdf9c9_1aa05ad4","line":341,"in_reply_to":"cefa1678_5f5d1a8e","updated":"2026-03-19 20:37:28.000000000","message":"Ugh I\u0027m sorry, I was conflating \"raw\" with GPT _again_ 😣 and I see I had actually quoted luks/gpt too. _That_ is the thing I thought should be allowed and we are leaving that open as a future possibility.\n\nI remember the PTG discussion and I have been one in support of requiring GPT in the future and rejecting \"raw\".\n\nSorry everyone for the noise, please ignore my previous comment.","commit_id":"86aba94b3816c8eefee26a09797ba6c6f941b585"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"ec6f75f999c5101a01435ae6e2a56305d4c97f79","unresolved":true,"context_lines":[{"line_number":338,"context_line":"As such, encrypted volumes originating from an encrypted image with raw disk"},{"line_number":339,"context_line":"format would not cause issues in Nova in the same way as the encrypted images"},{"line_number":340,"context_line":"themselves would directly."},{"line_number":341,"context_line":""},{"line_number":342,"context_line":""},{"line_number":343,"context_line":"Notifications impact"},{"line_number":344,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"68cb0f15_ae5f117c","line":341,"in_reply_to":"ee39d56c_03070ece","updated":"2025-12-12 17:23:01.000000000","message":"Thanks for sharing your thoughts on this, Melanie!\n\n\u003e ... I do wonder what, if anything, will be done for defending in this case? Would Cinder volumes be a loophole for potential bad images?\n\nWhat are \"bad images\" in this context from your point of view? From the discussions up until now I gathered that the main threat we want to defend against are images which might trigger some unintended and dangerous behavior (e.g. OSSA-2024-001) in any of the tools they are interpreted with, qemu-img for example, when they are attempted to be identified or converted. Do you have any other kinds of \"bad\" in my mind?\n\nFrom my experience with volumes, the first entity that interprets its (decrypted) payload is the bootloader for the guest VM.\nIf we are talking about loopholes here, let\u0027s imagine the following scenario:\nA user attaches an empty volume to a Nova instance - encrypted or not, does not matter. The user remotely connects to the VM via SSH. As the volume is a generic block device they can write any data to it. They can craft the binary representation of a malicious image within the VM and write it directly to the volume. Afterwards, they detach the volume and set it to bootable (\"os-set_bootable\" Cinder API action). If this volume is cloned to another volume or attached to a different Nova instance, we would end up with a similar case as if a \"bad\" image was transferred to a volume. All of this is already possible today.\n\nSo the question is, what new \"loophole\" would be added by the image encryption. The only thing I can think of is that by allowing disk_format\u003draw for encrypted images created from volumes, whose payload may have been malicously crafted during volume attachment, they cannot be inspected in Glance in contrast to disk_format\u003dgpt.\n\nDisallowing disk_format\u003draw completely would however introduce regressions in Cinder, see the latter half of my comment on the Cinder spec here: https://review.opendev.org/c/openstack/cinder-specs/+/964777/comments/23fd7bfb_8ee80e3c\n\n\u003e I would think for the Cinder case the defending would happen at upload to Glance time, so would it upload and pass disk_format\u003dgpt in the case of a bootable volume?\n\nIf the Glance defender mechanism can find a way to look at the first few blocks of the decrypted LUKS payload to verify that, then yes we could consider restricting bootable to gpt. This would require partial/streamable decryption of LUKS in Glance, which we don\u0027t know for sure yet if possible.\n\nIn case of volumes, that would be a weak protection in my opinion. You could set the volume to non-bootable, upload an image from it with disk_format\u003draw, create a new volume from that and set the volume to bootable (os-set_bootable API).\n\nThe only place where \"disk_format\u003dgpt in the case of a bootable volume\" could help is if such image is later attempted to be reused for bootable ephemeral storage in Nova when Nova would otherwise block non-gpt formats completely or at least reject them for creating bootable instances as discussed in the PTG.\n\nCurrently, the specs and implementation do not make that distinction for Cinder (it always uses \"raw\") but I\u0027ll think about this a bit more. For Cinder alone it didn\u0027t make much of a difference (for image to volume) so far due to the freely mutable bootable property of volumes. But for Nova interoperability it might help to treat uploading bootable volumes always as gpt with additional verification, given that non-gpt bootable volumes do not sound like a valid use case.\nBut that\u0027d require a working mechanism for validating GPT in LUKS as mentioned earlier.","commit_id":"86aba94b3816c8eefee26a09797ba6c6f941b585"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"c4807c4029f2b9a557bcd7b58bd3303df6a61cd0","unresolved":true,"context_lines":[{"line_number":338,"context_line":"As such, encrypted volumes originating from an encrypted image with raw disk"},{"line_number":339,"context_line":"format would not cause issues in Nova in the same way as the encrypted images"},{"line_number":340,"context_line":"themselves would directly."},{"line_number":341,"context_line":""},{"line_number":342,"context_line":""},{"line_number":343,"context_line":"Notifications impact"},{"line_number":344,"context_line":"--------------------"}],"source_content_type":"text/x-rst","patch_set":7,"id":"89d8f6d0_8d4db970","line":341,"in_reply_to":"ee39d56c_03070ece","updated":"2025-12-12 16:55:07.000000000","message":"Well, the first line of defense will be that Nova doesn\u0027t currently allow/support booting from these at all, so.. secure by lack of support I guess :)\n\nHowever, once we try to do that, yes we\u0027ll need to do more work on the Nova side and glance won\u0027t really be able to provide any defense (assuming it can\u0027t stream-decrypt the image to verify).\n\nIf we are able to move forward with Nova getting to the point where it refuses to boot a `raw` and only supports booting from `gpt`, `qcow2`, etc then Nova can do that checking once it downloads and decrypts the image. Basically, `raw` means \"some random stuff that the user wrote into a cinder volume.. fine for data but nova won\u0027t try to boot it, or do anything besides attach for you to access`. For flat encrypted images that we expect to boot from, we\u0027d have to decrypt and probe (safely, with format inspector) to see if it is, indeed, a GPT inside before we proceed.\n\nI don\u0027t love that, because I want glance to be able to defend here and avoid having to build all that logic into everything that consumes glance images (at least glance itself, nova, cinder, ironic) but we\u0027re probably not going to be able to do that (or at least *rely* on being able to do that).\n\nSomething else that has to be done first is figuring out how to get legit cinder snapshots that should be bootable into glance as `gpt` instead of `raw`. My preference would be for there to be some way to tell cinder\u0027s snapshot operation that you want it to be bootable, so cinder says \"cool, let me make sure this is some recognizable bootable format\" and then have it set that as such in glance when it does. Currently this is the thing that is blocking Nova being able to stop booting any-binary-data-stream as `raw`.","commit_id":"86aba94b3816c8eefee26a09797ba6c6f941b585"},{"author":{"_account_id":8122,"name":"Cyril Roelandt","email":"cyril@redhat.com","username":"cyril.roelandt.enovance"},"change_message_id":"87e395306077a8b8f486b805492ba599236434be","unresolved":true,"context_lines":[{"line_number":272,"context_line":""},{"line_number":273,"context_line":"* Glance may lose the ability to provide a first-layer defense against image"},{"line_number":274,"context_line":"  policy violations (such as rejecting invalid/disallowed formats), because"},{"line_number":275,"context_line":"  inspection of encrypted data may not possible at all times."},{"line_number":276,"context_line":""},{"line_number":277,"context_line":"There has been extensive discussion around the problem of verifying encrypted"},{"line_number":278,"context_line":"data payload and how to handle the corresponding disk formats at the Project"}],"source_content_type":"text/x-rst","patch_set":8,"id":"45374440_247590a4","line":275,"range":{"start_line":275,"start_character":39,"end_line":275,"end_character":47},"updated":"2026-02-25 20:47:00.000000000","message":"Could we remove this line? Dan thinks it\u0027s possible to implement this, and I think this should be part of the initial work so that Glance can keep its role as the first line of defense.","commit_id":"37bc213e3396c7045a9fdc5c7036b27793eaa1ae"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"9be57fdf7bbb50f76c6c4c1970784045c39ccff8","unresolved":false,"context_lines":[{"line_number":272,"context_line":""},{"line_number":273,"context_line":"* Glance may lose the ability to provide a first-layer defense against image"},{"line_number":274,"context_line":"  policy violations (such as rejecting invalid/disallowed formats), because"},{"line_number":275,"context_line":"  inspection of encrypted data may not possible at all times."},{"line_number":276,"context_line":""},{"line_number":277,"context_line":"There has been extensive discussion around the problem of verifying encrypted"},{"line_number":278,"context_line":"data payload and how to handle the corresponding disk formats at the Project"}],"source_content_type":"text/x-rst","patch_set":8,"id":"f603403d_ce99b231","line":275,"range":{"start_line":275,"start_character":39,"end_line":275,"end_character":47},"in_reply_to":"122f0714_5c908c4d","updated":"2026-03-12 16:37:19.000000000","message":"Awesome thanks.","commit_id":"37bc213e3396c7045a9fdc5c7036b27793eaa1ae"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"46202d1bf2333d0e96fe407db8da3adab8eb7ade","unresolved":true,"context_lines":[{"line_number":272,"context_line":""},{"line_number":273,"context_line":"* Glance may lose the ability to provide a first-layer defense against image"},{"line_number":274,"context_line":"  policy violations (such as rejecting invalid/disallowed formats), because"},{"line_number":275,"context_line":"  inspection of encrypted data may not possible at all times."},{"line_number":276,"context_line":""},{"line_number":277,"context_line":"There has been extensive discussion around the problem of verifying encrypted"},{"line_number":278,"context_line":"data payload and how to handle the corresponding disk formats at the Project"}],"source_content_type":"text/x-rst","patch_set":8,"id":"8f58d379_aadb6f61","line":275,"range":{"start_line":275,"start_character":39,"end_line":275,"end_character":47},"in_reply_to":"45374440_247590a4","updated":"2026-02-25 21:40:16.000000000","message":"Yep, I\u0027ll be pushing up POC code soon (probably tomorrow) that demonstrates this inspection for a few different scenarios. Based on this, I\u0027d like to actually flip the polarity on this bullet point to say \"Glance *must* retain the ability to provide a first-layer defense...\"","commit_id":"37bc213e3396c7045a9fdc5c7036b27793eaa1ae"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"23230291c97616affd654ce610222e31322698e7","unresolved":true,"context_lines":[{"line_number":272,"context_line":""},{"line_number":273,"context_line":"* Glance may lose the ability to provide a first-layer defense against image"},{"line_number":274,"context_line":"  policy violations (such as rejecting invalid/disallowed formats), because"},{"line_number":275,"context_line":"  inspection of encrypted data may not possible at all times."},{"line_number":276,"context_line":""},{"line_number":277,"context_line":"There has been extensive discussion around the problem of verifying encrypted"},{"line_number":278,"context_line":"data payload and how to handle the corresponding disk formats at the Project"}],"source_content_type":"text/x-rst","patch_set":8,"id":"95dd8f5d_125583f3","line":275,"range":{"start_line":275,"start_character":39,"end_line":275,"end_character":47},"in_reply_to":"8f58d379_aadb6f61","updated":"2026-02-27 22:57:34.000000000","message":"Just to link this to the above POC, here\u0027s the meat of it: https://review.opendev.org/c/openstack/oslo.utils/+/978097","commit_id":"37bc213e3396c7045a9fdc5c7036b27793eaa1ae"},{"author":{"_account_id":27665,"name":"Markus Hentsch","email":"markus.hentsch@cloudandheat.com","username":"mhen"},"change_message_id":"c7646de8f2144075211fd70a72ef788af1d1d53e","unresolved":false,"context_lines":[{"line_number":272,"context_line":""},{"line_number":273,"context_line":"* Glance may lose the ability to provide a first-layer defense against image"},{"line_number":274,"context_line":"  policy violations (such as rejecting invalid/disallowed formats), because"},{"line_number":275,"context_line":"  inspection of encrypted data may not possible at all times."},{"line_number":276,"context_line":""},{"line_number":277,"context_line":"There has been extensive discussion around the problem of verifying encrypted"},{"line_number":278,"context_line":"data payload and how to handle the corresponding disk formats at the Project"}],"source_content_type":"text/x-rst","patch_set":8,"id":"122f0714_5c908c4d","line":275,"range":{"start_line":275,"start_character":39,"end_line":275,"end_character":47},"in_reply_to":"95dd8f5d_125583f3","updated":"2026-03-12 15:27:17.000000000","message":"Dan, I gave your oslo.utils code a try and using a small prototype and some crafted files was able to correctly detect LUKS+gpt and LUKS+qcow2 while reading only about 2MB.\n\nAs a result, I have now rephrased that statement like you suggested since I can now safely assume that the inspection will be possible.","commit_id":"37bc213e3396c7045a9fdc5c7036b27793eaa1ae"}]}