[
https://issues.apache.org/jira/browse/GEODE-8353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-8353:
--------------------------------
Description:
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 product distribution (signed by release manager)
2. download product checksums (ditto)
3. verify signatures on 1, 2 against public key hard-coded in {{Dockerfile}}
4. verify that locally-computed product checksums match downloaded ones
5. validate authenticity of hard-coded public key per:
https://www.apache.org/info/verification.html
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.
was:
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 product distribution (signed by release manager)
2. download product checksums (ditto)
3. verify signatures on 1, 2 against public key hard-coded in {{Dockerfile}}
4. validate authenticity of hard-coded public key per:
https://www.apache.org/info/verification.html
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.
> Replace Product SHA with Release Manager's Public Key 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 product distribution (signed by release manager)
> 2. download product checksums (ditto)
> 3. verify signatures on 1, 2 against public key hard-coded in {{Dockerfile}}
> 4. verify that locally-computed product checksums match downloaded ones
> 5. validate authenticity of hard-coded public key per:
> https://www.apache.org/info/verification.html
> 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
