[ 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)