[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [atomic-devel] docs-first RFE for stripping containers
- From: Colin Walters <walters verbum org>
- To: atomic-devel projectatomic io
- Subject: Re: [atomic-devel] docs-first RFE for stripping containers
- Date: Tue, 17 Feb 2015 15:37:34 -0500
On Thu, Feb 5, 2015, at 02:57 PM, Adam Miller wrote:
>
> since we'd lose the option of 'rpm -V' and verifying rpm signing (the
I know that a lot of people like "rpm -V" and want it to work, but don't
confuse it with a system for *trust*. I could easily hand you a Docker
image where rpm -V comes back clean and I have malicious code
stored in /etc/bash_completion.d for example.
(Personally I've been coming around to the PoV that per-package RPM GPG
signatures aren't really useful, and we should move to GPG signed repo metadata
and apply that transitively to the packages, but that's a more complex topic)
> Im kind of struggling with a way to determine what would 1) need to
> be removed/stripped and 2) what would be safe to remove/strip in a
> pragmatic way.
I'd say ideal is that the application is an RPM that expresses
its dependencies. Then you can remove everything that isn't a dependency.
That just leaves the non-dependency axes of locales, documentation, etc.
Now it is possible to take things further than this - one could imagine
doing e.g. Link Time Optimization across all the native code for a container,
e.g. if your app doesn't happen to use strfry() from glibc, it gets dropped
out. But there's huge amounts of complexity here, particularly for
dynamic languages which are impossible to analyze statically
for dependencies.
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]