Update docker images #25418
Update docker images #25418
Conversation
|
Why was this removed without contacting us? We're in the middle of integrating code upstream between windows/linux builds and this gives us 0 coverage |
|
Sorry for the late notice. I have a tight deadline. I need to address all such security issues by the end of this month. |
|
When I made this change, I put comments in your PR to mention this issue.
|
Right, and you don't think we don't? We had to find this as we're in the middle of testing between windows linux and your official mainline breaks, yet all your CI is fine/ your other engineers are expediting changes with the assumption CI is all green. I mean you reached out for pulling the ROCm EP on a long weekend after the fact we said something, which that was sudden, but now you're just not supporting our CI and not contacting us? What about the Nvidia side? You contact them when you decide any sort of changes like this? What's frustrating here is I'm getting pushed by your end, while you're ripping out functionality with minimal heads up |
|
I am sorry for the insufficient communication. But, there are some rules I must obey. I need to avoid private technical communications unless I am pretty sure the people on the other end are not subject to Export Administration Regulations (EAR), which is a very complicated topic. Therefore, I use GitHub to communicate with our partners for all Github related issues. I was hoping you would see it and make response to it. I really appreciate your long term support. |
|
I'm subject to the same restrictions you are. I'm in Canada. This isn't a wildly technical discussion, nor something to warrant export restrictions. I don't understand this comment, this is a MIT licensed public repo. What export restrictions are there? Contacting us to improve or fix something doesn't fall under export restrictions. No new technology or trade secrets/knowledge is being exchanged. In fact we would be helping you improve your project. On the other hand, the testing for AMD EPs and Nvidia EPs are very different for us. I am not able to get any AMD GPU into our build system, while I have hundreds of Nvidia GPUs. This issue has last for a long while. Yes, the CI situation is very frustrating. Right, so this sounds like a preference then, I just have to say really? You've supported ROCm EP/MIGraphX EP builds prior and now you're just ripping out infrastructure overnight...well a week ago. Whats the change? What I can't understand is why is this the second time after the fact that we're finding out after you rip out items in regards to AMD related contributions. I haven't had any issues getting code in for the last two/three years and suddenly, I'm hitting roadblocks, and your CI/Support has dried up. What gives? |
|
Linux is open source, but Linux also has the same issue. See: https://www.phoronix.com/news/Linux-Compliance-Requirements |
|
Let me ask again Why is this the second time after the fact that we're finding out after you rip out items in regards to AMD related contributions. I haven't had any issues getting code in for the last two/three years and suddenly, I'm hitting roadblocks, and your CI/Support has dried up. What gives? |
I am sorry for that. It's important for me to to clarify that: we hold the same security and compliance standard for ONNX Runtime git repos. . Every thing that runs in our CI build pipelines(which run in Microsoft's internal infrastrure) must meet the same standard. There is no exception. I am really sorry for the interruption to your work. Please understand that Microsoft prioritize security above all else. I would like to work with you to resolve the issues we found and getting the pipelines back. |
If that's the case, how is ripping out all testing/oversight on contributor code contribute to security then and not telling anyone? Wouldn't that literally be the definition of creating a security hole? You ripped out all the infrastructure for testing a code path entirely but still accepting changes? I would like to work with you to resolve the issues we found and getting the pipelines back. Gladly, tell us what you require then. You have my full attention. |
|
Here are the issues I mentioned: |
|
Right, so again , you guys are using images from Dockerhub for nvidia right? These ones? https://hub.docker.com/r/nvidia/cuda/tags we have the latest ROCm 6.4.2 released as well. Did you even look on the ROCm side? |
|
Yes, that would work. But I think we need to get the source code and built it ourselves so that we can apply system updates timely. |
Can you not apply security patches on top? It doesn't look like you're doing the same for Nvidia and pulling in their items from Which is just a container on docker hub? We don't have conda in that almalinux rocm image I linked either. |
|
The "ARG BASEIMAGE=nvidia/cuda:12.5.1-cudnn-devel-ubi8" line provides a default value for who wants to build this image locally. It's not what we use in our pipelines. |
|
I've opened an issue here to track this : #25532 |
1. Update the docker images to install system updates(per vulnerability
management requirements)
2. Disable DNNL pipelines since
a. There was no active development.
b. The code is incompatible with CMake 4.x.
3. Disable migraphx pipeline due to license issues(conda is not free
unless you only use conda-forge packages).
4. Change all UBI8 based images to use AlmaLinux8.
I will make the base images public. They are under internal review.
1. Update the docker images to install system updates(per vulnerability
management requirements)
2. Disable DNNL pipelines since
a. There was no active development.
b. The code is incompatible with CMake 4.x.
3. Disable migraphx pipeline due to license issues(conda is not free
unless you only use conda-forge packages).
4. Change all UBI8 based images to use AlmaLinux8.
I will make the base images public. They are under internal review.
1. Update the docker images to install system updates(per vulnerability
management requirements)
2. Disable DNNL pipelines since
a. There was no active development.
b. The code is incompatible with CMake 4.x.
3. Disable migraphx pipeline due to license issues(conda is not free
unless you only use conda-forge packages).
4. Change all UBI8 based images to use AlmaLinux8.
I will make the base images public. They are under internal review.
a. There was no active development.
b. The code is incompatible with CMake 4.x.
I will make the base images public. They are under internal review.