Binaries exceed GitHub's 100MB git push limit so they cannot be stored
in the gh-pages branch. Two changes to fix this:
- release.yml: stop copying binaries/minisig to gh-pages; write
buckit.sha256sum files with the release tag embedded in the filename
field (e.g. 'buckit.RELEASE.xxx') so the Go code can construct the
versioned GitHub Releases URL.
- update.go / admin-handlers.go: getBinaryURL now constructs a
github.com/releases/download URL when the checksum source is github.io
and the sha256sum filename contains a release tag. Fixes two dead-code
bugs in both admin handlers where 'if updateURL == ""' was always
false after updateURL had already been set.
fix(api): Don't send responses twice.
In some cases multiple responses are being sent for one request, causing
the API server to incorrectly drop connections.
This change introduces a ResponseWriter which tracks whether a
response has already been sent. This is used to prevent a response being
sent if something already has (e.g. by a preconditions check function).
Fixes#21633.
Co-authored-by: Menno Finlay-Smits <hello@menno.io>
This fixes a security issue where sub-policy attached to a service
account or STS account is not properly validated under certain "own"
account operations (like creating new service accounts). This allowed a
service account to create new service accounts for the same user
bypassing the inline policy restriction.
fix: use correct dummy ARN for claim-based OIDC provider
When listing OIDC access keys, use the correct ARN when looking up the provider configuration for the claim-based provider. Without this it was impossible to list access keys for a claim-based provider, only for a role-policy-based provider.
Fixesminio/minio#21548
`go run golang.org/x/tools/gopls/internal/analysis/modernize/cmd/modernize@latest -fix -test ./...` executed.
`go generate ./...` ran afterwards to keep generated.
RoleARN is a required parameter in AssumeRoleWithWebIdentity,
according to the standard AWS implementation, and the official
AWS SDKs and CLI will not allow you to assume a role from a JWT
without also specifying a RoleARN. This meant that it was not
possible to use the official SDKs for claim-based OIDC with Minio
(minio/minio#21421), since Minio required you to _omit_ the RoleARN in this case.
minio/minio#21468 attempted to fix this by disabling the validation
of the RoleARN when a claim-based provider was configured, but this had
the side effect of making it impossible to have a mixture of claim-based
and role-based OIDC providers configured at the same time - every
authentication would be treated as claim-based, ignoring the RoleARN entirely.
This is an alternative fix, whereby:
- _if_ the `RoleARN` is one that Minio knows about, then use the associated role policy
- if the `RoleARN` is not recognised, but there is a claim-based provider configured, then ignore the role ARN and attempt authentication with the claim-based provider
- if the `RoleARN` is not recognised, and there is _no_ claim-based provider, then return an error.
abuckit