| opendevreview | Max proposed openstack/glance master: feat: return size in get_image_data_iter https://review.opendev.org/c/openstack/glance/+/976627 | 13:16 |
|---|---|---|
| *** jbernard_ is now known as jbernard | 13:19 | |
| croelandt | I'm thinking of releasing glance_store 5.4.0 at 032d273acc57f9010123f184cb112979f37391a5 | 15:41 |
| croelandt | If you want anything else in the release, stop me now :) | 15:42 |
| croelandt | abhishekk: ^ | 15:42 |
| croelandt | rosmaita: thanks for reviewing my S3 patch btw! | 15:42 |
| abhishekk | croelandt: nothing from my end | 15:43 |
| rosmaita | croelandt: i looked at that dave hill patch , but wasn't quite sure what i thought about it | 15:43 |
| croelandt | rosmaita: it does not seem too critical to me: you need to "under configure" Cinder to hit it | 15:46 |
| croelandt | Takashi has issues with the patch, and I'd like Rajat to take a look at it | 15:46 |
| croelandt | so I guess we'll release it as part of H-M2 maybe? | 15:46 |
| croelandt | we (I?) have been pushing a ton of patches in the past few days already :D | 15:47 |
| opendevreview | Max proposed openstack/glance master: feat: return size in get_image_data_iter https://review.opendev.org/c/openstack/glance/+/976627 | 15:56 |
| croelandt | https://review.opendev.org/c/openstack/releases/+/977245 and here we go! | 16:58 |
| dansmith | croelandt: do you still need me to review a thing? | 18:31 |
| dansmith | croelandt: also, how do you feel about the image encryption stuff effectively turning glance back into the pre-defender state? if images are unencrypted we can know that they have been safety checked, but if they're encrypted, we... no longer can. | 18:32 |
| dansmith | if nova blocks booting or using of those images, then at least the damage is "not my problem" for the time being, but it really kinda sucks to backslide on that, IMHO :/ | 18:32 |
| croelandt | I don't need any reviews anymore | 18:35 |
| croelandt | dansmith: see, that's what annoys me about the whole feature, we keep uncovering new issues like this | 18:35 |
| croelandt | I would expect that if an admin encrypts their images, they take full responsability for them | 18:36 |
| dansmith | croelandt: this is the same issue I've been harping on since the beginning (of when I started reviewing) but I agree | 18:36 |
| croelandt | so if they are malware, well, that's the admin's problem | 18:36 |
| dansmith | croelandt: this is about user images not admin issues | 18:36 |
| dansmith | s/issues/images/ | 18:36 |
| croelandt | yeah but I think admins have to trust certain users with uploading images and booting from them? | 18:37 |
| dansmith | there's no way for them to do that though | 18:37 |
| dansmith | where in this proposal does it say that admins can restrict this (effective) hiding of the content from glance only to trusted users? | 18:37 |
| croelandt | yeah users can either uplaod or not upload depending on the policy | 18:37 |
| croelandt | so you either trust all users or none of them | 18:38 |
| dansmith | where does an admin disable this functionality though? policy protections on one of the required properties? | 18:38 |
| croelandt | can't an admin do that through RBAC? | 18:40 |
| dansmith | do what? | 18:40 |
| croelandt | say "users cannot upload images, only admins can" | 18:41 |
| dansmith | users have to be able to upload images for basic functionality of the cloud to work, | 18:41 |
| dansmith | but the question here is not "can users upload images" it's "can users upload _encrypted_ images which bypass all the safety checks" | 18:41 |
| dansmith | property protections are the only way I can imagine that being doable, and it's insecure by default | 18:42 |
| croelandt | oh yeah if users cannot uplaod images, you lose a ton of functionality :D | 18:42 |
| croelandt | you end up saying "hey, you got these 3 images, have fun" | 18:42 |
| croelandt | so ok, would you want to improve fine-grained control over who can upload unencrypted images? | 18:43 |
| dansmith | I mean, that's one thing we could do, and restrict it by default so the admin knows what they're losing by enabling it | 18:43 |
| dansmith | I guess the other I'd like is to explore the "can we safety check these images" thing more, but the current proposal is sort "not my problem"-ing that | 18:44 |
| dansmith | which sounds like others are okay with but... it sucks | 18:44 |
| dansmith | I assume you saw we just published another image safety CVE yesterday... | 18:45 |
| croelandt | I don't think I've seen this | 19:02 |
| croelandt | A different one from the "3 bugs CVE" we've been discussing? | 19:03 |
| croelandt | So would you like to check the content of the encrypted images when they're uploaded? | 19:09 |
| dansmith | nova bug | 19:14 |
| dansmith | ideally we would inspect them in exactly the same way we do today, of course | 19:15 |
| dansmith | I understand that it's non-trivial, but it'd surely be nice to make that the goal and not just a punt | 19:15 |
| croelandt | oh I missed the nova bug, do you have a link? | 19:20 |
| dansmith | it's the same old thing: https://bugs.launchpad.net/nova/+bug/2137507 | 19:21 |
| croelandt | oh ok not a new one | 19:22 |
| dansmith | it's new, but the same pattern | 19:23 |
| dansmith | the reason that wasn't worse than it was is _because_ glance would refuse to upload a snapshot | 19:23 |
| dansmith | sorry, accept a snapshot upload I mean | 19:24 |
| dansmith | you see in the discussion how we prevented a worse problem because glance refuses to accept the modified image | 19:24 |
| dansmith | if glance protection wasn't enabled (or possible due to encryption) then I could have exfiltrated host data there | 19:25 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!