Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

traceroute command in the build/run image #139

Open
doddisam opened this issue Jun 13, 2024 · 4 comments
Open

traceroute command in the build/run image #139

doddisam opened this issue Jun 13, 2024 · 4 comments

Comments

@doddisam
Copy link

Hello Team,

Can we please include the traceroute command in the run image ?

It will be easy to troubleshoot the network and FW related issue.

-Sameer

@doddisam
Copy link
Author

can somebody help on this ?

@sophiewigmore
Copy link
Member

@doddisam hey there Sameer, can you discuss a bit more about your use case for needing this at run-time? Would it be helpful for all types of apps, or specific ones?

We usually take a conservative approach to adding new packages to the stack images in order to limit vulnerability surface area, so I'd really like to understand fully what the benefit will be here.

I see some associated CVEs with this package, like https://ubuntu.com/security/CVE-2023-46316, in which a fix is only available in the ESM (expanded security maintenance) version of the package which we cannot ship in the project.

@doddisam
Copy link
Author

@sophiewigmore Thanks for the reply.

I will be helpful if we have in all types of apps which uses this stack. In our environment many DEV teams deploy apps and they connect to external database, messaging and redis etc. Quite often there will be some network related issue or FW issue and it will be helpful to have traceroute for troubleshooting. App teams can work with network or FW team directly and provide traceroute outputs to destination server.

@sophiewigmore
Copy link
Member

@doddisam I'm not sure about this. I can see why including traceroute might be useful for debugging, but I'm also hesitant to add a package with a considerable CVE surface area to the stack when it would only be there for troubleshooting, and not for producing production-ready builds. @robdimsdale would you be able to weigh in?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants