[
https://issues.apache.org/jira/browse/GEODE-8353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-8353:
--------------------------------
Summary: Replace Product SHA with Release Manager's Public Key ID in
Dockerfile for Official Docker Image (was: Replace Product SHA with Release
Manager's Public Key in Dockerfile for Official Docker Image)
> Replace Product SHA with Release Manager's Public Key ID in Dockerfile for
> Official Docker Image
> ------------------------------------------------------------------------------------------------
>
> Key: GEODE-8353
> URL: https://issues.apache.org/jira/browse/GEODE-8353
> Project: Geode
> Issue Type: Bug
> Reporter: Bill Burcham
> Priority: Major
>
> Currently the {{Dockerfile}} for the official Geode Docker image contains a
> product SHA. As a result, the source code of the {{Dockerfile}} used to
> produce the official Docker image, for publication on Docker Hub, is not part
> of the source code covered by the Geode product SHA. Instead, the
> {{Dockerfile}} comes from the {{master}} branch.
> This presents a number of problems:
> 1. folks looking at the Geode source code do not see the correct
> {{Dockerfile}} source unless they know to look for it on the {{master}} branch
> 2. the release process has extra steps to maintain the {{Dockerfile}} on the
> master branch
> 3. inescapably, revisions to the the {{Dockerfile}} on the master branch
> follow a linear progression whereas the sources of that file are following a
> tree-structured one
> When this story is complete, Geode's official Docker image will not come from
> the {{Dockerfile}} on the master branch. Instead, the {{Dockerfile}} on
> {{develop}} and support branches, will contain the public key of the (a)
> release manager instead of a product SHA. Verification will proceed like this
> inside the {{Dockerfile}}:
> 1. download release manager's public key-cert from key server {{gpg
> --keyserver some.apache.key.server --recv-keys
> release-managers-key-id-from-dockerfile}}
> 2. download product checksums
> 3. download a signature for the checksums—signed by the release manager's
> private key
> 4. download product distribution
> 5. validate checksums (2) with signature (3) {{gpg --batch --verify
> signature-file downloaded-checkums-file}}
> 6. verify that locally-computed product checksums match downloaded ones
> If any of those steps fail, then the {{Dockerfile}} build fails.
> This is similar to the approach used in this {{Dockerfile}}:
> https://hub.docker.com/_/consul
> Release manager instructions will be updated to reflect these structural and
> procedural changes.
> There is one final validation step that cannot be done inside the Dockerfile,
> and that is validating that the release manager's public key is trustworthy.
> This is something that users of the official Geode Docker image would do:
> * validate authenticity of release manager's public key per:
> https://www.apache.org/info/verification.html
> This last step is beyond the scope of this story.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
