[
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 ID 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.
Steps (2) and (3) may require additions to our release process. TBD if we
already have a checksums file (2). I don't think we have a signature (3) over
that file.
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.
(see _Validating Authenticity of a Key_ here:
https://www.apache.org/info/verification.html) This last step is beyond the
scope of this story. Ostensibly, the Geode community would ensure the validity
of the public key ID in the Dockerfile in the release branches of the public
Git repo.
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 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.
> 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 ID 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.
> Steps (2) and (3) may require additions to our release process. TBD if we
> already have a checksums file (2). I don't think we have a signature (3) over
> that file.
> 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.
> (see _Validating Authenticity of a Key_ here:
> https://www.apache.org/info/verification.html) This last step is beyond the
> scope of this story. Ostensibly, the Geode community would ensure the
> validity of the public key ID in the Dockerfile in the release branches of
> the public Git repo.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
