You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Bill Burcham (Jira)" <ji...@apache.org> on 2020/07/10 16:19:00 UTC

[jira] [Updated] (GEODE-8353) Replace Product SHA with Release Manager's Public Key in Dockerfile for Official Docker Image

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