Issue #113 Use an image containing a KEYS file to avoid downloading keys

[olamy]

fix #113

[tianon]

See https://github.com/docker-library/official-images#repeatability, especially:

No official images can be derived from, or depend on, non-official images ...

Additionally https://github.com/docker-library/faq#openpgp--gnupg-keys-and-verification, especially:

Another common solution to this problem is to simply check a KEYS file into Git that contains the public keys content (...). The primary downsides of this are that it's a pain during the Official Images review process (since every added/removed KEYS entry is many lines of what essentially is just noise to the image diff) but more importantly that it becomes much more difficult for users to then verify that the key being checked is one that upstream officially publishes (...).

(emphasis mine)

[olamy]

@tianon jettyproject:keys image is an official image published by a Jetty committer but I'm not sure what "official image" means in the docker world.....
storing a KEYS file in this repo is problematic to get it available during the build of all images (docker build can’t really see files from other directories) except duplicating in multiple repositories which is a real nightmare to maintain.....
Using multistage builds is definitely recommended here https://docs.docker.com/develop/develop-images/multistage-build/

[md5]

@olamy what is your comment about multistage builds referring to?

If multistage builds are an option, I could see having a stage that has enough to build the GPG keyring and uses the usual gpg commands as we currently have in this image. The main jetty image could then copy in this keyring and use apt-key or whatever the recommended means is to import that keyring after a COPY --from=keys.

@tianon apologies if this is something I could easily look up, but are multistage Dockerfiles in use for any Docker Official Images?

[md5]

The benefit of having the key fetching in a separate stage is that we may be able to make that stage simple enough that it can be cached more robustly by Docker build servers, but maybe that's a negligible impact.

[md5]

Here's what I have in mind:

FROM openjdk:11-jre AS keys # change this to a smaller, simpler base, maybe one with a minimal GPG setup

# GPG Keys are personal keys of Jetty committers (see https://github.com/eclipse/jetty.project/blob/0607c0e66e44b9c12a62b85551da3a0edce0281e/KEYS.txt)
ENV JETTY_GPG_KEYS \
	# Jan Bartel      <janb@mortbay.com>
	AED5EE6C45D0FE8D5D1B164F27DED4BF6216DB8F \
	# Jesse McConnell <jesse.mcconnell@gmail.com>
	2A684B57436A81FA8706B53C61C3351A438A3B7D \
	# Joakim Erdfelt  <joakim.erdfelt@gmail.com>
	5989BAF76217B843D66BE55B2D0E1FB8FE4B68B4 \
	# Joakim Erdfelt  <joakim@apache.org>
	B59B67FD7904984367F931800818D9D68FB67BAC \
	# Joakim Erdfelt  <joakim@erdfelt.com>
	BFBB21C246D7776836287A48A04E0C74ABB35FEA \
	# Simone Bordet   <simone.bordet@gmail.com>
	8B096546B1A8F02656B15D3B1677D141BCF3584D \
	# Greg Wilkins    <gregw@webtide.com>
	FBA2B18D238AB852DF95745C76157BDF03D0DCD6 \
	# Greg Wilkins    <gregw@webtide.com>
	5C9579B3DB2E506429319AAEF33B071B29559E1E

RUN mkdir /jetty-keys

RUN set -xe \
	&& export GNUPGHOME=/jetty-keys \
        # Make this as robust as it needs to be, possibly using a helper script
	&& for key in $JETTY_GPG_KEYS; do \
		gpg --keyserver ha.pool.sks-keyservers.net --recv-keys "$key"; done

FROM openjdk:11-jre

# Some stuff

COPY --from=keys /jetty-keys/trustdb.gpg /jetty-keys/trustdb.gpg

RUN set -xe \
	&& curl -SL "$JETTY_TGZ_URL" -o jetty.tar.gz \
	&& curl -SL "$JETTY_TGZ_URL.asc" -o jetty.tar.gz.asc \
	&& GNUPGHOME=/jetty-keys gpg --batch --verify jetty.tar.gz.asc jetty.tar.gz \
	&& tar -xvf jetty.tar.gz --strip-components=1 \
	&& sed -i '/jetty-logging/d' etc/jetty.conf \
	&& rm jetty.tar.gz* \
	&& rm -rf /tmp/hsperfdata_root

# Some other stuff

[md5]

If there were a simple "add gpg key" helper script and some reasonable approach to trustdb.gpg (or the equivalent for APT), then I could see having a RUN line per key in the keys image stage

[olamy]

this will not prevent fetching an external server... the main goal here is avoid such download because those datas never change.
I don't really understand the problem with using this image with a KEYS file. This is a common way to do it. And by the way this image and KEYS are publish by a Jetty committer (myself) and available on github (https://github.com/jetty-project/jetty-keys)

[md5]

I think in light of the section @tianon quoted, that goal should be reconsidered. At this point, the OpenPGP pool seems like a better option to me

[tianon]

The keys themselves may not change, but hopefully the metadata does (key expiration date, for example).

[olamy]

so I guess we abandon this and simply change the server and keep duplicating keys in different files?

[gregw]

@olamy I think so. The multistage Dockerfile as suggest above looks like it will give many of the benefits of this PR as it will build a base image containing the keys that will only be rebuilt if that section of the Dockerfile changes