| *** abhishekk is now known as akekane|home | 05:26 | |
| *** akekane|home is now known as abhishekk | 05:26 | |
| *** bhagyashris_ is now known as bhagyashris|ruck | 08:37 | |
| *** whoami-rajat is now known as Guest89 | 09:05 | |
| *** whoami-rajat__ is now known as whoami-rajat | 09:05 | |
| opendevreview | jinyuanliu proposed openstack/python-glanceclient master: Clean up extra spaces https://review.opendev.org/c/openstack/python-glanceclient/+/799807 | 12:46 |
|---|---|---|
| *** bhagyashris is now known as bhagyashris|ruck | 13:59 | |
| croelandt | abhishekk: Hey! Wanna talk about upstream bugs? I went through the open "security" bugs and I think you had a lot of metadefs-related bugs | 14:00 |
| abhishekk | croelandt, yep | 14:01 |
| abhishekk | croelandt, For now we had ossn-0088 for metadef related issues | 14:02 |
| croelandt | was it https://bugs.launchpad.net/glance/+bug/1916926 ? | 14:03 |
| croelandt | oh no | 14:03 |
| croelandt | https://bugs.launchpad.net/glance/+bug/1545702 | 14:03 |
| croelandt | should we have some kind of quota for this as well? | 14:03 |
| abhishekk | There could be one more | 14:03 |
| abhishekk | Nope at the moment no | 14:04 |
| abhishekk | But I am really not sure how many people are using it | 14:04 |
| abhishekk | since most of the APIs don't have full client support | 14:04 |
| croelandt | yeah | 14:05 |
| croelandt | but it's still enough to create security holes | 14:05 |
| croelandt | how could we fix #1545702? | 14:06 |
| abhishekk | Looking | 14:07 |
| abhishekk | For that we need to add quotas for metadefs | 14:08 |
| abhishekk | This we can take as enhancement in upcoming cycle | 14:08 |
| croelandt | yeah using the quota feature we just merged | 14:08 |
| croelandt | we should probably list all Glance resources that might suffer from the same problem | 14:09 |
| croelandt | there is at least namespaces and tags | 14:09 |
| abhishekk | Right | 14:09 |
| abhishekk | But as you know we are approaching milestone 2 which is also spec freeze for us | 14:10 |
| abhishekk | so after m2 we are not accepting new enhancements | 14:10 |
| croelandt | yeah we might just want to know that this should be done in the next cycle | 14:11 |
| abhishekk | 100 % | 14:11 |
| croelandt | and that we'll have to 1) list abusable resources 2) add keystone quotas for them | 14:11 |
| abhishekk | I have plan for this :D | 14:11 |
| croelandt | oh ok | 14:11 |
| croelandt | Can't wait to hear about that :) | 14:11 |
| abhishekk | Surely will discuss once its confirmed | 14:11 |
| croelandt | ok ok | 14:12 |
| croelandt | so wanna go over your other metadefs bugs? | 14:12 |
| abhishekk | Yeah, I have listed them at the end of the etherpad | 14:13 |
| abhishekk | as well as reported 2 which are at line #90 and #91 | 14:14 |
| croelandt | oh yeah I see | 14:14 |
| croelandt | so docs & client | 14:14 |
| abhishekk | yes | 14:15 |
| abhishekk | I think last one needs to be fixed on priority as we are migrating metadef to use RBAC | 14:15 |
| croelandt | ok | 14:16 |
| croelandt | on the "OSNN" front, https://bugs.launchpad.net/glance/+bug/1837200 had a patch about 2 years ago that was forgotten | 14:17 |
| croelandt | it might be nice to discuss whether that is a feature we are interested in, and if so, to revive the patch | 14:17 |
| abhishekk | looking | 14:17 |
| abhishekk | I think we already have some fix about it in purge command of glance-manage utility | 14:18 |
| croelandt | oh | 14:19 |
| abhishekk | Let me check | 14:20 |
| abhishekk | I remember, I guess we have added separate command to purge images table | 14:21 |
| abhishekk | and traditional purge command will only purge data from other tables than images | 14:21 |
| abhishekk | https://review.opendev.org/c/openstack/glance/+/579507 | 14:24 |
| *** bhagyashris_ is now known as bhagyashris|ruck | 14:24 | |
| croelandt | oh I see | 14:24 |
| abhishekk | https://specs.openstack.org/openstack/glance-specs/specs/rocky/implemented/glance/mitigate-ossn-0075.html | 14:24 |
| croelandt | good, we can close the bug then :) | 14:24 |
| abhishekk | I think we are good to close that issue | 14:25 |
| croelandt | yep | 14:25 |
| abhishekk | Cool, could you please add above details to bug and mark it fixed released? | 14:25 |
| abhishekk | I will move it out from the etherpad after that | 14:25 |
| abhishekk | I found another issue between :P | 14:26 |
| croelandt | yeah I will | 14:27 |
| croelandt | hahah | 14:27 |
| abhishekk | cool, | 14:28 |
| abhishekk | also dansmith has replied to your comment on policy refactoring spec | 14:28 |
| croelandt | oh about compatibility | 14:29 |
| abhishekk | yeah | 14:30 |
| croelandt | oh yeah I see | 14:31 |
| croelandt | yeah I was confused a bit by what you meant exactly | 14:31 |
| croelandt | I'll take another pass at the spec | 14:32 |
| abhishekk | cool, I have also added this as topic to tomorrows discussion | 14:32 |
| croelandt | ok | 14:34 |
| croelandt | Are we good? | 14:34 |
| abhishekk | Yep | 14:34 |
| abhishekk | Thank you :D | 14:34 |
| croelandt | Thank *you* | 14:35 |
| abhishekk | haha | 14:35 |
| opendevreview | Nobuto Murata proposed openstack/glance_store master: s3: Optimize WRITE_CHUNKSIZE to minimize an overhead https://review.opendev.org/c/openstack/glance_store/+/799870 | 16:56 |
| croelandt | rosmaita: hey! you filed https://bugs.launchpad.net/glance/+bug/1875439 about a year ago. I think it is solved by 8027d907109b6b3c96623f9793aff752cec8ed12 , could you check that it does in fact solve your problem? | 17:47 |
| rosmaita | croelandt: i guess that plus a34419aecdf3db58426fe8fb7e1849ebdff6a5f1 in glance_store | 18:35 |
| rosmaita | croelandt: should probably put a note in the bug that instead of no longer populating the 'checksum' property, it will continue to be populated, but we recommend that image consumers use the secure multihash for validation purposes | 18:37 |
| croelandt | it does work in the ultra-secure environments whose name is currently escaping me, right? | 18:38 |
| rosmaita | i guess ... when i wrote the bug, it wasn't clear to me that upstream python was going to accept the 'usedforsecurity' flag idea, and might remove md5 from hashlib altogether | 18:39 |
| rosmaita | but it looks like "fips mode" is a real thing | 18:40 |
| croelandt | oh maybe I could ask vstinner tomorrow | 18:40 |
| croelandt | do we want to release an OSSN as per https://bugs.launchpad.net/glance/+bug/1875630 ? | 18:40 |
| rosmaita | not sure | 18:41 |
| rosmaita | also, i wonder about some of the usedforsecurity=False in a34419aecdf3db58426fe8fb7e1849ebdff6a5f1 | 18:42 |
| rosmaita | like https://review.opendev.org/c/openstack/glance_store/+/756157/3/glance_store/_drivers/cinder.py#832 | 18:42 |
| croelandt | hm | 18:44 |
| croelandt | what worries you? | 18:44 |
| rosmaita | well, the idea is that you can use the resulting os_hash_value to verify an image download, which seems to me like a security context | 18:48 |
| croelandt | Isn't there a security team that could help review this and make sure we did the right thing? | 18:56 |
| rosmaita | yeah, should probably ask the VMT | 18:57 |
| rosmaita | fungi: ^^ | 18:58 |
| fungi | gimme a moment to regain context from however long ago that was ;) | 18:59 |
| rosmaita | probably 2 years ago | 19:00 |
| croelandt | the patches are not that old though :D | 19:02 |
| fungi | yeah, so the idea is to suggest to operators of deployments <=victoria that upgrading to >=ussuri will allow them to stop relying on questionably weak md5 checksums... does that still seem relevant to folks at this point? | 19:02 |
| rosmaita | yes ... i think the question we have at this point is https://review.opendev.org/c/openstack/glance_store/+/756157/3/glance_store/_drivers/cinder.py#832 | 19:04 |
| fungi | oh, i see from the ussuri release note that it was available back as far as rocky, we simply also provided md5 checksums for backwards compatibility | 19:05 |
| rosmaita | yeah, the idea was we would remove the md5 computation code and no longer populate that field | 19:05 |
| rosmaita | so that we didn't have to worry if md5 was not available on a glance node | 19:06 |
| rosmaita | but in the meantime, it looks like FIPS will allow md5 usage for non-security-contexts, so we don't have to worry about the algorithm not being available | 19:07 |
| fungi | one minor nit, would it make sense to treat usedforsecurity as a kwarg when calling get_hasher(), so it's more clear what's being overridden there? | 19:10 |
| rosmaita | i agree, it's a bit obscure otherwise | 19:11 |
| fungi | i had to go looking at the function definition to realize that's what was being passed | 19:11 |
| fungi | which, for something like "we're treating this as a non-sensitive context" is fairly opaque | 19:12 |
| fungi | i feel like devs are at risk of just cargo-culting that without realizing what it says | 19:12 |
| rosmaita | that is an excellent point, we should do a follow-up patch regardless of whether we need to change the value or not | 19:14 |
| fungi | i also see i had ussuri and victoria backwards in my earlier comment here... need to relearn my alphabet apparently | 19:18 |
| fungi | so anyway, the new multihash field was made available as early as rocky, deprecation of the legacy (md5) checksum field happened shortly before ussuri. that field remains deprecated but is still being made available via usedforsecurity=false in wallaby | 19:23 |
| rosmaita | right | 19:23 |
| rosmaita | the original plan was to stop populating it, but it looks like we can continue | 19:24 |
| rosmaita | so the question now is just whether the usedforsecurity=False claims for the non-md5 algos throughout glance_store are correct | 19:24 |
| fungi | i'm struggling to remember what exactly we wanted to convey to operators once glance no longer required an md5 implementation | 19:24 |
| rosmaita | yeah, i don't remember either | 19:25 |
| rosmaita | i think telling them about the "secure multihash" basically said it all, already | 19:25 |
| fungi | but yeah, auditing the usedforsecurity values is a good idea. probably important to consider both what those are meant to be used for and also what people might incorrectly assume they're safe to be relied on for | 19:26 |
| rosmaita | and i guess, we need to stress that although the 'checksum' is md5, glance (and image consumers) don't need to rely on md5 for verification | 19:27 |
| fungi | and if the latter includes things which are security sensitive, maybe we need to figure out a way to make it more apparent what they should be using instead | 19:27 |
| fungi | do clients still present that field in more recent releases? | 19:27 |
| rosmaita | i think so | 19:28 |
| rosmaita | mainly because legacy images won't have the alternative multihash | 19:28 |
| fungi | so probably 1. clients should either stop showing the old checksum field or make it clear they're not reliable, 2. the api docs need to clearly mark the checksum field in the responses as deprecated if it doesn't already | 19:29 |
| fungi | my concern at this point is end users thinking the checksum field is reliable, since they're unlikely to have ever seen the glance ussuri release notes | 19:31 |
| rosmaita | glanceclient uses the multihash to validate a download, you have to explicitly request --allow-md5-fallback for it to use the checksum | 19:31 |
| rosmaita | https://docs.openstack.org/releasenotes/python-glanceclient/victoria.html#relnotes-3-2-0-stable-victoria | 19:31 |
| fungi | that helps | 19:31 |
| fungi | do commands like show provide the checksum by default or is it also hidden behind a non-default option now? | 19:32 |
| rosmaita | this is what you see from the client: http://paste.openstack.org/show/807241/ | 19:33 |
| rosmaita | but to answer your question, the checksum is displayed along with all the other image properties | 19:34 |
| croelandt | I think we might discuss this further at the end of tomorrow's meeting if we got time :) | 19:58 |
| croelandt | fungi: do you think it would make sense to release an OSSN once we are sure we did the right thing? | 19:58 |
| fungi | croelandt: if we can decide what we want to convey in it, sure. an ossn is essentially an appendix of the security guide, containing recommendations for configuration or operational practices | 20:00 |
| fungi | it's also fairly operator-focused | 20:00 |
| fungi | is there some particular action operators/deployers need to take in relation to this change? | 20:02 |
| croelandt | ok so here it would be "maybe do not use --fallback-to-md5" for instance | 20:02 |
| croelandt | ? | 20:02 |
| fungi | well, if the context help for that option already indicates it's not preferred | 20:04 |
| fungi | which it seems to | 20:04 |
| fungi | then that doesn't seem like as much of a risk | 20:04 |
| fungi | users of glanceclient and osc are more likely to see the context help than an ossn published in various places they probably never pay attention to | 20:05 |
| fungi | the bigger risk might be more general reliance on the checksum field reported in the image properties, because it doesn't sound like that is hidden by default nor clearly identified as unreliable and deprecated | 20:07 |
| fungi | so it could constitute an attractive nuisance for users who don't understand why there are both a checksum and a multihash property | 20:08 |
| croelandt | so the OSSN could be clarifying that? | 20:09 |
| fungi | maybe, but even then it seems like the better route would be to improve the client(s) to make it apparent that value is unreliable | 20:09 |
| fungi | security notes, as i said, mostly target operators and deployers of clouds, not the end users, who are harder for us to reach with general broadcast communications | 20:10 |
| fungi | when it comes to users, it's better to just pad all the sharp edges so they don't cut themselves | 20:10 |
| croelandt | indeed | 20:13 |
| fungi | i'm also on the fence when it comes to making too much noise about eliminating md5 checksums. the primary risk with md5 is still chosen plaintext attacks, which basically rely on the attacker producing two items which happen to result in the same checksum, and substituting one for the other at some opportune moment. the ways you could leverage that to nefarious ends with server images | 20:16 |
| fungi | uploaded to a cloud are few if any because it implies a situation where you trust the image but not the producer of the image | 20:16 |
| fungi | once someone figures out how to reliably execute a second preimage attack against md5, eliminating it will become more urgent | 20:18 |
| fungi | the main news here is "now you can use glance on fips mode systems" which is more of a regulatory compliance thing than actual operational security, truth be told | 20:20 |
| croelandt | okay, so maybe we should forget about the OSSN | 20:28 |
| fungi | the actual "risk" with these sorts of uses of md5 currently is that you risk people who don't know better thinking your software is insecure because they've been repeatedly been told "md5 bad" | 20:28 |
| fungi | so better to avoid it where possible (it's good future proofing anyway, for the eventual point where these uses of md5 actually becomes a genuine security risk), and hiding all the rest as best you can so you don't repeatedly have to answer questions from confused users who have been told md5 is unilaterally problematic | 20:30 |
| * croelandt might be one of those users | 20:30 | |
| fungi | a good analogy is harvesting wild mushrooms. if you're educated about them you can identify which ones are tasty and which will kill you dead. but most people just avoid eating any mushrooms they find in the woods | 20:32 |
| opendevreview | Pranali Deore proposed openstack/glance master: Implement project personas for metadef namespaces https://review.opendev.org/c/openstack/glance/+/798700 | 20:48 |
| opendevreview | Pranali Deore proposed openstack/glance master: Implement project personas for metadef resource-type and object https://review.opendev.org/c/openstack/glance/+/799671 | 20:48 |
| opendevreview | Pranali Deore proposed openstack/glance master: Implement project personas for metadef property and tags APIs https://review.opendev.org/c/openstack/glance/+/799912 | 20:48 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!