[#726] feat(doc): Add document on how to sign and verify releases

[justinmclean]

What changes were proposed in this pull request?

Add documentation on how to sign and verify a release.

Why are the changes needed?

Signed releases are more trusted and a requirement for passing several security checks.

Fix: #726

Does this PR introduce any user-facing change?

No

How was this patch tested?

Tested shell commands on existing 0.2 release.

[justinmclean]

Once this is merged I'll sign and update the 0.2 release.

[github-actions]

Code Coverage Report

Overall Project	67.25%	🟢

There is no coverage information present for the Files changed

[jerryshao]

AFAIK, we don't need step 2-4 to sign a release binary, our gradle assembleDistribution will automatically generate a sha256 file corresponding to the release binary.

[justinmclean]

A hash is not a signature. Hashes can be used to verify the release contents, but a signature can be used to verify release authenticity and contents.

[justinmclean]

The assembleDistribution only produces a ".tar.gz", we have both a "zip" and a ".tar.gz" in GitHub, and both will need hashes and signatures. Any reason why sha256 rather than sha512 was selected?

[xunliu]

The assembleDistribution only produces a ".tar.gz", we have both a "zip" and a ".tar.gz" in GitHub, and both will need hashes and signatures.

If desired, we can support the generation of both tar.gz and .zip files with a few code changes in the build.gradle.kts script.

Any reason why sha256 rather than sha512 was selected?

There is no particular reason to choose sha256, we can change it to sha512 if needed

[jerryshao]

@xunliu , please take a review, thanks.

[xunliu]

The sha256 code generated by this command is the same as gravitino-0.3.0-SNAPSHOT-bin.tar.gz.sha256

shasum -a 512 <filename>.[zip|tar.gz] > <filename>.[zip|tar.gz].sha512
shasum -a 256 gravitino-0.3.0-SNAPSHOT-bin.tar.gz

Could we use the gradle signing plugin to perform this step?
Just like the Publish Gravitino related jar and documentation to OSSRH #543 method?

[justinmclean]

I can change to using sha256, but you didn't seem to answer why sha256 was chosen on sha512. I also think you may also be confusing GitHub releases with Gradle distributions.

[justinmclean]

I'll also updated https://github.com/datastrato/gravitino/releases/tag/v0.2.0

[justinmclean]

I also created a video https://youtu.be/P4F5oe6hIxA showing the process.

[jerryshao]

I can change to using sha256, but you didn't seem to answer why sha256 was chosen on sha512. I also think you may also be confusing GitHub releases with Gradle distributions.

@xunliu please reply this.

[xunliu]

The sha256 code generated by this command is the same as gravitino-0.3.0-SNAPSHOT-bin.tar.gz.sha256

shasum -a 512 <filename>.[zip|tar.gz] > <filename>.[zip|tar.gz].sha512
shasum -a 256 gravitino-0.3.0-SNAPSHOT-bin.tar.gz

Could we use the gradle signing plugin to perform this step? Just like the Publish Gravitino related jar and documentation to OSSRH #543 method?

My only question is whether it is possible to automate the steps in this PR via a gradle script.
If following the open source rules requires manually going through and following the documentation, I have no problem with that. :-)

[jerryshao]

We can unify with sha512, @justinmclean can you please update the related gradle scripts?

[xunliu]

Additionally, Github Action IT execution fails because docker is bound to a fixed port docker run -P 50070:50070, I use new docker container testing method to fixed this issue in the #711, So we can re-run Github Action temporarily ignore it.

[justinmclean]

So I looked at modifying build.gradle.kts to produce both the zip and tar.gz, and sign and generate hashes and while it is certainly possible it's a bit more involved than I first thought. The signing requires user setup. I think it would be best to make automating this a separate issue as it is not a high priority in the short term.