search

GoogleContainerTools / distroless

🥑 Language focused docker images, minus the operating system.
Apache License 2.0
19.18k stars 1.17k forks source link

Add mime.types to static image #816

Open Xjs opened 3 years ago

Xjs commented 3 years ago

Could the file /etc/mime.types be added to the static image? This had been requested in #256 but was apparently overlooked. The file /etc/mime.types is provided by the Debian package media-types, cf. https://packages.debian.org/sid/media-types/filelist

Thanks :)

loosebazooka commented 3 years ago

Is this only required for go? As described in https://github.com/GoogleContainerTools/distroless/issues/256#issuecomment-451569173

Xjs commented 3 years ago

My personal use-case is Go, if that's what you're asking. Generally, I don't know which applications consume this file, but I believe it is assumed present in many Linux distributions.

loosebazooka commented 3 years ago

I might need some help justifying this, so the point of this file is to point mime-types to applications (is it?) or types to extensions? In the case of distroless does it have any use? The only application on the container is yours?

Does golang fail critically if this file is missing?

Xjs commented 3 years ago

The point of the file is to associate file extensions and MIME types. Go uses the file in package mime, in my example I was using https://pkg.go.dev/mime#TypeByExtension to determine the MIME type to declare in an e-mail header for an attachment.

Go applications that use package mime are reduced to the built-in table (currently https://cs.opensource.google/go/go/+/refs/tags/go1.17.1:src/mime/type.go;l=60) for this kind of lookups. This is no hard failure. Applications can register specific associations themselves as well (this is what I'm currently doing as a workaround).

The only application on the container is mine, yes. It's a statically linked Go binary. I'm using the image through https://github.com/bazelbuild/rules_docker#go_image, which makes it comparatively hard to include the file myself (it would require me to maintain a version of the file, or pin a specific e. g. Debian package source in my WORKSPACE as well. Since distroless already maintains Debian package source versions it would be simpler overall to include the file here.

FTR: I can live with a rejection of this issue, I just thought it had been overlooked in #256 and wanted to reopen the discussion.