FiloSottile / age

A simple, modern and secure encryption tool (and Go library) with small explicit keys, no config options, and UNIX-style composability.
https://age-encryption.org
BSD 3-Clause "New" or "Revised" License
15.95k stars 482 forks source link

refactor: move from io/ioutil to io and os packages #353

Closed Juneezee closed 2 years ago

Juneezee commented 2 years ago

The io/ioutil package has been deprecated in Go 1.16 (See https://golang.org/doc/go1.16#ioutil). Since age has been upgraded to Go 1.17 in 36b0a4f6117c9ee7210207a69de2eab36b650869, this PR replaces the existing io/ioutil functions with their new definitions in io and os packages.

mikecook commented 2 years ago

Rerun build step, it appears Filo fixed the Github secret for osslsigncode certkey pass that failed this build.

Juneezee commented 2 years ago

Rerun build step, it appears Filo fixed the Github secret for osslsigncode certkey pass that failed this build.

@mikecook The build step is still failing. I don't think it has been fixed yet.

mikecook commented 2 years ago

Whoops, his last build that passed wasn't using his windows build commit. 11 days ago the build passed for Filo with windows in the build https://github.com/FiloSottile/age/runs/4446552982?check_suite_focus=true#step:4:72 I'm not sure what's going on.

@FiloSottile 's windows build step broke it here https://github.com/FiloSottile/age/commit/3bd9ab8e9bc4d0925f9b0b4ff8b75f26d382b5a0#diff-5c3fa597431eda03ac3339ae6bf7f05e1a50d6fc7333679ec38e21b337cb6721R40

@FiloSottile can you check secrets.SIGN_PASS is correct?

mikecook commented 2 years ago

Workflows that use environments are tricky around secrets because of the potential for secret leakage

For a private repo you can enable this setting: Send secrets to workflows from fork pull requests. https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/

But for a public repo the secrets aren't shared: https://docs.github.com/en/actions/learn-github-actions/events-that-trigger-workflows#pull-request-events-for-forked-repositories With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository.

https://docs.github.com/en/actions/security-guides/encrypted-secrets#about-encrypted-secrets For secrets stored at the environment level, you can enable required reviewers to control access to the secrets. A workflow job cannot access environment secrets until approval is granted by required approvers.

https://docs.github.com/en/actions/managing-workflow-runs/reviewing-deployments To approve the job, click Approve and deploy. Once a job is approved (and any other environment protection rules have passed), the job will proceed. At this point, the job can access any secrets stored in the environment.

Options: 1) Move secrets.SIGN_PASS from the environment level to the repository level (BAD: could leak exe signing key pass) 2) Set Required Reviewers and have Reviewer run the job which would allow job access to secrets (Extra work for Reviewers) 3) Leave the building for Releases by removing https://github.com/FiloSottile/age/blob/main/.github/workflows/build.yml#L6 (and unless the github builds are used for testing, probably also remove the on.push above on.pull_request.) 4) Split build and exe signing into separate workflow steps to allow builds for forked PRs.

mikecook commented 2 years ago

rebase on main and it should work now

Juneezee commented 2 years ago

@mikecook Great, the build step now passes.

FiloSottile commented 2 years ago

The version in the go.mod is not really the minimum supported version, but I don't feel the need to support versions of Go that are out of security support, so we can count on Go 1.16+.