Add a workflow to release a tarball including all submodules

[jgru]

Dear Simson,

this PR provides a GitHub workflow that creates a tarball including all submodules. The workflow is configured to be triggered manually from the default branch, as described here.

Maybe this is of interest since it could ease distributing new versions of bulk_extractor.

Best regards, jgru

[codecov[bot]]

Codecov Report

Merging #367 (68f8eb3) into main (8bc9a91) will not change coverage. The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #367   +/-   ##
=======================================
  Coverage   47.69%   47.69%           
=======================================
  Files         112      112           
  Lines       13451    13451           
=======================================
  Hits         6415     6415           
  Misses       7036     7036           

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

[simsong]

@jgru — are you okay with the security issue with the github action?

[jgru]

@jgru — are you okay with the security issue with the github action?

The third party action uses the GitHub API. The secrets.GITHUB_TOKEN can only be accessed by the repo admin and organization owner respectively. It is pushed into the runner instance. Overally, I think its fine.

Thank you for merging.

[simsong]

@jgru — are you okay with the security issue with the github action?

The third party action uses the GitHub API. The secrets.GITHUB_TOKEN can only be accessed by the repo admin and organization owner respectively. It is pushed into the runner instance. Overally, I think its fine.

Yes, but the secrets.GITHUB_TOKEN has significant permissions. By default it can do a ton of things, including overwriting code, removing permissions, accepting pull-requests, creating and deleting issues, etc. So it basically gives the author of the action full control over the repo while the action is running.

Can you look at the permissions key and suggest which one of the actions are required? I think that default could be changed to read and only one of the properties needs to be set to write, but I'm not sure which it is.

[jgru]

@jgru — are you okay with the security issue with the github action?

The third party action uses the GitHub API. The secrets.GITHUB_TOKEN can only be accessed by the repo admin and organization owner respectively. It is pushed into the runner instance. Overally, I think its fine.

Yes, but the secrets.GITHUB_TOKEN has significant permissions. By default it can do a ton of things, including overwriting code, removing permissions, accepting pull-requests, creating and deleting issues, etc. So it basically gives the author of the action full control over the repo while the action is running.

Can you look at the permissions key and suggest which one of the actions are required? I think that default could be changed to read and only one of the properties needs to be set to write, but I'm not sure which it is.

I see, I thought that you are concerned about the third party action as such. It is definitely a good idea to restrict the permissions. I searched the documentation for the needed permissions and drafted PR #372 to address this issue (tracked as #371).

[simsong]

Thank you so much for doing this!

[jgru]

Thank you so much for doing this!

I'm very happy that I could help!