| opendevreview | Rajat Dhasmana proposed openstack/glance_store master: Cinder: Correct exception logging during attach https://review.opendev.org/c/openstack/glance_store/+/838335 | 05:02 |
|---|---|---|
| opendevreview | Merged openstack/glance-tempest-plugin master: Update python testing classifier https://review.opendev.org/c/openstack/glance-tempest-plugin/+/823261 | 06:41 |
| *** pdeore_ is now known as pdeore | 13:03 | |
| opendevreview | Pierre-Samuel Le Stang proposed openstack/glance-specs master: [APIImpact] Add a new glance-download import method https://review.opendev.org/c/openstack/glance-specs/+/836132 | 13:20 |
| pdeore | abhishekk, rosmaita, jokke_, dansmith, croelandt, mrjoshi glance weekly meeting in 10 minutes at #openstack-meeting | 13:51 |
| abhishekk | ty! | 13:51 |
| whoami-rajat | abhishekk, croelandt hey, can we have a conclusion on this? it has been sitting there for quite a long time :) https://review.opendev.org/c/openstack/glance_store/+/833767 | 13:58 |
| abhishekk | whoami-rajat, will have a look after weekly meeting | 13:58 |
| whoami-rajat | abhishekk, ack | 13:58 |
| dansmith | whoami-rajat: I piled on there | 14:03 |
| whoami-rajat | dansmith, thanks! | 14:04 |
| dansmith | jokke_: so, what I was trying to say was: if I show up at some service and say "here is some sensitive data and here is my md5 hash so you know you got it", | 14:59 |
| dansmith | the remote service should not say "well, I've been told not to use md5, but I'll take your data anyway and return you a 200 without error, warning, etc" | 15:00 |
| dansmith | now, IIRC, if I just do a glance upload, glance calculates the hash on its end, and the user could verify that glance got the whole thing after the fact by comparing its computed hash to the one the user knows to be right | 15:01 |
| dansmith | that's the expected workflow today for upload yeah? | 15:01 |
| jokke_ | yep, same with web-download ... we don't scrape say ubuntu download page if they happen to have a hash we can replicate, we get the data, calculate the hash when _uploading_ to the first store (as in after possible conversion etc. plugins that might change that data) and the user will have the hash available in the image metadata | 15:03 |
| jokke_ | oh, sorry, just upload no import, yes we calculate it from the stream we push to the store | 15:04 |
| dansmith | which happens for both upload and import right? I wasn't making the distinction because I assumed the same | 15:05 |
| jokke_ | well yeah, the difference is that in upload we just stream the user provided data through, import there might be changes before it goes to the store | 15:05 |
| dansmith | right, so we could (or do we?) calculate the hash while we stage it in the import case? | 15:06 |
| jokke_ | so with import the user might not get same checksum back even if using same algo | 15:06 |
| dansmith | ah, so calculate the hash after during staging->store because we could have converted it in staging? | 15:06 |
| jokke_ | We don't calculate it in staging as it's WORM value ... once it's set it cannot be changed | 15:06 |
| jokke_ | correct | 15:06 |
| dansmith | (sorry in the tc meeting too, just a sec) | 15:07 |
| opendevreview | Abhishek Kekane proposed openstack/glance master: [oslo.policy] Blacklist 3.12.0 https://review.opendev.org/c/openstack/glance/+/839780 | 15:11 |
| abhishekk | jokke_, ^^ | 15:11 |
| jokke_ | also the unfortunate design model of multi-hash is that it's not really a multihash as the algo and the hash are separate properties, we cannot even go and provide multiple hashes with different algorithms. so there is no way with Images API v2 for us to update the hash say with newer secure algo | 15:11 |
| jokke_ | abhishekk: thanks | 15:11 |
| abhishekk | jokke_, probably I will fix the instant caching spec tomorrow morning | 15:13 |
| abhishekk | sorry for the delay | 15:13 |
| jokke_ | abhishekk: no problem | 15:15 |
| jokke_ | dansmith: And while that was designed, the decision was made that we treat hashes we can't replicate as if they were not existing. So say there is issue with algo that is in use, you update configs for new safe algo and then you path your system to not having that old algo anymore, we do not fail the operations as we couldn't calculate the hash, if we can calculate it and we get different value, | 15:18 |
| jokke_ | then we fail | 15:18 |
| jokke_ | so your old images keeps working | 15:19 |
| dansmith | jokke_: sorry, still in a section I have to chat, but .. can you point me to where in the code we ignore a missing algo for another operation? | 15:19 |
| jokke_ | dansmith: no prob, read through when you have time ... was just writing my thoughts so I don't forget it | 15:20 |
| jokke_ | https://github.com/openstack/python-glanceclient/blob/master/glanceclient/v2/images.py#L220-L237 that explains the validation chain | 15:25 |
| jokke_ | importance there on point 4 | 15:25 |
| dansmith | jokke_: ack, so summarizing the scheme right now is basically "the server computes the hash as it got it, the client is responsible for verifying" either after upload or during download yeah? | 15:32 |
| dansmith | I'm not sure what we do at #1 if allow_md5_fallback=False, but that case and #2 itself says "if md5 is not available to the client, the download fails" which would be the fail-safe to not download if we can't validate the image right? | 15:33 |
| dansmith | point here is that glance with glance-download is behaving both as client (of glance) and server | 15:34 |
| dansmith | replicating the glanceclient behavior may be reasonable, although I think sticking to the stricter behavior is better because the point of the feature is to avoid the user having to download the image | 15:34 |
| dansmith | so if I go glance-download an image from one cloud to another, the destination cloud should ideally be able to validate (to me) that the image it got is the same as the one in the source cloud, because it may then modify that image (i.e. convert) before it calculates its hash during staging->store | 15:35 |
| abhishekk | ERROR: Requirement for package oslo.policy excludes a version not excluded in the global list. | 15:35 |
| abhishekk | Local settings : {'!=3.12.0'} | 15:35 |
| abhishekk | Global settings: {'!=3.0.0', '!=3.6.1'} | 15:35 |
| abhishekk | Unexpected : {'!=3.12.0'} | 15:35 |
| dansmith | otherwise, in the latter case, the hash will not match between the source and dest clouds but I have no way of knowing that it at least made it to the dest cloud intact before it was mechanically converted | 15:36 |
| dansmith | so to me, it seems like the best plan would be to calculate one of the available hashes while we're downloading, and if we really have none in common, either refuse (as glanceclient seems to do if md5 is not available) or at least warn the user in some way | 15:36 |
| jokke_ | dansmith: so if we tell it to verify md5 in absence of multihash it fails if the md5 is not there. Unless specifically told so we skip the points 2&3 | 15:37 |
| dansmith | I haven't read the code just the comment, but you're saying if allow_md5_fallback=False and no hashes are supported, we jump to #4? | 15:38 |
| jokke_ | yup | 15:38 |
| jokke_ | meaning we do not have hash as we don't have any compatible algos to verify and we continue unverified | 15:39 |
| dansmith | okay, but do you understand why that's not as big of a deal if I'm downloading the image and can manually calculate another hash to validate, but I can't if it's cloud-to-cloud? | 15:39 |
| jokke_ | dansmith: no this is the same behaviour when nova and cinder are consuming the image | 15:40 |
| jokke_ | it's not just CLI behaviour | 15:40 |
| jokke_ | if compute does not have the algo available, it will consume the image | 15:41 |
| jokke_ | which is why I'm saying ignoring algos we don't have is the consistent thing to do. The user can see if they have matching checksums after image creation and investigate if not. | 15:43 |
| dansmith | okay, if we can't even agree on the premise then I guess there's really not much conversation left to have | 15:43 |
| dansmith | but fwiw, I don't actually see that nova even checks the checksum or the os_hash values, so I don't think your assertion that it silently ignores those if it doesn't have the aglo available is right | 15:44 |
| jokke_ | but we shouldn't waste the bandwidth and make the user download&upload manually just because the origin had hashing algorithm used which doesn't exist in destination | 15:44 |
| jokke_ | dansmith: nova doesn't because the the client does it in the fly | 15:45 |
| jokke_ | so if the checksum fails during the download the client will throw exception | 15:45 |
| jokke_ | instead of providing nova the imge | 15:45 |
| dansmith | ack, fair enough | 15:46 |
| jokke_ | That said the only case where I've actually seen this happening was recent thing where store was corrupting the image data. I cannot recall when I would have seen actual transfer error last time. Nowadays networking, tcp & http are just pretty darn recilient | 15:48 |
| dansmith | tcp and http only checksum 64k blocks at a time, using CRC. And malicious actors can easily modify data in flight. | 15:48 |
| jokke_ | so I'd say the most likely case for getting checksum mismatch would be when expired algo has been used | 15:49 |
| jokke_ | which seems to be pretty rare in https environments | 15:50 |
| jokke_ | not saying impossible, just haven't came across mitm attacks for long time | 15:51 |
| * abhishekk signing out for the day | 15:52 | |
| jokke_ | for sure easier in "trusted" environments where the malicious actor more likely has access to trusted certs too | 15:52 |
| jokke_ | night abhishekk | 15:52 |
| abhishekk | good night o/~ | 15:52 |
| abhishekk | https://review.opendev.org/c/openstack/releases/+/839775 | 15:53 |
| abhishekk | This will unblock us | 15:53 |
| opendevreview | Elod Illes proposed openstack/glance master: [CI] Install dependencies for docs target https://review.opendev.org/c/openstack/glance/+/839786 | 16:03 |
| opendevreview | Durga Malleswari Varanasi proposed openstack/glance master: Internal server error if shared member tries to stage data to image https://review.opendev.org/c/openstack/glance/+/834701 | 16:35 |
| opendevreview | Elod Illes proposed openstack/glance stable/yoga: [CI] Install dependencies for docs target https://review.opendev.org/c/openstack/glance/+/839814 | 18:29 |
| opendevreview | Elod Illes proposed openstack/glance stable/xena: [CI] Install dependencies for docs target https://review.opendev.org/c/openstack/glance/+/839815 | 18:30 |
| opendevreview | Elod Illes proposed openstack/glance stable/wallaby: [CI] Install dependencies for docs target https://review.opendev.org/c/openstack/glance/+/839816 | 18:31 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!