You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 3, 2021. It is now read-only.
In running a security scan of the AZTK container using Artifactory X-Ray, I find 338 CVEs. This is largely due to basically using a complete, desktop linux system.
For example, there are dozens of issues related to X.org libraries like this one:
Integer overflow in X.org libXfixes before 5.0.3 on 32-bit platforms might allow remote X servers to gain privileges via a length value of INT_MAX, which triggers the client to stop reading data and get out of sync.
I'm fairly certain spark doesn't use even a part of the X Window System for anything.
Could you start with a smaller image with less security surface area and build this on that?
Or, barring that, would you accept a patch that fixes this issue and allows spark to run in a lightweight container?
The text was updated successfully, but these errors were encountered:
Yes, patches are encouraged, especially for security vulnerabilities. The AZTK containers are quite old at this point and need to be updated. Likely that will remove many of the CVEs, but likely not all.
Switching to a non-Ubuntu16.04 base image is an option, but it could break users. Adding an additional set of images that run in a lighterweight/more security sensitive distro would be a nice feature add in my opinion. What base image in particular are you interested in?
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
In running a security scan of the AZTK container using Artifactory X-Ray, I find 338 CVEs. This is largely due to basically using a complete, desktop linux system.
For example, there are dozens of issues related to X.org libraries like this one:
I'm fairly certain spark doesn't use even a part of the X Window System for anything.
Could you start with a smaller image with less security surface area and build this on that?
Or, barring that, would you accept a patch that fixes this issue and allows spark to run in a lightweight container?
The text was updated successfully, but these errors were encountered: